Re: [Users] x-lite and nat_uac_test(16)

On 05/21/2007 07:17 PM, Klaus Darilion wrote: I'm using X-lite 3.0, build 34025 which is the newest version available. Stun is disabled, see below. 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@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). >>>> >>>> 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