[Users] x-lite and nat_uac_test(16)

Alexander Bergolth leo at strike.wu-wien.ac.at
Mon May 21 19:25:48 CEST 2007


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:30001 at 137.208.90.164:6276;rinstance=b834d8b3a5111f02;transport=TCP>;expires=150,
>>
>> <sip:30001 at 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

-- 
e-mail   ::: Alexander.Bergolth (at) wu-wien.ac.at
fax      ::: +43-1-31336-906050
location ::: Computer Center | Vienna University of Economics | Austria





More information about the sr-users mailing list