Re: [Sipwitch-devel] sipwitch call dropped after 16 seconds

[David Sugar]

SIP requires a three-way handshake to complete to establish a call.

There is a SIP invite to initiate the call.  There is a SIP answer to accept
the call.  And there is also a SIP "ack" then sent by the initiator to confirm
the call.

Many clients establish the media session after receiving the answer.

If the final SIP ack is not received within 16 seconds, the session is
terminated.

The hairpin scenario is one way that such acks may fail.  This is because the
ack is not an in-dialog message attached to any call session, but rather is a
separate stand-alone SIP message.  It is not clear if the ack tries to send to
the client directly, or goes through sipwitch.  If it is the former, it
certainly can get lost in routing issues. The destination of the ack is also
determined by the uri if it is given to sipwitch, and perhaps this may not be
the right uri for sipwitch itself or for the actual destination.  A good
trace with wireshark may be needed to figure out precisely where/which cases
this scenario fails and ultimately why/where acks are being sent to.

Steve Murphy wrote:

> I have had a similiar experience ( i.e. calls terminating after a short 
> duration ).
> In my case this was due to testing calls between extensions behind a
> router that did not "hairpin" public forwarded ports onto the local
> network . 'Hairpin' is a test defined by the stun test set -
> essentially it means that clients on the local network can connect
> to each other by ports forwarded on the public network connection of
> the router.  My belief is that for sipwitch clients residing on the
> same private network to call each other via a public sipwitch
> server, the router connecting the private network to the public
> network must support "hairpinning".
> To determine whether you router supports "hairpinning" you can use
> the stun test client available with most linux distros with a stun
> service  : e.g. 'stun stunserver.org'  will run the test for you.
> 
> If you're problem only occurs when sipwitch is running on the public
> network and goes away when you run it on the same private network as
> the clients, then the problem is likely to be due to the router not
> supporting "hairpinning".    I believe such problems can be worked
> around by running multiple sipwitches ( local and public )  but I
> think it could be easier to get a different router.
> 
> HTH
> 
> Steve
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> If you are exI expect that if you run sipwitch on the same local
> network as the clients you will see no problems. The symptoms
> 
> 
> On 08/19/2011 05:59 PM, Haakon Meland Eriksen wrote:
> >Hi Paul,
> >
> >David suggests using Wireshark to find out what really happens in your 
> >network,
> >he writes:
> >
> >"SIP depends on a 3 step handshake to establish a call.  There is an invite,
> >an answer, and a ack.  Many sip clients establish audio for the call on the
> >answer.  However, if the do not receive the ack within 16 seconds, they then
> >disconnect.
> >
> >SIP witch sends the ack back to the client when it receives it from the
> >destination.  This probably will require wireshark to figure out if the
> >destination sent back the ack, and then if/where sipwitch sent it to the
> >caller.  Most often when this happens it is a network routing or client 
> >config
> >issue, though."
> >
> >Yours,
> >Haakon
> >
> >
> >Onsdag 10. august 2011 09.48.51 skrev Paul Mathebula :
> >>Hi,
> >>
> >>I have downloaded, compiled ad installed sip witch release candidate 1.1.1
> >>i had previously installed other version. My calls are setup up properly
> >>HOWEVER all my active calls are terminated after 16 or so seconds. All
> >>previous versions I had installed from 0.8.4 exhibit the same limitations.
> >>What is the cause of this and how do i resolve it ? Thanks in advance.
> >>Additional info;
> >>
> >>
> >>    - ubuntu natty
> >>    - running sipwitch as root
> >>    - my domain in sipwitch.conf is fully qualified and ends with a fullstop
> >>    - no localnames specified
> >>    - realm is gnuvoip which is also used in client voip softphones
> >>
> >>my sipwitch.conf:
> >>
> >><?xml version="1.0"?>
> >><sipwitch>
> >><!-- my test users -->
> >><provision>
> >><user id="bumblebee">
> >>      <secret>sam001</secret>  <extension>101</extension>
> >><display>Bumblebee</display>
> >>    </user>
> >><user id="megatron">
> >>      <secret>allspark</secret>  <extension>102</extension>
> >><display>Megatron</display>
> >>    </user>
> >></provision>
> >><access>
> >></access>
> >>
> >><stack>
> >>
> >>   <domain>fqdn.</domain><!--my fully qualified domain name, withheld-->
> >>
> >>   <mapped>900</mapped>
> >>   <threading>4</threading>
> >>   <interface>*</interface>
> >>   <dumping>false</dumping>
> >>
> >>   <system>system</system>
> >>   <anon>anonymous</anon>
> >></stack>
> >>
> >><timers>
> >>   <!-- ring every 4 seconds -->
> >>   <ring>4</ring>
> >>   <!-- call forward no answer after x rings -->
> >>   <cfna>4</cfna>
> >>   <!-- call reset to clear cid in stack, 6 seconds -->
> >>   <reset>6</reset>
> >></timers>
> >>
> >><registry>
> >>
> >>   <prefix>100</prefix>
> >>   <range>1000</range>
> >>   <keysize>77</keysize>
> >>   <mapped>1800</mapped>
> >>   <realm>gnuvoip</realm>
> >></registry>
> >>
> >><routing>
> >></routing>
> >></sipwitch>
> >>
> >>
> >>my /etc/default/sipwitch contents:
> >>
> >># Default values for daemon operation.  This should be edited and is
> >>invoked # by init script.
> >>
> >># install specifc plugins, or use "auto" to auto-load whatever is
> >>installed...
> >>PLUGINS="zeroconf scripting subscriber forward"
> >>
> >># runtime priority, recommended realtime for high capacity
> >>PRIORITY="1"
> >>
> >># can be used to adjust pthread concurrency...
> >>CONCURRENCY=0
> >>
> >># can be used to specify running effective user/group id for the server
> >>GROUP="sipwitch"
> >>
> >># set server errlog history buffer, typical may be 100, default is none...
> >>HISTORY=10000
> >>
> >># set UID mapping for automatic extension numbers, or 0 to disable
> >>FIRSTUID="1000"
> >>
> >># set group for automatic sip users, or - to disable
> >>SIPUSERS="sipusers"
> >>
> >># specify security model, desktop or server.
> >>SECURITY="server"
> >
> 
> 
>