External calls can't be answered or declined

Asterisk Asterisk General
1

Hi all,

Setup: Asterisk 11 server on Centos 6.4 64bit, and it runs fine. And I’m new to Asterisk.

Calling between internal extensions works fine and presents no issues. But there is an issue with calls to/from the outside world, in that the status of the call (answered, declined) doesn’t seem to be passed along. For example, if I call from x1001 to 555-555-5555, the call can be answered with working audio and speech but it dies after 30 seconds. And if the call is declined, the server still attempts to connect the call until the 30-second mark is reached (ie - even if declined, the server will continue to ring the line).

I understand that the 30 seconds mark is from a default that is setting the amount of time to attempt a call. The real issue I am trying to determine is why the status of the call (answered, declined) isn’t being transmitted to/from the outside world. I am 99.99% sure it is a simple server configuration issue that I have overlooked, but I don’t know exactly what needs changed. Obviously a critical response of some sort is not being passed along.

To bridge from the Asterisk server to the outside world, I am using Twilio.

Sip.conf:

[xlite1]
; This is extension 1001
type=friend
host=dynamic
username=xlite1
remotesecret=<a_password_here>
transport=udp,tcp
context=dialphones

[xlite2]
; This is extension 1002
type=friend
host=dynamic
username=xlite2
remotesecret=<a_password_here>
tranport=udp,tcp
context=dialphones

[twilio]
type=friend
username=twilio
password=<a_password_here>
host=<my_twilio_sip_domain>
qualify=no

[twiliocaller](!)
type=peer
qualify=no
allowguest=yes
context=dialphones

; And I have an entry like this for each Twilio IP that should be allowed access.
; eg: [twilioip-1], [twilioip-2] .... [twilioip-23]
[twilioip-1](twiliocaller)
host=107.21.222.153

Extensions.conf:

[dialphones]
; If starting with a 9, dial the outside world
exten => _9.,1,Dial(SIP/{$EXTEN:1}@twilio)

[public]
include => demo

exten => 1001,1,Dial(SIP/xlite1)
exten => 1002,1,Dial(SIP/xlite2)

Here is the CLI output during a call, that is answered, from x1001 to 555-555-5555. (Yes, I am using a real phone number when testing this, but I’m not posting it here, of course.). The output is the same whether the call is answered or declined.

testserver*CLI> 
== Using SIP RTP CoS mark 5
-- Executing [915555555555@dialphones:1] Dial("SIP/xlite1-0000000d", "SIP/{$EXTEN:1}@twilio") in new stack
== Using SIP RTP CoS mark 5
-- Called SIP/{$EXTEN:1}@twilio
-- SIP/twilio-0000000e is ringing 
-- SIP/twilio-0000000e answered SIP/xlite1-0000000d
-- Remotely bridging SIP/xlite1-0000000d and SIP/twilio-0000000e
testserver*CLI>

Traffic captures of a call from x1001 to 555-555-5555 that is answered or declined looks identical. In the following I’ve made the data anonymous, so here is the legend:
[ul]
1.) 111.111.111.111 is the IP address of my Asterisk server, which is my.asterisk.server.com
2.) 222.222.222.222 is the IP address of the xlite1 client
3.) 107.21.222.153 is the IP address of the Twilio SIP server passing the information
[/ul]

