Re: [Sipwitch-devel] Public sipwitch server handling calls between extensions behind router

[Steve Murphy]

Thanks for your thoughts.
I've tried those options without success.

Re: This I suspect is because eXosip gets confused where to send the ack,

This is the case when twinkle does not use stun - and the clients 
register with sipwitch using  local IP and port nums. eXosip loses the 
plot at the point the call should be established, and begins to send 
packets to the 192...(local)  network that the clients registered with.  
Thinking about this for a second, I wondered how the registration could 
complete at all if sipwitch was communicating with the 192 network. 
Packet sniffing shows that sipwitch/eXosip is smart enough to know that 
the registration request packets did not arrive from 192, and uses the 
source IP and port number in the packet headers to address replies, at 
least until the moment that the ACK should be relayed to confirm the 
call has been established, at which point it reverts to using the 192. 
address and the plot is lost.
Although eXosip goes wrong eventually, it is clear that it has all the 
information it needs to route control ( 5060) packets correctly in this 
situation.  It is effectively acting as it's own stun server, and looks 
at IP and port numbers in the header to determine the port forwarding on 
the router.
What seems clear to me now is that the information to resolve the port 
forwarding for the media connection ( normally port 8000 ) is simply not 
available to the server as it never receives any packet originating from 
a clients port 8000 - and so can't determine the forwarded port on the 
public IP network.

This is why the client must use a STUN server to determine this 
information and register using the forwarded IP and port numbers, as 
well as invite other clients to calls using the forwarded media port.

The "problem" with using a STUN server however ( in my situation - 
multiple clients on local IP ) is that the media connection for calls 
must be routed via the public forwarded ports on the router - even if 
both clients are on the private side of the router.  For this to work, 
the router must support "hairpinning" ( packets that originate on the 
local network, sent to the forwarded ports of the router, must be routed 
back to the local network ). It seems not all routers support this kind 
of functionality.  Hairpin tests are included in the STUN tests - and 
confirm that for my test setup there is no 'hairpin'.  Therefore,  I 
believe this is a "no fault found" with sipwitch / twinkle - but a fault 
in my router ( FYI:  D-LINK DSL-2641R ).

I'm curious to know if Skype copes with the situation. It is probably 
not something that most skype users try very often ( call another user 
who happens to be on the same local network ) ,  but really should work 
without problems in an ideal world ( hairpin or no hairpin). I suspect 
it will work with Skype,  and it is not rocket science to make it work 
,  but it requires the call server to receive at least one packet from 
the media ( 8000) port of the call initiator in order to figure out the 
forwarding.  Then it knows both the local and forwarded ports and IP 
numbers for both control and media packets,  and can give the 
appropriate values to the called client, depending on whether it is 
behind the same router or not.

Anyway ,  I guess we will not get SIP clients extended in this way in 
the imminent future, so I will just concentrate on fixing my router 
setup in the meantime,  but it seems to be something that must be done 
at some point if calls are to connect correctly in this situation with 
common router boxes.


Steve
















On 08/06/2010 01:48 PM, David Sugar wrote:
> This I suspect is because eXosip gets confused where to send the ack,
> based on where the incoming call sip session appears to be from vs where
> it actually is.
>
> There are a number of eXosip specific options that can be set that may
> solve this by setting exosip options per server/stack.cpp
>
> EXOSIP_OPT_UDP_KEEP_ALIVE       (hmm...this looks useful for nat...)
> EXOSIP_OPT_UDP_LEARN_PORT
> EXOSIP_OPT_USE_RPORT
>
> The ones currently supported under<stack>  in config:
>                         <keepalive>unsigned ?seconds</keepalive>
>                         <learn>bool</learn>
> and are set in server/stack.cpp.
>
> I need to add<rport>  to these...
>
> If you have loss of udp peers, this might be related to the newer
> nat/subnet rtp media proxy code.  This can be disabled by setting
> <media><count>0</count></media>  in config.
>
> On 08/06/2010 06:58 AM, Steve Murphy wrote:
>    
> > Hi all
> >
> > I just wanted to make a note of what I have observed running a SIP Witch
> > 0.8.4 server on a public internet server,  conducting tests using SIP
> > clients on the same network behind a single router box ( with single
> > public IP address).  I am using twinkle softphones as well as a snom m3
> > ( only a single extension/handset unfortunately ).
> >
> > I have used the snom phone on this network using a providers asterisk
> > service without setting a stun server for some time without any problems
> > ( admittedly this was the only sip client on the network previously )
> > and this fact made me conduct initial tests without a stun server set
> > for the snom or the twinkle softphones on the local network.
> >
> > 1) Tests without stun server set for clients:
> > ********************************************
> > 1a) If twinkle client calls snom phone , call is established normally ,
> > and audio is working.
> >
> > 1b) If snom calls twinkle , twinkle rings,  and call can be picked up,
> > but twinkle gets stuck with line status message "establishing call,
> > please wait" .  Audio is working , but after about 30 secs twinkle hangs
> > up the call , printing status message "Line 1: no ACK recieved , call
> > will be terminated".  A similiar problem  is discussed at
> > http://osdir.com/ml/voip.twinkle/2008-05/msg00025.html.  The snom phone
> > does detects the hangup and it's call timer continues until it is
> > explicitly hung up.
> >
> > 1c) If one twinkle1 calls twinkle2 , situation is as 1b above (
> > substituting 'twinkle1' for 'snom' and 'twinkle2' for 'twinkle' in 1b).
> >
> > Observations: The snom phone always seems to bag the default sip port on
> > the router box (5060) regardless of which order the phones are powered
> > up  and registered. The twinkle phones 5060 ports are forwarded to
> > different ports on the router.
> >
> >
> > 2) Tests with  a stun server  set for the clients:
> > ****************************************************
> > I set all the clients to use stunserver.org
> > Now all the calls are established normally,  and can be hung-up
> > normally by either end BUT the audio does not work! ( silence at both
> > ends ).
> >
> >
> > Further info:
> >
> > I have started following Michel de Boer's advice to the author of the
> > voip.twinkle thread mentioned above,  and collected some network traffic
> > on the server and local network during call set up.  What this shows is
> > that for tests 1 ( no stun ) at the point the call is picked up,  the
> > server begins to generate SIP packets intended for  the failing ( callee
> > ) client  using it's LOCAL network address ( e.g. 192.168.1.x ) .  Not
> > surprising that the client receives no more control packets relating to
> > this call!
> > When stun is set for the clients,  the server never generates packets
> > with 192.168.1.x  addresses - but something (as yet undetermined) is
> > going wrong with the UDP peer to peer connection between clients.
> >
> > Is this a known issue?  Does anyone know where the fault is likely to
> > originate from ? ( e.g. clients , server or router )
> >
> > As a complete bodge - I have hacked a copy of twinkle to not hang up the
> > call after 30 seconds, which gives me a usable system,  but would much
> > rather prefer to fix the underlying problem.
> >
> > I can press on and find out more about what is happening to  the
> > audio/UDP session when the stun servers are setup,  however  all that I
> > know of the  details of SIP calling and SIP network traffic has been
> > learned while looking at this problem, so it may take a little time.
> >
> > I suspect everything will work fine as long as I do not call a client on
> > the same local network,  but this is harder for me to test, and clients
> > on the same network is useful.
> >
> > Grateful for any thoughts/ advice
> >
> > Steve
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >