[asterisk-dev] Re: 'IAX2 call variable passing between servers '
Tony Mountifield
tony at softins.clara.co.uk
Mon Aug 7 13:30:45 MST 2006
In article <645FEC31A18FE54A8721500CDD55A7B6035075E4 at mail.oneeighty.com>,
Douglas Garstang <dgarstang at oneeighty.com> wrote:
>
> Steven, at the request of a few people last week, I posted a diagram of
> what I was working with. Then, there was absolute silence. No a single
> response. Here's a cut down version.
>
> UA-A ---> Asterisk-1 ---> IAX2 ---> Asterisk-2 ---> UA-B
>
> > At asterisk 2, you are IAX2. You don't know about the other side, and
> > you shouldn't care about the otherside. Any call from asterisk 2 out
> > won't know that the link on the otherside of asterisk1 is and
> > shouldn't
> > care.
>
> The call from Asterisk-2 to UA-B has to be a SIP call, because UA-B only
> talks SIP. It doesn't know anything about IAX2. I ABSOLUTELY do care
> about the other side, because when Asterisk-2 calls my AGI script that
> dials UA-B, it sets agi_type to IAX2, not SIP.
When your AGI script is called, surely it is in the dialplan that is
executing on the channel of the incoming call to Asterisk-2. That channel
is an IAX2 channel, and agi_type is describing that. At that point, it
doesn't even know that your AGI is going decide to call a SIP device, does
it?
The same thing would be true of this:
PSTN --> Zap (e.g. T1) --> Asterisk --> SIP-UA
At the point your AGI is invoked on the incoming call, agi_type would be
Zap, because that is the kind of channel that leg of the call is on.
In both cases, it is only the new channel created by the Dial application
that would have a "type" of SIP.
> If that UA-B transfers or
> forwards a call, and sends a 'Moved Temporarily' SIP message back to
> Asterisk-2, Asterisk-2 re-enters the dial plan again with agi_type set
> to IAX2 again, not SIP. Because the type is IAX2, we've lost our rdnis
> value which is essential for forwarding calls, and we've lost dnid which
> is essential for transferring calls.
I think the lack of rdnis in IAX channels has been true for a long time.
I remember running into it over a year ago. I worked round it by making
sure that my AGI was called from the original ${EXTEN} of the incoming
call.
It may have been fixed in trunk. What version of Asterisk are you using?
Cheers
Tony
--
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org
More information about the asterisk-dev
mailing list