[Freeswitch-users] SIP and nat traversal IPv4/IPv6 issue

Discussion:

[Freeswitch-users] SIP and nat traversal IPv4/IPv6 issue

Jason White

2009-06-17 07:00:19 UTC

this is an issue which I've been discussing with Brian West on IRC and in
e-mail correspondence, which I thought I should bring to the list so that
others can look at it as well.

The configuration

My external SIP profile has its ext-sip-ip and ext-rtp-ip set to
stun:stun.freeswitch.org. This is necessary for nat traversal.

I have an internal-ipv6 profile as well, which is working, but for some reason
it's interfering with calls on the external profile (which of course is an
IPv4 profile).

The symptom is the following line in outgoing SIP messages while attempting to
establish a call to a gateway via the external profile:

o=FreeSWITCH 1245193059 1245193060 IN IP6 stun:stun.freeswitch.org

in response to which, the other side returns a 488 (invalid session
description).

I can confirm that ext-sip-ip and ext-rtp-ip are *not* set in the
internal-ipv6.xml profile, but they are said as explained above in the
external profile, where the problem lies.

This looks like a bug to me but I want to rule out misconfiguration first.

This has been tested on revision 13806.

Jason White

2009-06-17 07:36:06 UTC

Post by Jason White
The symptom is the following line in outgoing SIP messages while attempting to
o=FreeSWITCH 1245193059 1245193060 IN IP6 stun:stun.freeswitch.org

However, if I place an IPv6 call via the internal-ipv6 profile, the o= line
contains the correct IPv6 address - so this is only adversely affecting the
IPv4 external profile, it seems.

Brian West

2009-06-17 13:16:04 UTC

Right which is what you have to do... I haven't been able to reproduce
the issue... which is odd.

/b

Post by Jason White

Post by Jason White
The symptom is the following line in outgoing SIP messages while attempting to
o=FreeSWITCH 1245193059 1245193060 IN IP6 stun:stun.freeswitch.org

However, if I place an IPv6 call via the internal-ipv6 profile, the o= line
contains the correct IPv6 address - so this is only adversely
affecting the
IPv4 external profile, it seems.
_______________________________________________
Freeswitch-users mailing list
Freeswitch-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Raul Fragoso

2009-06-17 20:10:32 UTC

I can confirm the same issue, but it happens even with all the IPv6
stuff removed.
This is my sofia status:

freeswitch at internal> sofia status

Name Type Data
State
=================================================================================================
internal profile sip:mod_sofia at 10.0.13.10:5060
RUNNING (0)
imxtony.sytes.net alias internal
ALIASED
external profile sip:mod_sofia at 10.0.13.10:5080
RUNNING (0)
example.com gateway sip:joeuser at example.com
NOREG
italk2 gateway sip:6499744069 at akl.italk.co.nz
REGED
italk gateway sip:6499744074 at akl.italk.co.nz
REGED
=================================================================================================
2 profiles 1 alias

And this is the INVITE for a gateway from an internal endpoint:

freeswitch at internal> originate sofia/imxtony.sytes.net/218
&bridge(sofia/gateway/italk/6499744074)

------------------------------------------------------------------------
send 1344 bytes to udp/[203.184.16.2]:5060 at 20:01:50.190193:

------------------------------------------------------------------------
INVITE sip:6499744074 at akl.italk.co.nz SIP/2.0
Via: SIP/2.0/UDP 60.234.179.34:5080;rport;branch=z9hG4bKgypXrUy0889Np
Max-Forwards: 70
From: "FreeSWITCH"
<sip:6499744074 at akl.italk.co.nz;transport=udp>;tag=KSgjD3t33N9yp
To: <sip:6499744074 at akl.italk.co.nz>
Call-ID: 893ed581-d61c-122c-d885-00237dc8dc02
CSeq: 116516120 INVITE
Contact: <sip:gw+italk at 60.234.179.34:5080;transport=udp>
Expires: 3600
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk- at SWITCH_VERSION_REVISION@
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,
NOTIFY, REFER, UPDATE, REGISTER, INFO
Supported: timer, precondition, path, replaces
Allow-Events: talk, refer
Proxy-Authorization: Digest username="6499744074",
realm="italk.co.nz", nonce="75444262", algorithm=MD5,
uri="sip:6499744074 at akl.italk.co.nz",
response="89bb5673f48252622025641153b882de"
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 315
Remote-Party-ID: "FreeSWITCH"
<sip:0000000000 at akl.italk.co.nz>;party=calling;screen=yes;privacy=off

