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

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 19 Sep 2012 12:25:14 +0000

Hi All,

Please let me know if any one else have comments / inputs on the proposed
modification for <stream> element in the metadata model and XML as given
by Paul below. Except for one response from Charles who seem to be
favoring this way of representation, I have not heard any feedback any one
else in the WG.

Please provide your inputs.

Regards,
Ram

> On 08/08/12 9:27 AM, "Charles Eckel (eckelcu)" <[email-masked]> wrote:

>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
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Paul Kyzivat
>> Sent: Friday, August 03, 2012 8:40 PM
>> To: Ravindran, Parthasarathi
>> Cc: [email-masked]
>> Subject: Re: [siprec] comments on draft-ietf-siprec-metadata-07
>> 
>> On 8/2/12 4:51 PM, Ravindran, Parthasarathi wrote:
>> > 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.
>> 
>> 
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> 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: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 27 Sep 2012 06:40:53 +0000

Hi All,

Please let us know of any inputs/comments you have on this proposed
change. Expect for one response favoring the proposed change we have not
seen any more.

If there is no response by 3/10, I would go ahead and incorporate the
below in the next revision of draft.

Regards,
Authors.

> On 19/09/12 5:55 PM, "Ram Mohan R" <[email-masked]> wrote:

---

From: Leon Portman <[email-masked]>
Date: Thu, 27 Sep 2012 09:26:44 +0200

I am Ok

Regards

Leon