[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipwitch-devel] Public sipwitch server handling calls between exten
From: |
David Sugar |
Subject: |
Re: [Sipwitch-devel] Public sipwitch server handling calls between extensions behind router |
Date: |
Fri, 06 Aug 2010 07:48:23 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 |
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