I use an Asterisk box as a switch between 2 SIP trunks (one trunk to the “PSTN”, one trunk to our IP-Centrex softswitch).
It does RTP proxy too.
I am having some issues with RTP media loss on the customers connected to our IP-Centrex, so I need to make a deep analysis of some calls AFTERWARDS (because the issue we are having is random).
My issue is that on the Asterisk side, I can dig and find a call in the logs and the CDRs, but I can’t find a way to log the RTP ports of both call legs which were used for a specific call going through the Asterisk.
From a debugging perspective, it’s a nightmare.
I really need a SIP channel to RTP ports (at least the local one) mapping.
Anyone has a solution for that ?
Perhaps a debugging option I missed somewhere ?
Put “canreinvite = no” for all trunks so Asterisk always stay in the middle of the audio path. The most reliable way to debug RTP is dumping the ethernet interface (tcpdump). But to log all ethernet traffic is a nightmare.
My Asterisk is already in the middle of the audio path.
I could capture the ethernet traffic, but it doesn’t allow me to easily know which UDP ports were used for the call coming from CLID XXXXX at time T.
I guess Asterisk could (theoretically) log the UDP ports in the CDR. It’s a pity it does not for debugging purpose, and that there is no other way.
I am pretty sure our issue does not come from Asterisk (although we run 1.4.1, and I guess there are probably quite some bugs in this one), but at least, knowing the UDP port used for a specific call will help me to trace what is happening on my “Class 5” softswitch.
for the purposes of debugging, why not just run tcpdump on the machine to a pcap file. You could have a cron job run every 15 minutes to roll the file so it never gets to big.
viewing the pcap in wireshark would be very helpful, as it has some nice VoIP/SIP utilities built in. I believe you can even search for a call by the SIP callid.
yes, there most certainly is. You can do a VoIP call ananlysis and it will break down all the calls and then you can drill down into each one to analyze the SIP messaging as well as the RTP stream.