[Home]

Summary:ASTERISK-26569: ari: Redirect does not work over sip trunk
Reporter:Daniele Pallastrelli (Daniele77)Labels:
Date Opened:2016-11-09 08:53:42.000-0600Date Closed:2016-11-09 10:20:10.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Core/Stasis Resources/res_ari_channels
Versions:13.10.0 14.0.2 GIT Frequency of
Occurrence
Constant
Related
Issues:
Environment:Linux debian-8 3.16.0-4-586 #1 Debian 3.16.36-1+deb8u1 (2016-09-03) i686 GNU/Linux gcc (Debian 4.9.2-10) 4.9.2 Attachments:( 0) console_26569.txt
( 1) debug_log_26569
( 2) output_26569.txt
Description:h4. Frequency
Systematic issue.

h4. Symptoms
ARI redirect channel over sip trunk does not work.

h4. Steps required to reproduce the issue

With the following setup:
* extension 6100 that answer and then put the channel in a stasis app called "attendant"
* a phone named 290
* a sip trunk called "toronto" towards another asterisk installation with a phone named 101

A phone (290) calls the extension 6100 (stasis application), resulting in a channel with id:
 pc_dany_asterisk-1478699776.2

Then, try to redirect the channel towards the phone 101 over the trunk "toronto":
{code}
curl -v -u asterisk:asterisk -X POST "http://localhost:8088/ari/channels/pc_dany_asterisk-1478699776.2/redirect?endpoint=sip/toronto/101"
{code}

