Audio issues with asterisk 13 - asterisk

I have two extensions registered to asterisk (asterisk has a real IP), both of them behind NAT, and every one of them belong to a different LAN network.
The SIP work just fine (i.e: the extensions can call each other), but there is no voice at all.
I configure natting and media in sip.conf in asterisk as follow:
nat=force_rtp,comedia
directrtpsetup=yes
Note: when i put the extensions in the same NAT, there is no problem, both SIP and RTP work just fine.
does anybody knows what is the problem or how to solve it?
thanks in advance.

Asterisk 1.8: The 'nat' option has now been been changed to have yes,
no, force_rport, and comedia as valid values. Setting it to yes forces
RFC 3581 behavior and enables symmetric RTP support. Setting it to no
only enables RFC 3581 behavior if the remote side requests it and
disables symmetric RTP support. Setting it to force_rport forces RFC
3581 behavior and disables symmetric RTP support. Setting it to
comedia enables RFC 3581 behavior if the remote side requests it and
enables symmetric RTP support.
force_rtp is not valid option. Force_rport,comedia are mutially exclusive options.
Directrtpsetup most likly will not work if both clients NATed.

thanks, idescovered the problem and its solution.
first of all, the wright NAT options are:
nat=force_rport,comedia
second, the wright media option is:
directmedia=no
my problem was related to opened port, in rtp.conf i put:
rtpstart=1111
rtpend=2222
but in the server the range of the opened port is {44444 --> 55555}
and because of that there wasn't voice between the callee and the caller.

Related

Why do I need Direct Media in Asterisk

I have a question, Why do I need to enable the Direct media in Asterisk?
Is it just to improve performance ? Hardware Problems ? Or what exactly?
Why shouldn't I let the Asterisk control the connections between clients?
Can you please inform about this feature and why it is important
Let say you are large provider and have 1000 calls.
If you do it directly, you have 1000*64=64Mbits+ of rtp traffic. If you have 2 servers in line you have that 3x time more on your switches etc etc
In same time you are connected to larger provider, who can do all NAT and RTP job for you.
So you can do just SIP packets without RTP.
From other point of view, not all types of NAT support directrtpsetup and directmedia. For thoose clients you may want proxy rtp.

I don't using canreinvite option in asterisk

I want to develop VoIP using asterisk.
Communications between DeviceA and DeviceB are good.
SIP, RTP and most of protocols are go through the Asterisk server.
I hope that go through the server only sip protocol is.
So, I was changing canreinvite option (from no to yes).
But, there is nothing changed.
How to use canreinvite option?
1) it have be set on ALL side of call
2) it have be SAME codec supported on both side
3) very likly after reinvite you never get result or lenght of that call.
First, canreinvite (directmedia) should be turned on for both peers engaged in a call.
Second, some application overrides canreinvite. Most famous is MixMonitor.

Freeswitch codec G729

I'm working with freeswitch and I made the connection between my server and another one, for hearing each other I used the codec G729. The issue is the next: I call them, the call is established and I can hear the other part perfectly but they can't hear me and they can see the audio packets coming to their server but they can't hear me, any idea? Thanks!
I'd start by looking at the firewall on the remote machine. libpcap will allow you to see all packets hitting the box before the firewall rules are applied, so it can be a little deceptive. So there's a good chance that the firewall is blocking the packets.
Also, you didn't specify what the other user is connecting to their server with, and how. So if they're connecting to their server from behind NAT, then you could just be experiencing the typical one-way audio issues so common with NAT scenarios. Check out http://wiki.freeswitch.org/wiki/Nat for more info.
This issue doesn't seem to be directly related to the g.729 codec or you'd have most likely gotten a 488 SIP response.
It's possible that the person on the other end isn't able to decode the the G729 stream.
What kind of phone are they using?
I would google that phone model and try a known supported codec for it.
Then I would setup your Freeswitch to encode for that codec.
If that works then it's likely an issue with the phone.
Hope this helps.

Asterisk + NAT. Either get called or be called

My Asterisk set up is as follows:
- I have 2 grandstream GXP 2000 phones connected to my router
- My small linux server (with asterisk) is connected to the router as well
I have a dynamic ip from my isp provider, but I signed up for DynDNS
When I started I could call people and talk to them. If people rang me, the phone would ring, and I could hear them speak. They could not hear me. I found out this was because of the directmedia / canreinvite setting. So I set this to:
canreinvite=no
directmedia=no
Now, people could call me and I could answer. However, due to this change I can call people, but as soon as they answer, I can't hear them, I only hear static. When I remove the two lines I add, everything is back as it was before.
What could be the issue ? The 5060 port is forwarded to my server ,as well as the 1000 - 2000 udp rang.
Regards,
Digits
First of all, you should probably read the sip.conf.sample file delivered with Asterisk. Specifically, read the NAT SUPPORT section. canreinvite and directmedia (which are the same setting by the way) attempt to set up the RTP streams directly between the UAs involved in a call, bypassing Asterisk. Thus, while that setting is affected by NAT, it does not necessarily control the channel driver behavior with respect to NAT - so its not surprising you're still having issues.
Without knowing whether or not the UAs in question are sending rport, its difficult to know for sure what your settings should be. That being said, based on your problem description, you may want to set the 'nat' parameter in your [general] section to either:
nat = force_rport,comedia
; or, depending your version
nat = yes
Note that you can set nat on a peer by peer basis, but that's discouraged for security reasons.
Additionally, you may also need to explore the extern* settings, such as externhost.
Ok, some information for other people in the same situation:
- check your codecs, make sure you get no errors in the Asterisk CLI (command line interface). I got errors, but it worked, so I didn't care. That was a mistake
- upgrade to asterisk 1.8
- set directmedia = no
- it's upd range 10000 to 20000 (I missed a 0).
This all fixed this problem.

Programmatically determine the Router NAT type

I need to programmatically determine the Router NAT type in my program. I did look at some of the STUN related answers and UPnP related information on SO. But did not get any definitive answers.
I looked at STUN RFC (rfc 5389) and it does not specify how to determine the NAT type. It does mention that it's previous version (RFC 3489) did provide the mechanism to determine NAT type. But also mentions that
Furthermore. classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there.
Given above, could you please advice on how I should go ahead with determination of router NAT type in my software. Further, now that RFC 3489 is obsoleted is there any other means?
Thanks in advance.
RFC 3489 was split into three different RFCs:
RFC 5389 - basic STUN protocol. Basic protocol of STUN binding request and binding response are largely the same as RFC 3489. The protocol header gets updated with a magic cookie occupying some of the transaction id field. Some STUN attributes get redefined. A few new ones added (specifically - XOR_MAPPED_ADDRESS). Some changes to how STUN auth is done. NAT behavior and classification discussion moved to RFC 5780.
RFC 5780 - "Nat Behavior discovery using STUN". The basic change to NAT type discovery was to distinguish NAT port mapping behavior separate from NAT filtering behavior. Whereas RFC 3489 would try to classify a NAT into one of several buckets ("cone", "port restricted", "symmetric") - which was just too generic to describe a NAT.
RFC 5769 - Just outlines what the hex dump of a few different STUN message types would look like.
Out of curiosity, I suppose knowing if your app is running behind a NAT is useful. But how would knowing the NAT's behavior influence your code path?
Shameless plug - Use my STUN Server code that is hosted on GitHub.

Resources