На 2018-11-03 05:58, Pavel Troller написа:
Hello,
On Thu, Nov 1, 2018 at 9:13 AM Kaloyan Kovachev <[email protected]>
wrote:
>
> ???? 2018-10-31 20:44, Matt Fredrickson ????????????:
> > On Mon, Oct 29, 2018 at 10:33 AM Kaloyan Kovachev <[email protected]>
> > 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
--
_____________________________________________________________________
-- 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
