[asterisk-dev] [Code Review]: Ensure that Min-SE is included if a 422 was ever returned

[opticron]

> On Dec. 4, 2012, 5:21 p.m., Mark Michelson wrote:
> > First off, the changes you have regarding the use of a named constant instead of magic numbers are great, as is the change you made regarding the setting of the cached Min-SE.
> > 
> > The other parts seem off.
> > 
> > The test you have created is not valid. If Asterisk is set to "accept" mode, then it should not be putting any sort of session-timers headers in the initial INVITE. If it's not sending any session-timer headers in the INVITE, then it doesn't make sense that the endpoint would respond with a 422 since there was no proposed session interval. If we do go up against an endpoint that sends us a 422 when we haven't proposed session timers, then I'm really not sure how we should react to that, to be honest. Since they should be proposing a Min-SE in their 422, we could potentially respond with some sort of Session Timer proposal, but that would violate the local policy of what "accept" means. I think that if we receive a 422 when we're in "accept" mode, then we're clearly dealing with a broken implementation and should not attempt to renegotiate.
> > 
> > The change you have put in now can result in placing a Min-SE header but no Session-Expires header in the initial INVITE when in "accept" mode, which is less than ideal.
> >
> 
> opticron wrote:
>     When in "accept" mode, Asterisk offers "timer" in the Supported header.  This allows intermediate proxies to place a Session-Expires header in the invite or to reduce the value thereof according to RFC 4028.  Later proxies or the final recipient of the message can then respond with a 422 specifying a Min-SE header which Asterisk will be required to include in all further attempts.
>     
>     I agree that Asterisk should not be placing a Min-SE or Session-Expires in the initial invite when in "accept" mode.  The test for including that needs a little tweaking.

Actually, including a Min-SE in the initial invite when in "accept" mode could prevent the situation where we receive a 200 OK with an unacceptably low Session-Expires (according to peer configuration) and need to tear down the call after the fact (which doesn't currently happen, see ASTERISK-20653).  The end result would be acceptance of a call that does not conform to the configuration of the peer.  If/When ASTERISK-20653 gets fixed, this situation becomes less of an issue since the call can be torn down as expected.


- opticron


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


On Nov. 30, 2012, 4:26 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2222/
> -----------------------------------------------------------
> 
> (Updated Nov. 30, 2012, 4:26 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> RFC 4028 states that if a 422 response is ever received during a session refresh or during a call attempt (and the UAC wishes to retry), the all subsequent attempts or refreshes must have a Min-SE header.  Asterisk does not currently do this if operating in the "accept" mode.  This patch corrects this behavior and swaps out a few magic numbers for a pre-existing constant.
> 
> This was discovered when writing the test for https://reviewboard.asterisk.org/r/2223/
> 
> 
> This addresses bug SWP-5051.
>     https://issues.asterisk.org/jira/browse/SWP-5051
> 
> 
> Diffs
> -----
> 
>   branches/1.8/channels/chan_sip.c 376948 
> 
> Diff: https://reviewboard.asterisk.org/r/2222/diff
> 
> 
> Testing
> -------
> 
> Before this patch, the test in https://reviewboard.asterisk.org/r/2223/ failed.  After the patch, it passes.
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121205/78e7651b/attachment.htm>