Also, realize ANY SBC would be able to have its own dialplan and rules to do this.
So where is sangoma on this issue? On Wed, Dec 12, 2012 at 11:09 AM, Matt White <[email protected]>wrote: > 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><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 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/ > -- ~~~~~~~~~~~~~~~~~~ Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.465.6833 ~~~~~~~~~~~~~~~~~~ Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet Fax services! ~~~~~~~~~~~~~~~~~~ Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab 2013! <http://sipxcolab2013.eventbrite.com/?discount=tony2013> -- 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/
