[asterisk-dev] [Code Review] 3438: Implement SIP TImer C in Asterisk

[Matt Jordan]

> On April 23, 2014, 9:13 a.m., Mark Michelson wrote:
> > /trunk/channels/chan_sip.c, lines 22992-22996
> > <https://reviewboard.asterisk.org/r/3438/diff/1/?file=57236#file57236line22992>
> >
> >     RFC 3261 section 16.7, bullet point 2 states:
> >     
> >     "...if the response is a provisional response with status codes 101 to 199 inclusive (i.e., anything but 100), the proxy MUST reset timer C..."
> >     
> >     This else case needs to be modified to not execute if the response is a 100.
> 
> Matt Jordan wrote:
>     I think I agree with Mark here as well, and the RFC makes sense when it says to not reset Timer C on a 100. There's no real need to reset Timer C in that case, as that typically comes directly on the heels of the transmitted INVITE request.
> 
> Olle E Johansson wrote:
>     I am not sure. What's the use case for not doing it on 100. I understand why a proxy should not react to a 100, since it's hop by hop, but for a UA I don't see the point of your comment.
> 
> Matt Jordan wrote:
>     I would guess it is for two reasons:
>     
>     (1) Timer C is started when the INVITE request is first processed. A 100 Trying received from who you just sent the INVITE request to is extremely likely to happen very quickly, since the UAS should be sending the 100 Trying on immediately receiving the INVITE request. Resetting the timer on the 100 Trying doesn't really offset the timer by much.
>     
>     (2) More specifically, this probably relates to stateful proxies not forwarding 100 Trying messages. Since we aren't a proxy, that's probably of less impact in this case.
>     
>     I'd bypass resetting the timer on a 100 for two reasons:
>     (1) It doesn't add much value to reset the timer in the first place on a 100
>     (2) It precludes (yet another) "you don't follow the RFC" bug report :-)
> 
> Olle E Johansson wrote:
>     This doesn't make sense for a UA. We should reset it for any responses. By implementing this timer and calling it Timer C and not AstTimer Q we break the RFC any way. ;-)

Barring a strong technical reason for not resetting the timer on a 100 - which I don't have, other than "the RFC says not to" - I'm okay with that. If someone files that issue, I suppose I can always reply with "patches welcome" :-)


- Matt


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


On May 16, 2014, 7:32 a.m., Olle E Johansson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3438/
> -----------------------------------------------------------
> 
> (Updated May 16, 2014, 7:32 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> SIP Timer C is defined for proxys that forward messages. In some ways, we forward calls. It is activated when we receive a 100 trying and wait for any other message. If that's not received, timer C triggers and cancels the call attempt.
> 
> This is required in an interoperability test I'm working with.
> 
> Red dots will be handled in the way they deserve.
> 
> 
> Diffs
> -----
> 
>   /trunk/configs/sip.conf.sample 414046 
>   /trunk/channels/sip/include/sip.h 414046 
>   /trunk/channels/chan_sip.c 414046 
>   /trunk/CHANGES 414046 
> 
> Diff: https://reviewboard.asterisk.org/r/3438/diff/
> 
> 
> Testing
> -------
> 
> Passed interoperability testing with funky test tool.
> 
> 
> Thanks,
> 
> Olle E Johansson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140521/ec856dda/attachment.html>