2008/8/16 Valentin Nechayev <[EMAIL PROTECTED]>: > Dialog data in UA contains remote target. (See section 12 for details.) > RFC3261 doesn't declare (AFAIK) its initial value, but it declares > - remote target shall be set to contact value of response > - remote target shall be used for RURI of next requests within > dialog (except case of strict routing - but this is corner case)
> It doesn't limit implementation, but the only implementation which > conforms common sense is that when UA (as UAC) sends initial > INVITE, remote target in the UA state is already assigned to the > value sent in RURI. I don't read it in RFC3261 but: 12.1.2 UAC Behavior -------------------- When a UAC **receives** a response that establishes a dialog, it constructs the state of the dialog. ... The remote target MUST be set to the URI from the Contact header field of the response. -------------------- > Having the remote target unassigned until > first response with contact is IMO senseless - But having remote target as original RURI is also useless because if the UAC sends an in-dialog request (an INFO, UPDATE, PRACK...) during the early-dialog using the original RURI as RURI, the proxy couldn't route it: The request has a "To tag" so the proxy must route it without changing the RURI and the request will do a loop into the proxy in any case. Of course I expect a proxy should never ask a location service to replace the RURI in an in-dialog request. > particularly, > because there is no strong rule to carry contact in each response. Well, for me Section 12.1.1 says very clear that any 101-199 or 2XX response MUST include a "Contact" header since all of those responses create a dialog (early or confirmed): Sections 12.1.1 says: ------------------------------------ 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. The UAS MUST add a Contact header field to the response. ------------------------------------ >> I really can't understand it. The "remote" target is the received >> "Contact", so if there is not received "Contact" during 1XX responses, >> then there is no remote target and in-dialog requests are not possible >> from UAC to UAS. Am I wrong? > > See above. To clarify: this is kind of proof "by the rule of > contraries": supposing that the remote target is initially > unassigned you fall in contradiction with section 20. Do you mean "Table 2" that says "Contact" is just optional for 1XX responses? Sincerely I don't trust that table, it contradicts the text above (Section 12.1.1). Thanks a lot for you response :) -- Iñaki Baz Castillo <[EMAIL PROTECTED]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
