Please see commenst inline. Regards, Ramakrishna
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nina Garaca Sent: Thursday, April 12, 2007 3:33 PM To: [EMAIL PROTECTED] Subject: [Sip-implementors] Question about UPDATE request Hi All, I have some questions regarding the UPDATE request: Q1: Is it a valid situation for UPDATE response (read response to UPDATE request) to come after the 2xx final response to the initial INVITE? Will it update the remote target of the dialog. A B INVITE |-------------------------------------->| 180 rel |<--------------------------------------| /Early dialog established/ PRACK |-------------------------------------->| 200 (PRACK) |<--------------------------------------| UPDATE |-------------------------------------->| 200 OK (INVITE) |<--------------------------------------| 200 OK (UPDATE) |<--------------------------------------| <comment> This is a possible scenario. But I don't see an issues with remote targets at A and B in this scenario. Assuming INVITE is sent with Contact A1 and UPDATE with contact A2, B updates its remote target as A2. While sending response whatever Contact B sent in 200 OK(assuming B1) for INVITE should be copied to 200 OK. So A will also have the correct remote target(B1). The following statement from UPDATE rfc assumes that UAS sends 200 OK for Invite after sending an UPDATE or 200 OK for UPDATE. This doesn't apply for the above call flow. " If a UA uses an UPDATE request or response to modify the remote target while an INVITE transaction is in progress, and it is a UAS for that INVITE transaction, it MUST place the same value into the Contact header field of the 2xx to the INVITE that it placed into the UPDATE request or response." So in the call flow described above, if 200 OK for UPDATE contains B2 as Contact instead of B1, A will update its remote target accordingly. But this scenario might be unlikely. </comment> Q2: What is happening if this was non 2xx final response such as 408 or 481or maybe 491? This is very strange situation because 2xx to INVITE has already established the confirmed dialog, and 408 or 481 to UPDATE should tear down the dialog. 491 response should cause sending the UPDATE once more. Am I right? <comment> Yes. Processing is similar to mid-dialog reponse processing at UAC. </comment> Q3: I understand that UPDATE shouldn't be used when confirmed dialog is established, but still , what is happening if the final response to reINVITE hasn't been received yet, is it valid to try to UPDATE the dialog? <comment> It is recommended not to use. It is not invalid but there are clauses in how offer/answer exchange should happen in overlapping INVITE/UPDATE transactions. </comment> Q4: Q1 and Q2 in the case of reINVITE. <comment> same as the initial Invite </comment> Thanks very match in advance. Nina. -- Nina Garaca Software Development & Testing --- "ZESIUM mobile" d.o.o. Valentina Vodnika 8/9 21000 Novi Sad Serbia Tel: +381 (0)21 472 15 48 Fax: +381 (0)21 472 15 49 Mob: +381 (0)63 16 15 891 E-mail: [EMAIL PROTECTED] _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
