[asterisk-app-dev] ARI : Adding more than one “external” SIP channels to stasis bridge ends the calls

[Peter Warrick]

I have setup an ARI application the same way the "getting started" documentation states. I'm using the swagger UI to do my testing. 

Using swagger and ARI I can setup a bridge. I can create channels to either internal SIP extensions or through external SIP trunks to a real phone number. Then I can add the channels to the bridge (mixing type) and the channels are able to speak to each other. 

The problem is that if I only use external SIP channels then when the second channel is added to the bridge, both lines are hung up. I've done this using my home phone and my cell phone. 

If I have an internal SIP extension connected to the bridge then everything works. I've tried one extension and one or more external phone numbers and it works fine. 

To be a bit more clear on what exactly I'm doing...

In the "create a new channel (originate)" UI on Swagger I use an endpoint of SIP/101 for what I call the "internal channel." This exists in the "from-internal" context but I do not specify it here as it does not appear to be needed. I also set the app (name) and timeout and hit "Try it out!". All works fine. Extension 101's phone rings. 

I then do the same for the external channels except the only difference is the endpoint syntax. In this case I use SIP/[phone number]@from-trunk. "from-trunk" is the context I have setup for my sip-trunk. I do this once (or twice to a second phone number) and the phone rings and I pick it up. 

Then I use the id's that were generated from the create channel function and use that to add to my bridge that I've already created. This all works fine and the 3 channels are able to talk to each other. 

The problem arises if I do not include the SIP/101 channel. Just the SIP/[phone number]@from-trunk. If I only use this type of endpoint then when I add them both to the bridge, the lines disconnect. 

I’ve posted this over on community.asterisk.org <http://community.asterisk.org/> as well and my log files don’t seem to be pointing to anything obvious. But here is one of the log files. This is the log of when the second channel is added. The logs don’t immediately show anything when the lines are actually dropped. I kept it running for a bit more in case it shows something. 

Log file is at http://pasted.co/3050a39e <http://pasted.co/3050a39e> and the password is asteriskhelp99

Here are my current SIP Peer settings for my trunk. 

[101]
deny=0.0.0.0/0.0.0.0
secret= XXXXXXX
dtmfmode=rfc2833
canreinvite=no
context=from-internal
host=dynamic
trustrpid=yes
mediaencryption=no
sendrpid=pai
type=friend
nat=force_rport,comedia
port=5060
qualify=yes
qualifyfreq=60
transport=tcp,udp,tls
avpf=no
force_avp=no
icesupport=no
encryption=no
callgroup=
pickupgroup=
dial=SIP/101
mailbox=101 at default
permit=0.0.0.0/0.0.0.0
callerid=Test User <101>
callcounter=yes
faxdetect=no
cc_monitor_policy=generic

[trunk403]
disallow=all
host=XXXXXXX
defaultuser= XXXXXXX
secret= XXXXXXX
type=friend
allow=ulaw
qualify=yes
insecure=invite
directmedia=no
context=from-trunk-sip-trunk403

[trunk587]
disallow=all
host= XXXXXXX
defaultuser= XXXXXXX
secret= XXXXXXX
type=friend
allow=ulaw
qualify=yes
insecure=invite
directmedia=no
context=from-trunk-sip-trunk587

[from-trunk]
disallow=all
defaultuser= XXXXXXX
secret= XXXXXXX
type=friend
allow=ulaw
host= XXXXXXX
canreinvite=nonat
qualify=yes
insecure=invite
context=from-trunk-sip-trunk403

Of note is that the [from-trunk] context has the defaultuser set as the same as the trunk403 default user. Not sure this is a factor at all. However trunk587 is not used because trunk403 has 2 channels so you won’t see it in the log. So this may not be a factor at all.

Any ideas? Very much appreciate any insight here. I’ve been struggling with this for awhile. Figure it has to be some sort of config I’ve messed up. 

Regards,

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20160229/b0e29650/attachment.html>