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

[paul]

Hi David,

I will certainly try reducing the registration interval to one("1") minute as 
you've proposed below as well and will let you know how that goes.

Thanks for your inputs, most appreciated.

Paul
Sent from my BlackBerry® Paul M. Mathebula

-----Original Message-----
From: David Sugar <address@hidden>
Date: Sat, 20 Aug 2011 08:44:52 
To: Paul Mathebula<address@hidden>
Cc: Steve Murphy<address@hidden>; <address@hidden>
Subject: Re: [Sipwitch-devel] sipwitch call dropped after 16 seconds

Yes, that makes sense.  When sending in-dialog messages and replies, exosip
probably simply writes the reply back to the "appearing" peer address.  Hence,
when receiving the invite and replying with the clients answer message, this
goes back cleanly, and the media session is started.  However, when sending
unsolicated messages such as ack, it may be trying to send by resolving the
uri of the destination, which perhaps does not go back to the pinhole address
by itself.  With STUN, the client presents itself with it's public address and
port number when behind NAT, so everything probably carries that public
address.

Another theory for the missing ack, at least in a NAT scenario, is that
sipwitch also does track the "appearing" peer address also, but only at the
time of registration, and of course this may be different or change by the
time the actual invite is sent by the NAT'd client if the pinhole is not kept
open.  Hence, where sipwitch believes the client is (by port and ip address)
may no longer be true.  Again, for in-dialog replies, the sip message is
returned by the last peer address of the original request by the exosip stack,
but, for unsolicited requests, they have to resolve either by the uri or by
sipwitch itself substituting the last "known" peer address from the last
registration message.  One solution might be to use a very short registration
interval, such as 1 minute, since most NAT's keep the udp port associated with
a local udp socket when idle for 90 seconds.

Paul Mathebula wrote:

> Hi Steve
> 
> I have managed to resolve that I need a stun server.Thanks for the pointers.
> 
> Regards,
> Paul
> 
> On Fri, Aug 19, 2011 at 10:06 PM, Steve Murphy <address@hidden> 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"
> >>>
> >>
> >>
> >
> >
> >