[asterisk-dev] redirecting lost over IAX

Kaloyan Kovachev kkovachev at varna.net
Sat Nov 3 04:22:00 CDT 2018


На 2018-11-03 05:58, 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.
> 

The possibility for call loops is definitely a bug for me, but will open 
it as feature request.

> 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
> 
> 

Thanks, that's the way i was going to workaround it and the question was 
more about, is it a bug or misunderstanding on my side.
I have tested some time ago with SIP and as i recall there were no 
problems with 'count' being incremented properly (will test again to 
confirm), so this is IAX only problem

>> 
>> --
>> 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



More information about the asterisk-dev mailing list