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

Douglas Garstang dgarstang at oneeighty.com
Fri Aug 11 10:03:03 MST 2006


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