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"