Re: Draft new version: draft-ietf-sip-199-07

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