Please forgive my newbie question here. I have set-up and Asterisk server and it seems to perform fine however sometimes the audio of the call routes through Asterisk and sometimes it goes straight to the other party.
So, for example if I call someone, as soon as I am connected the network activity light for the server stops flashing and the ATA network activity light continues. I’m guessing the RTP data is going straight to the other party. This is fine.
However, sometimes I call the same person, and once the call it connected, network activity lights on both server and ATA flash like mad throughout the entire call. When this happens the speech is all jumbled up. I’m guessing the RTP data is going to the server and being forwarded on.
Both the Asterisk server and the ATA share the same router but they both have external IP addresses so there is no NAT.
Now I’ll never be doing anything particularily clever with the server, so I would like to prevent the server from routing these RTP packets (if at all possible) to prevent the problem.
Is this possible or am I barking up the wrong tree (so to speak)?
Many thanks.
Chris.
I have been looking at this more closely today, and added nat=no and canreinvite=yes.
The quality of the call is better in that the audio is now only interrupted when the server is under heavy load (the machine Asterisk server is on also provides postfix, apache, DNS, file sharing etc).
The trouble is that when I make SIP calls through Voxalot the audio traffic goes straight out to the other party (good quality).
When I make calls to the Sipgate SIP>PSTN gateway, the audio is still going through my Asterisk server (poor quality). I’d like the audio to travel in the same way that it does for SIP calls.
Does anyone have any pointers for me?
Many thanks.
Chris
if you’ve set the peer with canreinvite=yes and you’re not negating this with your Dial() options, monitoring or codec preferences, then if the peer accepts or issues a reinvite the audio should go the way you want.
if you’re not getting that setup, perhaps an email to SipGate’s tech support would help ? you’ll need to capture a sip debug to show the reinvites being issued/ignored.
Thank you baconbuttie, for your reply. Sorry if my questions are obvious I’m still really learning.
I have have a look at the ‘sip debug’ and I could not see any reinvites at all. So I restricted codecs to just alaw and ulaw on Asterisk and my ATA. Interestingly enough, I see this in my debug:
Found RTP audio format 8
Found RTP audio format 0
Peer audio RTP is at port 217.10.69.7:18294
Found description format PCMA
Found description format PCMU
Capabilities: us - 0xc (ulaw|alaw), peer - audio=0xc (ulaw|alaw)/video=0x0 (nothing), combined - 0xc (ulaw|alaw)
Non-codec capabilities: us - 0x1 (g723), peer - 0x0 (nothing), combined - 0x0 (nothing)
– SIP/3858082-f7d2 is making progress passing it to SIP/201-8bba
We’re at 87.127.182.194 port 16426
Answering with preferred capability 0x4 (ulaw)
Answering with preferred capability 0x8 (alaw)
Answering with non-codec capability 0x1 (telephone-event)
Now I might be getting this all mixed up, but this to me says that both us and peer support ulaw and alaw yet the last line states that no codec compatibility can be found.
I am interested to know: Why ulaw is shown as 0x4 above when it is shown as format 0 in the invite message and also what 0x1 (telephone-event) is.
It seems that Asterisk sees that there are no compatible codecs between the two devices and provides some kind of conversion?
Once again I appreciate any help on this.
Many thanks.
Chris