[asterisk-dev] [Code Review] Just remove the silly SIP registertrying option

[wdoekes]

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

Ship it!


Good riddance.


/branches/1.8/channels/sip/include/sip.h
<https://reviewboard.asterisk.org/r/1562/#comment8844>

    http://lists.digium.com/pipermail/asterisk-dev/2011-October/051596.html
    
    Removing 1<<24 would've been sufficient/better.


(Ah, I seemed to have be working in a very stale branch where r325279 hadn't killed the 100's for alwaysauthreject victims yet. That explains things.)

- wdoekes


On Nov. 2, 2011, 5:27 p.m., Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1562/
> -----------------------------------------------------------
> 
> (Updated Nov. 2, 2011, 5:27 p.m.)
> 
> 
> Review request for Asterisk Developers and wdoekes.
> 
> 
> Summary
> -------
> 
> Way back in the day, Asterisk sent a 100 Trying when receiving a register request, despite RFC 3261 stating:
> 8.2.6.1 Sending a Provisional Response
> 
> One largely non-method-specific guideline for the generation of
> responses is that UASs SHOULD NOT issue a provisional response for a
> non-INVITE request. Rather, UASs SHOULD generate a final response to
> a non-INVITE request as soon as possible.
> 
> Someone initially tried to remove the 100 Trying in https://issues.asterisk.org/jira/browse/ASTERISK-9157 , but cries of "there might be phones that require this behavior!" were made and YAUO (yet another useless option) was added to chan_sip. There is no conceivable way that someone would write code that requires a provisional 100 response to a REGISTER. It would be an absurd amount of going out of one's way to write broken code. Add to that the fact (as wdoekes points out on the mailing list) that the flag is set on the peer, not copied to the pvt, but checked on the pvt anyway--it hasn't even worked all these years.
> 
> Even better, fixing the code would lead to the same kind of username disclosure as the nat= debacle we are trying to clean up. This leads me to the happy conclusion that we should finally just rip this code out. This patch does that.
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 343161 
>   /branches/1.8/channels/sip/include/sip.h 343161 
> 
> Diff: https://reviewboard.asterisk.org/r/1562/diff
> 
> 
> Testing
> -------
> 
> It compiles.
> 
> 
> Thanks,
> 
> Terry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111102/1b7129a7/attachment.htm>