h4. Expected Behaviour
After the http POST, the local phone should result connected to the remote phone (according to https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Channels+REST+API#Asterisk14ChannelsRESTAPI-redirect)

h4. Behaviour actually encountered
The redirect operation fails with the message:

{{handle_request_invite: Call from '290' (192.168.210.111:5060) to extension 'toronto101' rejected because extension not found in context 'LocalSets'.}}

(logs attached)

h4. Notes
It seems there is a problem parsing the "endpoint" parameter in the request. The slash between "toronto" and "101" is missing (in the request I send "sip/toronto/101" but in the log message I get "toronto101")

Other http requests (e.g., channel creation) works with sip trunks. The url of the request has the same syntax as for the endpoint parameter:

{code}
POST http://192.168.210.132:8088/ari/channels?endpoint=sip/toronto/101&app=attendant
{code}

I tested the bug also with the last (at the time of writing this) commit in the git repository: GIT-master-0d85f18
Comments:By: Asterisk Team (asteriskteam) 2016-11-09 08:53:43.680-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Joshua C. Colp (jcolp) 2016-11-09 09:21:52.160-0600

What exactly are you wanting to do? The redirect operation does a protocol level redirect, that is it uses a SIP REFER or 302 to say "hey - go to this SIP URI". Is that what you are looking to do?

By: Daniele Pallastrelli (Daniele77) 2016-11-09 10:14:13.449-0600

My goal is to put in communication a local phone (who called a stasis application) with a phone on the other side of a trunk.
The alternative method is to set up a local bridge with one channel to the local phone and another to the trunk. Is this the right method?
Thanks.

By: Joshua C. Colp (jcolp) 2016-11-09 10:19:39.686-0600

ARI provides the building blocks to write that. It does not provide a specific operation to do it, as that's really application logic. Using a POST to channels[1] you can create an outgoing channel to where you want. Once answered you can create a bridge[2] and add both channels[3] to allow them to talk.

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Channels+REST+API#Asterisk14ChannelsRESTAPI-originate
[2] https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Bridges+REST+API#Asterisk14BridgesRESTAPI-create
[3] https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Bridges+REST+API#Asterisk14BridgesRESTAPI-addChannel

By: Joshua C. Colp (jcolp) 2016-11-09 10:20:05.385-0600

Yes, that is the method by which it is done in ARI.

By: Daniele Pallastrelli (Daniele77) 2016-11-09 10:36:35.779-0600

So: maybe in my application I can go with a local bridge + 2 channels (supposing that's not taking too much resources on the local asterisk).
But is the fact that redirect does not work with sip trunks a real bug, or is it this way by design?

By: Asterisk Team (asteriskteam) 2016-11-09 10:36:36.074-0600

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.

By: Joshua C. Colp (jcolp) 2016-11-09 10:42:17.887-0600

That's how you should do it if you want the channels to remain on your system. A redirect does work, but as I said it's up to the remote side to handle that case. In the case of chan_sip receiving that it's as if you have told it to do a blind transfer to a provided extension.

By: Joshua C. Colp (jcolp) 2016-11-09 10:44:03.135-0600

If you want to explore it further you'd need to provide complete console output with sip set debug on so the generated 302 or REFER can be seen.

By: Daniele Pallastrelli (Daniele77) 2016-11-09 11:25:01.613-0600

Done. You can find the file attached.

By: Joshua C. Colp (jcolp) 2016-11-09 11:35:39.135-0600

So the REFER is telling the softphone to contact "toronto/101@192.168.210.132". If you replace SIP/toronto/101 with SIP/101@toronto it may work better. This does mean, though, that the softphone will no longer be connected to the system where it entered the ARI application and if any authentication is required by the other server (toronto) your softphone may not be able to authenticate.

By: Joshua C. Colp (jcolp) 2016-11-10 05:13:50.435-0600

Did my suggestion change the result?

By: Daniele Pallastrelli (Daniele77) 2016-11-10 09:38:22.359-0600

It works if I use SIP/290@192.168.210.71 as uri (192.168.210.71 is the ip address of the machine "toronto") with a voip phone "Yealink". The sip trace is more or less:

{quote}
(291 is the caller, 290 is the phone over the trunk, 6100 is the stasis app)

-> Invite sip:6100@192.168.210.132
<- 100 Trying
<- 200 Ok
-> Ack sip:6100@192.168.210.132
<- Refer sip:291@192.168.210.41
-> 202 Accepted
-> Notify sip:6100@192.168.210.132 (100 Trying)
<- 200 Ok
-> Notify sip:6100@192.168.210.132 (200 Ok)
<- 200 Ok
{quote}

However, if I use instead the softphone PhonerLite to make the first call, the redirect does not work. This is the sip trace:

{quote}
(290 is the caller, 102 is the phone over the trunk, 6100 is the stasis app)

-> Invite sip:6100@192.168.210.132
<- 100 Trying
<- 200 Ok
-> Ack sip:6100@192.168.210.132
<- Refer sip:290@192.168.210.111
-> 202 Accepted
-> Invite sip:102@192.168.210.71
<- 100 Trying
-> Bye sip:6100@192.168.210.132
<- 200 Ok
<- 503 Service Unavailable (subscriber absent)
-> Ack sip:102@192.168.210.71
{quote}

And then, the asterisk cli is flooded with tons of the WARNING message:
{quote}
channel.c: Unable to write to alert pipe on SIP/290-00000001 (qlen = 0): Resource temporarily unavailable!
{quote}

By: Joshua C. Colp (jcolp) 2016-11-10 09:44:10.837-0600

Doing so shouldn't result in that flood so I'd suggest uploading a console output of that.

As for it not working - this goes back to one of my earlier comments. We are telling the phone to go elsewhere and it is up to it to do that. Not all implementations are created equal and not all expect it to occur or handle it properly. From the Asterisk side there's nothing we can do to change that. Your other option as previously mentioned is to create an outgoing channel in Asterisk and bridge them. That will work all the time.

By: Daniele Pallastrelli (Daniele77) 2016-11-10 10:49:21.934-0600

I attached the console output for the flooding (BTW: I erased from the file 470000 lines containing the same warning message :-) )
I had to redirect the stdout to a file.

As for my application: I understand that the REFER request can work with some endpoint and not with other. Maybe Yealink phone handle the request int he right way while PhonerLite don't.
Anyway I'll go for the solution you suggested: I'll create a bridge and an outgoing channel. Moreover, I prefer to mantain the control of the channels, so I guess this should be my first option.
Thanks a lot.

By: Rusty Newton (rnewton) 2016-11-10 13:34:20.712-0600

Since the issue is now the particular behavior with one specific softphone during an ARI redirect , can you open a new issue for that report, and post the debug there? That will make it easier for those coming to issue to decipher what we are investigating.

However, your log file didn't include the DEBUG or verbose options. If you open a new issue please attach a log of the problem that includes "warning,notice,error,verbose,debug" and be sure that verbose and debug are both turned up to level 5 or above.

I'll go ahead and close this issue out since the original issue was not a problem.