[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Sip timers and what granularity do we want in the sip protocol mib?
I think T1, T2, T4 and Timer D are enough.
Regards,
Hisham
> -----Original Message-----
> From: ext Drage, Keith (Keith) [mailto:drage@lucent.com]
> Sent: Wednesday, February 26, 2003 7:56 PM
> To: 'Sean Olson'; Jean-Francois Mule; sip@ietf.org
> Cc: Kevin Lingle; Kavitha P.
> Subject: RE: [Sip] Sip timers and what granularity do we want
> in the sip
> protocol mib?
>
>
> For use over the radio interface, 3GPP has recommended longer
> values of some of these timers, based on the increased round
> trip delay that might be expected. Therefore an piece of user
> equipment that can use SIP in either mobile environment or
> directly connected to the internet might need to be able to
> alter the values of these timers.
>
> Of course, whether that is best done by the MIB or not is a
> different question.
>
> Keith
>
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: drage@lucent.com
>
> > -----Original Message-----
> > From: Sean Olson [mailto:seancolson@yahoo.com]
> > Sent: 26 February 2003 16:57
> > To: Jean-Francois Mule; sip@ietf.org
> > Cc: Kevin Lingle; Kavitha P.
> > Subject: Re: [Sip] Sip timers and what granularity do we want
> > in the sip
> > protocol mib?
> >
> >
> > It would be interesting to know how common it is
> > for implementations to actually change these
> > timer values. In other words, do these really
> > need to be exposed in the MIB at all?
> >
> >
> > --- Jean-Francois Mule <jf.mule@cablelabs.com> wrote:
> > > We have currently some tables for timers & retry
> > > counters in
> > > sip-mib-draft04 (sipCommonCfgTimer and
> > > sipCommonCfgRetry).
> > > Reading more about rfc3261, it seems that SIP
> > > entities have to set the
> > > various variable timers (Timer A - K based on T1 by
> > > default or as the
> > > spec mandates it). Most if not all default timer
> > > values are dependent on
> > > the value of T1.
> > >
> > > So, in the past sip mib drafts, we've always
> > > provided more flexibility
> > > (i.e. provided ways to touch specific method timers
> > > without affecting
> > > their default values to T1 but allowing more
> > > granularity if needed). I
> > > see the same proposal here. In other words, we've
> > > got 2 options:
> > >
> > > --- OPTION A - define atomic timers
> > > (this is my preference even if it means default all
> > > the atomic timers to
> > > multiples of T1)
> > >
> > > SipCommonCfgTimerEntry ::= SEQUENCE {
> > > sipCfgTimerA Unsigned32,
> > > sipCfgTimerB Unsigned32,
> > > sipCfgTimerC Unsigned32,
> > > sipCfgTimerD Unsigned32,
> > > sipCfgTimerE Unsigned32,
> > > sipCfgTimerF Unsigned32,
> > > sipCfgTimerG Unsigned32,
> > > sipCfgTimerH Unsigned32,
> > > sipCfgTimerI Unsigned32,
> > > sipCfgTimerJ Unsigned32,
> > > sipCfgTimerK Unsigned32,
> > > sipCfgTimerT1 Unsigned32,
> > > sipCfgTimerT2 Unsigned32,
> > > sipCfgTimerT4 Unsigned32
> > > }
> > >
> > > --- OPTION B - define t1, t2, t4 and that is it.
> > > One can make the argument that that is all we really
> > > need.
> > > SipCommonCfgTimerEntry ::= SEQUENCE {
> > > sipCfgTimerT1 Unsigned32,
> > > sipCfgTimerT2 Unsigned32,
> > > sipCfgTimerT4 Unsigned32
> > > }
> > >
> > >
> > > Looking at it from an implementation point of view,
> > > I've always
> > > preferred to expose more granularity rather than the
> > > bare minimum (it is
> > > often built it in the code anyway).
> > >
> > > Any comments?
> > > Jean-Francois.
> > > ---
> > > _______________________________________________
> > > Sip mailing list
> > > https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP
> > > Protocol
> > > Use sip-implementors@cs.columbia.edu for questions
> > > on current sip
> > > Use sipping@ietf.org for new developments on the
> > > application of sip
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - forms, calculators, tips, more
> > http://taxes.yahoo.com/
> > _______________________________________________
> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip