[asterisk-dev] 'IAX2 call variable passing between servers '

Evan Borgström evan.borgstrom at ca.mci.com
Tue Aug 8 07:04:14 MST 2006


Doug,

	You're still missing the point about Asterisk's view of the channels in
your calls. In your diagram you posted you had the following (I'm going
to break it down into sections);

Section #1
----------
UA-A -SIP-> PBX-1 -IAX2(DUNDi)-> PBX-2

Section #2
----------
PBX-2 -SIP-> UA-B -SIP(302)-> PBX-2 -SIP-> UA-C

	The end of Section #1 is where you AGI is executing so no matter what
happens in Section #2 the agi_type will ALWAYS be IAX because that's
what invoked the AGI.

	Here's what I think you're failing to remember/get/whatever. Asterisk
is acting as a bridge for the calls (yes, there are 2 of them), the
incoming leg being IAX2 and the outgoing being SIP so no matter what
happens on the outgoing leg (INVITE, 302 Moved, re-INVITE, REFER, etc)
nothing is going to change the fact that the originating side is IAX2.
Thus, anything that goes on in your AGI is going to see agi_type as IAX
since that's the channel that invoked the AGI in the first place. When
your SIP client, UA-B, modifies the SIP leg via a redirect or a transfer
the setup is not changing so that you have the original SIP call on one
side of the transaction and the new SIP call on the other, instead you
have the original IAX2 call on one side and the new SIP call on the
other and your AGI is getting IAX2 as the call type. Asterisk does NOT
re-enter the dialplan as you seem to think it should, it doesn't need to
as the dialplan logic has already been evaluated and only the outbound
call leg is being changed.

	When you switched to SIP it worked because a SIP channel executed your
AGI so all messages subsequently generated by your AGI will reference a
SIP channel, and viola... agi_type will always be SIP.

	Regarding the rdnis & dnid, I'm not going to comment. I'm not involved
in the IAX2 or SIP channel development so I don't really have a point of
view on how those two pieces of information should be transfered around.
But, the way Asterisk is behaving in those situations is correct.

-Evan

Douglas Garstang wrote:
>> -----Original Message-----
>> From: Steven Critchfield [mailto:critch at basesys.com]
>> Sent: Monday, August 07, 2006 1:52 PM
>> To: Asterisk Developers Mailing List
>> Subject: RE: [asterisk-dev] 'IAX2 call variable passing 
>> between servers
>> '
>>
>>
>> On Mon, 2006-08-07 at 13:33 -0600, Douglas Garstang wrote:
>>>> -----Original Message-----
>>>> From: Kevin P. Fleming [mailto:kpfleming at digium.com]
>>>> Sent: Monday, August 07, 2006 12:45 PM
>>>> To: Asterisk Developers Mailing List
>>>> Subject: Re: [asterisk-dev] 'IAX2 call variable passing 
>>>> between servers
>>>> '
>>>>
>>>>
>>>> ----- Douglas Garstang <dgarstang at oneeighty.com> wrote:
>>>>> The endpoint, UA-B, is a sip phone. How can an IAX2 call be 
>>>> placed to
>>>>> the new destination?
>>>> Please ask questions that make a little more sense... if the 
>>>> new destination is (for example) extension 3001 in the SIP 
>>>> peer's dialing context, and that extension ends up pointing 
>>>> to an IAX2 endpoint, then of course the outbound call that 
>>>> will be placed will be an IAX2 call.
>>> I'm having a little trouble understanding how a Polycom 601 
>> phone that
>>> has no knowledge of IAX can receive an IAX call. It may make perfect
>>> sense to you, but it doesn't to me. 
>> In your example, this is very easy. 
>>
>> Sip-1 ---> SIP call --> Asterisk 1 --> IAX2 --> Asterisk 2
> 
> 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. 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'm assuming that some where you are hoping to get a transfer 
>> done that
>> will get your asterisk machines out of the loop as well as your other
>> stated problems. Without using the same transport from end to end, it
>> won't happen.
> 
> Well, that seems to be the problem. IAX, from what I understood was supposed to be exactly designed for this kind of thing. As soon as I changed to SIP between the Asterisk boxes, these problems went away. 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> 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