[asterisk-dev] classifying SIP peers

Olle E. Johansson oej at edvina.net
Mon Feb 10 13:25:01 CST 2014


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. 

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. 

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

/O


More information about the asterisk-dev mailing list