Hi!
I've noticed that (at least on my boxes) x-lite uses a different source-port for the sip-connection than the one that is announced in the Via-header. (See the example below.)
This behavior results in nat_uac_test(16) always reporting that the client is behind a NAT.
Can anyone confirm this behavior? Is it a bug in X-Lite or is there any good reason for it?
Cheers, --leo
-------------------- 8< -------------------- No. Time Source Destination Protocol Info 4 0.000808 137.208.90.164 137.208.89.45 SIP Request: REGISTER sip:wu-wien.ac.at
Frame 4 (640 bytes on wire, 640 bytes captured) Ethernet II, Src: DellEsgP_85:83:ea (00:0b:db:85:83:ea), Dst: Cisco_f3:2e:80 (00:0d:29:f3:2e:80) Internet Protocol, Src: 137.208.90.164 (137.208.90.164), Dst: 137.208.89.45 (137.208.89.45) Transmission Control Protocol, Src Port: 1831 (1831), Dst Port: 5060 (5060), Seq: 1, Ack: 1, Len: 586 Source port: 1831 (1831) Destination port: 5060 (5060) Sequence number: 1 (relative sequence number) [Next sequence number: 587 (relative sequence number)] Acknowledgement number: 1 (relative ack number) Header length: 20 bytes Flags: 0x18 (PSH, ACK) Window size: 1028096 (scaled) Checksum: 0x491e [correct] Session Initiation Protocol Request-Line: REGISTER sip:wu-wien.ac.at SIP/2.0 Message Header Via: SIP/2.0/TCP 137.208.90.164:1676;branch=z9hG4bK-d87543-bd24cf102007467f-1--d87543-;rport Max-Forwards: 70 Contact: sip:30001@137.208.90.164:1676;rinstance=7ce462f932219953;transport=TCP To: "Alexander Bergolth"sip:30001@wu-wien.ac.at From: "Alexander Bergolth"sip:30001@wu-wien.ac.at;tag=b904b134 Call-ID: N2VjNGQxYzZlOWNiYWU5OTMwNzQ4OTZkMWU3NmRkYTE. CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite release 1006e stamp 34025 Content-Length: 0 -------------------- 8< --------------------
Hi Alex
Am using fix_nated_sdp("11") and fix_nayed_uac(16");
its workking fine ...... in All cases of NAT sections
On 5/18/07, Alexander Bergolth leo@strike.wu-wien.ac.at wrote:
Hi!
I've noticed that (at least on my boxes) x-lite uses a different source-port for the sip-connection than the one that is announced in the Via-header. (See the example below.)
This behavior results in nat_uac_test(16) always reporting that the client is behind a NAT.
Can anyone confirm this behavior? Is it a bug in X-Lite or is there any good reason for it?
Cheers, --leo
-------------------- 8< -------------------- No. Time Source Destination Protocol Info 4 0.000808 137.208.90.164 137.208.89.45 SIP Request: REGISTER sip:wu-wien.ac.at
Frame 4 (640 bytes on wire, 640 bytes captured) Ethernet II, Src: DellEsgP_85:83:ea (00:0b:db:85:83:ea), Dst: Cisco_f3:2e:80 (00:0d:29:f3:2e:80) Internet Protocol, Src: 137.208.90.164 (137.208.90.164), Dst: 137.208.89.45 (137.208.89.45) Transmission Control Protocol, Src Port: 1831 (1831), Dst Port: 5060 (5060), Seq: 1, Ack: 1, Len: 586 Source port: 1831 (1831) Destination port: 5060 (5060) Sequence number: 1 (relative sequence number) [Next sequence number: 587 (relative sequence number)] Acknowledgement number: 1 (relative ack number) Header length: 20 bytes Flags: 0x18 (PSH, ACK) Window size: 1028096 (scaled) Checksum: 0x491e [correct] Session Initiation Protocol Request-Line: REGISTER sip:wu-wien.ac.at SIP/2.0 Message Header Via: SIP/2.0/TCP 137.208.90.164:1676 ;branch=z9hG4bK-d87543-bd24cf102007467f-1--d87543-;rport Max-Forwards: 70 Contact: sip:30001@137.208.90.164:1676;rinstance=7ce462f932219953;transport=TCP To: "Alexander Bergolth"sip:30001@wu-wien.ac.at From: "Alexander Bergolth"sip:30001@wu-wien.ac.at;tag=b904b134 Call-ID: N2VjNGQxYzZlOWNiYWU5OTMwNzQ4OTZkMWU3NmRkYTE. CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite release 1006e stamp 34025 Content-Length: 0 -------------------- 8< --------------------
-- e-mail ::: Alexander.Bergolth (at) wu-wien.ac.at fax ::: +43-1-31336-906050 location ::: Computer Center | Vienna University of Economics | Austria
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Alexander,
I've noticed that (at least on my boxes) x-lite uses a different source-port for the sip-connection than the one that is announced in the Via-header. (See the example below.)
Are you sure there isn't any NAT or ALG in between? By default, x-lite binds to local port 5060, but you've some non-standard ports in there. So my guess is either a non-standard port setting in x-lite and NAT, or a faulty ALG on the NAT device.
Here's a trace using x-lite 2.0 r1105d (Linux):
U 192.168.123.129:5060 -> <public IP>:5060 REGISTER sip:<some domain> SIP/2.0. Via: SIP/2.0/UDP 192.168.123.129:5060;rport;branch=z9hG4<snip>
Cheers, Andreas
On 05/18/2007 05:21 PM, Andreas Granig wrote:
Alexander,
I've noticed that (at least on my boxes) x-lite uses a different source-port for the sip-connection than the one that is announced in the Via-header. (See the example below.)
Are you sure there isn't any NAT or ALG in between? By default, x-lite binds to local port 5060, but you've some non-standard ports in there. So my guess is either a non-standard port setting in x-lite and NAT, or a faulty ALG on the NAT device.
Here's a trace using x-lite 2.0 r1105d (Linux):
U 192.168.123.129:5060 -> <public IP>:5060 REGISTER sip:<some domain> SIP/2.0. Via: SIP/2.0/UDP 192.168.123.129:5060;rport;branch=z9hG4<snip>
I did some further tests using X-Lite for Windows with interesting results:
TCP enabled:
- X-Lite binds to a source-port different from 5060 although 5060 is available according to netstat.
- the port that shows up in the Via-header is different from the source-port that is used for the TCP-connection
only UDP enabled on the server:
- X-Lite binds to a source-port different from 5060 although 5060 is available according to netstat.
- the port that shows up in the Via-header is the correct source-port
- if there is a TCP-SRV record in DNS, it tries TCP first, falls back to UDP after 19 seconds but uses "Via: SIP/2.0/TCP" instead of "Via: SIP/2.0/UDP"
I'll file a bug-report, let's see what happens...
Cheers, --leo
Hi,
Can you provide a full trace of the complete X-Lite startup sequence from the host where X-Lite is running? Maybe there's some STUN stuff going on prior to the registration (don't know exactly how this works, but it'll show up in the trace).
Cheers, Andreas
Alexander Bergolth wrote:
On 05/18/2007 05:21 PM, Andreas Granig wrote:
Alexander,
I've noticed that (at least on my boxes) x-lite uses a different source-port for the sip-connection than the one that is announced in the Via-header. (See the example below.)
Are you sure there isn't any NAT or ALG in between? By default, x-lite binds to local port 5060, but you've some non-standard ports in there. So my guess is either a non-standard port setting in x-lite and NAT, or a faulty ALG on the NAT device.
Here's a trace using x-lite 2.0 r1105d (Linux):
U 192.168.123.129:5060 -> <public IP>:5060 REGISTER sip:<some domain> SIP/2.0. Via: SIP/2.0/UDP 192.168.123.129:5060;rport;branch=z9hG4<snip>
I did some further tests using X-Lite for Windows with interesting results:
TCP enabled:
- X-Lite binds to a source-port different from 5060 although 5060 is
available according to netstat.
- the port that shows up in the Via-header is different from the
source-port that is used for the TCP-connection
only UDP enabled on the server:
- X-Lite binds to a source-port different from 5060 although 5060 is
available according to netstat.
the port that shows up in the Via-header is the correct source-port
if there is a TCP-SRV record in DNS, it tries TCP first, falls back to
UDP after 19 seconds but uses "Via: SIP/2.0/TCP" instead of "Via: SIP/2.0/UDP"
I'll file a bug-report, let's see what happens...
Cheers, --leo
On 05/21/2007 03:15 PM, Andreas Granig wrote:
Can you provide a full trace of the complete X-Lite startup sequence from the host where X-Lite is running? Maybe there's some STUN stuff going on prior to the registration (don't know exactly how this works, but it'll show up in the trace).
Stun-stuff is turned off and doesn't show up in the trace. An x-lite trace and the corresponding wireshark output is available at
http://leo.kloburg.at/tmp/x-lite/
The source-port used by the tcp-connection is 2752, the Via-header states 21744.
Cheers, --leo
Alexander Bergolth wrote:
On 05/18/2007 05:21 PM, Andreas Granig wrote:
Alexander,
I've noticed that (at least on my boxes) x-lite uses a different source-port for the sip-connection than the one that is announced in the Via-header. (See the example below.)
Are you sure there isn't any NAT or ALG in between? By default, x-lite binds to local port 5060, but you've some non-standard ports in there. So my guess is either a non-standard port setting in x-lite and NAT, or a faulty ALG on the NAT device.
Here's a trace using x-lite 2.0 r1105d (Linux):
U 192.168.123.129:5060 -> <public IP>:5060 REGISTER sip:<some domain> SIP/2.0. Via: SIP/2.0/UDP 192.168.123.129:5060;rport;branch=z9hG4<snip>
I did some further tests using X-Lite for Windows with interesting results:
TCP enabled:
- X-Lite binds to a source-port different from 5060 although 5060 is
available according to netstat.
- the port that shows up in the Via-header is different from the
source-port that is used for the TCP-connection
only UDP enabled on the server:
- X-Lite binds to a source-port different from 5060 although 5060 is
available according to netstat.
the port that shows up in the Via-header is the correct source-port
if there is a TCP-SRV record in DNS, it tries TCP first, falls back to
UDP after 19 seconds but uses "Via: SIP/2.0/TCP" instead of "Via: SIP/2.0/UDP"
I'll file a bug-report, let's see what happens...
Cheers, --leo
Hi!
For SIP capture please use "ngrep -W byline port 5060" which is much more readable. (or post the .cap file to open it in wireshark)
IIRC xlite/eyebeam always puts the local socket into the Via header. But this should be no problem as rport parameter is used. Further, the Contact: header will be the public socket (learned by rport/received from Viaheader of 200 Ok).
Thus, xlite does SIP NAT traversal for TCP itself.
regards klaus
Alexander Bergolth wrote:
On 05/21/2007 03:15 PM, Andreas Granig wrote:
Can you provide a full trace of the complete X-Lite startup sequence from the host where X-Lite is running? Maybe there's some STUN stuff going on prior to the registration (don't know exactly how this works, but it'll show up in the trace).
Stun-stuff is turned off and doesn't show up in the trace. An x-lite trace and the corresponding wireshark output is available at
http://leo.kloburg.at/tmp/x-lite/
The source-port used by the tcp-connection is 2752, the Via-header states 21744.
Cheers, --leo
Alexander Bergolth wrote:
On 05/18/2007 05:21 PM, Andreas Granig wrote:
Alexander,
I've noticed that (at least on my boxes) x-lite uses a different source-port for the sip-connection than the one that is announced in the Via-header. (See the example below.)
Are you sure there isn't any NAT or ALG in between? By default, x-lite binds to local port 5060, but you've some non-standard ports in there. So my guess is either a non-standard port setting in x-lite and NAT, or a faulty ALG on the NAT device.
Here's a trace using x-lite 2.0 r1105d (Linux):
U 192.168.123.129:5060 -> <public IP>:5060 REGISTER sip:<some domain> SIP/2.0. Via: SIP/2.0/UDP 192.168.123.129:5060;rport;branch=z9hG4<snip>
I did some further tests using X-Lite for Windows with interesting results:
TCP enabled:
- X-Lite binds to a source-port different from 5060 although 5060 is
available according to netstat.
- the port that shows up in the Via-header is different from the
source-port that is used for the TCP-connection
only UDP enabled on the server:
- X-Lite binds to a source-port different from 5060 although 5060 is
available according to netstat.
the port that shows up in the Via-header is the correct source-port
if there is a TCP-SRV record in DNS, it tries TCP first, falls back to
UDP after 19 seconds but uses "Via: SIP/2.0/TCP" instead of "Via: SIP/2.0/UDP"
I'll file a bug-report, let's see what happens...
Cheers, --leo
Hi!
On 05/21/2007 04:30 PM, Klaus Darilion wrote:
For SIP capture please use "ngrep -W byline port 5060" which is much more readable. (or post the .cap file to open it in wireshark)
OK. Didn't know that ngrep is also available for Windows. The pcap file is now available at http://leo.kloburg.at/tmp/x-lite/.
IIRC xlite/eyebeam always puts the local socket into the Via header.
What do you mean by "local socket"? TDImon shows that xlite binds (listens) to the port that is announced by the Via header but it doesn't send any packet from that port.
But this should be no problem as rport parameter is used.
Yes, xlite adds an rport parameter but the wrong port number nevertheless confuses nat_uac_test(16). openser thinks that NAT mapping is involved and always activates rtpproxy although maybe the client has full internet connectivity.
Of course I could disable nat_uac_test(16) and only use nat_uac_test(3) but I don't think that this is the intended behavior.
Further, the Contact: header will be the public socket (learned by rport/received from Viaheader of 200 Ok).
The Contact header sent by the server in the OK-message contains three port numbers:
- 6276 which I couldn't find in any packet before (?) - 21744, the "wrong" port number which is also found in the initial Via-header - 2752 (the correct source port) in the received parameter
-------------------- 8< -------------------- Contact: sip:30001@137.208.90.164:6276;rinstance=b834d8b3a5111f02;transport=TCP;expires=150, sip:30001@137.208.90.164:21744;rinstance=8f61071c78d28a71;transport=TCP;expires=3600;received="sip:137.208.90.164:2752;transport=TCP" -------------------- 8< --------------------
Cheers, --leo
Thus, xlite does SIP NAT traversal for TCP itself.
regards klaus
Alexander Bergolth wrote:
On 05/21/2007 03:15 PM, Andreas Granig wrote:
Can you provide a full trace of the complete X-Lite startup sequence from the host where X-Lite is running? Maybe there's some STUN stuff going on prior to the registration (don't know exactly how this works, but it'll show up in the trace).
Stun-stuff is turned off and doesn't show up in the trace. An x-lite trace and the corresponding wireshark output is available at
http://leo.kloburg.at/tmp/x-lite/
The source-port used by the tcp-connection is 2752, the Via-header states 21744.
Cheers, --leo
Alexander Bergolth wrote:
On 05/18/2007 05:21 PM, Andreas Granig wrote:
Alexander,
I've noticed that (at least on my boxes) x-lite uses a different source-port for the sip-connection than the one that is announced in the Via-header. (See the example below.)
Are you sure there isn't any NAT or ALG in between? By default, x-lite binds to local port 5060, but you've some non-standard ports in there. So my guess is either a non-standard port setting in x-lite and NAT, or a faulty ALG on the NAT device.
Here's a trace using x-lite 2.0 r1105d (Linux):
U 192.168.123.129:5060 -> <public IP>:5060 REGISTER sip:<some domain> SIP/2.0. Via: SIP/2.0/UDP 192.168.123.129:5060;rport;branch=z9hG4<snip>
I did some further tests using X-Lite for Windows with interesting results:
TCP enabled:
- X-Lite binds to a source-port different from 5060 although 5060 is
available according to netstat.
- the port that shows up in the Via-header is different from the
source-port that is used for the TCP-connection
only UDP enabled on the server:
- X-Lite binds to a source-port different from 5060 although 5060 is
available according to netstat.
the port that shows up in the Via-header is the correct source-port
if there is a TCP-SRV record in DNS, it tries TCP first, falls
back to UDP after 19 seconds but uses "Via: SIP/2.0/TCP" instead of "Via: SIP/2.0/UDP"
I'll file a bug-report, let's see what happens...
Cheers, --leo
This looks indeed strange. Are you using the newest version of xlite?
Maybe the client tries STUN too and gets this port from a STUN lookup. Is stun disabled/enabled? What are the settings on the "Topology" card (STUN, IP address, X-tunnels)?
regards klaus
Alexander Bergolth wrote:
Hi!
On 05/21/2007 04:30 PM, Klaus Darilion wrote:
For SIP capture please use "ngrep -W byline port 5060" which is much more readable. (or post the .cap file to open it in wireshark)
OK. Didn't know that ngrep is also available for Windows. The pcap file is now available at http://leo.kloburg.at/tmp/x-lite/.
IIRC xlite/eyebeam always puts the local socket into the Via header.
What do you mean by "local socket"? TDImon shows that xlite binds (listens) to the port that is announced by the Via header but it doesn't send any packet from that port.
But this should be no problem as rport parameter is used.
Yes, xlite adds an rport parameter but the wrong port number nevertheless confuses nat_uac_test(16). openser thinks that NAT mapping is involved and always activates rtpproxy although maybe the client has full internet connectivity.
Of course I could disable nat_uac_test(16) and only use nat_uac_test(3) but I don't think that this is the intended behavior.
Further, the Contact: header will be the public socket (learned by rport/received from Viaheader of 200 Ok).
The Contact header sent by the server in the OK-message contains three port numbers:
- 6276 which I couldn't find in any packet before (?)
- 21744, the "wrong" port number which is also found in the initial
Via-header
- 2752 (the correct source port) in the received parameter
-------------------- 8< -------------------- Contact: sip:30001@137.208.90.164:6276;rinstance=b834d8b3a5111f02;transport=TCP;expires=150, sip:30001@137.208.90.164:21744;rinstance=8f61071c78d28a71;transport=TCP;expires=3600;received="sip:137.208.90.164:2752;transport=TCP" -------------------- 8< --------------------
Cheers, --leo
Thus, xlite does SIP NAT traversal for TCP itself.
regards klaus
Alexander Bergolth wrote:
On 05/21/2007 03:15 PM, Andreas Granig wrote:
Can you provide a full trace of the complete X-Lite startup sequence from the host where X-Lite is running? Maybe there's some STUN stuff going on prior to the registration (don't know exactly how this works, but it'll show up in the trace).
Stun-stuff is turned off and doesn't show up in the trace. An x-lite trace and the corresponding wireshark output is available at
http://leo.kloburg.at/tmp/x-lite/
The source-port used by the tcp-connection is 2752, the Via-header states 21744.
Cheers, --leo
Alexander Bergolth wrote:
On 05/18/2007 05:21 PM, Andreas Granig wrote:
Alexander, > I've noticed that (at least on my boxes) x-lite uses a different > source-port for the sip-connection than the one that is announced in > the > Via-header. (See the example below.) Are you sure there isn't any NAT or ALG in between? By default, x-lite binds to local port 5060, but you've some non-standard ports in there. So my guess is either a non-standard port setting in x-lite and NAT, or a faulty ALG on the NAT device.
Here's a trace using x-lite 2.0 r1105d (Linux):
U 192.168.123.129:5060 -> <public IP>:5060 REGISTER sip:<some domain> SIP/2.0. Via: SIP/2.0/UDP 192.168.123.129:5060;rport;branch=z9hG4<snip>
I did some further tests using X-Lite for Windows with interesting results:
TCP enabled:
- X-Lite binds to a source-port different from 5060 although 5060 is
available according to netstat.
- the port that shows up in the Via-header is different from the
source-port that is used for the TCP-connection
only UDP enabled on the server:
- X-Lite binds to a source-port different from 5060 although 5060 is
available according to netstat.
the port that shows up in the Via-header is the correct source-port
if there is a TCP-SRV record in DNS, it tries TCP first, falls
back to UDP after 19 seconds but uses "Via: SIP/2.0/TCP" instead of "Via: SIP/2.0/UDP"
I'll file a bug-report, let's see what happens...
Cheers, --leo
On 05/21/2007 07:17 PM, Klaus Darilion wrote:
This looks indeed strange. Are you using the newest version of xlite?
I'm using X-lite 3.0, build 34025 which is the newest version available.
Maybe the client tries STUN too and gets this port from a STUN lookup. Is stun disabled/enabled? What are the settings on the "Topology" card (STUN, IP address, X-tunnels)?
Stun is disabled, see below.
Stun-stuff is turned off and doesn't show up in the trace. An x-lite trace and the corresponding wireshark output is available at
Topology settings are:
IP address: Use local IP address
STUN-Server: Discover Server
(cannot be disabled, but "Enable ICE" is disabled which should deactivate all STUN stuff)
Use XTunnels: Never
Cheers, --leo
regards klaus
Alexander Bergolth wrote:
Hi!
On 05/21/2007 04:30 PM, Klaus Darilion wrote:
For SIP capture please use "ngrep -W byline port 5060" which is much more readable. (or post the .cap file to open it in wireshark)
OK. Didn't know that ngrep is also available for Windows. The pcap file is now available at http://leo.kloburg.at/tmp/x-lite/.
IIRC xlite/eyebeam always puts the local socket into the Via header.
What do you mean by "local socket"? TDImon shows that xlite binds (listens) to the port that is announced by the Via header but it doesn't send any packet from that port.
But this should be no problem as rport parameter is used.
Yes, xlite adds an rport parameter but the wrong port number nevertheless confuses nat_uac_test(16). openser thinks that NAT mapping is involved and always activates rtpproxy although maybe the client has full internet connectivity.
Of course I could disable nat_uac_test(16) and only use nat_uac_test(3) but I don't think that this is the intended behavior.
Further, the Contact: header will be the public socket (learned by rport/received from Viaheader of 200 Ok).
The Contact header sent by the server in the OK-message contains three port numbers:
- 6276 which I couldn't find in any packet before (?)
- 21744, the "wrong" port number which is also found in the initial
Via-header
- 2752 (the correct source port) in the received parameter
-------------------- 8< -------------------- Contact: sip:30001@137.208.90.164:6276;rinstance=b834d8b3a5111f02;transport=TCP;expires=150,
sip:30001@137.208.90.164:21744;rinstance=8f61071c78d28a71;transport=TCP;expires=3600;received="sip:137.208.90.164:2752;transport=TCP"
-------------------- 8< --------------------
Cheers, --leo
Thus, xlite does SIP NAT traversal for TCP itself.
regards klaus
Alexander Bergolth wrote:
On 05/21/2007 03:15 PM, Andreas Granig wrote:
Can you provide a full trace of the complete X-Lite startup sequence from the host where X-Lite is running? Maybe there's some STUN stuff going on prior to the registration (don't know exactly how this works, but it'll show up in the trace).
Stun-stuff is turned off and doesn't show up in the trace. An x-lite trace and the corresponding wireshark output is available at
http://leo.kloburg.at/tmp/x-lite/
The source-port used by the tcp-connection is 2752, the Via-header states 21744.
Cheers, --leo
Alexander Bergolth wrote:
On 05/18/2007 05:21 PM, Andreas Granig wrote: > Alexander, >> I've noticed that (at least on my boxes) x-lite uses a different >> source-port for the sip-connection than the one that is >> announced in >> the >> Via-header. (See the example below.) > Are you sure there isn't any NAT or ALG in between? By default, > x-lite > binds to local port 5060, but you've some non-standard ports in > there. > So my guess is either a non-standard port setting in x-lite and > NAT, or > a faulty ALG on the NAT device. > > Here's a trace using x-lite 2.0 r1105d (Linux): > > U 192.168.123.129:5060 -> <public IP>:5060 > REGISTER sip:<some domain> SIP/2.0. > Via: SIP/2.0/UDP 192.168.123.129:5060;rport;branch=z9hG4<snip> I did some further tests using X-Lite for Windows with interesting results:
TCP enabled:
- X-Lite binds to a source-port different from 5060 although 5060 is
available according to netstat.
- the port that shows up in the Via-header is different from the
source-port that is used for the TCP-connection
only UDP enabled on the server:
- X-Lite binds to a source-port different from 5060 although 5060 is
available according to netstat.
the port that shows up in the Via-header is the correct source-port
if there is a TCP-SRV record in DNS, it tries TCP first, falls
back to UDP after 19 seconds but uses "Via: SIP/2.0/TCP" instead of "Via: SIP/2.0/UDP"
I'll file a bug-report, let's see what happens...
Cheers, --leo
Hi!
I can easily reproduce this behavior. Looks like xlite opens a TCP socket and thinks the assigned port is the same as it used for UDP -> bug.
regards klaus
Alexander Bergolth wrote:
On 05/21/2007 07:17 PM, Klaus Darilion wrote:
This looks indeed strange. Are you using the newest version of xlite?
I'm using X-lite 3.0, build 34025 which is the newest version available.
Maybe the client tries STUN too and gets this port from a STUN lookup. Is stun disabled/enabled? What are the settings on the "Topology" card (STUN, IP address, X-tunnels)?
Stun is disabled, see below.
Stun-stuff is turned off and doesn't show up in the trace. An x-lite trace and the corresponding wireshark output is available at
Topology settings are:
IP address: Use local IP address
STUN-Server: Discover Server
(cannot be disabled, but "Enable ICE" is disabled which should deactivate all STUN stuff)
Use XTunnels: Never
Cheers, --leo
regards klaus
Alexander Bergolth wrote:
Hi!
On 05/21/2007 04:30 PM, Klaus Darilion wrote:
For SIP capture please use "ngrep -W byline port 5060" which is much more readable. (or post the .cap file to open it in wireshark)
OK. Didn't know that ngrep is also available for Windows. The pcap file is now available at http://leo.kloburg.at/tmp/x-lite/.
IIRC xlite/eyebeam always puts the local socket into the Via header.
What do you mean by "local socket"? TDImon shows that xlite binds (listens) to the port that is announced by the Via header but it doesn't send any packet from that port.
But this should be no problem as rport parameter is used.
Yes, xlite adds an rport parameter but the wrong port number nevertheless confuses nat_uac_test(16). openser thinks that NAT mapping is involved and always activates rtpproxy although maybe the client has full internet connectivity.
Of course I could disable nat_uac_test(16) and only use nat_uac_test(3) but I don't think that this is the intended behavior.
Further, the Contact: header will be the public socket (learned by rport/received from Viaheader of 200 Ok).
The Contact header sent by the server in the OK-message contains three port numbers:
- 6276 which I couldn't find in any packet before (?)
- 21744, the "wrong" port number which is also found in the initial
Via-header
- 2752 (the correct source port) in the received parameter
-------------------- 8< -------------------- Contact: sip:30001@137.208.90.164:6276;rinstance=b834d8b3a5111f02;transport=TCP;expires=150,
sip:30001@137.208.90.164:21744;rinstance=8f61071c78d28a71;transport=TCP;expires=3600;received="sip:137.208.90.164:2752;transport=TCP"
-------------------- 8< --------------------
Cheers, --leo
Thus, xlite does SIP NAT traversal for TCP itself.
regards klaus
Alexander Bergolth wrote:
On 05/21/2007 03:15 PM, Andreas Granig wrote:
Can you provide a full trace of the complete X-Lite startup sequence from the host where X-Lite is running? Maybe there's some STUN stuff going on prior to the registration (don't know exactly how this works, but it'll show up in the trace).
Stun-stuff is turned off and doesn't show up in the trace. An x-lite trace and the corresponding wireshark output is available at
http://leo.kloburg.at/tmp/x-lite/
The source-port used by the tcp-connection is 2752, the Via-header states 21744.
Cheers, --leo
Alexander Bergolth wrote: > On 05/18/2007 05:21 PM, Andreas Granig wrote: >> Alexander, >>> I've noticed that (at least on my boxes) x-lite uses a different >>> source-port for the sip-connection than the one that is >>> announced in >>> the >>> Via-header. (See the example below.) >> Are you sure there isn't any NAT or ALG in between? By default, >> x-lite >> binds to local port 5060, but you've some non-standard ports in >> there. >> So my guess is either a non-standard port setting in x-lite and >> NAT, or >> a faulty ALG on the NAT device. >> >> Here's a trace using x-lite 2.0 r1105d (Linux): >> >> U 192.168.123.129:5060 -> <public IP>:5060 >> REGISTER sip:<some domain> SIP/2.0. >> Via: SIP/2.0/UDP 192.168.123.129:5060;rport;branch=z9hG4<snip> > I did some further tests using X-Lite for Windows with interesting > results: > > TCP enabled: > > - X-Lite binds to a source-port different from 5060 although 5060 is > available according to netstat. > > - the port that shows up in the Via-header is different from the > source-port that is used for the TCP-connection > > only UDP enabled on the server: > > - X-Lite binds to a source-port different from 5060 although 5060 is > available according to netstat. > > - the port that shows up in the Via-header is the correct source-port > > - if there is a TCP-SRV record in DNS, it tries TCP first, falls > back to > UDP after 19 seconds but uses "Via: SIP/2.0/TCP" instead of "Via: > SIP/2.0/UDP" > > I'll file a bug-report, let's see what happens... > > Cheers, > --leo
-
Alexander Bergolth -
Andreas Granig -
Andreas Granig -
Klaus Darilion -
raviprakash sunkara