|
pacpac
Member
2013-Jan-25 11:02 am
RTP/NAT router, how to configure PAP2T/FreePBX?Currently I have the PAP2T connected directly to the cable modem registered with my FreePBX/Asterisk VPS. This is done because I need Asterisk not to proxy the media, i.e. RTP stream directly between the endpoints. Is it possible to connected the PAP2T to a NAT router, e.g. set the PAP2T in DMZ, in order for the RTP stream to go directly? If so, how would I configure the PAP2T and FreePBX? |
|
|
|
Stewart
Member
2013-Jan-25 11:43 am
I have almost your exact setup, except have SPA3102. On the FreePBX end, the only special setting is canreinvite=yes .
On the ATA, Line 1, set NAT Mapping Enable to yes. On SIP tab, you must set STUN Enable to yes and STUN Server to a valid STUN server; I use stun.counterpath.net . You could set up your own STUN server on the VPS.
The other NAT Support Parameters are all set to no, except Substitute VIA Address=yes.
I don't have any special router settings, but have carefully chosen unique RTP port ranges for all VoIP devices, and avoid using RTP ports that are used by Windows, Mac. Linux, or other embedded devices. My SPA has RTP Port Min=3300 and RTP Port Max=3398.
If no luck, try forwarding the RTP UDP port range to the SPA. I don't recommend DMZ. If your (buggy) router insists on translating the source port number in spite of the port forwarding, then you are SOL, and will have to get another router, or limit your trunks to providers that do symmetric RTP, e.g. Callcentric. |
|
|
pacpac
Member
2013-Jan-25 1:03 pm
Hi, I tried your settings and I get the ATA to register and can make in/out calls OK. However, when I look at Asterisk CLI running RTP SET DEBUG ON, it looks to me Asterisk is proxying the media. Comments? |
|
pacpac |
pacpac
Member
2013-Jan-25 1:28 pm
Got it to work. My first try was to connect the ATA to my dual WAN RV042 and I could not get it to send/receive the RTP stream directly. However, the RV042 is behind a Linksys WRT320N, which is connected to the cable modem. I followed your settings, this time connecting the PAP2T to the WRT320N (gave the PAP2T a static LAN IP and did not need to port forward). In FreePBX I set canreinvite=yes where relevant, set Yes to NAT on each extension and in Advanced Settings. I had to add directrtpsetup=yes in Asterisk SIP Settings to get Asterisk out of the way. When I run RTP SET DEBUG ON, I note Asterisk is not proxying the media and I get in/out calls to work. I guess I need to set NAT Mapping Enable to yes on both Line 1 and 2 in PAP2T? |
|
|
to pacpac
Check that in General Settings, the Asterisk Dial command options is r or blank. Any of the other options require Asterisk to stay in the path to listen for DTMF.
Check that the codecs match, both trunk and extension have canreinvite=yes, and the extension has nat=force_rport or nat=no.
If no luck, look on the CLI (with verbosity 3) for "Remotely bridging ..." If you don't see that, track down why it's not attempting to re-invite. If you do see it, use SIP debug to see why the re-invite is being rejected by the extension or trunk. |
|
|
pacpac
Member
2013-Jan-25 3:04 pm
Ref my last post, set NAT=no on extensions and in Advanced Settings, then rebooted the VPS and power cycled the modems, routers and PAP2T. It is working just fine, Asterisk do not proxy media. I have some problems when connecting the PAP2T to the RV042. However, that is not important since I do need 2 routers between the RV042 and the cable modems in order to get the RV042 to operate properly. Thanks. |
|
2 edits |
to Stewart
said by Stewart:If no luck, look on the CLI (with verbosity 3) for "Remotely bridging ..." If you don't see that, track down why it's not attempting to re-invite. If you do see it, use SIP debug to see why the re-invite is being rejected by the extension or trunk. This is a subject that interests me quite a bit. I have been using G722 codec with Asterisk for a couple years now. It sounds great, even if it is only available between my extensions and the one other person I call with a SIP phone. Using Asterisk CLI debug on a call between extensions "1" and "2" I see: -- Called 1
-- SIP/1-0000005e is ringing
-- SIP/1-0000005e answered SIP/2-0000005d
-- Remotely bridging SIP/2-0000005d and SIP/1-0000005e
So this means Asterisk is not proxying the media? I would like to try SILK-WB codec, which Asterisk does not support. But my phones, Bria for Android, do support this codec. I had thought Asterisk support for the codec would not be needed. Am I wrong? I can not get SILK codec to work between these extensions. Edit: I see that Asterisk will not even attempt a connection between the two extensions when SILK is set as the only codec. I read somewhere there was a fix to Asterisk for this issue . . . in Asterisk 10 and 11. I guess it will be time to upgrade soon. |
|
SCADAGeo Premium Member join:2012-11-08 N California |
SCADAGeo
Premium Member
2013-Jan-27 4:57 am
said by lifespeed:Edit: I see that Asterisk will not even attempt a connection between the two extensions when SILK is set as the only codec. I read somewhere there was a fix to Asterisk for this issue . . . in Asterisk 10 and 11. I guess it will be time to upgrade soon.
Sfinxsoftware posted a link in the comments section of Skype's - The Big Blog announcement about the free SILK codec. The link used to lead to the preliminary, free SILK port for Asterisk 1.8. Unfortunately, it's no longer free... |
|
|
to Stewart
said by Stewart:If no luck, look on the CLI (with verbosity 3) for "Remotely bridging ..." If you don't see that, track down why it's not attempting to re-invite. If you do see it, use SIP debug to see why the re-invite is being rejected by the extension or trunk. When I look at the CLI (verbosity 3) and place an outgoing call (not to another extension), I do not see any reference to either "Locally bridging ..." or "Remotely bridging ..". I am on Asterisk version 10.4.0, why would I not see any refence to "bridging"? When I run RTP SET DEBUG ON I do not see any activity in CLI after the call is set up. Should that not indicate Asterisk is not proxying the media? |
|
|
Sorry, I'm still on 1.8 and don't know whether newer versions differ in this regard. You can use SIP debug in Asterisk to see what re-invites, if any, are being sent. Or, use SIP Debug on the device to see where it is sending RTP. Or, run tcpdump on the Asterisk machine -- you don't even have to look at the dump, just stop it after a few seconds and check the packet count.
If you want to be absolutely certain, rig a way to capture the ATA's traffic with Wireshark and see where RTP packets are coming from and where they are going. |
|
|
pacpac
Member
2013-Jan-28 9:18 am
I can do 'sip set debug on' at CLI and 'tcpdump -i eth0 -n -s0 -v udp port 5074' at root. How do I see a) what re-invites, if any and b) packet count?
When I do 'tcpdump -i eth0 -n -s0 -v udp port 5074' and close with ctr-C, I see this:
67 packets captured 67 packets received by filter 0 packets dropped by kernel |
|
pacpac |
pacpac
Member
2013-Jan-28 9:36 am
I believe I have identified the issue (ref one earlier discussion). When I do 'sip set debug on' and look at the c=IN IP4 ip address, I note the IP of my Asterisk box does not appear in any. I understand that Asterisk is not proxying the media, but saying to send media to the endpoint. Correct? |
|
|
Stewart
Member
2013-Jan-28 10:15 am
Sorry, I was confused. If you are doing directrtpsetup, then no re-invites are needed, because the initial invites and responses should have the audio go directly between the endpoints.
For detailed debugging, I typically do tcpdump -s 0 -w foo.cap then stop it with ctrl-C. I move the foo.cap file to my local PC with sftp and open it in Wireshark to analyze. |
|
|
pacpac
Member
2013-Jan-28 1:14 pm
I have the .cap file on Wireshark. What do I look for in order to confirm Asterisk do not proxy media? |
|
|
said by pacpac:I have the .cap file on Wireshark. What do I look for in order to confirm Asterisk do not proxy media? Among other things, if it is proxying media, the vast majority of the packets will be RTP. With directrtpsetup properly working, you won't see any. However, Wireshark does a great job of interpreting SIP and SDP, so just select one of those packets (if you are using other than port 5060, tell it to decode as SIP). You can then expand SIP, the header and/or body, and see where both endpoints have been told to send RTP. |
|
|
pacpac
Member
2013-Jan-28 10:37 pm
Thanks. No RTP packets and no acitivity on RTP SET DEBUG ON; working as intended. |
|