Hi, >Yes, I agree that the draft should avoid such rules. My observation was specifically in the the "Proxy Behavior" section >which mentions only about To header tag creation identifying the terminated early dialog. > >"The 199 provisional response MUST contain a To header tag parameter, which identifies the early dialog that has been >terminated."
Yes. But, that is required in order to identity which early dialog is terminated. >It is still worth mentioning about the other informational headers that the proxy may propagate from received final >failure response towards UAC in 199 response. I guess I could add, to the proxy section, a note saying that the proxy may include information (including response codes and header values) from the message which triggered the 199 response. Regards, Christer ~Vikram On Thu, May 22, 2008 at 2:44 PM, Christer Holmberg <[EMAIL PROTECTED]> wrote: > > Hi, > >>Besides conveying the indication for terminated early dialog, this > response can also carry additional information of the >>reason of termination as indicated by Warning, Reason or History-Info > header received in the final failure response from >>UAS to the forking proxy. >> >>I think it is worth mentioning the rules of creating this 199 response > by forking proxy which includes preserving these >>headers from the actual final failure response. > > We need to be a little careful here. > > There were long discussions on what the scope of this draft was going > to > be: simply to indicate that an early dialog has been terminated, or to > go further and solve the whole so called HERPF problem. The agreement > was that the scope is to indicate than an early dialog has been > terminated. > > Now, the draft DOES say the following: > > "The UAC MAY use additional information (for example the final > response which triggered the 199 response) received in the 199 > response when initiating new sessions, if it is possible to avoid the > new session initation request to be rejected." > > So, that doesn't forbid sending of header information etc, but I am > not sure that we want to start specifying rules about that - at least > not in this draft. > >>Earlier, all this information was lost as the forking proxy had to > suppress the final failure response and had to forward >>the most appropriate final response back. > > I agree. But, again, the question is whether that is within the scope > of the draft or not. > > Regards, > > Christer > > > > >> >> Hi, >> >> I've submitted the first version of the SIP WG 199 draft. >> >> It can also be found at: >> >> http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-00.txt >> >> 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
