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
http://leo.kloburg.at/tmp/x-lite/
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:[EMAIL
PROTECTED]:6276;rinstance=b834d8b3a5111f02;transport=TCP>;expires=150,
<sip:[EMAIL
PROTECTED]: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
_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
