Hi, Jonathan. Thank you very much for your comment. I think it will help to refer to this matter in the spec (to ensure smoother interoperability).
Regards, Yuko > It actually doesnt matter if you do or don't copy them. They'll be > ignored anyway. Thats why the spec doesnt say. > > -Jonathan R. > > [EMAIL PROTECTED] wrote: > > > > > > > > Hi Yuko, > > Regarding the response to the re-INVITE, it would > > be correct to do the same thing: copy the headers from the > > re-INVITE request to the response. Though the RFC is not > > explicit in saying this, that is what is assumed. > > > > Regards, > > Subhash. > > > > > > > > > > Yuko TAKAHASHI > > <[EMAIL PROTECTED] > > ei.co.jp> To > > [EMAIL PROTECTED] > > 06/30/04 02:58 PM cc > > [EMAIL PROTECTED], > > [EMAIL PROTECTED], > > [EMAIL PROTECTED] > > Subject > > Re: [Sip] Record-Route header field > > in re-INVITE transaction > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > Thank you all for the comments. I do understand that the route set must > > not be changed by target refresh requests. > > > > For initial Invite transactions, it says in RFC3261 as follows: > > ----- > > 12.1.1 UAS behavior > > > > When a UAS responds to a request with a response that establishes a > > dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route > > header field values from the request into the response (including the URIs, > > URI parameters, and any Record-Route header field parameters, whether they > > are known or unknown to the UAS) and MUST maintain the order of those > > values. > > ----- > > > > But I don't think it's clear for re-INVITE transactions. > > > > So I meant to ask, should I copy the values from the re-INVITE *without > > changing the route set*, or should I use the values from the route set > > learned from the initial INVITE transaction, or doesn't it matter at all? > > > > Thanks, > > Yuko > > > > > >>Please address implementation related questions to > >><[EMAIL PROTECTED]> > >> > >>The Route set, once established in the initial INVITE, cannot > >>change in mid-dialog requests. Only the remote target URI can > >>change during the dialog. Quoting section 12.2 of the RFC: > >>"...Requests within a dialog MAY contain Record-Route and > >>Contact header fields. However, these requests do not cause > >>the dialog's route set to be modified, although they may modify > >>the remote target URI." > >> > >>- Subhash Nayak. > >>Hughes Software Systems > >>http://www.hssworld.com > >> > >> > >> > >> > >> > > > > > >> Yuko TAKAHASHI > > > > > >> <[EMAIL PROTECTED] > > > > > >> ei.co.jp> > > > > To > > > >> Sent by: [EMAIL PROTECTED] > > > > > >> [EMAIL PROTECTED] > > > > cc > > > >> org > > > > > > Subject > > > >> [Sip] Record-Route header field in > > > > > >> 06/30/04 01:36 PM re-INVITE transaction > > > > > > > > > > > > > > > > > >> > >> > >> > >> Hi, > >> > >> Could anyone help me on the following question? > >> > >> If I were to place a Record-Route header field in the 200 OK response to > > > > a > > > >>re-INVITE and the re-INVITE had the header field, which values should I > >>use? Should I just copy the values from the re-INVITE, or use the route > > > > set > > > >>learned from the initial INVITE transaction, or doesn't it matter at all? > >> > >> Thanks in advance. > >> > >> Regards, > >> Yuko Takahashi > >> > >>_______________________________________________ > >>Sip mailing list https://www1.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-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > [EMAIL PROTECTED] FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
