[Users] x-lite and nat_uac_test(16)

Klaus Darilion klaus.mailinglists at pernau.at
Mon May 21 19:54:05 CEST 2007


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: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
> 




More information about the Users mailing list