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

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

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

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.

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

> I also think the SRV function needs to be built on a proper implementation in the channel, not as a separate addon.
> The channel needs to be aware of the current choice and stay there, and be able to switch if the current choice
> fails.

This code is not in any way an attempt to make chan_sip be RFC 3263
compliant, so please don't assume that it was :-) Again, this was built
because there is an end user who wants to do some of their own (outside
Asterisk) processing of SRV lookup results to decide which of the
candidates they wish to send calls to, and in the true spirit of the
Asterisk model, we built a small tool that can be leveraged through
dialplan/AGI/etc. programming to achieve the result. Even if we do end
up building full RFC 3263 support for chan_sip, I would expect it to
*not* be embedded inside chan_sip, but rather another module that allows
the administrator some flexibility in deciding which of the candidates
returned by the SRV lookup they are willing to deliver the call to.
Doing it inside chan_sip means having a multitude of configurable knobs
to control whether things like TLS are required/acceptable/not
acceptable, whether the channel driver should be using some sort of
'qualify' mechanism in advance to each of the candidates, etc. This
cries out for the ability of the administrator to be able to write their
own logic for how to decide which candidates are acceptable, with
examples provided that demonstrate the 'standard' behavior. In this
model, chan_sip would end up being configured to refer to some logical
name (probably the DNS domain name for the service) but it would get
targets from the other module when it needs them.

> No, I have no patch. I just have opinions.

Constructive technical opinions are certainly welcome; the more the merrier.

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