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

[Kevin P. Fleming]

Klaus Darilion wrote:
> 
> 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.

Why do you assume this was a design decision, and not an oversight? This
is why the code was posted to ReviewBoard, so that people with an
interest in talking about how it was implemented could do so. Now that
the issue has been brought up, it seems perfectly reasonable for
chan_sip to be modified to skip the entire address resolution process
for the peer's configured address if the 'override address' has been
supplied.

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

How? I've asked twice now and I've seen no examples of how this would
improve the situation. As best I can tell, this is in fact *not* the
case, because the outbound proxy setting on a dialog is only used
directly for the first request on the dialog; the remaining requests on
the dialog go directly to the contact address supplied by the remote
endpoint, unless the proxy adds a Record-Route to force the requests to
be sent through the proxy. This is entirely different behavior from what
is desired here.

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

Umm... yes. Just like all Asterisk feature requests that get development
time. If Digium has a paying customer that wants to have us add full RFC
3263 support (which is different from 'proper SRV' support, since we're
talking about SRV in the context of SIP specifically here), then it's
likely one of our developers would be tasked with writing that code...
this is no different from a paying customer paying a community developer
to do it. In addition, this feature was built this way because it can
*already* be used from the dialplan to implement RFC 3263-style server
location, by implementing the failover logic in the dialplan (or AGI, or
something similar), which is far preferable to the logic being embedded
in chan_sip.

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