True, but when the call goes from the ITSP to the SANGOMA, the SBC (sangoma) should be modifying the INVITE with the private info of the SANGOMA....ie 192.168.10.19
But its not, its sending the public ITSP packet into sipx rather than modifying it, which makes sipxproxy think its not a local SIP invite and sipxrelay jumps into action to take over. The point of the SBC is to hide the public info when sending it to the proxy and preform the header modification between the proxy and the ITSP. -M >>> Chris Rawlings <[email protected]> 12/12/12 9:11 AM >>> this is the initial invite. This is where the call is comming from the ITSP -> WAN IP 24.229.51.68 -> NAT FIREWALL -> SBC IP 192.168.10.19 (FreeSWITCH / SANGOMA) The Sangoma SBC then hands this off to the PBX later in the chain where it creates both an ITSP and PBX side of the call and bridges them. This invite needs to be NAT aware as the SBC is behind a NAT firewall.. all communications on Port 5060 inbound to 192.168.10.19 are ITSP communications. All communications on Port 5080 inbound to 192.168.10.19 are PBX communications. And then finally i was under the impression that at NO TIME will an unmanaged Gateway have a WAN IP address put into any portion of the SIP messaging On Tue, Dec 11, 2012 at 9:09 PM, Joegen Baclor <[email protected]> wrote: The root of all evil is in the INVITE. It advertised itself as NATed by providing a public contact and a public via. Why is the gateway doing this? INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 24.229.51.68:5080;rport;branch=z9hG4bKSSZZ7Ht02mHSN Max-Forwards: 11 From: "+16107413324" <sip:[email protected];transport=udp>;tag=rFp8vK6FN17Bj To: <sip:[email protected]> Call-ID: 62b9c0f2-be62-1230-4aa1-005056a433a6 CSeq: 37288972 INVITE Contact: <sip:[email protected]:5080;transport=udp;gw=blueuc.com> User-Agent: NetBorder Session Controller Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: precondition, path, replaces Allow-Events: talk, hold, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 191 X-Inbound: TRUE X-Account-Code: None X-Account-Inbound: 3587 P-Acme-VSA: 202:3587 P-Acme-VSA-1: 201:None X-Device: 24.229.51.68 X-FS-Support: update_display Remote-Party-ID: "+16107413324" <sip:[email protected]>;party=calling;screen=yes;privacy=off v=0 o=nsc 1355222135 1355222136 IN IP4 192.168.10.19 s=nsc c=IN IP4 192.168.10.19 t=0 0 m=audio 27938 RTP/AVP 0 8 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 On 12/12/2012 05:10 AM, Josh Patten wrote: Sorry I forgot to put this info. Unmanaged Gateway. On Tue, Dec 11, 2012 at 3:06 PM, Tony Graziano <[email protected]> wrote: Is this an update unmanaged gateway or sip trunk? On Dec 11, 2012 3:08 PM, "Josh Patten" <[email protected]> wrote: Holy incoherent sentences Batman! "The culprit, I believe, is sipX inserting conflicting connection information into the SDP In the INVITE, and is unnecessarily inserting the WAN address into the SDP even though the , causing the media relay to a Should read: The culprit, I believe, is sipX inserting conflicting connection information into the SDP in the INVITE and is unnecessarily inserting the public IP address of sipX into the SDP even though the gateway is in the same subnet as the sipX server, causing the media relay to attempt to send the RTP through the media relay and out over the internet to the gateway. On Tue, Dec 11, 2012 at 1:56 PM, Josh Patten <[email protected]> wrote: Chris Rawlings of Blue Cloud Consulting and myself were on the phone with Sangoma attempting to determine why hairpinned calls were resulting in no Audio, and believe we may have found an issue in the way sipX modifies the SDP (Sangoma uses FreeSWITCH). So here is the calling scenario: Call comes in from +16107413324 (PSTN CALLER) to 7175463006 (Auto Attendant) call is transferred to extension 212, which is set to perform call forwarding (at the same time) to 7174680293 (Cell Phone) If the call is answered on 212, no audio If the call is answered on cell phone, there is audio The culprit, I believe, is sipX inserting conflicting connection information into the SDP In the INVITE, and is unnecessarily inserting the WAN address into the SDP even though the , causing the media relay to attempt to send the RTP out of the WAN interface to the gateway. Here is the SDP for step 1 (generated by the gateway): v=0 o=nsc 1355222135 1355222136 IN IP4 192.168.10.19 s=nsc c=IN IP4 192.168.10.19 t=0 0 m=audio 27938 RTP/AVP 0 8 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 Here is the SDP that is generated internally by FreeSWITCH IVR and sent to the Proxy: v=0 o=FreeSWITCH 1355235729 1355235730 IN IP4 192.168.10.9 s=FreeSWITCH c=IN IP4 192.168.10.9 t=0 0 m=audio 12894 RTP/AVP 9 101 13 a=rtpmap:9 G722/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 And here is what we send back in our 200 OK to the gateway after traversing the Proxy: v=0 o=FreeSWITCH 1355235655 1355235656 IN IP4 192.168.10.9 s=FreeSWITCH c=IN IP4 192.168.10.9 t=0 0 m=audio 30496 RTP/AVP 0 101 13 c=IN IP4 24.229.51.65 <---- THIS IS THE PUBLIC IP OF SIPX a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 a=x-sipx-ntap:X192.168.10.9-24.229.51.65;14 Why is the proxy messing with the SDP like this when there is clearly no need to rewrite it for a call that the RTP is terminating on devices on the same subnet? I've attached a trace of the SDP example. -- Josh Patten eZuce Solutions Architect O.978-296-1005 X2050 M.979-574-5699 http://www.ezuce.com -- Josh Patten eZuce Solutions Architect O.978-296-1005 X2050 M.979-574-5699 http://www.ezuce.com _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/ LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/ -- Josh Patten eZuce Solutions Architect O.978-296-1005 X2050 M.979-574-5699 http://www.ezuce.com _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/ -- Thank You, Chris Rawlings BlueCloud Consultants – CEO Phone. 484-335-1444 x201 SIP URI. sip:[email protected] XMPP / Jabber / Google Talk – [email protected]
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