v=0
o=FreeSWITCH 1245252480 1245252481 IN IP6 stun:stun.freeswitch.org
s=FreeSWITCH
c=IN IP6 stun:stun.freeswitch.org
t=0 0
m=audio 16430 RTP/AVP 0 3 8 101 13
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=ptime:20

------------------------------------------------------------------------
2009-06-18 08:01:50.191067 [DEBUG] sofia.c:3210 Channel
sofia/external/6499744074 entering state [calling][0]
recv 469 bytes from udp/[203.184.16.2]:5060 at 20:01:50.252230:

------------------------------------------------------------------------
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP
60.234.179.34:5080;rport;branch=z9hG4bKgypXrUy0889Np;received=60.234.179.34
From: "FreeSWITCH"
<sip:6499744074 at akl.italk.co.nz;transport=udp>;tag=KSgjD3t33N9yp
To: <sip:6499744074 at akl.italk.co.nz>;tag=as34133b10
Call-ID: 893ed581-d61c-122c-d885-00237dc8dc02
CSeq: 116516120 INVITE
User-Agent: italk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0

------------------------------------------------------------------------
send 360 bytes to udp/[203.184.16.2]:5060 at 20:01:50.252988:

------------------------------------------------------------------------
ACK sip:6499744074 at akl.italk.co.nz SIP/2.0
Via: SIP/2.0/UDP 60.234.179.34:5080;rport;branch=z9hG4bKgypXrUy0889Np
Max-Forwards: 70
From: "FreeSWITCH"
<sip:6499744074 at akl.italk.co.nz;transport=udp>;tag=KSgjD3t33N9yp
To: <sip:6499744074 at akl.italk.co.nz>;tag=as34133b10
Call-ID: 893ed581-d61c-122c-d885-00237dc8dc02
CSeq: 116516120 ACK
Content-Length: 0

------------------------------------------------------------------------
2009-06-18 08:01:50.253252 [DEBUG] sofia.c:3210 Channel
sofia/external/6499744074 entering state [terminated][488]

That IP6 is clearly messing things up.

Regards,

Raul

Post by Jason White

Post by Jason White
The symptom is the following line in outgoing SIP messages while attempting to
o=FreeSWITCH 1245193059 1245193060 IN IP6 stun:stun.freeswitch.org

However, if I place an IPv6 call via the internal-ipv6 profile, the o= line
contains the correct IPv6 address - so this is only adversely affecting the
IPv4 external profile, it seems.
_______________________________________________
Freeswitch-users mailing list
Freeswitch-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090617/f98483e0/attachment.html

Jason White

2009-06-18 01:01:30 UTC

Post by Raul Fragoso
I can confirm the same issue, but it happens even with all the IPv6
stuff removed.

Thank you for the corroboration.

It only happens to me if I have the following in my external.xml profile:
<param name="local-network-acl" value="localnet.auto"/>

Note that I need the above line for nat traversal; if I leave it out,
FreeSWITCH uses a private IPv4 address in outgoing invites, and can't
establish a call.

Brian West

2009-06-18 04:57:03 UTC

I need in one of your boxs... there is no way this is doing this
unless you are putting stun:stun.freeswitch.org into the ext-rtp-ip or
sip ip... which could make it trigger the ipv6 check since its just
looking for : in the ip address. And stun: has that.. so you're
triggering it... tar up your entire conf folder and mail it to me ASAP.

/b

Post by Jason White

Post by Raul Fragoso
I can confirm the same issue, but it happens even with all the IPv6
stuff removed.

Thank you for the corroboration.
<param name="local-network-acl" value="localnet.auto"/>
Note that I need the above line for nat traversal; if I leave it out,
FreeSWITCH uses a private IPv4 address in outgoing invites, and can't
establish a call.
_______________________________________________
Freeswitch-users mailing list
Freeswitch-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Brian West

2009-06-18 04:57:03 UTC

I need in one of your boxs... there is no way this is doing this
unless you are putting stun:stun.freeswitch.org into the ext-rtp-ip or
sip ip... which could make it trigger the ipv6 check since its just
looking for : in the ip address. And stun: has that.. so you're
triggering it... tar up your entire conf folder and mail it to me ASAP.

/b

Post by Jason White

Post by Raul Fragoso
I can confirm the same issue, but it happens even with all the IPv6
stuff removed.

