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.
You will need to make the console output and log information available for this. What you are doing is being done by others fine, so it may be something environment specific.
Before this log the bridge is already setup as are the channels. The log contains the part where first one channel is connected (successfully) and then the second channel is connected (which then causes both channels to disconnect).
I noticed something down around line 1189. Something about DAHDI. Goes on to say something about my bridge (test4) that it cannot use DAHDI as it is not compatible. This is supposed to be a SIP only “mixing” bridge in the stasis app.
I’m fairly new to Asterisk but I have not configured any DAHDI settings. There was one trunk setup as a DAHDI by default (I installed the asterisk now setup) so I deleted that but that didn’t help. Do I need to turn off DAHDI and if so how? Or is this a “red herring”?
No, you don’t need to turn off DAHDI. The bridging architecture finds the best way to connect things together by asking each one, including DAHDI. Since it’s not a DAHDI channel that’s not a viable option and it does not use it.
As for your problem I think you cut off the log too soon. I don’t see any channels being disconnected. More would be needed, and the sip debug (sip set debug on) would also be useful since SIP is in use.
What’s concerning is that when the channels do drop there doesn’t seem to be any immediate logging of it. I think they just drop and then they probably timeout as far as the system is concerned. You’ll see a gap in the timecodes there. I’m not sure if that extended logging shows them dropping or if it’s just other random data.
Just for reference, I’m using the freepbx web interface. I added this into the peer details of my trunk. Here’s what I currently have (private info X’d out) in the “Peer Details” text box. Applied the config and everything took just fine.
On a shallow analysis of that configuration, you have conflicting settings for directmedia. canreinvite is a deprecated or obsolete name for directmedia and nonat and no are mutually incompatible.
Also insecure=very is deprecated or obsolete for insecure=port,invite. Most cases that needed insecure=invite do not also need insecure=port.
qualify=no should only be used if qualify is causing problems. Setting it to no can cause problems with NAT and with dynamic firewall rules.
As I said, this is a shallow analysis, and may not be related to your problem.
I appreciate the input here. I figure it has to be something like this. Some config in the way I have my trunks setup or something. I changed my config based on your comments to this…
I’m still banging my head against the wall on this one.
I went through the web socket messages that were coming through and I noticed one thing.
The scenario where things work when one of the channels is an extension, I notice that there is a “ChannelConnectedLine” messages that comes through. Here’s the json…
As you can see it seems to be a connection between the 101 extension and the external number.
The last message I get when I only call two external numbers (the 101 extension is excluded) is a “Channelvarset” for variable BRIDGEPVTCALLID and then the two lines disconnect. This is the same message that the successful log shows before the “ChannelConnectedLine” message.
So for some reason when things fail this ChannelConnectedLine is not being triggered. I’m not sure if this helps at all but hoping someone might have some insight?
All the other messages leading up to that point are exactly the same.
With direct media disabled I’d suggest providing updated logs… but really I’m not seeing anything on the Asterisk side to explain what you are experiencing on the provider side, unless they are doing something incorrectly to a perfectly normal thing we’re doing.
That’s what I’m beginning to wonder. What I’m using for my testing purposes is a freephoneline.ca account which comes with two channels. In fact I got a second account to see if that was the issue but still the same problem.
What I can’t figure out is why it works when I dial in an extension and add it to the bridge. It’s only when it’s just the two channels on the sip trunk that causes it to fail. What kind of communication back to the provider could be happening that would block this? Doesn’t make sense.
I finally figured it out. Your recommendation to set directmedia to disabled was correct.
However I had only put it in the outgoing context. Not in the inbound settings. I’m fairly new to Asterisk and am using the FreePBX front end. It wasn’t until I started playing around with specifying contexts that I realized that even though the context was in the inbound section it still applied to outbound calls. This is when I realized that these settings applied no matter the direction of the call. As a result the UI can definitely throw you off.
So after I duplicated the settings in both outbound and inbound, it all started working.
You had me on the exact right path, jcolp. It just took me forever to implement. Thanks again!
The FreePBX use of inbound and outbound is questionable. For an inbound call, Asterisk will use the first one that matches. I think it tries all user matches before peer matches. If, as is normally the case, you are always using peer matches, there is a good chance that the inbound entry is totally redundant. I don’t think anything guarantees in which order they will be checked.
Hi…as per my knowledge the bridging architecture finds the best way to connect things together by asking each one, including DAHDI. Since it’s not a DAHDI channel that’s not a viable option and it does not use it.As for your problem I think you cut off the log too soon. I don’t see any channels being disconnected. More would be needed, and the sip debug would also be useful since SIP is in use.
Hi etep, i want to build a similar application. Could you just elaborate the steps you followed to establish a call connection. Many Thanks in advance.
Thanks again!