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

Evan Borgström evan.borgstrom at ca.mci.com
Fri Aug 11 10:34:38 MST 2006


	Let me further explain then... When I said it doesn't re-enter the
dialplan I meant that it doesn't re-enter the dialplan as a new call.
You're expecting it to replace the IAX side of the bridge with the first
SIP leg which is not what's going to happen. Nothing is going to change
the fact that the original call came in via IAX2 and thus will be
maintained as IAX2 no matter what happens on the other side. You could
go SIP1 -(302)-> Zap -(Busy)-> SIP2 and the originating side is STILL IAX2.

	Your asking questions is not what I'm referring to, this is after all a
forum where questions are expected. I'm referring to comments you
continually make that are outside your questions, such as "the silence
is deafening". It's not necessary. Your posting to a mailing list of an
open source development community which you are soliciting for help, for
free at that, and you consistently throw out little comments like that
and then you "Ugh" when someone responds and calls out you on it...

-Evan

Douglas Garstang wrote:
> Ah that reminds me. I absolutely disagreed with your statements about Asterisk not re-entering the dialplan. It does... you can see it on the console.
> 
> Ugh. You call it high school mentality. I call it asking honest questions.
> Whatever. I shall cease and desist, because no one seems to understand my frustration that IAX, seemingly designed for exactly this kind of thing doesn't do what it's touted to do.
> 
>> -----Original Message-----
>> From: Evan Borgström [mailto:evan.borgstrom at ca.mci.com]
>> Sent: Friday, August 11, 2006 10:53 AM
>> To: Asterisk Developers Mailing List
>> Cc: Douglas Garstang
>> Subject: Re: [asterisk-dev] 'IAX2 call variable passing 
>> between servers
>> '
>>
>>
>>
>> 	Are you kidding? I, along with many others, have addressed your
>> diagrams (my response was dated 8/8/2006 10:04am, in case you somehow
>> failed to read/see it).
>>
>> 	Stop with the crass remarks and get yourself out this 
>> high school
>> mentality that you seem to have in all of your posts. It's really
>> getting old...
>>
>> -Evan
>>
>> Douglas Garstang wrote:
>>> Someone asked me to post diagrams. I post diagrams... and 
>> the silence is deafening.
>>>> -----Original Message-----
>>>> From: Douglas Garstang 
>>>> Sent: Friday, August 04, 2006 11:49 AM
>>>> To: jaredsmith at jaredsmith.net; Asterisk Developers Mailing List
>>>> Subject: RE: [asterisk-dev] 'IAX2 call variable passing 
>>>> between servers
>>>> '
>>>>
>>>>
>>>> Jared,
>>>>
>>>> I sure can. He's a first, basic scenario. UA-A wants to reach 
>>>> UA-B. We first execute a ChanAvail() application command to 
>>>> determine the location of UA-B. We then attempt to reach UA-B 
>>>> via the supplied IAX path. There's nothing too unusual about 
>>>> this. Lots of people are doing this.
>>>>
>>>>  +------+           +-------+                          
>>>> +-------+           +------+
>>>>  |      |           |       | DUNDi Lookup of UA-B     |      
>>>>  |           |      |
>>>>  | UA-A | - SIP --> | PBX-1 | -------- IAX2 ---------> | 
>>>> PBX-2 | - SIP --> | UA-B |
>>>>  |      |           |       |                          |      
>>>>  |           |      |
>>>>  +------+           +-------+                          
>>>> +-------+           +------+
>>>>
>>>> Now, when UA-B forwards a call that came from UA-A to UA-C, 
>>>> it sends a 'Moved temporarily' message back to PBX-2. PBX-2 
>>>> re-enters the dial plan at this  point, looking for a new 
>>>> match for the forwarded call. It executes my AGI script 
>>>> again. Normally, the rdnis would be set, and the type of the 
>>>> call would be SIP. However, when the call has been trunked 
>>>> from another Asterisk system, the call type is instead IAX2, 
>>>> eventhough it should be SIP. As a result, because IAX2 does 
>>>> not convery rdnis, it gets lost.
>>>>
>>>>  +------+           +-------+                          
>>>> +-------+           +------+           +-------+           +------+
>>>>  |      |           |       | DUNDi Lookup of UA-B     |      
>>>>  |           |      | Moved     |       |           |      |
>>>>  | UA-A | - SIP --> | PBX-1 | -------- IAX2 ---------> | 
>>>> PBX-2 | - SIP --> | UA-B | - SIP --> | PBX-2 | - SIP --> | UA-C |
>>>>  |      |           |       |                          |      
>>>>  |           |      |           |       |           |      |
>>>>  +------+           +-------+                          
>>>> +-------+           +------+           +-------+           +------+
>>>>                                                               
>>>>                                 ^                          ^
>>>>                                                               
>>>>                                 |                          |
>>>>                                                               
>>>>                                 +- Appears as an IAX call--+
>>>>
>>>> A similar thing happens in the case of a transferred call. 
>>>> However, the dnid is set to the UA-B, and the extension is 
>>>> set to UA-C. Once again, because the call comes in as an IAX2 
>>>> call, the dnid is lost.
>>>>
>>>>  +------+           +-------+                          
>>>> +-------+           +------+           +-------+           +------+
>>>>  |      |           |       | DUNDi Lookup of UA-B     |      
>>>>  |           |      |           |       |           |      |
>>>>  | UA-A | - SIP --> | PBX-1 | -------- IAX2 ---------> | 
>>>> PBX-2 | - SIP --> | UA-B | - SIP --> | PBX-2 | - SIP --> | UA-C |
>>>>  |      |           |       |                          |      
>>>>  |           |      |           |       |           |      |
>>>>  +------+           +-------+                          
>>>> +-------+           +------+           +-------+           +------+
>>>>                                                               
>>>>                                 ^                          ^
>>>>                                                               
>>>>                                 |                          |
>>>>                                                               
>>>>                                 +- Appears as an IAX call--+
>>>>
>>>> I'm not sure if these diagrams help much.... but it's a 
>>>> start. Does this make any sense?
>>>>
>>>> Doug.
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Jared Smith [mailto:jaredsmith at jaredsmith.net]
>>>>> Sent: Friday, August 04, 2006 8:46 AM
>>>>> To: Asterisk Developers Mailing List
>>>>> Subject: RE: [asterisk-dev] 'IAX2 call variable passing 
>>>>> between servers
>>>>> '
>>>>>
>>>>>
>>>>> On Fri, 2006-08-04 at 08:32 -0600, Douglas Garstang wrote:
>>>>>> A far more serious issue is that at the other end of that 
>>>>> trunk, when
>>>>>> Asterisk makes calls to SIP phones, and those phones transfer or
>>>>>> forward calls, all new calls generated from those are 
>>>> flagged as IAX
>>>>>> calls instead of SIP calls. 
>>>>> I'm not sure we have enough information of your setup to be 
>>>>> able to help
>>>>> you out here.  Can you please explain (preferably on a web 
>>>> page, with
>>>>> pictures or diagrams) what you're trying to do, so we can 
>> understand
>>>>> what your complaint is?  I certainly can't offer any 
>>>> suggestions if I
>>>>> can't visualize what it is you're trying to accomplish.
>>>>>
>>>>> -Jared
>>>>>
>>>>> _______________________________________________
>>>>> --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
>>>>>
>>>> _______________________________________________
>>>> --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
>>>>
>>> _______________________________________________
>>> --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