Thank you for the corroboration.
<param name="local-network-acl" value="localnet.auto"/>
Note that I need the above line for nat traversal; if I leave it out,
FreeSWITCH uses a private IPv4 address in outgoing invites, and can't
establish a call.
_______________________________________________
Freeswitch-users mailing list
Freeswitch-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Brian West

2009-06-18 05:04:16 UTC

Ok you both didn't notice you CAN NOT put stun:stun.freeswitch.org in
rtp-ip, thats the problem. It clearly says IP ADDRESSES ONLY in the
comments. DO not use $${external_rtp_ip} for rtp-ip either :P

/b

Post by Raul Fragoso
I can confirm the same issue, but it happens even with all the IPv6
stuff removed.
freeswitch at internal> sofia status
Name Type Data
State
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
======================================================================
internal profile sip:mod_sofia at 10.0.13.10:5060
RUNNING (0)
imxtony.sytes.net alias internal
ALIASED
external profile sip:mod_sofia at 10.0.13.10:5080
RUNNING (0)
example.com gateway sip:joeuser at example.com
NOREG
italk2 gateway sip:6499744069 at akl.italk.co.nz
REGED
italk gateway sip:6499744074 at akl.italk.co.nz
REGED
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
======================================================================
2 profiles 1 alias
freeswitch at internal> originate sofia/imxtony.sytes.net/218
&bridge(sofia/gateway/italk/6499744074)
------------------------------------------------------------------------
------------------------------------------------------------------------
INVITE sip:6499744074 at akl.italk.co.nz SIP/2.0
Via: SIP/2.0/UDP
60.234.179.34:5080;rport;branch=z9hG4bKgypXrUy0889Np
Max-Forwards: 70
6499744074 at akl.italk.co.nz;transport=udp>;tag=KSgjD3t33N9yp
To: <sip:6499744074 at akl.italk.co.nz>
Call-ID: 893ed581-d61c-122c-d885-00237dc8dc02
CSeq: 116516120 INVITE
Contact: <sip:gw+italk at 60.234.179.34:5080;transport=udp>
Expires: 3600
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-
@SWITCH_VERSION_REVISION@
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE,
SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO
Supported: timer, precondition, path, replaces
Allow-Events: talk, refer
Proxy-Authorization: Digest username="6499744074",
realm="italk.co.nz", nonce="75444262", algorithm=MD5, uri="sip:6499744074 at akl.italk.co.nz
", response="89bb5673f48252622025641153b882de"
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 315
0000000000 at akl.italk.co.nz>;party=calling;screen=yes;privacy=off
v=0
o=FreeSWITCH 1245252480 1245252481 IN IP6 stun:stun.freeswitch.org
s=FreeSWITCH
c=IN IP6 stun:stun.freeswitch.org
t=0 0
m=audio 16430 RTP/AVP 0 3 8 101 13
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=ptime:20
------------------------------------------------------------------------
2009-06-18 08:01:50.191067 [DEBUG] sofia.c:3210 Channel sofia/
external/6499744074 entering state [calling][0]
------------------------------------------------------------------------
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP
60.234.179.34
:5080;rport;branch=z9hG4bKgypXrUy0889Np;received=60.234.179.34
6499744074 at akl.italk.co.nz;transport=udp>;tag=KSgjD3t33N9yp
To: <sip:6499744074 at akl.italk.co.nz>;tag=as34133b10
Call-ID: 893ed581-d61c-122c-d885-00237dc8dc02
CSeq: 116516120 INVITE
User-Agent: italk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0
------------------------------------------------------------------------
------------------------------------------------------------------------
ACK sip:6499744074 at akl.italk.co.nz SIP/2.0
Via: SIP/2.0/UDP
60.234.179.34:5080;rport;branch=z9hG4bKgypXrUy0889Np
Max-Forwards: 70
6499744074 at akl.italk.co.nz;transport=udp>;tag=KSgjD3t33N9yp
To: <sip:6499744074 at akl.italk.co.nz>;tag=as34133b10
Call-ID: 893ed581-d61c-122c-d885-00237dc8dc02
CSeq: 116516120 ACK
Content-Length: 0
------------------------------------------------------------------------
2009-06-18 08:01:50.253252 [DEBUG] sofia.c:3210 Channel sofia/
external/6499744074 entering state [terminated][488]
That IP6 is clearly messing things up.
Regards,
Raul

Post by Jason White

