[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.

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 :-)


> On April 23, 2014, 9:13 a.m., Mark Michelson wrote:
> > /trunk/channels/chan_sip.c, lines 30787-30791
> > <https://reviewboard.asterisk.org/r/3438/diff/1/?file=57236#file57236line30787>
> >
> >     I'm a bit confused by this. If the configured timerc value is greater than 100 seconds, then that is considered invalid and the default of 180 seconds is used instead.
> >     
> >     RFC 3261 Section 16.6, bullet point 11 states that timer C MUST be larger than 3 minutes. I would expect, then, that if the configured value were less than 180 seconds, that is when you would consider the configuration to be invalid and go with the default value of 180 seconds.
> 
> Matt Jordan wrote:
>     Hey Olle - I took a look at RFC 3261 to see what Mark was alluding to here, and I think he is right - the minimum shouldn't be less than 3 minutes:
>     
>     {quote}
>     11. Set timer C
>     
>              In order to handle the case where an INVITE request never
>              generates a final response, the TU uses a timer which is called
>              timer C.  Timer C MUST be set for each client transaction when
>              an INVITE request is proxied.  The timer MUST be larger than 3
>              minutes.  Section 16.7 bullet 2 discusses how this timer is
>              updated with provisional responses, and Section 16.8 discusses
>              processing when it fires.
>     {quote}
>     
>     Is there a reason why we wouldn't go with a default value of 180 seconds, per the RFC?
> 
> Olle E Johansson wrote:
>     180 seconds is not really a good solution, like 500 ms as the base for T1, in real life situations. I took it down to 100 in my implementation since it gave a better solution for the user. The proxy case is a bit different than a user agent in my humble opinion. I won't pick a fight over this though, as I have more important issues to fight over in my code :-)

How about we set the default to 180, but let someone set it lower if they want? That gets the best of both worlds!


- 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/63c97fb6/attachment-0001.html>