Subject: [Sip] Multiple 200 OKs for an INVITE

From: Ofir Arkin <[email-masked]>
Date: Thu, 28 Feb 2002 12:21:54 +0000

Section 13.2.2.4 2xx responses (for INVITE):

"Multiple 2xx responses may arrive at a UAC for a single INVITE 
request...each response is distinguished by the tag parameter in the TO 
header field and each represents a distinct dialog identifier".

In this phase there is no tag in the 'To' field held in the 'state' if I 
understand this correctly. Actually the 200OK is the first message to 
carry the value back from a UAS.

"If the dialog identifier in the 2xx response matches the dialog 
identifier of an existing dialog, the dialog MUST be transitioned to the 
"confirmed" atate..."

Ok, but what will happen if we receive in the same time two 200OKs from 
two different UASs? The state is still not "confirmed"...

Is this is first arrived first processed therefore won situation?

Also - after the first 200OK will be processed, the state will change to 
"confirmed" and further 200OKs will not match a dialog identifier any 
more...

Thoughts?

-- 
Ofir Arkin
Managing Security Architect
@stake, Limited.
http://www.atstake.com
email: 
[email-masked]
Tel: 
+44 (0) 207 495 7002
Fax: 
+44 (0) 207 495 7062
Mobile: +44 (0) 779 630 8632	

-----------------------------
The information transmitted is intended only for the person or entity to 
which it is addressed and may contain confidential and/or privileged 
material.  Any review, re transmission, dissemination or other use of, 
or taking of any action in reliance upon, this information by persons or 
entities other than the intended recipient is prohibited.  If you 
received this in error, please contact the sender and delete the 
material from any computer.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Feb 2002 14:43:53 +0200

Hi Ofir,

If you receive multiple 200 OK, you would normally accept the first. Then
you would ACK/BYE any other 200OK you may receive.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 28 Feb 2002 07:59:37 -0500

----- Original Message -----
From: "Ofir Arkin" <[email-masked]>

> carry the value back from a UAS.

The arrival of a response from a UAS (1xx or 2xx) with a To-tag establishes
a dialog. For a 1xx, it is an "early" dialog. For a 2xx it is a "confirmed"
dialog. If you get responses (with To-tags) from multiple UASs, you have
multiple dialogs.

> two different UASs? The state is still not "confirmed"...

Each 200 OK represents/established a separate dialog. An existing dialog
would be matched if the UAS sending the 200-OK has previously sent a 1xx
with a To-tag. These pre-existing dialogs would be in the "early" state. The
matched dialog would transition from "early" to "confirmed" state. Any other
"early" dialogs would remain "early" dialogs.

> Is this is first arrived first processed therefore won situation?

This is up to the implementation and local policy in the UAC. It may choose
to keep all dialogs up (in which case it would have to mix the streams) or
it could choose to keep one and send BYE to all the rest (after ACKing the
200 OK). I would imagine that a basic SIP Phone would keep the first and
send BYE to all the rest.

> "confirmed" and further 200OKs will not match a dialog identifier any

They won't match that dialog, but might match other "early" dialogs or
establish a new dialog. If the UAC does not want to keep it. It ACKs and
then sends a BYE.

---

From: "Prabhas Sinha" <[email-masked]>
Date: Thu, 28 Feb 2002 08:33:07 -0500

If you have drawn some finite state machine for the INVITATION protocol, you
will realise that UAC can send many INVITE requests and go to (say)
"WAIT FOR INVITE RESPONSE ONLY" state. Provisional responses (1xx) to the
INVITE request wont cause the state machine to leave this state. However
they would stop the UAC from transmitting the INVITE request further.
Now multiple 2xx responses will be primarily due to proxy forking
downstream. The UAC will ACK the first 200 OK or even BYE if it doesnt want
to talk. The state will obviously change but then UAC should be capable of
handling other 200 OK responses which will come to it as a result of
forking. Probably UAC might maintain state machine for each possible forked
request but then it might not know the amount of forking that has been done.
Certainly other 2xx responses needs to be BYEed, how it would be achieved
could be an implementation issue.
Does it make sense ?

Prabhas
Research Assistant
Dept of Computer Engineering
North Carolina State University
Raleigh, NC 27695
USA

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 28 Feb 2002 18:31:30 +0200

> "confirmed" and further 200OKs will not match a dialog identifier any

You are talking about the state of the INVITE transaction. Take into
account that the ACK for a 2xx response is not part of the INVITE
transaction, but a transaction by itself. Therefore, it is handled by
the TU. Further 2xx resposes for the INVITE will be also passed to the
TU.

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]