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

[David Sugar]

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

dyfet.vcf
Description: Vcard