[Freeswitch-users] Bypass media succeeds from extension to gateway but fails from extension to extension
Phil Quesinberry
philq at qsystemsengineering.com
Fri May 11 22:41:24 MSD 2012
Ken,
Thanks for taking the time to write that out. I understand that and that
makes perfect sense, although the endpoints in this case are configured to
report their external IP addresses, either through STUN or a static NAT IP
entry. What still is unclear to me is why this failed when FS was able to
successfully bridge the same extension directly to the PSTN gateway.
As for my skill level before I continue - I’ve got years and years of
advanced networking experience but I’ve only been running FS for a few
months and I still have a lot to learn, so please forgive me if I’m still
missing the point. I feel like I’m really starting to make sense of it all
now though, which probably only serves to make me a danger to myself and
others. I don’t want to waste your time with dumb questions, but I get the
impression that there aren’t that many people out there with the level of
understanding to be able to answer questions like this who are actually
willing to do so. I REALLY appreciate your time, I want to be sure that I
fully understand this.
The situation here, endpoint A is a local extension on the same LAN as FS:
Endpoint A (192.168.1.4) -> FS (192.168.1.6) -> NAT A -> Internet ->
NAT B -> Endpoint B (10.0.0.x/24) Endpoint B’s WAN address is
71.179.xx.xx
>From the traffic I pastebinned, we can see that Endpoint A is sending its
external WAN address info to FS, right before FS sends Endpoint A’s internal
LAN address to Endpoint B, so I would think that FS should be passing
Endpoint A’s WAN address along instead of its LAN address for media:
recv 722 bytes from udp/[192.168.1.4]:5060 at 14:03:20.015051:
------------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP
71.179.xx.xx;rport=5060;branch=z9hG4bKgKQKBycpSp0XD;received=192.168.1.6
From: <sip:225 at 192.168.1.6:5060;user=phone>;tag=6F6tm8F5v3D5j
To: "Phil" <sip:102 at 192.168.1.6:5060>;tag=fce60a24bc
Call-ID: cabfc783414db5c6
CSeq: 27863635 UPDATE
Contact: "Phil"
<sip:102 at 192.168.1.4:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0
000-1000-8000-00085D296BF3>"
Server: Aastra 9480i/3.2.2.2044
Session-Expires: 120;refresher=uas
Supported: path, timer
Content-Type: application/sdp
Content-Length: 178
v=0
o=MxSIP 0 2 IN IP4 192.168.1.4
s=SIP Call
c=IN IP4 71.179.xx.xx
t=0 0
m=audio 16384 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
------------------------------------------------------------------------
2012-05-07 10:03:20.011485 [DEBUG] switch_core_session.c:900 Send signal
sofia/internal/102 at 192.168.1.6:5060 [BREAK]
2012-05-07 10:03:20.011485 [DEBUG] switch_core_session.c:900 Send signal
sofia/internal/102 at 192.168.1.6:5060 [BREAK]
2012-05-07 10:03:20.011485 [DEBUG] switch_core_session.c:900 Send signal
sofia/internal/102 at 192.168.1.6:5060 [BREAK]
2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:754 Send signal
sofia/internal/sip:225 at 74.93.xx.xx:1067 [BREAK]
2012-05-07 10:03:20.039490 [DEBUG] sofia.c:5628 Channel
sofia/internal/102 at 192.168.1.6:5060 entering state [ready][200]
2012-05-07 10:03:20.039490 [DEBUG] sofia.c:5639 Remote SDP:
v=0
o=MxSIP 0 2 IN IP4 192.168.1.4
s=SIP Call
c=IN IP4 71.179.xx.xx
t=0 0
m=audio 16384 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=silenceSupp:off - - - -
a=ptime:20
send 1103 bytes to udp/[74.93.xx.xx]:1067 at 14:03:20.052233:
------------------------------------------------------------------------
INVITE sip:225 at 74.93.xx.xx:1067;transport=udp SIP/2.0
Via: SIP/2.0/UDP 71.179.xx.xx;rport;branch=z9hG4bKHvgcDSXSpZpgS
Max-Forwards: 69
From: "Phil" <sip:102 at 192.168.1.6>;tag=7rZKp308Sc4Qe
To: <sip:225 at 74.93.xx.xx:1067;transport=udp>;tag=1672444754
Call-ID: 3682faf7-12f0-1230-4bae-feffffffffff
CSeq: 27863631 INVITE
Contact: <sip:mod_sofia at 71.179.xx.xx:5060>
User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-883dd29 2012-05-06
11-27-00 +0000
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO,
REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Require: timer
Supported: timer, precondition, path, replaces
Session-Expires: 120;refresher=uas
Min-SE: 120
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 217
X-FS-Support: update_display,send_info
Remote-Party-ID: "Phil"
<sip:102 at 192.168.1.6>;party=calling;screen=yes;privacy=off
v=0
o=FreeSWITCH 1336379701 1336379703 IN IP4 71.179.xx.xx
s=FreeSWITCH
c=IN IP4 192.168.1.4 WRONG!
t=0 0
m=audio 1638 RTP/AVP 0 8 98 3
a=rtpmap:98 iLBC/8000
a=fmtp:98 mode=30
a=silenceSupp:off - - - -
a=ptime:20
------------------------------------------------------------------------
2012-05-07 10:03:20.039490 [DEBUG] sofia_glue.c:4817 Our existing sdp is
still good [PCMU 71.179.xx.xx:16384], let's keep it.
2012-05-07 10:03:20.039490 [DEBUG] sofia_glue.c:5043 No 2833 in SDP.
Disable 2833 dtmf and switch to INFO
2012-05-07 10:03:20.039490 [DEBUG] sofia.c:6212 Processing updated SDP
2012-05-07 10:03:20.039490 [DEBUG] sofia_glue.c:3214 Audio params are
unchanged for sofia/internal/102 at 192.168.1.6:5060.
2012-05-07 10:03:20.039490 [DEBUG] sofia_glue.c:3224
sofia/internal/102 at 192.168.1.6:5060 Setting audio receive payload in
Re-INVITE to 0
2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:754 Send signal
sofia/internal/102 at 192.168.1.6:5060 [BREAK]
2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:900 Send signal
sofia/internal/sip:225 at 74.93.xx.xx:1067 [BREAK]
2012-05-07 10:03:20.039490 [DEBUG] switch_ivr_bridge.c:1146
(sofia/internal/102 at 192.168.1.6:5060) State Change CS_EXECUTE ->
CS_HIBERNATE
2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:1205 Send signal
sofia/internal/102 at 192.168.1.6:5060 [BREAK]
2012-05-07 10:03:20.039490 [DEBUG] switch_ivr_bridge.c:1147
(sofia/internal/sip:225 at 74.93.xx.xx:1067) State Change CS_PARK ->
CS_HIBERNATE
2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:1205 Send signal
sofia/internal/sip:225 at 74.93.xx.xx:1067 [BREAK]
2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:816 Send signal
sofia/internal/sip:225 at 74.93.xx.xx:1067 [BREAK]
2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:816 Send signal
sofia/internal/102 at 192.168.1.6:5060 [BREAK]
2012-05-07 10:03:20.053837 [DEBUG] sofia.c:5628 Channel
sofia/internal/sip:225 at 74.93.xx.xx:1067 entering state [calling][0]
2012-05-07 10:03:20.053837 [DEBUG] mod_sofia.c:2191 Not sending same id
again "Phil" <102>
send 1006 bytes to udp/[192.168.1.4]:5060 at 14:03:20.054056:
------------------------------------------------------------------------
INVITE sip:102 at 192.168.1.4:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 71.179.xx.xx;rport;branch=z9hG4bKj594emeXK8c3m
Max-Forwards: 70
From: <sip:225 at 192.168.1.6:5060;user=phone>;tag=6F6tm8F5v3D5j
To: "Phil" <sip:102 at 192.168.1.6:5060>;tag=fce60a24bc
Call-ID: cabfc783414db5c6
CSeq: 27863636 INVITE
Contact: <sip:225 at 71.179.xx.xx:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-883dd29 2012-05-06
11-27-00 +0000
2012-05-07 10:03:20.053837 [DEBUG] switch_core_state_machine.c:426
(sofia/internal/sip:225 at 74.93.xx.xx:1067) State PARK going to sleep
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO,
REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Require: timer
Supported: timer, precondition, path, replaces
2012-05-07 10:03:20.053837 [DEBUG] switch_core_state_machine.c:362
(sofia/internal/sip:225 at 74.93.xx.xx:1067) Running State Change CS_HIBERNATE
Session-Expires: 120;refresher=uas
Min-SE: 120
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 218
X-FS-Support: update_display,send_info
v=0
o=FreeSWITCH 1336377747 1336377749 IN IP4 192.168.1.6
s=FreeSWITCH
c=IN IP4 74.93.xx.xx
t=0 0
m=audio 51720 RTP/AVP 0 8 98 3
a=rtpmap:98 iLBC/8000
a=fmtp:98 mode=30
a=silenceSupp:off - - - -
a=ptime:20
------------------------------------------------------------------------
Call fails with no audio.
Now, if I try to make a call from that same endpoint to the PSTN in bypass
media mode, FS sends the endpoint’s WAN address like I would expect it to,
and the call works... see below. I'm getting rid of a bunch of ACKs and
such for brevity and clarity but the transaction goes like this:
Endpoint A sends its invite, complete with WAN address info:
------------------------------------------------------------------------
recv 1279 bytes from udp/[192.168.1.4]:5060 at 18:00:37.133916:
------------------------------------------------------------------------
INVITE sip:94109693xxx at 192.168.1.6:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.1.4;branch=z9hG4bK69b9ae7c0bd9ac684;rport
Route: <sip:192.168.1.6:5060;lr>
Proxy-Authorization: Digest
username="102",realm="192.168.1.6",nonce="ecd26c6e-c2d9-4669-b842-
232e99abb7a2",uri="sip:94109693xxx at 192.168.1.6:5060;user=phone",response="6e
2edf5ebde2d6eaae7dd46e73cf5f88",algorithm=MD5,qop=auth,cnonce="6defb5b4",nc=
00000001
Max-Forwards: 70
From: "Phil" <sip:102 at 192.168.1.6:5060>;tag=6de7cac307
To: <sip:94109693xxx at 192.168.1.6:5060;user=phone>
Call-ID: 8d9c7aa8f30bc1d3
CSeq: 30988 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK,
SUBSCRIBE, INFO
Allow-Events: talk, hold, conference, LocalModeStatus
Contact: "Phil"
<sip:102 at 192.168.1.4:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0
000-1000-8000-00085D296BF3>"
Min-SE: 120
Session-Expires: 120
Supported: path, 100rel, replaces, timer
User-Agent: Aastra 9480i/3.2.2.2044
Content-Type: application/sdp
Content-Length: 255
v=0
o=MxSIP 0 1 IN IP4 192.168.1.4
s=SIP Call
c=IN IP4 71.179.xx.xx
t=0 0
m=audio 16384 RTP/AVP 0 110 8 9
a=rtpmap:0 PCMU/8000
a=rtpmap:110 PCMU/16000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
Now FS sends the invite to the gateway, complete with proper info:
send 1163 bytes to udp/[199.96.248.140]:5060 at 18:00:37.171788:
------------------------------------------------------------------------
INVITE sip:14109693xxx at 199.96.248.140 SIP/2.0
Via: SIP/2.0/UDP 71.179.xx.xx:5080;rport;branch=z9hG4bKK20cSjr649cta
Max-Forwards: 69
From: "QSystems" <sip:14109698xxx at 71.179.xx.xx>;tag=m2Djgjet89Ztj
To: <sip:14109693xxx at 199.96.248.140>
Call-ID: 0db1020c-1636-1230-a98d-feffffffffff
CSeq: 28043554 INVITE
Contact:
<sip:gw+Alcazar_US at 71.179.xx.xx:5080;transport=udp;gw=Alcazar_US>
User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-883dd29 2012-05-06
11-27-00 +0000
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO,
REGISTER, REFER, NOTIFY
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 279
X-accountcode: 102
X-FS-Support: update_display,send_info
Remote-Party-ID: "QSystems"
<sip:14109698xxx at 71.179.xx.xx>;party=calling;screen=yes;privacy=off
v=0
o=MxSIP 3719756330637231183 2523006830856012877 IN IP4 192.168.1.4
s=SIP Call
c=IN IP4 71.179.xx.xx
t=0 0
m=audio 16384 RTP/AVP 0 110 8 9
a=rtpmap:0 PCMU/8000
a=rtpmap:110 PCMU/16000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=silenceSupp:off - - - -
a=ptime:20
------------------------------------------------------------------------
In the meantime, FS receives and passes along 180 - Ringing
PSTN destination answers the call, gateway comes back with upstream
provider's media address:
------------------------------------------------------------------------
recv 886 bytes from udp/[199.96.248.140]:5060 at 18:00:43.320321:
------------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 71.179.xx.xx:5080;rport=5080;branch=z9hG4bKK20cSjr649cta
Record-Route: <sip:199.96.248.140;lr=on>
From: "QSystems" <sip:14109698xxx at 71.179.xx.xx>;tag=m2Djgjet89Ztj
To: <sip:14109693xxx at 199.96.248.140>;tag=m3p9c1NF8UDyQ
Call-ID: 0db1020c-1636-1230-a98d-feffffffffff
CSeq: 28043554 INVITE
Contact: <sip:14109693xxx at 10.1.50.23:5004;transport=udp>
User-Agent: AlcazarSBC 1.10
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, NOTIFY
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 193
X-FS-Support: update_display,send_info
v=0
o=FreeSWITCH 1336742245 1336742246 IN IP4 208.103.143.3
s=FreeSWITCH
c=IN IP4 208.103.143.3
t=0 0
m=audio 16998 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=silenceSupp:off - - - -
a=ptime:20
------------------------------------------------------------------------
FS passes upstream info to Endpoint A, and then sends an update (for the
display, I think):
send 1045 bytes to udp/[192.168.1.4]:5060 at 18:00:43.330695:
------------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.4;branch=z9hG4bK69b9ae7c0bd9ac684;rport=5060
From: "Phil" <sip:102 at 192.168.1.6:5060>;tag=6de7cac307
To: <sip:94109693xxx at 192.168.1.6:5060;user=phone>;tag=0BaHerZS08taQ
Call-ID: 8d9c7aa8f30bc1d3
CSeq: 30988 INVITE
Contact: <sip:94109693xxx at 71.179.xx.xx:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-883dd29 2012-05-06
11-27-00 +0000
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO,
REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Require: timer
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla,
include-session-description, presence.winfo, message-summary, refer
Session-Expires: 120;refresher=uac
Min-SE: 120
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 193
v=0
o=FreeSWITCH 1336742245 1336742246 IN IP4 208.103.143.3
s=FreeSWITCH
c=IN IP4 208.103.143.3
t=0 0
m=audio 16998 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=silenceSupp:off - - - -
a=ptime:20
------------------------------------------------------------------------
2012-05-11 14:00:27.083254 [DEBUG] switch_core_session.c:900 Send signal
sofia/internal/102 at 192.168.1.6:5060 [BREAK]
send 973 bytes to udp/[192.168.1.4]:5060 at 18:00:43.331578:
------------------------------------------------------------------------
UPDATE sip:102 at 192.168.1.4:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 71.179.xx.xx;rport;branch=z9hG4bKN3ej0NXFj8ayj
Max-Forwards: 70
From: <sip:94109693xxx at 192.168.1.6:5060;user=phone>;tag=0BaHerZS08taQ
To: "Phil" <sip:102 at 192.168.1.6:5060>;tag=6de7cac307
Call-ID: 8d9c7aa8f30bc1d3
CSeq: 28043557 UPDATE
Contact: <sip:94109693xxx at 71.179.xx.xx:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-883dd29 2012-05-06
11-27-00 +0000
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO,
REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Min-SE: 120
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 193
P-Asserted-Identity: "Outbound Call" <sip:14109693xxx at 192.168.1.6>
v=0
o=FreeSWITCH 1336742245 1336742246 IN IP4 208.103.143.3
s=FreeSWITCH
c=IN IP4 208.103.143.3
t=0 0
m=audio 16998 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=silenceSupp:off - - - -
a=ptime:20
------------------------------------------------------------------------
Call completes normally, and everything works. Help me to understand why FS
can't do the same thing for extension to extension calls.
Thanks again,
- Phil
----------
Ken Rice
Thu May 10 19:08:53 MSD 2012
The contact IP has nothing to do with where the media goes... That¹s
entirely defined in the SDP...
Consider this Endpoint A (192.168.100.100) -> NAT A -> FreeSWITCH
(4.2.2.2) -> NAT B -> Endpoint B (192.168.100.200)
Now lets assume that NAT A and NAT B are 2 separate nat gateways and that
Endpoint A and Endpoint B are on 2 different physical LANs... Telling
Endpoint A to talk directly to Endpoint B without proxying media will never
work since the endpoints think they are on the same LAN. There is no
mechanism there to allow for the redirection and automagic adjustments of
ports etc so that they can talk directly to each other...
Now lets change this slightly so that endpoint B is 192.168.200.200. Unless
NAT A knows how to get to 192.168.200.0/24 (assuming class C sized block)
and NAT B knows how to get to 192.168.100.0/24 they are both going to use
their default routing which is to NAT the outgoing RTP, and forward it to
the next hop...
Again, RTP will not make it to other side in either direction... FreeSWITCH
cant compensate due to a number of factors... Your Endpoints have to be
smart enough to actually compensate for the NAT in this situation OR your
NAT boxes have to compensate for it...
The simple answer, don¹t use bypass media in this situation, the complex
answer I wont get into here... Stop by IRC and ask around...
There is a 3rd option here you might want to consider, contact
consulting at freeswitch.org
<http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> for some
professional help... This may not be
specifially what you need to get going as I have no clue what your skill
level happens to be, and you did say you are still learning.
Good Luck!
Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users
mailing list