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

[Olle E Johansson]

> On April 23, 2014, 4:13 p.m., Mark Michelson wrote:
> > Like Matt, I'm also a bit confused on the use case for a proxy-specific timer. At the same time, though, I have to say that this can be a useful feature to have in case a situation were to arise where Asterisk sends out an INVITE, gets a provisional response (which kills timer B), and then never gets any further response. This would allow for the call to be torn down automatically in such a situation. In fact, I'm curious what a UAC is supposed to do in such a situation if it does not implement timer C.

Exactly.


> On April 23, 2014, 4:13 p.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.

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.


> On April 23, 2014, 4:13 p.m., Mark Michelson wrote:
> > /trunk/configs/sip.conf.sample, lines 583-592
> > <https://reviewboard.asterisk.org/r/3438/diff/1/?file=57238#file57238line583>
> >
> >     Since the other timers are configured with milliseconds, I suggest configuring timer c in milliseconds as well.

I do not agree.


> On April 23, 2014, 4:13 p.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?

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


- Olle E


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


On May 16, 2014, 2:32 p.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, 2:32 p.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/a5fc576b/attachment-0001.html>