Re: Draft new version: draft-ietf-sip-199-07 - comment onsection 7

"Christer Holmberg" <[email protected]>
Newsgroups gmane.ietf.sip
Message-ID <CA9998CD4A020D418654FCDEF4E707DF0C4E490A@esealmw113.eemea.ericsson.se>
 
>Yep, unless there really is a new "MUST" to write in the 199 draft.

Not in my opinion.

Regards,

Christer



> > -----Original Message-----
> > From: Christer Holmberg [mailto:[email protected]]
> > Sent: Thursday, April 09, 2009 5:54 AM
> > To: DRAGE, Keith (Keith); Tan, Ya Ching (NSN - DE/Munich)
> > Cc: [email protected]
> > Subject: RE: [Sip] Draft new version: draft-ietf-sip-199-07 
> - comment 
> > onsection 7
> > 
> > 
> > Hi,
> > 
> > >Is that a "MUST" or something that is not must like "RFC
> > 3261 specifies
> > when a final response is sent."
> > 
> > RFC 3261 does specify when a final response is sent. Would 
> you prefer 
> > something like:
> > 
> > "The 199 Early Dialog Terminated response code does not "replace" a 
> > final response. RFC 3261 specifies when a final response is sent."
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > > > -----Original Message-----
> > > > From: [email protected] [mailto:[email protected]] On
> > > Behalf Of
> > > > Christer Holmberg
> > > > Sent: Wednesday, April 08, 2009 9:09 PM
> > > > To: Tan, Ya Ching (NSN - DE/Munich)
> > > > Cc: [email protected]
> > > > Subject: Re: [Sip] Draft new version: draft-ietf-sip-199-07
> > > - comment
> > > > on section 7
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > -----
> > > > 
> > > > >2) Section 7 Backward compatibilility
> > > > >
> > > > >"The 199 Early Dialog Terminated response code does not
> > > "replace" a
> > > > >final response.  A final response is always sent, after one
> > > > or many 199
> > > > provisional responses have been sent."
> > > > >
> > > > >A final response is NOT always sent.  If the forking has
> > > > resulted in at
> > > > >least one 2xx being sent on the server transaction, no
> > > > 3xx/4xx/5xx/6xx
> > > > is allowed to be sent to the same
> > > > >server transaction after the 2xx.
> > > > >
> > > > >So these early dialogs which receive non-2xx final
> > response AFTER a
> > > > first 2xx final response will not get 199 but will
> > > > >only be considered terminated by the UAC 64*T1 seconds 
> after the
> > > > reception of the first 2xx response.  Even those early
> > > > >dialogs for which 199 responses have been sent 
> (because the final
> > > > responses were received before the first 2xx) will not
> > > > >receive a final response.
> > > > >
> > > > >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."
> > > > >
> > > > 
> > > > I propose the following text:
> > > > 
> > > > "The 199 Early Dialog Terminated response code does not
> > "replace" a
> > > > final response. A final response must always be sent when
> > > mandated by
> > > > the procedures in RFC3261."
> > > > 
> > > > I think that would clarify that we are not modifying 
> the core SIP 
> > > > rules on sending final responses.
> > > > 
> > > > Regards,
> > > > 
> > > > Christer
> > > > 
> > > > _______________________________________________
> > > > 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.