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/
