[asterisk-dev] classifying SIP peers

[Matthew Jordan]

On Tue, Feb 11, 2014 at 11:55 AM, Daniel Pocock <daniel at pocock.com.au> wrote:
>
>
> On 11/02/14 03:13, Matthew Jordan wrote:
>> On Mon, Feb 10, 2014 at 1:25 PM, Olle E. Johansson <oej at edvina.net> wrote:
>>>
>>> On 10 Feb 2014, at 20:16, Daniel Pocock <daniel at pocock.com.au> wrote:
>>>
>>>>
>>>>
>>>> I'm looking at the way chan_sip.c matches peers (by name or by IP/port)
>>>>
>>>> It may be possible to add an extra discriminator, for example, it could
>>>> be called "class"
>>>>
>>>> [my-proxy-a]
>>>> host=192.168.100.1
>>>> class=group-a
>>>> dtlsenable=no
>>>>
>>>> [my-proxy-b]
>>>> host=192.168.100.1
>>>> class=group-b
>>>> dtlsenable=yes
>>>>
>>>>
>>>> The proxy then signals the desired class in the request URI, e.g.
>>>>
>>>>   INVITE sip:1234 at 192.168.100.2;x-asterisk-class=group-b
>>>>
>>>> If no tag is supplied or it doesn't match, it would fall back to a peer
>>>> with class=<nothing> (ensuring existing behavior is consistent)
>>>>
>>>> It appears that this logic can be inserted in most of the places where
>>>> callbackexten is used as a discriminator for peer selection.
>>>>
>>>> Has anybody else already started on anything like this on a branch or in
>>>> any third-party patch?
>>>
>>> I am not sure it is the right way to add it to a URI. I have thought of creating a
>>> branch where we control the peer choice with a header. It implies *A LOT* of trust,
>>> but in some systems it would be useful.
>
> I'm thinking of a situation where an edge proxy is used with Asterisk
> and the proxy is adding the class parameter to the request URI
>
> In my use case, the main reason for this is simply to separate the
> different types of WebRTC callers (Chrome/without DTLS, Firefox with
> DTLS) and also standard SIP callers (no AVPF/maybe no icesupport)
>
>
>>>
>>> No, I have no similar code. No, I don't like complicating the peer configuration
>>> with a new setting called "class". A simple header that tells you the peer name
>>> is propably enough. The header should be configured in the "[general]" section
>>> and there has to be ACLs on the peers.
>
> That is another interesting permutation, I agree it is simpler and for
> those who trust their proxy it is just as valid
>
>>> Maybe one way could be to copy the ideas I had in the match-beyond-proxy
>>> code that I actually have in a branch. In that you first hit one peer definition
>>> and that one leads somewhere else. Like:
>>>
>>> [my-proxy]
>>> host=192.168.100.1
>>> peerselectheader=Peername
>>>
>>> [my-proxy-nodtls]
>>> host=192.168.100.1
>>>
>>> I would force the user of the same peer name as a prefix so that we don't
>>> open ALL peers for a single peer. In the case above the my-proxy-nodtls
>>> would be selected by adding the header "Peername: nodtls" to the
>>> SIP request.
>>>
>>> Just thinking loud...
>>
>> I agree with Olle. Complicating peer matching in chan_sip isn't
>> something I would ever encourage. Each request type in chan_sip is
>> handled just slightly differently in how it looks up a peer (or, for
>> that matter, a "user") - so to fully deploy this logic, you would have
>> a ripple effect across all of the request handlers. Further
>> complicating it is whether or not users.conf is in use, or realtime,
>> or... you get the idea. Given the structure of chan_sip, this is not
>> easy to get right in a universal fashion.
>>
>> However, if you're interested in adding this kind of functionality,
>> I'd highly recommend looking at the new PJSIP-based stack in Asterisk
>> 12. It supports the notion of custom endpoint identifiers, which are
>> implemented entirely in separate modules.
>
> I had a look over this, what you describe is very relevant. Is the
> Asterisk 12 code at a stage where people should be considering it for
> production projects though?  I don't want to be rushing Digium to
> announce it is stable though.
>

"Stable" or "production" are things that you have to determine for
yourself. I don't know your system, or your deployment requirements.
It's open source software; if it works for your system, then great. If
not, then the good news is that it's open source! There's a community
of developers around to help you figure out what is going on.

Speaking only for Digium, I will point out that we are actively
developing, improving, and testing the PJSIP stack in Asterisk. Going
forward, I would expect that - barring bug fixes in chan_sip - the new
SIP stack is what will receive the vast majority of our attention.

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org