[Asterisk-Dev] Multiple Routes for an * channel

[John Todd]

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