Subject: Re: [siprec] comments on draft-ietf-siprec-metadata-07

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 2 Aug 2012 23:51:15 +0000

Hi all,

As discussed today meeting, Paul mentioned below metadata model change is an alternative which clarifies the stream XML element usage within the specific single CS instead of spread across. I'm interested in hearing anybody has objection to this change.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Paul Kyzivat
>Sent: Wednesday, August 01, 2012 11:30 AM
>To: [email-masked]
>Subject: Re: [siprec] comments on draft-ietf-siprec-metadata-07
>
>Hi Henry,
>
>Yes, I agree that there is an inconsistency.
>We have also been discussing problems with this association that we plan
>to talk about on Thursday. My proposal is to change it to:
>
>CS ------------------- Media Stream
>    0..1          0..*
>
>	Thanks,
>	Paul
>
>On 7/31/12 7:26 PM, Henry Lum wrote:
>> Hi,
>>
>> I notice that in the metadata model in section 4 CS has a 1..* to 0..*
>relation with a media stream and this is inconsistent with further text.
>>
>> In section 6.3, CS is stating that it has a 0..* to 0..* relation with
>a media stream. On top of page 12 it explains that a media stream can be
>associated with zero of more CS and points out that a multicast MOH
>stream can be without a CS. In section 6.7 a media stream can connect to
>1..* CS.
>>
>> Which one is the intended usage? Note that XML<stream>  requires the
>session_id attribute so it seems like section 6.3 is odd one out.
>>
>> Regards,
>> Henry
>> _______________________________________________
>> siprec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/siprec
>>
>
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Aug 2012 20:40:04 -0700

> As discussed today meeting, Paul mentioned below metadata model change is an alternative which clarifies the stream XML element usage within the specific single CS instead of spread across. I'm int…

In followup to the presentation at the meeting, which probably wasn't 
very clear...

(This will be longer than I'd like, but I don't know how to say it more 
concisely.)

In metadata-07 we have the following model:

                                    Participant
                                | 0..*       1..*|
                        receives|                |sends
                                | 0..*       0..*|
                             +-------------------------+
                             |          Media Stream   |
                             |                         |
    Communication 1..*  0..* +-------------------------+
      Session    ------------|                         |
                             |  Media Stream Reference |
                             |  Content-type           |
                             |                         |
                             +-------------------------+

Note that a Media Stream can associate with one or more Communication 
Sessions.

One issue with this is that we had wanted to allow a media stream with 
zero sessions. That's an easy change.

Normally there would be no need for a media stream to associate with 
more than one CS. We made the change to allow multiple to accommodate 
the Turret use case, where there is a desire to record a mix of streams 
from multiple CSs.

What we ended up with for the XML of the Media Stream element in 
metadata-07 is called <stream>, has two attributes, identifying the 
stream itself as well as a Communication Session.

If you never think about streams that associate with more than one one 
CS, this seems reasonable. You can then think of it as a stream element 
with one attribute identifying its key, and another non-key attribute 
identifying the CS its associated with.

But if you attempt to do an example where a media stream associates with 
multiple CSs (see section 4.6 of draft-ram-siprec-callflows-01) it gets 
weird. Because we need to identify two CSs, and can only do one per 
<stream>, we need two instances of <stream>. But because they are 
supposed to be the same stream, they must have the same stream id. We 
can see that in 4.6:

           <stream id="UAAMm5GRQKSCMVvLyl4rFw=="
               session="hVpd7YQgRW2nD22h7q60JQ==">
               <label>96</label>
           </stream>
           <stream id="UAAMm5GRQKSCMVvLyl4rFw=="
               session="zzlafnvvjlCHllaHF6mn8kkSS==">
               <label>96</label>
           </stream>

In the above, both have the same id=, and are distinguished by differing 
session= values. If <stream> had only one key attribute, then the 2nd of 
these would *replace* the first. For that not to happen, both the 'id' 
and 'session' attributes must be key attributes.

The XML representing senders and receivers only identifies the 'id' of 
the stream, such as:

           <participantstreamassoc
               participant="zSfPoSvdSDCmU3A3TRDxAw==">
             <send>UAAMm5GRQKSCMVvLyl4rFw==</send>
             <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
           </participantstreamassoc>

This isn't consistent with the model. In the XML, regular elements have 
a single key attribute that identifies the element itself. Assoc 
elements have two key attributes that identify the keys of the two 
elements they associate. So our XML is more consistent with:

                             +-------------------------+
                             |        Media Stream     |
                             |                         |
    Communication 1..*  0..* +-------------------------+
      Session    ------------|                         |
                     |       |  Media Stream Reference |
                     |       |  Content-type           |
                     |       |                         |
                     |       +-------------------------+
                     |
                     |       +-------------------------+
                     |       |   MediaStream_CS_Assoc  |
                     +-------|                         |
                             +-------------------------+

But not quite, because we don't have two XML types. Rather we have one 
XML element called <stream> that has the two keys of the association 
class, but also carries the attributes of the Media Stream. But the 
<send> and <recv> reference the single 'id' of Media Stream that isn't 
explicitly coded at all.

This disturbs me. Its inconsistent with the way the rest of the model is 
represented.

So the way I propose to fix this is to change the model a bit:

                                    Participant
                                | 0..*       1..*|
                        receives|                |sends
                                | 0..*       0..*|
                             +-------------------------+
                             |          Media Stream   |
                             |                         |
    Communication 0..1  0..* +-------------------------+
      Session    ------------|                         |
                             |  Media Stream Reference |
                             |  Content-type           |
                             |                         |
                             +-------------------------+

In this model, a Media Stream can associate with at most one CS. No 
association class is needed. The association can be represented in XML 
as an optional attribute of <stream>.

This appears not to support the turret case. I propose to address that 
simply by having multiple distinct instances of <stream> reference a 
common m-line by using the same <label> value. The schema looks very 
much the same, but the 'session' attribute of <stream> is becomes a 
non-key attribute, and is optional.

So in the turret example, the two streams will have different values of 
the 'id' attribute.

I think the change to the schema in metadata-07 will be simple:

OLD:

    <xs:complexType name="stream">
...
        <xs:attribute name="stream_id" type="xs:base64Binary"
             use="required"/>
        <xs:attribute name="session_id" type="xs:base64Binary"
             use="required"/>
    </xs:complexType>

NEW:

    <xs:complexType name="stream">
...
       <xs:attribute name="id" type="xs:base64Binary"
             use="required"/>
        <xs:attribute name="session_id" type="xs:base64Binary"/>
    </xs:complexType>

(There has been some flopping around of the name of the first attribute 
between 'id' and 'stream_id'. I don't care, but I think Partha got some 
guidelines that suggest it should be 'id' if it is a single key.)

I *hope* this makes things clearer rather than more confusing.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 8 Aug 2012 03:57:56 +0000

Hi Paul,

Thank you for the detailed description of the problem and the proposed solution. I must admit, I was completely confused by the discussion of this topic during the working group session. Having had a chance now to read through your e-mail, I am pretty sure I get it, and I like your proposed solution as well. It provides the flexibility required for the turret case to be supported as described, yet it does not complicate the more typical case, nor does it add the undesirable burden of dealing with compound keys.

Thanks,
Charles

> Sent: Friday, August 03, 2012 8:40 PM
> To: Ravindran, Parthasarathi
> Cc: [email-masked]
> > As discussed today meeting, Paul mentioned below metadata model
> change is an alternative which clarifies the stream XML element usage
> within the specific single CS instead of spread across. I'm interested in
> hearing anybody has objection to this change.
> 
>