Tan wrote: > [Tan] The RFC has to be able to stand by itself and not be > dependant on > what implementations would normally do.
It is obviously impossible to implement 199 without also implementing and conforming to RFC 3261. If the required behaviour is already specified in RFC 2119 language in RFC 3261, then we should not repeat that requirement in the 199 draft. Any RFC 2119 language should be limited to requirements that are changes to RFC 3261 behaviour. regards Keith > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Tan, Ya Ching (NSN - DE/Munich) > Sent: Thursday, April 09, 2009 11:56 AM > To: ext Christer Holmberg > Cc: [email protected] > Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 > > Comments inline start with [Tan] : > > -----Original Message----- > From: ext Christer Holmberg [mailto:[email protected]] > Sent: Thursday, April 09, 2009 11:32 AM > To: Tan, Ya Ching (NSN - DE/Munich) > Cc: [email protected] > Subject: RE: [Sip] Draft new version: draft-ietf-sip-199-07 > > > ---snip snip--- > > I would then propose that we say that a proxy SHOULD drop > unreliable 199 > responses which are sent out-of-dialog. > > If the 199 response is sent reliably, I don't think we can drop it. > > [Tan] 199 response sent reliably out-of-dialog are still illegal 199. > If the proxy can't drop it, does it create a new dialog with > its new To > tag like any non-100 responses ? Do we forward such reliable 199 > responses to UAC which did not indicate support of 199 just > because you > think that we cannot drop reliable 1xx. If yes, such reliable but > illegal 199 responses will create new early dialogs at UAC. > Even if the > UAC has indicated support of 199, should the reception of > out-of-dialog > 199 by UAC create a new early dialog ? > > ---snip snip--- > > >and RFC3261/13.2.2.4: > > > >The UAC core considers the INVITE transaction completed > >64*T1 seconds after the reception of the first 2xx response. > At this > >point all the early dialogs that have not transitioned to established > dialogs are > >terminated. Once the INVITE transaction is considered completed by > >the UAC core, no more new 2xx responses are expected to arrive. > > Implementations will normally terminate all other early > dialogs when the > first 2xx is recevied. Then, if additional 2xx response (on other > dialogs) are received, implementations will normally send ACK+BYE for > them. So, yes, the INVITE transaction is still alive, but the early > dialogs are normally terminated. > > [Tan] The RFC has to be able to stand by itself and not be > dependant on > what implementations would normally do. > > > Regards, > Ya-Ching > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [email protected] for questions on current sip > Use [email protected] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
