[asterisk-dev] [Code Review] Explicit context set in SIP peer overridden by default domain context

[Mark Michelson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/565/#review1825
-----------------------------------------------------------


As far as code integrity and falling within the Asterisk coding guidelines goes, this is very well done. Great work!

The only thing is that I don't really feel comfortable greenlighting a behavior change such as this one without some sort of discussion and/or consensus being reached first. It's mainly due to the fact that I'm not one who uses SIP domains. I agree with this change myself, for the record. Could someone else please weigh in on this? Olle, perhaps?

- Mark


On 2010-04-09 14:41:36, pprindeville wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/565/
> -----------------------------------------------------------
> 
> (Updated 2010-04-09 14:41:36)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Having inbound SIP 'guest' calls associated to a default context is
> handy, especially when multi-tenancy or hosting multiple domains is
> being done.
> 
> However, the code as written will clobber an explicitly configured
> context associated with a peer if a domain-list is configured.
> 
> This is counter-intuitive, since (a) explicit configuration should
> always trump default or implicit config, and (b) puts all internal
> domain-bound SIP handsets in the same context as guest callers, making
> it hard to apply a restricted dialplan to guest callers.
> 
> 
> This addresses bug 17040.
>     https://issues.asterisk.org/view.php?id=17040
> 
> 
> Diffs
> -----
> 
>   branches/1.6.2/channels/chan_sip.c 256425 
> 
> Diff: https://reviewboard.asterisk.org/r/565/diff
> 
> 
> Testing
> -------
> 
> Running patched 1.6.2.6 on our production network.  Seems to work fine.
> 
> 
> Thanks,
> 
> pprindeville
> 
>