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>;tag=rFp8vK6FN17Bj
To: <sip:[email protected]>
Call-ID: 62b9c0f2-be62-1230-4aa1-005056a433a6
CSeq: 37288972 INVITE
Contact: <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]>;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] <mailto:[email protected]>>
wrote:
Is this an update unmanaged gateway or sip trunk?
On Dec 11, 2012 3:08 PM, "Josh Patten" <[email protected]
<mailto:[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] <mailto:[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 <tel:%2B16107413324>
(PSTN CALLER) to 7175463006 <tel:7175463006> (Auto
Attendant)
2. call is transferred to extension 212, which is set to
perform call forwarding (at the same time) to
7174680293 <tel: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 <tel:978-296-1005%20X2050>
M.979-574-5699 <tel:979-574-5699>
http://www.ezuce.com
--
Josh Patten
eZuce
Solutions Architect
O.978-296-1005 X2050 <tel:978-296-1005%20X2050>
M.979-574-5699 <tel:979-574-5699>
http://www.ezuce.com
_______________________________________________
sipx-dev mailing list
[email protected] <mailto:[email protected]>
List Archive: http://list.sipfoundry.org/archive/sipx-dev/
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426 <tel:434.984.8426>
sip: [email protected]
<mailto:[email protected]>
Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-dev mailing list
[email protected] <mailto:[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/
