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

Klaus Darilion klaus.mailinglists at pernau.at
Wed Apr 21 03:17:57 CDT 2010



Am 20.04.2010 22:44, schrieb 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.

So why will Asterisk resolve a domain when the result is not needed at 
all? That greatly reduces flexibility, e.g. for routing with domains 
which are not in DNS.

I agree with Olle that there could be a more consistent solution. If the 
dialstring setting just overwrites the outbound proxy setting of the 
peer it could be used more generic.

So all this stuff was implemented because one customer has exotic ideas 
  how to do routing? What if one customer ask for proper SRV support 
(including failover) - will it implemented too?

regards
Klaus


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



More information about the asterisk-dev mailing list