Request URI for the retried request should be the same as the Request URI of the initial request
On Thu, Jul 30, 2009 at 10:20 AM, Krishna Rao Gurram<krishna.gur...@aricent.com> wrote: > ======================================================= > > Hi, > > Thank you for the detailed discussions. > > Like mentioned in one of the early responses to this post, the retried > request will have to be formed by using the same call-id and from tag, and > also by using a CSeq number that is higher. > > Hence though the initial request (which got challenged) did not succeed in > creating a dialog, implementations should maintain something similar to a > dialog state in order to ensure that the Call-Id and From Tag get copied into > the retried request and the CSeq number used is higher. Therefore the retried > request cannot be considered as a totally new request altogether (from > implementation point of view). > > In this context, our query can be described as below: > > (1) Since a dialog state is maintained, should the Request URI for the > retried request be picked up from the remote target address available in the > dialog state? > > (or) > > > (2) Should the Request URI for the retried request be the same as the Request > URI of the initial request? > > To illustrate with an example, > > The initial INVITE contains Request URI as sip:a...@domian.com:1234 and To > URI as sip:a...@domain.com. > > There is no port number in the TO URI since RFC 3261 does not allow it. > > The 401 response to the initial INVITE contained To URI as sip:a...@domain.com > > Now for the second INVITE (with authorization credentials), > > (1) Should the Request URI be picked up from the dialog state (as it is > done for in-dialog requests) and hence be kept as the remote URI of the > dialog state i.e. sip:a...@domain.com > > (or) > > (2) Should the Request URI be copied from the initial INVITE and hence be > kept as sip:a...@domain.com:1234 > > > Kindly clarify. > Thank You. > > ======================================================= > > > > Regards > Krishna.. > > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Krishna > Rao Gurram > Sent: Wednesday, July 29, 2009 3:39 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] Query about retrying requests > withAuthorization!!!! > > Hi, > Our call scenario involves the following exchange: > INV-> > <- 401 > ACK -> > INV With Credentials in Authorization header -> > > Please let us know if in this scenario, > Is it correct to use the same Request URI from the initial INVITE to form the > INVITE with credentials? > (or) > Is it correct to form the INVITE with credentials by creating a Request URI > from the dialog state (as mentioned in Section 12.2 of RFC 3261)? If this is > the case, the To URI / top most element from the Record-Route header in the > 401 response will be used as the Request URI in the INVITE with credentials. > > Thank You. > Krishna.. > > ________________________________ > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received this > message in error,please notify the originator immediately. If you are not the > intended recipient, you are notified that you are strictly prohibited from > using, copying, altering, or disclosing the contents of this message. Aricent > accepts no responsibility for loss or damage arising from the use of the > information transmitted by this email including damage from virus." > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received this > message in error,please notify the originator immediately. If you are not the > intended recipient, you are notified that you are strictly prohibited from > using, copying, altering, or disclosing the contents of this message. Aricent > accepts no responsibility for loss or damage arising from the use of the > information transmitted by this email including damage from virus." > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
