I think it would be agreed it has a way to go. Other SBC's can be problematic, so can some ITSP's.
It would be good to see a use case and sample for the wiki once the config stabilizes and things are tested. I don't have hairpinned issues with some SBC's or some ITSP's.it would be good to know what itsp the sangoma has been tested against and how things like MOH work or whether it has its onw (or any at all), On Wed, Dec 12, 2012 at 12:09 PM, Josh Patten <[email protected]> wrote: > Sangoma uses FreeSWITCH under the hood. > > FreeSWITCH still has an issue with hairpinned forking that needs to be > addressed. What happens is that when a 183 with SDP comes in from the > outside system (such as when calling a cell phone) the media stream is > established. When the 200 OK with SDP comes from a device other than what > generated the 183, the media stream will still attempt to go to the device > that issued the 183 until the stream is referred somewhere else, such as by > placing the call on hold and retrieving it again. > > > On Wed, Dec 12, 2012 at 10:36 AM, Tony Graziano < > [email protected]> wrote: > >> 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].**net<[email protected]> >> >> Helpdesk Customers: >> http://myhelp.myitdepartment.**net<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/ > -- ~~~~~~~~~~~~~~~~~~ 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/
