[prev in list] [next in list] [prev in thread] [next in thread]
List: sr-users
Subject: [Users] x-lite and nat_uac_test(16)
From: klaus.mailinglists () pernau ! at (Klaus Darilion)
Date: 2007-05-21 17:54:05
Message-ID: 4651DCBD.2090002 () pernau ! at
[Download RAW message or body]
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
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic