I can confirm the same issue, but it happens even with all the IPv6
stuff removed.
This is my sofia status:
freeswi...@internal> sofia status
Name Type Data
State
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
======================================================================
internal profile sip:[email protected]:5060
RUNNING (0)
imxtony.sytes.net alias internal
ALIASED
external profile sip:[email protected]:5080
RUNNING (0)
example.com gateway sip:[email protected]
NOREG
italk2 gateway sip:[email protected]
REGED
italk gateway sip:[email protected]
REGED
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
======================================================================
2 profiles 1 alias
And this is the INVITE for a gateway from an internal endpoint:
freeswi...@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:[email protected] SIP/2.0
Via: SIP/2.0/UDP
60.234.179.34:5080;rport;branch=z9hG4bKgypXrUy0889Np
Max-Forwards: 70
From: "FreeSWITCH" <sip:
[email protected];transport=udp>;tag=KSgjD3t33N9yp
To: <sip:[email protected]>
Call-ID: 893ed581-d61c-122c-d885-00237dc8dc02
CSeq: 116516120 INVITE
Contact: <sip:[email protected]: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:[email protected]
", response="89bb5673f48252622025641153b882de"
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 315
Remote-Party-ID: "FreeSWITCH" <sip:
[email protected]>;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:
[email protected];transport=udp>;tag=KSgjD3t33N9yp
To: <sip:[email protected]>;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:[email protected] SIP/2.0
Via: SIP/2.0/UDP
60.234.179.34:5080;rport;branch=z9hG4bKgypXrUy0889Np
Max-Forwards: 70
From: "FreeSWITCH" <sip:
[email protected];transport=udp>;tag=KSgjD3t33N9yp
To: <sip:[email protected]>;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
On Wed, 2009-06-17 at 17:36 +1000, Jason White wrote:
Jason White <[email protected]> wrote:
> 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
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
[email protected]
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
[email protected]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
