Subject: [clue] FW: New Version Notification for draft-romanow-clue-call-flow-01.txt

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 12 Jul 2012 02:07:14 +0000

Hi Folks,
I just submitted a call flow document, as I volunteered to do at the last interim.
This was a completely collaborative effort with Rob Hansen, whom you probably know, and Arun Krishna, whom you probably don't know. Arun is a SIP expert in the Cisco Telepresence group.

This is a -01 version as I improved the formatting from the -00 submitted Monday.

This is obviously not meant as a proposal but as a discussion piece to help us to make decisions for implementing the framework.

Best regards,
Allyn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 11, 2012 7:00 PM
To: Allyn Romanow (allyn)
Cc: Arun Krishna (arukrish); Robert Hansen (rohanse2)
Subject: New Version Notification for draft-romanow-clue-call-flow-01.txt

A new version of I-D, draft-romanow-clue-call-flow-01.txt
has been successfully submitted by Allyn Romanow and posted to the IETF repository.

Filename:	 draft-romanow-clue-call-flow
Revision:	 01
Title:		 Call Flow for CLUE
Creation date:	 2012-07-12
WG ID:		 Individual Submission
Number of pages: 41
URL:             http://www.ietf.org/internet-drafts/draft-romanow-clue-call-flow-01.txt
Status:          http://datatracker.ietf.org/doc/draft-romanow-clue-call-flow
Htmlized:        http://tools.ietf.org/html/draft-romanow-clue-call-flow-01
Diff:            http://tools.ietf.org/rfcdiff?url2=draft-romanow-clue-call-flow-01

Abstract:
   This draft shows the CLUE call flow demonstrating the use of CLUE in
   SIP.  It also provides information about the message and syntax for
   CLUE transport establishment and other extensions in SDP.  In CLUE
   participants act as both providers and consumers.  The draft includes
   a detailed example of a typical use case which includes both static
   and switched captures.

The IETF Secretariat

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Jul 2012 01:25:35 +0200

Hi Allyn,

As you use a SCTP user-plane channel to send the CLUE information (in order to be alligned with RTCWEB), do you assume that:

a) No intermediary will need the CLUE information sent in the SCTP channel; or
b) Any intermediary that will need the CLUE information will insert itself on the CLUE channel path?

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Allyn Romanow (allyn) [[email-masked]]
Sent: Thursday, July 12, 2012 5:07 AM
To: CLUE ([email-masked])
Subject: [clue] FW: New Version Notification for        draft-romanow-clue-call-flow-01.txt

Hi Folks,

Best regards,
Allyn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 11, 2012 7:00 PM
To: Allyn Romanow (allyn)
Cc: Arun Krishna (arukrish); Robert Hansen (rohanse2)
Subject: New Version Notification for draft-romanow-clue-call-flow-01.txt

Abstract:

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

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Fri, 13 Jul 2012 02:43:50 +0000

Hi Christer-
Assuming b-- that any intermediary needing CLUE info will need to do CLUE.

In conjunction with the work we did on using SDP to carry CLUE messages, which Flemming gave a presentation on at IETF, we tried to ascertain what info an intermediary would want from CLUE that it couldn't get from SDP. It was difficult to get a really definitive answer to this question. Generally people felt that bandwidth was the important information and that is available in SDP.

After concluding that it was infeasible to carry CLUE messages in SDP, we also felt that if there is some specific information not available in SDP if it appropriate, we could consider adding it to SDP; but if an intermediary wanted much CLUE info, they'd have to speak CLUE.

Make sense?

A

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Thursday, July 12, 2012 4:26 PM
To: Allyn Romanow (allyn); CLUE ([email-masked])
Subject: RE: [clue] FW: New Version Notification for draft-romanow-clue-call-flow-01.txt

Hi Allyn,

Regards,

Christer

Hi Folks,

Best regards,
Allyn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 11, 2012 7:00 PM
To: Allyn Romanow (allyn)
Cc: Arun Krishna (arukrish); Robert Hansen (rohanse2)
Subject: New Version Notification for draft-romanow-clue-call-flow-01.txt

Abstract:

The IETF Secretariat

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Jul 2012 09:39:02 +0200

Hi Allyn,

I for sure agree that we shouldn't "overload" SDP, but that's not the only way to carry information out-of-band.

Note that I am not suggesting to replace the SCTP channel with an out-of-band solution. I'm only saying that we need to consider whether some information is needed by intermediaries, and then figure out how to acheive that.

Regards,

Christer

________________________________________
From: Allyn Romanow (allyn) [[email-masked]]
Sent: Friday, July 13, 2012 5:43 AM
To: Christer Holmberg; CLUE ([email-masked])
Subject: RE: [clue] FW: New Version Notification for    draft-romanow-clue-call-flow-01.txt

Hi Christer-

Make sense?

A

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, July 12, 2012 4:26 PM
To: Allyn Romanow (allyn); CLUE ([email-masked])
Subject: RE: [clue] FW: New Version Notification for draft-romanow-clue-call-flow-01.txt

Hi Allyn,

Regards,

Christer

Hi Folks,

Best regards,
Allyn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 11, 2012 7:00 PM
To: Allyn Romanow (allyn)
Cc: Arun Krishna (arukrish); Robert Hansen (rohanse2)
Subject: New Version Notification for draft-romanow-clue-call-flow-01.txt

Abstract:

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Jul 2012 09:36:42 -0400

Christer,

(Speaking as individual)

Frankly I'm at a loss for a way to decide which information might be 
*needed* by an intermediary, in contrast to information that might be 
*desired* by an intermediary.

I'm sufficiently jaded to think that *all* information will be *desired* 
by some intermediary. (E.g. Facebook.)

Do you have a suggestion for how to determine need?
ISTM that to determine need, we must first determine what intermediary 
actions we are trying to facilitate.

	Thanks,
	Paul

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Fri, 13 Jul 2012 18:35:53 +0000

Hey Christer-
Any light you or anyone can throw on that question would be great!!

I spent a fair bit of effort "interviewing" people in and outside of my company who have to do with intermediaries and their customers and concluded that it wasn't clear.. 
We can talk offline if you like and I can tell you more about what I learned (or didn't..) :)

cheers

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Friday, July 13, 2012 12:39 AM
To: Allyn Romanow (allyn); CLUE ([email-masked])
Subject: RE: [clue] FW: New Version Notification for draft-romanow-clue-call-flow-01.txt

Hi Allyn,

Regards,

Christer

Hi Christer-

Make sense?

A

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, July 12, 2012 4:26 PM
To: Allyn Romanow (allyn); CLUE ([email-masked])
Subject: RE: [clue] FW: New Version Notification for draft-romanow-clue-call-flow-01.txt

Hi Allyn,

Regards,

Christer

Hi Folks,

Best regards,
Allyn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 11, 2012 7:00 PM
To: Allyn Romanow (allyn)
Cc: Arun Krishna (arukrish); Robert Hansen (rohanse2)
Subject: New Version Notification for draft-romanow-clue-call-flow-01.txt

Abstract:

The IETF Secretariat

---

From: Roni even <[email-masked]>
Date: Fri, 13 Jul 2012 22:18:17 +0000

Hi Allyn,
There was a discussion in MMUSIC when doing capability negotiation and the result is in http://tools.ietf.org/html/rfc5939#page-51 (section 3.12 of RFC 5939)
This applies not to the CLUE specific information (media captures) but to what should be declared in SDP so all streams will be known. In practice it will be good if all RTP media streams will be declared also in SDP and not only in CLUE.
The example in the call flow do not show what is the video m-line. It looks to me from section 5.2 that the draft says that there will be one payload type number specified for the video main to create an RTP session but in this session you may have multiple RTP video streams with different SSRCs. I am not sure if this will work through intermediaries and I am not sure if it works for any receiver without knowing what is this stream unless you think that all the RTP streams have the same codec and coded properties.
Roni

________________________________________
From: [email-masked] [[email-masked]] on behalf of Allyn Romanow (allyn) [[email-masked]]
Sent: Friday, July 13, 2012 21:35
To: Christer Holmberg; CLUE ([email-masked])
Subject: Re: [clue] FW: New Version Notification        for     draft-romanow-clue-call-flow-01.txt

Hey Christer-

cheers

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Friday, July 13, 2012 12:39 AM
To: Allyn Romanow (allyn); CLUE ([email-masked])
Subject: RE: [clue] FW: New Version Notification for draft-romanow-clue-call-flow-01.txt

Hi Allyn,

Regards,

Christer

Hi Christer-

Make sense?

A

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, July 12, 2012 4:26 PM
To: Allyn Romanow (allyn); CLUE ([email-masked])
Subject: RE: [clue] FW: New Version Notification for draft-romanow-clue-call-flow-01.txt

Hi Allyn,

Regards,

Christer

Hi Folks,

Best regards,
Allyn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 11, 2012 7:00 PM
To: Allyn Romanow (allyn)
Cc: Arun Krishna (arukrish); Robert Hansen (rohanse2)
Subject: New Version Notification for draft-romanow-clue-call-flow-01.txt

Abstract:

The IETF Secretariat