I have installed 1.0.7.Beta.3 (Sunrise-Tel) on my OS X Server (Panther) No NAT. All is well for some calls but in others the audio is all jumbled up.
It would appear that sometimes audio goes straight to the other party, when this happens all is well. Sometimes the traffic goes through Asterisk and the the audio jumbles up.
I have both my SPA-2002 device and Asterisk server set-up to allow only G.711a and G.711u and I have canreinvite=yes.
I have tried to upgrade to a later version of Asterisk but under Panther there appears to be something missing. But I’m sure this problem can be resolved staying with 1.0.7.Beta.3 - I’m just not experienced enough to do alone!
I’m not using any additional arguments with the dial command and I have canreinvite set to yes. Both parties in the call support the same codecs.
When the call is connected, I can see the reINVITE happening in the SIP debug, I can also see ‘attempting native bridge’. I can’t see any errors returned from the Asterisk server the other end, or my ATA.
Any suggestion on what parts of the SIP debug are relevant to my situation. I have tried to compare a successful call to one that is jumbled but I can see the wood for the trees!
I’m confused. Your original post implied that audio routing thru the asterisk box was causing the bad audio. Setting canreinvite to no forces this to happen, but now you’re saying that makes the audio better?
With canreinvite=yes some calls RTP goes direct but those that don’t have audio that sounds like it’s been chopped into little half-a-second pieces and jumbled up.
With canreinvite=no all calls RTP goes via Asterisk and the sound on all calls is okay.
I can only assume that in the first example, the reinvite in tried but fails.
At the end of the call the Asterisk server reports (several times over) ‘Call/leg transaction does not exist’. This doesn’t happen when canreinvite=no is set.
The only difference I can find so far is that in the calls that fail there is a ‘183 Session Progress’ message.
When the audio goes through my server and I scroll the terminal window up or down the audio in the call deteriorates (a CPU load thing), when the audio goes direct, the audio is uneffected by what I do on the server screen.
I have toyed with the idea that there are possibly two audio streams coming from the other party, one through the server and one direct to the ATA but I’m not sure that this is even possible.
I considered that at the Session Progress message RTP data starts flowing from the called party to the server and at the OK that follows, the ATA receives a reinvite to setup the RTP by itself.
I have noticed that during my jumbled calls, the audio is one-way so I also considered that the RTP packets from my ATA are being transmitted in the wrong direction (ie. to the Asterisk server instead of to the other party.)
I should probably point out at this point that my setup is No-NAT and that whilst my server and ATA are on one side of the gateway, the called party is on the other.
My understanding of Asterisk is still very limited but by using Asterisk I hope to eventually get to an advanced understanding of how it all hangs together. So I am grateful for ANY advice at all.
If you see a message “Attempting native bridge” in CLI, that means Asterisk is in the path. You can also follow a call flow, then show channels during a call to see if garbled call is engaged. The above suggests that you are using X on the server? Try not to. X’s impact on CPU is unpredictable.
You may want to clarify how the called party sits on the other side of “the” gateway. What is the gateway? NAT? Or a so-called VoIP gateway? (Well, device manufacturers - marketers precisely - are not doing a good job in using these terms.)
Based on the description, I guess that with canreinvite=yes, the reason why some calls still use Asterisk in audio path is because the two sides fail to negociate a common CODEC. (This is discussed in the voip-info article, I believe.) Whereas it’s hard to explain why canreinvite=no improves quality in all calls, this is perhaps a result you can better live with.
Now this is odd, I see ‘Attempting native bridge’ on every call. When I have canreinvite=yes and a good call (the ones that I think aren’t going through Asterisk) is active I can see two channels, both with the same codec (In this case G.711a). BUT, there is no network activity light on the server’s network connection once the call is connected?!?!?!
When I sent canreinvite=no I see the network activity light throughout the whole call (predictably).
The hardware that is running Asterisk is running a few other processes, postfix, apache, CUPS etc… So that’s why I’d prefer the RTP traffic not to go through Asterisk.
When I talk about the gateway, I really mean the ISPs gateway. I have a range of IP addresses (87.127.85.x) on my side of the gateway.
I can live with canreinvite=no but I’d really lie to get to the bottom of what’s unique about the calls that fail.
[quote=“chrisips2”]Now this is odd, I see ‘Attempting native bridge’ on every call. When I have canreinvite=yes and a good call (the ones that I think aren’t going through Asterisk) is active I can see two channels, both with the same codec (In this case G.711a). BUT, there is no network activity light on the server’s network connection once the call is connected?!?!?!
[/quote]
Then the info I gave could be wrong. If you want to be sure, use a sniffer. (tcpdump will do the job.)
Thank you for your support. I am going to try upgrading to 1.0.10 using Sunrise-tel’s A4M update to see if I can put this problem to bed finally.
If anyone has any experience upgrading from Sunrise-tel’s 1.0.7 on OS X 10.3.x Panther Server I would be very happy to hear about it. Indeed if anyone feels that someone with only a basic understanding of Asterisk and OS X terminal (BSD?) could upgrade to an even more recent version I would grateful for some pointers.
I have successfully upgraded to 1.2.18 and I must say, I am VERY happy. The problem has gone away completely! All calls now reinvite correctly and RTP goes direct, rather than through Asterisk. So I am putting the problem down to a bug in 1.0.7.
However in order to make 1.2.18 startup, I set several modules to ‘noload’.
I have no idea how this will effect the performance of my new Asterisk, but if I run into trouble and can’t work it out, I’ll no doubt post a new thread.