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 >>> 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].**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/
