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

[Kevin P. Fleming]

Olle E. Johansson wrote:
> 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?

No, the way the code is written right now, the normal lookup process is
done, and then the remote address for the dialog is overwritten with the
supplied address if one has been supplied.

>>> 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. 

Feel free to suggest something better.

>> 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.

It does have support for DNS names, although it does not do SRV lookups
(since that is already possible via other means). It effectively
replaces the configured outbound proxy, but for only for the specific
dialog it is applied to.

>> 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?

It seemed like you were concerned that this might affect existing
dialplans, yes. Your comments carried the tone of this change being
'architectural' in nature, when it isn't; it's just a single feature
that allows the dialplan writer to override one aspect of chan_sip's
defined behavior.

>>> 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.

I'm not aware of that being required, actually. Can you describe more
specifically what you mean by that? Remember that the entire goal of
this feature is be able to replicate the existing behavior of chan_sip
when presented with a DNS name that maps to SRV records, but to do it in
a decomposed way that allows the dialplan author to affect the result if
they wish. Given that, I'm not sure how proxies enter into the picture,
because if an Asterisk installation is sending all its SIP traffic
through a proxy, then I'd expect the proxy to be the responsible party
for doing SRV lookups for the DNS names present in the request URIs, not
Asterisk. If an Asterisk installation is using an outbound proxy, then
this new feature seems totally inapplicable to that installation, and
the administrator can just ignore it.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org