[Asterisk-Dev] Multiple Routes for an * channel

[Eric Liedtke]

It's seems fuzzy now but I think on Thu, Oct 14, 2004 at 02:58:51PM -0400 , John Todd said:
> At 6:07 PM -0500 10/12/04, Eric Liedtke wrote:
> >
> >I recently started poking around chan_sip to look into the 300 "Multiple
> >Choices" support. I found that enabling the promiscredir I could at
> >least use the first route, however I needed to be able to process and
> >use all the routes returned.
> >
> >I started looking into being able to support this in chan_sip and the
> >more I looked, the more it seemed to make sense to implement this in the 
> >base
> >ast_channel. I figured a route_list type construct could be used by more
> >than just chan_sip. Perhaps the EnumLookup() or even SRV lookup's would
> >then be able to use multiple routes, process weights,  etc.
> >
> >I did a proof of concept implementation with a simple linked list added
> >to ast_channel and created the necessary auxillary funtions to add
> >routes, free the list, etc.
> >
> >I think the actual internal behaviour is a little screwy though, I
> >copied the methodology used in the parse_moved_contact but employed it
> >in app_dial's wait_for_answer(). Basically if there is still a route
> >on the list then I move it into the call_forward field with that route
> >and then free() that entry from the list. It then copies remaining
> >routes into the list of the new channel. If the call get's answered I
> >also free the list.
> >
> >As this is my first foray into the guts of * I am just looking for
> >comments on the idea and any advice as to perhaps, a "more proper"
> >methodology for dealing with multiple routes than just setting the
> >call_forward of a channel every time..
> >
> >-e
> 
> I'm uncertain about how this should be handled, but I'm pretty sure 
> it shouldn't be dealt with in the Dial application.  I'm not 
> disagreeing with anything you're saying, particularly, but I think 
> that the redirected numbers or list of routes needs to be handed back 
> to the dialplan.
> 
> Here's the problem: we're making an assumption about where a call is 
> being sent when we call the Dial application.  We know what number 
> we're dialing, what channel type we're using, etc.  If we take 
> "redirects" from Dial and handle them internally with no external 
> processing, it's possible for the system to do things which may not 
> be permitted by other rules or processing logic which exists in the 
> dialplan.
> 
> Here's an example: I forbid my users from dialing "_1900." numbers in 
> my dialplan.  All my calls terminate through a SIP service provider. 
> Let's say that a user dials "18001234567", which then gets mapped to 
> my SIP gateway, in the fashion of:  SIP/sipgateway1/18001234567". 
> But... when the call reaches sipgateway1, it gets a redirect to 
> 19005551212.  Do I want the Dial application just to go forward with 
> that redirect and dial the number?  This essentially lets external 
> systems not necessarily under my control redirect calls to 
> destinations that I don't want.  Those destinations could be more 
> expensive, poor quality, administratively prohibited, or any number 
> of other things.  I'd like to have the redirected numbers, or 
> multiple choice answers, handed back to the dialplan so that I can 
> sequentially run the different answers through my dialing ruleset 
> before creating another outbound leg.
> 
> This may "violate" the concept that the end devices rule the network, 
> and that may be true.  At a minimum, I would like to maintain the 
> _ability_ to control dial paths, but I don't always necessarily want 
> to control those paths.  But if we ignore this issue now, it will be 
> impossible to recover from such a mistake once applications are in 
> place that don't work that way.
> 
> JT
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

Yup all valid points, which is why i posted ; ).

Perhaps it would make more sense to add the route constructs to the
channel and then provide a couple of applications to
control/retrieve/manipulate a route list. Something like
GetNextRoute(VARNAME), could pull the next unattempted route from the
list and populate it in VARNAME making it available in the dialplan in
the same fasion as EnumLookup does today, RoutesAvailable() could
provide a method for determining if there are any routes available,
returning the number of routes left. So a combo of
GotoIf(RoutesAvailable()), Dial, and GetNextRoute in a dialplan could
achieve this sort of functionality allowing you to do any
checking/verification you wnated inbetween the GetNextRoute and the
Dial.  Does this seem like a reasonable solution ? 

There are also cases where I might be in control of the DNS Zone or the
proxies offering the 300's and would inherently trust the response's
from these device's since I provisioned them. Would it make sense to add
a flag to Dial() to just basically invoke the behaviour of cycling
through the route list without input from the Dialplan.  I don't
know if anyone wants to add another flag to Dial() based on some of the
threads recently but I don't know where else it would make sense to invoke
that sort of behaviour, if anyone even thinks it's necessary to be able
to do that. It just seems that it might be a little more efficient that
looping in the dialplan if you trust those responses and you are trying
to push high call volumes.

Any other comments/idea's would be appreciated. If there is any
consensus on the design I'd be happy to do the implementation just don't
want to create something that's broken from the get-go. 

-e