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