[asterisk-dev] Looking to input on a feature I would like to write...in depth Transfer (REFER) failure reasons

Dan Cropp dan at amtelco.com
Fri Jan 8 09:09:22 CST 2021


Thank you Joshua

From: asterisk-dev <asterisk-dev-bounces at lists.digium.com> On Behalf Of Joshua C. Colp
Sent: Friday, January 8, 2021 8:43 AM
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Subject: Re: [asterisk-dev] Looking to input on a feature I would like to write...in depth Transfer (REFER) failure reasons

On Fri, Jan 8, 2021 at 10:41 AM Dan Cropp <dan at amtelco.com<mailto:dan at amtelco.com>> wrote:
Before I submit a feature request and take ownership of it, trying to gather some feedback.

I’m looking to write code for an additional feature in asterisk.
Currently, when performing a Transfer (REFER), the channel variable TRANSFERSTATUS only reports 3 values: SUCCESS, FAILURE, UNSUPPORTED.

We have some customers asking for a few additional results: 404 Not Found, 408 Request Timeout, and 486 Busy Here.
From past experience, these same customers will likely come up with some additional results they think should be returned.

Would it be better to add support where the TRANSFERSTATUS had new values for each of the additional result codes I make asterisk look for?
Or would it be better to add a new variable, example TRANSFERSTATUSCODE and have it return the SIP error code for the failure notification?  Personally, I like this approach because it means not having to add values for each possible sip error code that anyone would ever look for.

It would be best if it were a separate variable, and that it also stated it was protocol specific. TRANSFERSTATUSPROTOCOL for example.

--
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com<http://www.sangoma.com/> and www.asterisk.org<http://www.asterisk.org/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20210108/943f35a7/attachment-0001.html>


More information about the asterisk-dev mailing list