Hello, I think my Asterick 10.10.0 is making two calls to an extension, when only one call is made to a DID.
This call came in from a SIP trunk and is routed to extension 2000:
-- Executing [s@macro-dial-one:42] Dial("SIP/vitel-inbound-000000e8", "SIP/2000,30,tr") in new stack
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
-- Executing [s@macro-dial-one:38] GotoIf("SIP/vitel-inbound-000000e9", "1?godial") in new stack
-- Goto (macro-dial-one,s,42)
-- Executing [s@macro-dial-one:42] Dial("SIP/vitel-inbound-000000e9", "SIP/2000,30,tr") in new stack
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
-- Called SIP/2000
-- Called SIP/2000
-- SIP/2000-000000eb is ringing
-- Got SIP response 480 "Temporarily not available" back from 98.226.66.65:5060
-- SIP/2000-000000ea is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
This call was from extension 1001 to 2000 and it doesn’t look like there are two calls being made to ext 2000 like above:
-- Executing [s@macro-dial-one:42] Dial("SIP/1001-000000ec", "SIP/2000,30,trI") in new stack
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
-- Called SIP/2000
-- Connected line update to SIP/1001-000000ec prevented.
-- SIP/2000-000000ed is ringing
Does anyone have any idea why or where to look to track why this is happening?
You don’t mean extension you mean device. “extension”, in Asterisk, is reserved for the first field after “exten =>” in extensions.conf. Making this confusion results in less secure systems, as you use guessable device names, and denies the flexibility that comes from the distinction.
At the moment, I would tend to suspect that the trace is misleading, possibly an artifact of connected line updates. I’d need to see sip set debug on output, to see what is actually happening between Asterisk and the device.
The dialplan looks like it was generated by a GUI. I’m not going to debug the GUI. This is the wrong forum for this. If you provide the SIP trace, I can tell if the call is being attempted twice.
An “extension”, in the Asterisk sense, not yours, really is being called twice. There are two incoming calls with the same CLID and destination, almost simultaneously arriving from the trunk.
Also, device 2001 is rather slow in responding, which suggests that it has a poor SIP implementation, or the network or Asterisk server is overloaded. However, the problem arising before Asterisk gets the calls.
It would have been more obvious that there were two incoming calls if you had included step 38 from both of them.
When you said the above that made me realize that I setup the routing method on the sip provider to route to the IP and to the registered trunk. I was under the impression that the second method would be used as a backup route. Turns out its not and rings them both simultaneously. As soon as I changed it to just one of the methods the issue is no more. Thanks for your help on that!
Now about the Sip phone being slow in responding. This server is not being used for anything, but some testing and development. It is a Micro instance on Amazon EC2 which might explain the slowness as 1 inbound call takes up about 5% CPU.
As far as the implementation what would I look for? And where can I read up on SIP debugs? What is step 38?
– Executing [s@macro-dial-one:38] GotoIf(“SIP/vitel-inbound-000000e9”, “1?godial”) in new stack
If I had seen then same 3 steps leading up to the duplicate call, it would have been obvious that there were two incoming calls.
The reference to the implemntation is that SIP UASes only have a short time to send 100 Trying and I was suggesting that you had a phone that was designed in such a way that it took longer.
The retransmissions will be the consequences of trying to run on a virtual machine on a host tthat you do not control, so you cannot ensure low scheduling latencies and low concurrent loads.