[asterisk-dev] Sorry for late response - dialstring changes and SRV support

[Olle E. Johansson]

20 apr 2010 kl. 21.54 skrev Kevin P. Fleming:

> Olle E. Johansson wrote:
> 
>> The changes to add IPorHOst to the dialstring needs to be discussed much much more. What happens if you already
>> have an outbound proxy? What happens if...
> 
> By using this option the dialplan writer is explicitly overriding the
> defined outbound proxy. It can be documented as such.
Is the code implemented that way, so that the peer DNS name is NOT resolved?


> 
>> I think the only proper way is to implement a dialplan variable that overrides any peer/channel outbound proxys and NOT have it in the dial string. 
>> There are simply too many combinations that will fail. If the peer has an ip address - what do we put in the URI? 
>> And why is there no peer setting for this?...
> 
> A channel variable is not a good solution, because it is nearly
> impossible to use for a Dial() that dials multiple peers at once.
Agreed. I'm still not happy with the syntax. 

> The
> information must be part of the dial string to be able to be associated
> with a specific outbound channel (dialog).
> 
> This does not affect the request URI at all. This functionality was
> built at the request of a user who wants to do their own complex
> SRV-like processing, for request URIs that map to multiple IP addresses,
> but have all the outbound calls be associated with the same SIP peer. In
> any normal usage of this functionality, the SIP peer that has been
> defined will be non-dynamic, and will have a 'host' address that is a
> DNS domain name. Again, the documentation can explicitly state that this
> should *not* be used for dynamic peers, or peers that are defined at a
> specific IP address.

Any combination of options will be used whatever we document...
You know that. This code has to be parsed as outbound proxy,
with support for DNS names and as a replacement of the configured
outbound proxy.

> 
> Since the dialplan writer has to explicitly invoke this functionality,
> there is no danger of it being triggered accidentally or affecting any
> existing dialplans or behavior.
I did not say that, did I?

> 
>> If you add a route to a SIP dialog, you need to add it as a route in the route set, which means outbound proxy and nothing else.
>> A channel variable that is documented to override peer outbound proxy settings, which overrides channel outbound proxy settings
>> would be useful.
> 
> See my comment above; channel variables are not useful for this scenario
> (or many scenarios), because they effectively limit the Dial() to a
> single outbound channel.
My point is that the code has to be aligned with the outbound proxy support.

/O