Hi, I think it would be enough to say:
"If a proxy receives a 199 response out of dialog, it processes it as other non-100 provisional responses received out of dialog." I think the case when it will happen is really rare, so I don't see any advantage in specifying specific 199 procedures for what most likely is going to be an error case anyway. Regards, Christer > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of DRAGE, Keith (Keith) > Sent: 9. huhtikuuta 2009 14:05 > To: Tan, Ya Ching (NSN - DE/Munich); Christer Holmberg > Cc: [email protected] > Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07 > > 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 > _______________________________________________ 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
