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