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

[Klaus Darilion]

Hi Kevin!

Am 21.04.2010 13:16, schrieb 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

Actually I assumed something in between, just implementing a hacks for a 
certain scenario without taking a look at the big picture (of SIP and 
routing in general).

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

Ok.

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

Ok. I failed to understand what this feature solves exactly. But again, 
this could have been implemented more generic too. E.g. the 
outboundproxy setting could have been extended to be used just for the 
out-of-dialog requests or for all requests (or even messages). This can 
be useful for other scenarios too. Then, overwriting the outboundproxy 
and setting the outboundproxy-mode to "always" would do the trick. (A 
config option to enable/disable a Route header for the next hop would be 
useful too).

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

I tend to disagree. Of course it is nice to have full fail-over control 
in the dialplan. But it also would be nice to just Dial(SIP/user at domain) 
and Asterisk will choosing the proper SRV record and performs automatic 
fail-over.

So, when doing the fail-over logic manually in the dialplan, how do you 
specify how long to wait for a response from the next hop before trying 
the next destination? The normal Dial timeout is not useful for 
fail-over timing.

regards
klaus