Hope below helps. Regards,
Indresh -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nina Garaca Sent: Friday, March 30, 2007 5:35 AM To: [email protected] Subject: [Sip-implementors] Potential race condition between UPDATE and 200 OK to INVITE and UPDATE related questions ++ Hi all, I have some questions regard potential race condition between UPDATE and 200 OK to INVITE which following picture illustrates: A B INVITE |-------------------------------------->| 180 rel |<--------------------------------------| /Early dialog established/ PRACK |-------------------------------------->| 200 (PRACK) |<--------------------------------------| UPDATE |-------------------------------------->| 200 OK (INVITE) |<--------------------------------------| 200 OK (UPDATE) |<--------------------------------------| Q1: Is this valid situation, and if UPDATE was a target refresh request, does it updates the local target? >> Yes it is valid situtation. Let us say we had a B2BUA involved and there is another leg of the call. Then terminating side may have answered and UAS may be forwarding that 200 OK towards originating side, at the same time the originating side may have requested a media-modification in early dialog state. >> Base RFC-3261 suggests that re-INVITE is the only target refresh request. But section 5.1 of RFC-3311 is over-riding/expanding this. Target-Refresh requests over-write the remote-target-uri, not the local target on the UAS. On the UAC side there is some thing called local URI UPDATE is a target refresh request. As specified in RFC 3261 [1], this means that it can update the remote target of a dialog. A B INVITE |-------------------------------------->| 180 |<--------------------------------------| 200 OK (INVITE) |<--------------------------------------| UPDATE |-------------------------------------->| 200 OK (UPDATE) |<--------------------------------------| Q2: Is it OK for UPDATE to be sent after the 200 OK to INVITE and before ACK is sent, and if it was the second refresh target request would it change/update the local target? A B INVITE (C = LT1) |-------------------------------------->| 180 |<--------------------------------------| 200 OK (INVITE) |<--------------------------------------| ACK |-------------------------------------->| // C = Contact, LT = local target reINVITE (C = LT2) |-------------------------------------->| 180 |<--------------------------------------| UPDATE (C = LT3) |-------------------------------------->| 200 OK (UPDATE) |<--------------------------------------| 200 OK (reINVITE) |<--------------------------------------| ACK |-------------------------------------->| >> Do not think that an UPDATE can be sent by A after receiving 200 OK and before sending ACK. UPDATE is used for media re-negotiation and definitely can be used in place of re-INVITEs, but re-INVITEs are only sent after successful completion of previous INVITE transactions ( 3-way handshake ). Q3: Is it OK for UPDATE to be sent when re INVITE isn't actually responded with the final response? And what will be the dialog local target LT2 or LT3? According to RFC3311 I presume that 200 OK to reINVITE should have the same Contact as UPDATE or its response. >> Have never seen a 180 Ringing for a re-INVITE. Why would a UAS send 180 for a re-INVITE ? and finnaly: A B INVITE (C = LT1) |-------------------------------------->| 180 |<--------------------------------------| 200 OK (INVITE) |<--------------------------------------| ACK |-------------------------------------->| // C = Contact, LT = local target reINVITE (C = LT2) |-------------------------------------->| 180 |<--------------------------------------| UPDATE (C = LT3) |-------------------------------------->| 200 OK (UPDATE) |<--------------------------------------| 4xx OK (reINVITE) |<--------------------------------------| ACK |-------------------------------------->| Q4: Which is new dialog local target LT2 or LT3? I should say LT3. >> What is local target in dialog ? There is only local uri ( from header ) remote uri ( to header ) remote target uri ( contact header ) ? Am I missing something. Do not know ? Thanks very, 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
