Is this an update unmanaged gateway or sip trunk? On Dec 11, 2012 3:08 PM, "Josh Patten" <jpat...@ezuce.com> 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 <jpat...@ezuce.com> 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 > sipx-dev@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > -- LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-dev mailing list sipx-dev@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-dev/
