On Tue, Feb 11, 2014 at 11:55 AM, Daniel Pocock <dan...@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 <o...@edvina.net> wrote: >>> >>> On 10 Feb 2014, at 20:16, Daniel Pocock <dan...@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@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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev