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

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 6 Jul 2011 14:43:58 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Shekh-Yusef, Rifaat (Rifaat) [[email-masked]]

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/
________________________________________

If I understand the document correctly, it's a use-cases document, not a requirements document,
or a solution document.

One use case I don't see is where both ends of the call are using disaggregation (or should it be
aggregation?) simultaneously.

Dale

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 6 Jul 2011 22:05:17 +0300

Hi Dale

you are right, this is a use-cases documents

> aggregation?) simultaneously.
well that use case would be really interesting in the case of 
disaggregation,
not so sure if  for the aggregation one, that the wg is now investigating,
would add anything

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 6 Jul 2011 15:07:00 -0400

Here are diagrams of both ends using disaggregated media, with 2 UAs each, each UA handling two media streams.  The first diagram is "near-end managed", where each end has a UA managing all of its UAs.  The second diagram is "far-end managed", where the far-end UAs are aware of the aggregation.

(This is fixed-width ASCII art.  You may have to copy it to another tool to see it correctly.)

       "near-end managed":

        ----                                 ----
       | UA |\\                           //| UA |
        ----  \\ stream 1       stream 1 //  ----
      stream 2 \\                       // stream 3
                \---- ............. ----/         
                | UA |.............| UA |          
                /---- ............. ----\        
      stream 3 //     .............     \\ stream 2
        ----  // stream 4       stream 4 \\  ----
       | UA |//                           \\| UA |
        ----                                 ----
        Alice                                 Bob

     "far-end managed":

      /------------\    stream 1      /------------\ 
     |     ---- ____|________________|____ ----     |
     |    | UA |____|______    ______|____| UA |    |
     |     ----   stream 2 \  /      |     ----     |
     |              |       \/       |              |
     |              |       /\       |              |
     |            stream 3 /  \      |              |
     |     ---- ____|_____/    \_____|____ ----     |
     |    | UA |____|________________|____| UA |    |
     |     ----     |	stream 4     |     ----     |
      \------------/                  \------------/ 
          Alice                             Bob  

Dale

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 7 Jul 2011 19:04:33 +0300

Hi Dale,

what you show in the below diagrams are media streams not dialog, isn't it?

if so, the "near-end managed" is not really clear to me:
what the UA, the one managing all of its UAs, is supposed to do with the 
media streams
that passes trough it?

/Sal

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 7 Jul 2011 14:56:00 -0400

________________________________________
From: Salvatore Loreto [[email-masked]]

The drawings are taken from your draft, and yes, they aren't truly parallel to each other.

In the "near-end managed" version, called "Centralized scenario" in fig. 2, the
bundles of lines represent SIP dialogs, the individual lines are the media streams
as represented in the SDP carries in the dialogs.  In that sense, all 4 streams go
"though" the two coordinating UAs, in that those UAs pass through the SDP lines
that describe them.  Of course, the media packets themselves go directly from one
endpoint UA to another.

In the "far-end managed" version, called "distributed scenario" near fig. 9, there
are two groups of UAs, and there are 4 SIP dialogs between them, each dialog responsible
for one of the 4 media streams.  So the lines represent SIP dialogs as well as media streams.

The overall idea though, is that disaggregation (or aggregation, if you want to describe it)
is being done at both ends; both Alice and Bob have multiple UA devices they wish to operate
as if they were single UAs.

Having a mechanism that works in this situation should be a requirement, IMO.

Dale