Post by Jason White
The symptom is the following line in outgoing SIP messages while

attempting to

Post by Jason White
o=FreeSWITCH 1245193059 1245193060 IN IP6 stun:stun.freeswitch.org

However, if I place an IPv6 call via the internal-ipv6 profile, the o= line
contains the correct IPv6 address - so this is only adversely
affecting the
IPv4 external profile, it seems.
_______________________________________________
Freeswitch-users mailing list
Freeswitch-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

_______________________________________________
Freeswitch-users mailing list
Freeswitch-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090618/5b552778/attachment-0001.html

Brian West

2009-06-18 05:09:44 UTC

I no longer need your configs... I didn't try to put
stun:stun.freeswitch.org in sip-ip or rtp-ip because I know you
shouldn't. We clearly can not try to do a stun request in either of
these fields because you can't bind to IP's that aren't directly on
the machine... so do as per the config and put ONLY ip's that are
local on the machine... if you need to set the external rtp or sip ip
please set them with the ext-rtp-ip and ext-sip-ip params on the
profile. You CAN set the ext-rtp-ip and ext-sip-ip to
stun:stun.freeswitch.org and those will resolve.

/b

Post by Raul Fragoso
I can confirm the same issue, but it happens even with all the IPv6
stuff removed.

Jason White

2009-06-18 01:01:30 UTC

Post by Raul Fragoso
I can confirm the same issue, but it happens even with all the IPv6
stuff removed.

Thank you for the corroboration.

It only happens to me if I have the following in my external.xml profile:
<param name="local-network-acl" value="localnet.auto"/>

Note that I need the above line for nat traversal; if I leave it out,
FreeSWITCH uses a private IPv4 address in outgoing invites, and can't
establish a call.

Brian West

2009-06-18 05:04:16 UTC

Ok you both didn't notice you CAN NOT put stun:stun.freeswitch.org in
rtp-ip, thats the problem. It clearly says IP ADDRESSES ONLY in the
comments. DO not use $${external_rtp_ip} for rtp-ip either :P

/b

Post by Raul Fragoso
I can confirm the same issue, but it happens even with all the IPv6
stuff removed.
freeswitch at internal> sofia status
Name Type Data
State
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
======================================================================
internal profile sip:mod_sofia at 10.0.13.10:5060
RUNNING (0)
imxtony.sytes.net alias internal
ALIASED
external profile sip:mod_sofia at 10.0.13.10:5080
RUNNING (0)
example.com gateway sip:joeuser at example.com
NOREG
italk2 gateway sip:6499744069 at akl.italk.co.nz
REGED
italk gateway sip:6499744074 at akl.italk.co.nz
REGED
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
======================================================================
2 profiles 1 alias
freeswitch at internal> originate sofia/imxtony.sytes.net/218
&bridge(sofia/gateway/italk/6499744074)
------------------------------------------------------------------------
------------------------------------------------------------------------
INVITE sip:6499744074 at akl.italk.co.nz SIP/2.0
Via: SIP/2.0/UDP
60.234.179.34:5080;rport;branch=z9hG4bKgypXrUy0889Np
Max-Forwards: 70
6499744074 at akl.italk.co.nz;transport=udp>;tag=KSgjD3t33N9yp
To: <sip:6499744074 at akl.italk.co.nz>
Call-ID: 893ed581-d61c-122c-d885-00237dc8dc02
CSeq: 116516120 INVITE
Contact: <sip:gw+italk at 60.234.179.34:5080;transport=udp>
Expires: 3600
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-
@SWITCH_VERSION_REVISION@
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE,
SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO
Supported: timer, precondition, path, replaces
Allow-Events: talk, refer
Proxy-Authorization: Digest username="6499744074",
realm="italk.co.nz", nonce="75444262", algorithm=MD5, uri="sip:6499744074 at akl.italk.co.nz
", response="89bb5673f48252622025641153b882de"
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 315
0000000000 at akl.italk.co.nz>;party=calling;screen=yes;privacy=off
v=0
o=FreeSWITCH 1245252480 1245252481 IN IP6 stun:stun.freeswitch.org
s=FreeSWITCH
c=IN IP6 stun:stun.freeswitch.org
t=0 0
m=audio 16430 RTP/AVP 0 3 8 101 13
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=ptime:20
------------------------------------------------------------------------
2009-06-18 08:01:50.191067 [DEBUG] sofia.c:3210 Channel sofia/
external/6499744074 entering state [calling][0]
------------------------------------------------------------------------
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP
60.234.179.34
:5080;rport;branch=z9hG4bKgypXrUy0889Np;received=60.234.179.34
6499744074 at akl.italk.co.nz;transport=udp>;tag=KSgjD3t33N9yp
To: <sip:6499744074 at akl.italk.co.nz>;tag=as34133b10
Call-ID: 893ed581-d61c-122c-d885-00237dc8dc02
CSeq: 116516120 INVITE
User-Agent: italk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0
------------------------------------------------------------------------
------------------------------------------------------------------------
ACK sip:6499744074 at akl.italk.co.nz SIP/2.0
Via: SIP/2.0/UDP
60.234.179.34:5080;rport;branch=z9hG4bKgypXrUy0889Np
Max-Forwards: 70
6499744074 at akl.italk.co.nz;transport=udp>;tag=KSgjD3t33N9yp
To: <sip:6499744074 at akl.italk.co.nz>;tag=as34133b10
Call-ID: 893ed581-d61c-122c-d885-00237dc8dc02
CSeq: 116516120 ACK
Content-Length: 0
------------------------------------------------------------------------
2009-06-18 08:01:50.253252 [DEBUG] sofia.c:3210 Channel sofia/
external/6499744074 entering state [terminated][488]
That IP6 is clearly messing things up.
Regards,
Raul