49.467973 222.222.222.222 -> 111.111.111.111 SIP/SDP 937 Request: INVITE sip:915555555555@my.asterisk.server.com | , with session description
49.469001 111.111.111.111 -> 222.222.222.222 SIP 574 Status: 100 Trying | 
49.470174 111.111.111.111 -> 107.21.222.153 SIP/SDP 918 Request: INVITE sip:%7B$EXTEN@my_twilio_sip_domain.sip.twilio.com | , with session description
49.547463 107.21.222.153 -> 111.111.111.111 SIP 355 Status: 100 Giving a try | 
50.565114 107.21.222.153 -> 111.111.111.111 SIP 533 Status: 180 Ringing | 
50.565767 111.111.111.111 -> 222.222.222.222 SIP 590 Status: 180 Ringing | 
51.102807 107.21.222.153 -> 111.111.111.111 SIP/SDP 812 Status: 200 OK | , with session description
51.103428 111.111.111.111 -> 107.21.222.153 SIP 542 Request: ACK sip:10.70.227.82:5060 | 
51.103741 111.111.111.111 -> 222.222.222.222 SIP/SDP 881 Status: 200 OK | , with session description
51.104083 111.111.111.111 -> 107.21.222.153 SIP/SDP 929 Request: INVITE sip:10.70.227.82:5060 | , with session description
51.181029 107.21.222.153 -> 111.111.111.111 SIP 414 Status: 100 Giving a try | 
51.265552 107.21.222.153 -> 111.111.111.111 SIP/SDP 735 Status: 200 OK | , with session description
51.266103 111.111.111.111 -> 107.21.222.153 SIP 542 Request: ACK sip:10.70.227.82:5060 | 
51.298501 222.222.222.222 -> 111.111.111.111 SIP 503 Request: ACK sip:915555555555@111.111.111.111:5060 | 
51.298812 111.111.111.111 -> 222.222.222.222 SIP/SDP 852 Request: INVITE sip:xlite1@222.222.222.222:23924 | , with session description
51.310028 222.222.222.222 -> 111.111.111.111 UDP 46 Source port: 23924Destination port: sip
51.318159 222.222.222.222 -> 111.111.111.111 SIP/SDP 792 Status: 200 OK | , with session description
51.318646 111.111.111.111 -> 222.222.222.222 SIP 465 Request: ACK sip:xlite1@222.222.222.222:23924 | 
51.318877 111.111.111.111 -> 107.21.222.153 SIP/SDP 929 Request: INVITE sip:10.70.227.82:5060 | , with session description
51.395861 107.21.222.153 -> 111.111.111.111 SIP 414 Status: 100 Giving a try | 
51.477794 107.21.222.153 -> 111.111.111.111 SIP/SDP 737 Status: 200 OK | , with session description
51.478255 111.111.111.111 -> 107.21.222.153 SIP 542 Request: ACK sip:10.70.227.82:5060 |

And here is a traffic capture of a call between xlite1 (x1001) and xlite2 (x1002). As I said before, these give me no issues. But I’m providing them for trouble shooting purposes in case it helps any of you answer my question.

36.489786 111.111.111.111 -> 222.222.222.222 SIP/SDP 963 Request: INVITE sip:xlite1@222.222.222.222:23924;rinstance=21bd309ac44c2a5d | , with session description
36.631336 222.222.222.222 -> 111.111.111.111 SIP 348 Status: 100 Trying | 
36.663837 222.222.222.222 -> 111.111.111.111 SIP 473 Status: 180 Ringing | 
36.664360 111.111.111.111 -> 222.222.222.222 SIP 576 Status: 180 Ringing | 
41.150921 222.222.222.222 -> 111.111.111.111 SIP/SDP 804 Status: 200 OK | , with session description
41.151619 111.111.111.111 -> 222.222.222.222 SIP 474 Request: ACK sip:xlite1@222.222.222.222:23924 | 
41.151966 111.111.111.111 -> 222.222.222.222 SIP/SDP 869 Status: 200 OK | , with session description
41.152278 111.111.111.111 -> 222.222.222.222 SIP/SDP 885 Request: INVITE sip:xlite1@222.222.222.222:23924 | , with session description
41.208076 222.222.222.222 -> 111.111.111.111 SIP 491 Request: ACK sip:1001@111.111.111.111:5060 | 
41.209060 111.111.111.111 -> 222.222.222.222 SIP/SDP 863 Request: INVITE sip:xlite@222.222.222.222:30148 | , with session description
41.245060 222.222.222.222 -> 111.111.111.111 SIP/SDP 792 Status: 200 OK | , with session description
41.245601 111.111.111.111 -> 222.222.222.222 SIP 452 Request: ACK sip:xlite@222.222.222.222:30148 | 
41.277649 222.222.222.222 -> 111.111.111.111 SIP/SDP 804 Status: 200 OK | , with session description
41.278246 111.111.111.111 -> 222.222.222.222 SIP 474 Request: ACK sip:xlite1@222.222.222.222:23924 | 
41.278455 111.111.111.111 -> 222.222.222.222 SIP/SDP 885 Request: INVITE sip:xlite1@222.222.222.222:23924 | , with session description
41.297150 222.222.222.222 -> 111.111.111.111 SIP/SDP 804 Status: 200 OK | , with session description
41.297548 111.111.111.111 -> 222.222.222.222 SIP 474 Request: ACK sip:xlite1@222.222.222.222:23924 |
2

X-Lite bug. At least some versions ignore re-invites instead of either honouring them or actively rejecting them. Make sure that both sendrpid and directmedia are disabled for the X-Lite phones, as these are what enable Asterisk to send re-invites.

Please ask support questions on Asterisk Support.