Hi Jeroen, Forgive me if I don't understand what you are trying to say, but if you have an early dialog it means that you have received a non-100 provisional response with a to-tag.
Are you asking that I should indicate which state the entity is in when it sends the 199? Do you have some wording proposal? Regards, Christer -----Original Message----- From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED] Sent: 24. kesäkuuta 2008 21:23 To: Rockson Li (zhengyli) Cc: Christer Holmberg; [email protected] Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 Christer, My point was to formalize the moment a 199 is sent by relating it to the RFC3261 ICT state machine (BTW we're all silently assuming non-INVITE requests don't use provisional responses here) So associated with PROCEEDING-->COMPLETED, but indeed only if a to-tag was received before (so not only 100) Regards, Jeroen PS perhaps an idea to explicitly disallow 199 for non-INVITE requests? Rockson Li (zhengyli) wrote: > Yes, it's a typo, 100 does not establish early-dialog. > -Rockson > > -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2008 6:32 PM > To: Rockson Li (zhengyli); Jeroen van Bemmel > Cc: [email protected] > Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00 > > > Hi, > > >>> Should the 199 response contain a Contact header? And if yes, in >>> case a proxy sends it, should it contain the address of that proxy (since >>> the UAS already sent a final response)? >>> >> IF the 199 is sent reliably be the proxy must contain a Contact header >> containing the address of the proxy, yes. >> >> >>> Should we say that a proxy may only generate and send a 199 when it >>> receives a final error response on an INVITE client Transaction >>> which was in the PROCEEDING state? (i.e. 1xx response was received >>> before, so conceptually sending the 199 response is an action >>> associated with the transition from PROCEEDING to COMPLETED) >>> >> I am not sure I understand. The idea IS to send 199 when a final >> error response is received by the forking proxy, if a 18x has previously >> been received. >> [Rockson] PROCEEDING does not mean early-dialog is established, 100 >> Trying also move INVITE client Transaction to PROCEEDING state. >> > > [Christer] 199 is only sent when an early dialog has been established. 100 > Trying does not establish an early dialog. > > Regards, > > Christer > > > > > > > Also, a forking proxy with multiple INVITE client Transaction may > receive/forward 180 from one of them, and receive no provisional resp and > final resp directly from the other one, so INVITE client Transaction's state > is not dependable. The decision making must be done in TU. > > > > > > Christer Holmberg wrote: > >> Hi, >> >> I agree it may be a good idea to not forbid sending it reliably. >> >> I do think it would be good to have text, saying that it can be sent >> unreliable even if reliable responses are required, though, so that proxies >> aren't forced to terminate PRACKs etc. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of >> [EMAIL PROTECTED] >> Sent: 21. kesäkuuta 2008 1:38 >> To: [email protected] >> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 >> >> From: "Christer Holmberg" <[EMAIL PROTECTED]> >> >> [CHH] Whether the text should be in the document at all depends on if we >> allow 199 to be sent reliably in the first place. Based on the comments >> received so far we should not mandate 199 to be sent reliably, even if >> 100rel is required by the UAC. But, the question if whether we want to >> FORBID sending it reliably. >> >> If we ever might allow 199 to be used for HERFP, we should admit the >> possibility of sending it reliably in the first draft. Otherwise, we'll be >> locked out of sending it reliably in the future. >> >> Dale >> _______________________________________________ >> 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 > > _______________________________________________ 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