Post by Jason White

Post by Jason White
The symptom is the following line in outgoing SIP messages while

attempting to

Post by Jason White
o=FreeSWITCH 1245193059 1245193060 IN IP6 stun:stun.freeswitch.org

However, if I place an IPv6 call via the internal-ipv6 profile, the o= line
contains the correct IPv6 address - so this is only adversely
affecting the
IPv4 external profile, it seems.
_______________________________________________
Freeswitch-users mailing list
Freeswitch-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

_______________________________________________
Freeswitch-users mailing list
Freeswitch-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090618/5b552778/attachment-0002.html

Brian West

2009-06-18 05:09:44 UTC

I no longer need your configs... I didn't try to put
stun:stun.freeswitch.org in sip-ip or rtp-ip because I know you
shouldn't. We clearly can not try to do a stun request in either of
these fields because you can't bind to IP's that aren't directly on
the machine... so do as per the config and put ONLY ip's that are
local on the machine... if you need to set the external rtp or sip ip
please set them with the ext-rtp-ip and ext-sip-ip params on the
profile. You CAN set the ext-rtp-ip and ext-sip-ip to
stun:stun.freeswitch.org and those will resolve.

/b

Post by Raul Fragoso
I can confirm the same issue, but it happens even with all the IPv6
stuff removed.

Brian West

2009-06-17 13:16:04 UTC

Right which is what you have to do... I haven't been able to reproduce
the issue... which is odd.

/b

Post by Jason White

Post by Jason White
The symptom is the following line in outgoing SIP messages while attempting to
o=FreeSWITCH 1245193059 1245193060 IN IP6 stun:stun.freeswitch.org

However, if I place an IPv6 call via the internal-ipv6 profile, the o= line
contains the correct IPv6 address - so this is only adversely
affecting the
IPv4 external profile, it seems.
_______________________________________________
Freeswitch-users mailing list
Freeswitch-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Raul Fragoso

2009-06-17 20:10:32 UTC

I can confirm the same issue, but it happens even with all the IPv6
stuff removed.
This is my sofia status:

freeswitch at internal> sofia status

Name Type Data
State
=================================================================================================
internal profile sip:mod_sofia at 10.0.13.10:5060
RUNNING (0)
imxtony.sytes.net alias internal
ALIASED
external profile sip:mod_sofia at 10.0.13.10:5080
RUNNING (0)
example.com gateway sip:joeuser at example.com
NOREG
italk2 gateway sip:6499744069 at akl.italk.co.nz
REGED
italk gateway sip:6499744074 at akl.italk.co.nz
REGED
=================================================================================================
2 profiles 1 alias

And this is the INVITE for a gateway from an internal endpoint:

freeswitch at internal> originate sofia/imxtony.sytes.net/218
&bridge(sofia/gateway/italk/6499744074)

------------------------------------------------------------------------
send 1344 bytes to udp/[203.184.16.2]:5060 at 20:01:50.190193:

------------------------------------------------------------------------
INVITE sip:6499744074 at akl.italk.co.nz SIP/2.0
Via: SIP/2.0/UDP 60.234.179.34:5080;rport;branch=z9hG4bKgypXrUy0889Np
Max-Forwards: 70
From: "FreeSWITCH"
<sip:6499744074 at akl.italk.co.nz;transport=udp>;tag=KSgjD3t33N9yp
To: <sip:6499744074 at akl.italk.co.nz>
Call-ID: 893ed581-d61c-122c-d885-00237dc8dc02
CSeq: 116516120 INVITE
Contact: <sip:gw+italk at 60.234.179.34:5080;transport=udp>
Expires: 3600
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk- at SWITCH_VERSION_REVISION@
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,
NOTIFY, REFER, UPDATE, REGISTER, INFO
Supported: timer, precondition, path, replaces
Allow-Events: talk, refer
Proxy-Authorization: Digest username="6499744074",
realm="italk.co.nz", nonce="75444262", algorithm=MD5,
uri="sip:6499744074 at akl.italk.co.nz",
response="89bb5673f48252622025641153b882de"
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 315
Remote-Party-ID: "FreeSWITCH"
<sip:0000000000 at akl.italk.co.nz>;party=calling;screen=yes;privacy=off

v=0
o=FreeSWITCH 1245252480 1245252481 IN IP6 stun:stun.freeswitch.org
s=FreeSWITCH
c=IN IP6 stun:stun.freeswitch.org
t=0 0
m=audio 16430 RTP/AVP 0 3 8 101 13
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=ptime:20

------------------------------------------------------------------------
2009-06-18 08:01:50.191067 [DEBUG] sofia.c:3210 Channel
sofia/external/6499744074 entering state [calling][0]
recv 469 bytes from udp/[203.184.16.2]:5060 at 20:01:50.252230:

------------------------------------------------------------------------
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP
60.234.179.34:5080;rport;branch=z9hG4bKgypXrUy0889Np;received=60.234.179.34
From: "FreeSWITCH"
<sip:6499744074 at akl.italk.co.nz;transport=udp>;tag=KSgjD3t33N9yp
To: <sip:6499744074 at akl.italk.co.nz>;tag=as34133b10
Call-ID: 893ed581-d61c-122c-d885-00237dc8dc02
CSeq: 116516120 INVITE
User-Agent: italk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0

------------------------------------------------------------------------
send 360 bytes to udp/[203.184.16.2]:5060 at 20:01:50.252988:

------------------------------------------------------------------------
ACK sip:6499744074 at akl.italk.co.nz SIP/2.0
Via: SIP/2.0/UDP 60.234.179.34:5080;rport;branch=z9hG4bKgypXrUy0889Np
Max-Forwards: 70
From: "FreeSWITCH"
<sip:6499744074 at akl.italk.co.nz;transport=udp>;tag=KSgjD3t33N9yp
To: <sip:6499744074 at akl.italk.co.nz>;tag=as34133b10
Call-ID: 893ed581-d61c-122c-d885-00237dc8dc02
CSeq: 116516120 ACK
Content-Length: 0

------------------------------------------------------------------------
2009-06-18 08:01:50.253252 [DEBUG] sofia.c:3210 Channel
sofia/external/6499744074 entering state [terminated][488]

That IP6 is clearly messing things up.

Regards,

Raul

Post by Jason White

Post by Jason White
The symptom is the following line in outgoing SIP messages while attempting to
o=FreeSWITCH 1245193059 1245193060 IN IP6 stun:stun.freeswitch.org

However, if I place an IPv6 call via the internal-ipv6 profile, the o= line
contains the correct IPv6 address - so this is only adversely affecting the
IPv4 external profile, it seems.
_______________________________________________
Freeswitch-users mailing list
Freeswitch-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090617/f98483e0/attachment-0002.html

Jim Burke

2009-06-17 13:14:01 UTC

IMHO, as FS is a B2BUA the new leg should state ownership in the SDP. Add to this the fact the IPV6 is blindly copied from leg 1 and the IP address was not decoded correctly there does appear to be a defficiency in the code.

- original message -
Subject: [Freeswitch-users] SIP and nat traversal IPv4/IPv6 issue
From: Jason White <jason at jasonjgw.net>
Date: 17/06/2009 07:01

this is an issue which I've been discussing with Brian West on IRC and in
e-mail correspondence, which I thought I should bring to the list so that
others can look at it as well.

The configuration

