[asterisk-dev] redirecting lost over IAX

[Pavel Troller]

Hello,

> On Thu, Nov 1, 2018 at 9:13 AM Kaloyan Kovachev <kkovachev at varna.net> wrote:
> >
> > ???? 2018-10-31 20:44, Matt Fredrickson ????????????:
> > > On Mon, Oct 29, 2018 at 10:33 AM Kaloyan Kovachev <kkovachev at varna.net>
> > > wrote:
> > >>
> > >> Hello list,
> > >>   I have followed the example from
> > >> https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information
> > >> to unconditionally forward a call between two Asterisk instances
> > >> connected over IAX, but it seems there is a bug or the example is
> > >> incomplete.
> > >>
> > >>   The setup is:
> > >>    Astersik A receives a call over DAHDI (libSS7) or SIP and forwards
> > >> the
> > >> call to Asterisk B over IAX
> > >>    Astersik B checks the database and if redirecting is required sets
> > >> the
> > >> REDIRECTING details as above and forwards the call to Astersik A as a
> > >> new call, again over IAX, which should dial out over SIP or DAHDI
> > >>
> > >>   The problem is that only REDIRECTING(from-num) is populated and all
> > >> the
> > >> rest is blank with count remaining 0, so no redirection info is
> > >> forwarded with the new call.
> > >>   Is there something else that needs to be set or it's a bug in the
> > >> IAX
> > >> code to ignore the rest of the fields?
> > >
> > > Which other fields specifically are you looking for?
> > >
> > > It's quite possible the IAX2 protocol doesn't support some of the
> > > additional redirection info.
> > >
> > > REDIRECTING(from-num) seems to get mapped to the RDNIS IE in IAX
> > > protocol land.  I guess it's going to just depend on what other fields
> > > you need or are looking for.
> >
> > The problem is that the most important ones 'count' and 'reason' are not
> > forwarded and most of the code does not even bother to check the rest if
> > 'count' is 0, so redirecting loops are possible if IAX is used somewhere
> > in the path.
> >
> > Just made a test redirecting my mobile number to my fixed one and
> > checking
> > ${REDIRECTING(count)}/${REDIRECTING(reason)}/${REDIRECTING(from-all)}/${REDIRECTING(orig-all)}/${REDIRECTING(to-all)}
> > with NoOp:
> >   libss7 ( on Asterisk A) sets the first 4 as received from the telco (
> > will need to patch it to also set the 'to' fields )
> >   the call is then forwarded to the second Asterisk ( B ) where the same
> > NoOp only shows the 'from' field populates, so all the rest are lost
> >   on Asterisk B the call is further forwarded - 'count' is actually reset
> > to 1 (allowing loops to be created) and 'orig' is lost
> >
> > Expected behavior:
> >   all 5 fields received over SS7 should be forwarded over IAX to preserve
> > the call divert information
> >   on subsequent redirection the 'count' should be incremented instead of
> > being reset to prevent call loops
> >
> > Should i open a bug report in this case, as it seems it's not something
> > that i am doing wrong?
> 
> A bug report would probably inappropriate as this would be a "feature
> request", IMHO.  I think this is as limitation in the IAX2 protocol.
> The IAX2 RDNIS information element would either have to be extended to
> add this information or an additional information element would have
> to be created to contain this additional redirecting information.

I'm afraid that it's really a problem with IAX2. But on the other side,
you can workaround it in your dialplan using IAX2 variables. Just set up
some IAX2 variables on the calling side and they will be received on the
called side and you can regenerate the correct REDIRECTING() information
from them. I'm using exactly this for transmitting
CHANNEL(transfercapability) over the IAX2 trunks:

For example, for the B-side:
exten => s,n,ExecIf($["${ATECH}" = "IAX2"]?Set(TRANSFERCAPABILITY=${IAXVAR(tfcap)}))
exten => s,n,ExecIf($["${TRANSFERCAPABILITY}" != ""]?Set(CHANNEL(transfercapability)=${TRANSFERCAPABILITY}))
...

With regards,
  Pavel


> 
> -- 
> Matthew Fredrickson
> Digium - A Sangoma Company | Asterisk Project Lead
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> 
> -- 
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> Astricon is coming up October 9-11!  Signup is available at: https://www.asterisk.org/community/astricon-user-conference
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev