Subject: [splices] FW: New Version Notification for draft-loreto-splices-disaggregated-media-02.txt

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sat, 25 Jun 2011 09:14:40 -0400

Hi,

We have just submitted a new version for the draft-loreto-splices-disaggregated-media draft.
https://datatracker.ietf.org/doc/draft-loreto-splices-disaggregated-media/

We would appreciate it if you review it and provide us with your feedback.

Regards,
 Rifaat

________________________________________
From: [email-masked] [[email-masked]]
Sent: Saturday, June 25, 2011 9:11 AM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: [email-masked]; Shekh-Yusef, Rifaat (Rifaat); [email-masked]
Subject: New Version Notification for   draft-loreto-splices-disaggregated-media-02.txt

A new version of I-D, draft-loreto-splices-disaggregated-media-02.txt has been successfully submitted by Rifaat Shekh-Yusef and posted to the IETF repository.

Filename:        draft-loreto-splices-disaggregated-media
Revision:        02
Title:           Disaggregated Media in the Session Initiation Protocol (SIP)
Creation date:   2011-06-25
WG ID:           Individual Submission
Number of pages: 18

Abstract:
   Disaggregated media refers to the ability for a user to create a
   multimedia session combining different media streams, coming from
   different devices under his or her control, so that they are treated
   by the far end of the session as a single media session.  This
   document lists several use cases that involve disaggregated media in
   SIP.  Additionally, this document analyzes what types of
   disaggregated media can be implemented using existing protocol
   mechanisms, and the pros and cons of using each of those mechanisms.
   Finally, this document describes scenarios that are not covered by
   current mechanisms and proposes new IETF work to cover them.

The IETF Secretariat

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 28 Jun 2011 18:17:30 -0400

HI Rifaat,

I like the additions to the draft - makes it very concrete.

This matches what I remember being discussed on the list. It seems that an
unstated principle in section 4 is that the device which will establish the
audio connection is the device which answers the call, even if it is not in
the controller role. Is it worthwhile making that principle explicit?

Do you envisage a case where the device taking only video is the one to
answer the call?

Regards,

Peter Musgrave

On Sat, Jun 25, 2011 at 9:14 AM, Shekh-Yusef, Rifaat (Rifaat) <
[email-masked]> wrote:

> Hi,
>
> We have just submitted a new version for the
> draft-loreto-splices-disaggregated-media draft.
> Subject: New Version Notification for
> draft-loreto-splices-disaggregated-media-02.txt
>
> A new version of I-D, draft-loreto-splices-disaggregated-media-02.txt has
> been successfully submitted by Rifaat Shekh-Yusef and posted to the IETF
> repository.
>
> _______________________________________________
> splices mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/splices
>

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Tue, 28 Jun 2011 21:57:30 -0400

Thanks Peter,

The mechanism is flexable enough to allow any party to answe or initiate a call and take the controller role.
Take a look at the following email with an example of the video device initiating a call and taking the controller role.
http://www.ietf.org/mail-archive/web/splices/current/msg00123.html

Regards,
 Rifaat

________________________________
From: Peter Musgrave [[email-masked]]
Sent: Tuesday, June 28, 2011 6:17 PM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: [email-masked]
Subject: Re: [splices] FW: New Version Notification for draft-loreto-splices-disaggregated-media-02.txt

HI Rifaat,

This matches what I remember being discussed on the list. It seems that an unstated principle in section 4 is that the device which will establish the audio connection is the device which answers the call, even if it is not in the controller role. Is it worthwhile making that principle explicit?

Do you envisage a case where the device taking only video is the one to answer the call?

Regards,

Peter Musgrave

On Sat, Jun 25, 2011 at 9:14 AM, Shekh-Yusef, Rifaat (Rifaat) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,
 Rifaat

________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]
Sent: Saturday, June 25, 2011 9:11 AM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: [email-masked]<mailto:[email-masked]>; Shekh-Yusef, Rifaat (Rifaat); [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for   draft-loreto-splices-disaggregated-media-02.txt

Abstract:

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

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 29 Jun 2011 06:51:22 -0400

Right. I remember now.

This example is a good candidate for the next version of the draft.

Peter

On Tue, Jun 28, 2011 at 9:57 PM, Shekh-Yusef, Rifaat (Rifaat) <
[email-masked]> wrote:

> Take a look at the following email with an example of the video device
> initiating a call and taking the controller role.
>  ------------------------------
> *From:* Peter Musgrave [[email-masked]]
> *Sent:* Tuesday, June 28, 2011 6:17 PM
>
> *To:* Shekh-Yusef, Rifaat (Rifaat)
> *Cc:* [email-masked]
> *Subject:* Re: [splices] FW: New Version Notification for
>  This matches what I remember being discussed on the list. It seems that
> an unstated principle in section 4 is that the device which will establish
> the audio connection is the device which answers the call, even if it is not
> in the controller role. Is it worthwhile making that principle explicit?
>