Hi, >>If the proxy assignes its own To-tag, we can't use the To-tag to indciate >>which dialog was terminated. > >Right. That was part of my point. In addition, the to-tag it does use creates >*another* early dialog. > >>And then, suppose we did allow the proxy to reuse the existing dialog for the >>199, with a new contact. Then the UAC, >>upon receipt of the 199, will have to send the PRACK within the dialog. So >>the dialog can't be immediately destroyed. >>When *does* it get destroyed??? When the 200 to the PRACK is received? > >The extra state management and time required to handle this seems to run >contrary to the goal of the 199.
Correct. >>One option, as proposed by Paul, is to say that a UAC shall be able to >>RECEIVE reliable 199 responses. > >Based on my comments above, I am reconsidering the advisability of that. Well, I guess it wouldn't affect the complexness in the UAC, since it will have to be able to handle reliable provisional responses anyway (if it indicates support of it, that is). And, if the sender of the 199 is a B2BUA, I guess it COULD send it reliably. But, I have no strong feelings regarding this. Regards, Christer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Paul Kyzivat > Sent: 24. kesäkuuta 2008 15:25 > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00 > > There is a very messy slippery slope here with the reliable 199. > > I believe we have agreed that the 199 is to have the to-tag used by the UAS. > So conceptually it is *from* the UAS. If you want the proxy to send the 199 > reliably, then it will have to field the response. As others have mentioned, > this seems to mean that it will have to use its own contact address, which > will be a change from the contact used previously by the UAS for this early > dialog. > > That gives me heartburn - it just seems wrong. Ignoring that, it puts the 199 > into the middle of the open question about changing of contact addresses and > how they take effect. > > This could be addressed by always sending the 199 with a To-tag assigned by > the proxy. But that has its own problems. It actually makes the situation > worse for UACs that don't support 199. > > We sidestep all these problems by not sending the 199 reliably. > > Maybe we we should say that the UAC must be prepared to handle both reliable > and unreliable 199, but for now we don't specify any cases when a reliable > 199 is sent. > > Another thought - there aren't any issues if the *UAS* sends the 199 > reliably. But that isn't going to be the common case. > > Paul > > [EMAIL PROTECTED] wrote: >> 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
