21 May
2007
21 May
'07
8:17 p.m.
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
>