My external SIP profile has its ext-sip-ip and ext-rtp-ip set to
stun:stun.freeswitch.org. This is necessary for nat traversal.

I have an internal-ipv6 profile as well, which is working, but for some reason
it's interfering with calls on the external profile (which of course is an
IPv4 profile).

The symptom is the following line in outgoing SIP messages while attempting to
establish a call to a gateway via the external profile:

o=FreeSWITCH 1245193059 1245193060 IN IP6 stun:stun.freeswitch.org

in response to which, the other side returns a 488 (invalid session
description).

I can confirm that ext-sip-ip and ext-rtp-ip are *not* set in the
internal-ipv6.xml profile, but they are said as explained above in the
external profile, where the problem lies.

This looks like a bug to me but I want to rule out misconfiguration first.

This has been tested on revision 13806.

_______________________________________________
Freeswitch-users mailing list
Freeswitch-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Brian West

2009-06-17 13:26:13 UTC

Post by Jim Burke
IMHO, as FS is a B2BUA the new leg should state ownership in the
SDP. Add to this the fact the IPV6 is blindly copied from leg 1 and
the IP address was not decoded correctly there does appear to be a
defficiency in the code.

I don't think that is what is going on unless you're trying to do
proxy media from IPv4 to IPv6 which I haven't ever tried nor do I
recommend.

/b

Brian West

2009-06-17 13:26:13 UTC

Post by Jim Burke
IMHO, as FS is a B2BUA the new leg should state ownership in the
SDP. Add to this the fact the IPV6 is blindly copied from leg 1 and
the IP address was not decoded correctly there does appear to be a
defficiency in the code.

I don't think that is what is going on unless you're trying to do
proxy media from IPv4 to IPv6 which I haven't ever tried nor do I
recommend.

/b

Anthony Minessale

2009-06-17 13:32:42 UTC

can you confirm that they are not being inherited by some of the helper
variables exported from vars.xml?
can you minimalise your ip4 profile by cutting all the commented lines and
actually remove the ext-rtp-ip and ext-sip-ip params?
Then possibly post your config for each profile.

Post by Jason White
this is an issue which I've been discussing with Brian West on IRC and in
e-mail correspondence, which I thought I should bring to the list so that
others can look at it as well.
The configuration
My external SIP profile has its ext-sip-ip and ext-rtp-ip set to
stun:stun.freeswitch.org. This is necessary for nat traversal.
I have an internal-ipv6 profile as well, which is working, but for some reason
it's interfering with calls on the external profile (which of course is an
IPv4 profile).
The symptom is the following line in outgoing SIP messages while attempting to
o=FreeSWITCH 1245193059 1245193060 IN IP6 stun:stun.freeswitch.org
in response to which, the other side returns a 488 (invalid session
description).
I can confirm that ext-sip-ip and ext-rtp-ip are *not* set in the
internal-ipv6.xml profile, but they are said as explained above in the
external profile, where the problem lies.
This looks like a bug to me but I want to rule out misconfiguration first.
This has been tested on revision 13806.
_______________________________________________
Freeswitch-users mailing list
Freeswitch-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/

AIM: anthm
MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090617/abb0e0c2/attachment.html

Jason White

2009-06-17 07:00:19 UTC

this is an issue which I've been discussing with Brian West on IRC and in
e-mail correspondence, which I thought I should bring to the list so that
others can look at it as well.

The configuration

My external SIP profile has its ext-sip-ip and ext-rtp-ip set to
stun:stun.freeswitch.org. This is necessary for nat traversal.

I have an internal-ipv6 profile as well, which is working, but for some reason
it's interfering with calls on the external profile (which of course is an
IPv4 profile).

The symptom is the following line in outgoing SIP messages while attempting to
establish a call to a gateway via the external profile:

o=FreeSWITCH 1245193059 1245193060 IN IP6 stun:stun.freeswitch.org

in response to which, the other side returns a 488 (invalid session
description).

I can confirm that ext-sip-ip and ext-rtp-ip are *not* set in the
internal-ipv6.xml profile, but they are said as explained above in the
external profile, where the problem lies.

This looks like a bug to me but I want to rule out misconfiguration first.

This has been tested on revision 13806.

Jason White

2009-06-17 07:36:06 UTC

Post by Jason White
The symptom is the following line in outgoing SIP messages while attempting to
o=FreeSWITCH 1245193059 1245193060 IN IP6 stun:stun.freeswitch.org

