[asterisk-dev] [svn-commits] mmichelson: branch group/pimp_my_sip r380244 - /team/group/pimp_my_sip/res/

[Mark Michelson]

On 01/28/2013 01:49 AM, Olle E. Johansson wrote:
> 28 jan 2013 kl. 08:42 skrev SVN commits to the Digium repositories <svn-commits at lists.digium.com>:
>
>> The most common case for contact ACLs is for REGISTER requests. Of the various SIP
>> request types, REGISTER is most likely to contain multiple contact headers. With
>> this change, all contact headers are checked against contact ACLs.
> REGISTER is propably the ONLY with multiple contact headers. You want to check the
> contact headers for INVITEs and SUBSCRIBEs too.
Let me preface my reply by reiterating what the commit message that 
added res_sip_acl.c said. The module is something
that I created in my spare time as a proof of concept. The actual code 
that will end up in Asterisk for ACL handling will go through a design 
phase before actually going in. The code in res_sip_acl.c is meant to be 
used as a way of demonstrating sorcery as well as the modular nature of 
the new SIP work. It's possible some of the final ACL code may be in 
part based on this proof of concept, but the current code should in no 
way be seen as final.

Now to answer you more directly: the code in res_sip_acl.c checks all 
SIP request types, not just REGISTERs. In my initial commit, I would 
only ever check the first Contact header against the contact ACL. I 
realized that it's possible for REGISTERs to have multiple Contact 
headers, so I should account for that by checking all Contact headers in 
all incoming requests.

>
> Now, unless the REGISTER contacts have the same instance ID, how would you support this situation with multiple contacts for a sip endpoint?
> It's the same situation as multiple registrations for one sip account.

The code as currently written will outright reject the message with a 
403 response if there is any violation of any of the contact ACLs. This 
means that if an endpoint sent a REGISTER that attempted to bind 3 
contacts to an address of record, and one of those three violated the 
contact ACL, then none of the contacts would be bound. If the endpoint 
sent three separate REGISTERs, each with a different contact, then only 
the one in violation would be rejected.

I suspect that the code will be altered significantly, at least with 
regards to contact ACLs. Contact ACLs are a higher-level concept than 
plain ACLs, so their behavior should probably be left up to handlers of 
individual request types.

Mark Michelson

>
> /O
> --
> _____________________________________________________________________
> -- 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