> 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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
