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><sip:[email protected];transport=udp> > ;tag=rFp8vK6FN17Bj > To: <sip:[email protected]> <sip:[email protected]> > Call-ID: 62b9c0f2-be62-1230-4aa1-005056a433a6 > CSeq: 37288972 INVITE > Contact: > <sip:[email protected]:5080;transport=udp;gw=blueuc.com><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]><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 attempt to send the RTP >>> out of the WAN interface to the gateway." >>> >>> 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: >>>> >>>> 1. Call comes in from +16107413324 (PSTN CALLER) to 7175463006(Auto >>>> Attendant) >>>> 2. call is transferred to extension 212, which is set to perform >>>> call forwarding (at the same time) to 7174680293 (Cell Phone) >>>> 3. If the call is answered on 212, no audio >>>> 4. 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 <978-296-1005%20X2050> >>>> M.979-574-5699 >>>> http://www.ezuce.com >>>> >>>> >>> >>> >>> -- >>> Josh Patten >>> eZuce >>> Solutions Architect >>> O.978-296-1005 X2050 <978-296-1005%20X2050> >>> 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 [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/