However, if I place an IPv6 call via the internal-ipv6 profile, the o= line
contains the correct IPv6 address - so this is only adversely affecting the
IPv4 external profile, it seems.

Jim Burke

2009-06-17 13:14:01 UTC

IMHO, as FS is a B2BUA the new leg should state ownership in the SDP. Add to this the fact the IPV6 is blindly copied from leg 1 and the IP address was not decoded correctly there does appear to be a defficiency in the code.

- original message -
Subject: [Freeswitch-users] SIP and nat traversal IPv4/IPv6 issue
From: Jason White <jason at jasonjgw.net>
Date: 17/06/2009 07:01

this is an issue which I've been discussing with Brian West on IRC and in
e-mail correspondence, which I thought I should bring to the list so that
others can look at it as well.

The configuration

My external SIP profile has its ext-sip-ip and ext-rtp-ip set to
stun:stun.freeswitch.org. This is necessary for nat traversal.

I have an internal-ipv6 profile as well, which is working, but for some reason
it's interfering with calls on the external profile (which of course is an
IPv4 profile).

The symptom is the following line in outgoing SIP messages while attempting to
establish a call to a gateway via the external profile:

o=FreeSWITCH 1245193059 1245193060 IN IP6 stun:stun.freeswitch.org

in response to which, the other side returns a 488 (invalid session
description).

I can confirm that ext-sip-ip and ext-rtp-ip are *not* set in the
internal-ipv6.xml profile, but they are said as explained above in the
external profile, where the problem lies.

This looks like a bug to me but I want to rule out misconfiguration first.

This has been tested on revision 13806.

_______________________________________________
Freeswitch-users mailing list
Freeswitch-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Anthony Minessale

2009-06-17 13:32:42 UTC

can you confirm that they are not being inherited by some of the helper
variables exported from vars.xml?
can you minimalise your ip4 profile by cutting all the commented lines and
actually remove the ext-rtp-ip and ext-sip-ip params?
Then possibly post your config for each profile.

Post by Jason White
this is an issue which I've been discussing with Brian West on IRC and in
e-mail correspondence, which I thought I should bring to the list so that
others can look at it as well.
The configuration
My external SIP profile has its ext-sip-ip and ext-rtp-ip set to
stun:stun.freeswitch.org. This is necessary for nat traversal.
I have an internal-ipv6 profile as well, which is working, but for some reason
it's interfering with calls on the external profile (which of course is an
IPv4 profile).
The symptom is the following line in outgoing SIP messages while attempting to
o=FreeSWITCH 1245193059 1245193060 IN IP6 stun:stun.freeswitch.org
in response to which, the other side returns a 488 (invalid session
description).
I can confirm that ext-sip-ip and ext-rtp-ip are *not* set in the
internal-ipv6.xml profile, but they are said as explained above in the
external profile, where the problem lies.
This looks like a bug to me but I want to rule out misconfiguration first.
This has been tested on revision 13806.
_______________________________________________
Freeswitch-users mailing list
Freeswitch-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/

AIM: anthm
MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090617/abb0e0c2/attachment-0002.html

21 Replies
119 Views
Permalink to this page
Disable enhanced parsing

Thread Navigation

Jason White 2009-06-17 07:00:19 UTC

Jason White 2009-06-17 07:36:06 UTC

Brian West 2009-06-17 13:16:04 UTC

Raul Fragoso 2009-06-17 20:10:32 UTC

Jason White 2009-06-18 01:01:30 UTC

Brian West 2009-06-18 04:57:03 UTC

Brian West 2009-06-18 04:57:03 UTC

Brian West 2009-06-18 05:04:16 UTC

Brian West 2009-06-18 05:09:44 UTC

Jason White 2009-06-18 01:01:30 UTC

Brian West 2009-06-18 05:04:16 UTC

Brian West 2009-06-18 05:09:44 UTC

Brian West 2009-06-17 13:16:04 UTC

Raul Fragoso 2009-06-17 20:10:32 UTC

Jim Burke 2009-06-17 13:14:01 UTC

Brian West 2009-06-17 13:26:13 UTC

Brian West 2009-06-17 13:26:13 UTC

Anthony Minessale 2009-06-17 13:32:42 UTC

Jason White 2009-06-17 07:00:19 UTC

Jason White 2009-06-17 07:36:06 UTC

Jim Burke 2009-06-17 13:14:01 UTC

Anthony Minessale 2009-06-17 13:32:42 UTC

about - legalese

Loading...