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

[Leon Portman <[e-mail]>]

I am Ok

Regards

Leon

On Sep 27, 2012, at 8:40 AM, Ram Mohan R (rmohanr) <[e-mail]> wrote:

> 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" <[e-mail]> wrote:
> 
>> 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)" <[e-mail]>
>>> 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: [e-mail] [mailto:[e-mail]] On
>>>> Behalf
>>>> Of Paul Kyzivat
>>>> Sent: Friday, August 03, 2012 8:40 PM
>>>> To: Ravindran, Parthasarathi
>>>> Cc: [e-mail]
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>> _______________________________________________
>>> siprec mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/siprec
>>> 
>> 
>> 
>> 
> 
> 
> _______________________________________________
> siprec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec