Subject: [clue] #27: Avoiding 3rd O/A exchange

From: "clue issue tracker" <[email-masked]>
Date: Sat, 13 Oct 2012 18:55:51 -0000

#27: Avoiding 3rd O/A exchange

 Issue c from 19-20 Sept. 2012 interim.

 Is there an advantage to not having a 3rd O/A exchange in the session
 setup?

-- 
--------------------------------+---------------------------
 Reporter:  mary.ietf.barnes@…  |      Owner:  clue-chairs@…
     Type:  enhancement         |     Status:  new
 Priority:  minor               |  Milestone:
Component:  charter             |    Version:  1.0
 Severity:  -                   |   Keywords:
--------------------------------+---------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ticket/27>
clue <http://tools.ietf.org/wg/clue/>

---

From: "Roni Even" <[email-masked]>
Date: Sun, 14 Oct 2012 01:20:00 +0200

Hi,
I am not sure what this means, what are the first and second O/A in the session setup
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of clue issue tracker
Sent: 13 October, 2012 8:56 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [clue] #27: Avoiding 3rd O/A exchange

 Is there an advantage to not having a 3rd O/A exchange in the session  setup?

_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 14 Oct 2012 14:32:31 -0400

> I am not sure what this means, what are the first and second O/A in the session setup

Maybe it can be stated better.

As I see it, the point is that a new configure *may* require an O/A 
(before or after the configure) to set up the sip session to convey what 
has been configured.

At the start of a new clue session it will be common to exchange 
advertisements and configures. This *could* result in:
- an initial O/A to establish the sip session and clue channel
- an O/A to set up the media for the configure from A to B
- an O/A to set up the media for the configure from B to A

There may be lots of cases one or two of these may not be needed even 
without special care. But worst case could require this.

So the first question - the one that this Issue raises - is whether we 
care about this enough to even worry about it. (Suppose it turns out 
that this will be required *most* of the time. Do we care then?)

If we care, and would like to have a high probability that only two 
O/As, or only one, are required, then we need to consider it as part of 
the signaling design.

I think I can safely say that session establishment between dissimilar 
systems cannot be guaranteed to take less than two O/As. The more we put 
into SDP the less likely it is that it will *ever* be possible to do it 
with a single O/A.

If we structure things so that advertisements and configurations can be 
*exchanged* prior to the 2nd O/A of the session, then I think we can 
largely guarantee that 2nd O/A will be sufficient to satisfy both 
configurations. This will require some planning so that both sides 
understand and know to defer the O/A until the exchange is complete.

While it is highly likely that there will be a roughly concurrent 
exchange of configurations at the beginning of the session, after that 
it will probably be highly unlikely to get concurrent configs. So in 
that mode it will be appropriate to initiate any needed O/A change in 
conjunction with the single config, without first awaiting one from the 
other side.

Since the non-concurrent case needs to be supported anyway, it will 
simplify protocol specification and implementation to omit any special 
case handling of the initial session setup, and just live with the extra 
O/A this might cause.

	Thanks,
	Paul

---

From: "clue issue tracker" <[email-masked]>
Date: Mon, 15 Oct 2012 15:44:49 -0000

Comment (by mary.ietf.barnes@…):

 Discussion at Oct. 15, 2012 design team meeting:
 - Paul noted that he explicitly avoided 3rd O/A in his call flows
 - Issue may be more due to glare
 - Can't really decide this in isolation
 - Suggest to provide guidelines on how to do media so that we can avoid
 the 3rd O/A
 - Usually want to send SDP before config to provide context (initially)
 - Discussion as to whether config should always be within the context of
 the O/A(SDP)
 - Suggestion that anything needed by intermediary needs to be in SDP

 Need to revisit this one once signaling details (what goes in CLUE, what
 goes in SDP) are resolved.

-- 
--------------------------------+----------------------------
 Reporter:  mary.ietf.barnes@…  |       Owner:  clue-chairs@…
     Type:  enhancement         |      Status:  new
 Priority:  minor               |   Milestone:
Component:  charter             |     Version:  1.0
 Severity:  -                   |  Resolution:
 Keywords:                      |
--------------------------------+----------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ticket/27#comment:2>
clue <http://tools.ietf.org/wg/clue/>