On 05/18/2007 05:21 PM, Andreas Granig wrote: 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

On 05/21/2007 03:15 PM, Andreas Granig wrote: 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 -- e-mail ::: Alexander.Bergolth (at) wu-wien.ac.at fax ::: +43-1-31336-906050 location ::: Computer Center | Vienna University of Economics | Austria

Hi! On 05/21/2007 04:30 PM, Klaus Darilion wrote: 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/. 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. 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. 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 -- e-mail ::: Alexander.Bergolth (at) wu-wien.ac.at fax ::: +43-1-31336-906050 location ::: Computer Center | Vienna University of Economics | Austria

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