Re: [siprec] CS hold/resume clarification in protocol draft

[Paul Kyzivat <[e-mail]>]

WFM

On 5/9/13 2:30 AM, Ram Mohan R (rmohanr) wrote:
> Hi Charles,
>
> Sorry for delay. Please see inline
>
>> On 04/05/13 10:09 AM, "Charles Eckel (eckelcu)" <[e-mail]>
>> wrote:
>
>> Hi Ram,
>>
>> My thinking on this is that we should use changing of the direction of
>> media descriptions in the RS from sendonly to inactive and vice versa to
>> indicate stopping/starting the recording of the associated media stream
>> as a whole. This does not imply anything about the state of the media in
>> the CS.
>
> I gave some thought about this and I tend to agree with you that we could
> use the SDP direction attribute  of RS to indicate stop/re-start the
> recording of media represented by that m-line. Now how an SRC decides to
> start/stop should be left outside the scope of SIPREC and may be dictated
> by a policy.
>
>> A hold/resume of the CS could result in the SRC deciding to stop the
>> recording, but this is not necessarily the case. The SRC could let the
>> recording continue, and indicate in XML which participants in the CS are
>> actively contributing media.
>
> To represent hold/resume or any other change in CS media, we could still
> do with the existing metadata XML. We could use the <send> and <recv> XML
> elements of a <participant> to indicate whether a participant is sending
> media/not sending  a particular media stream whose properties are
> represented by <stream> element. Note with this we only convey if a
> participant is sending/not sending media but an SRC still cannot convey
> why a CS participant is not sending media(like hold e.t.c). I don't think
> an SRC can really know this, all it can leo is by looking at CS signaling
> SDP and learn the direction attributes of media and send a snapshot
> metadata which has the information on participant sending/not sending a
> particular media stream.
>
> For example, in your below case for a two party call if one participant
> Alice puts the call on hold  by sending a SDP with a=sendonly and Bob
> responds with a=recvonly then a snapshot of metadata at that instance from
> SRC to SRS would look as below. Assume here a snapshot was sent initially
> with both participants having <send> to the two streams:
>
> Snapshot sent from SRC to SRS after initial RS setup.
>
> F1  INVITE SRC --------------> SRS
>
>        Content-Type: application/SDP
>        ...
>        m=audio 49170 RTP/AVP 0
>        a=rtpmap:0 PCMU/8000
>        a=label:96
>        a=sendonly
>        ...
>
>        m=audio 51372 RTP/AVP 0
>        a=rtpmap:0 PCMU/8000
>        a=label:97
>        a=sendonly
>
>        ....
>     <?xml version="1.0" encoding="UTF-8"?>
>         <recording xmlns='urn:ietf:params:xml:ns:recording'>
>                <datamode>complete</datamode>
>           <session session_id="hVpd7YQgRW2nD22h7q60JQ==">
>              <start-time>2010-12-16T23:41:07Z</start-time>
>           </session>
>            <participant
>               participant_id="srfBElmCRp2QB23b7Mpk0w==">
>              <nameID aor=sip:[e-mail]>
>               <name xml:lang="it">Alice</name>
>              </nameID>
>            </participant>
>            <participantsessionassoc
>               participant_id="srfBElmCRp2QB23b7Mpk0w=="
>               session_id="hVpd7YQgRW2nD22h7q60JQ==">
>             <associate-time>2013-05-09T23:41:07Z</associate-time>
>            </participantsessionassoc>
>            <participantstreamassoc
>               participant_id="srfBElmCRp2QB23b7Mpk0w==">
>               <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
>               <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
>            </participantstreamassoc>
>            <participant
>                participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
>                <nameID aor=sip:[e-mail]>
>                 <name xml:lang="it">Bob</name>
>              </nameID>
>            </participant>
>            <participantsessionassoc
>                participant="zSfPoSvdSDCmU3A3TRDxAw=="
>                     session_id="hVpd7YQgRW2nD22h7q60JQ==">
>               <associate-time>2013-05-09T23:42:07Z</associate-time>
>            </participantsessionassoc>
>            <participantstreamassoc
>                participant="zSfPoSvdSDCmU3A3TRDxAw==">
>              <send>8zc6e0lYTlWIINA6GR+3ag==</send>
>              <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
>            </participantstreamassoc>
>             <stream id="i1Pz3to5hGk8fuXl+PbwCw=="
>                session="hVpd7YQgRW2nD22h7q60JQ==">
>                <label>96</label>
>            </stream>
>            <stream id="8zc6e0lYTlWIINA6GR+3ag=="
>                session="zSfPoSvdSDCmU3A3TRDxAw==">
>                <label>97</label>
>            </stream>
>          </recording>
>
>
>
> Partial metadata Snapshot sent when Alice puts Bob on hold:
>
> F2 INVITE SRC --------------> SRS
>
>        Content-Type: application/SDP
>        ...
>        m=audio 49170 RTP/AVP 0
>        a=rtpmap:0 PCMU/8000
>        a=label:96
>        a=sendonly
>        ...
>
>        m=audio 51372 RTP/AVP 0
>        a=rtpmap:0 PCMU/8000
>        a=label:97
>        a=sendonly
>
>
>
> Partial Snapshot after Alice resumes with Bob
> <?xml version="1.0" encoding="UTF-8"?>
>    <recording xmlns='urn:ietf:params:xml:ns:recording'>
>      <dataMode>partial</dataMode>
>      <participantstreamassoc
>               participant_id="srfBElmCRp2QB23b7Mpk0w==">
>               <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
> </participantstreamassoc>
> <participantstreamassoc
>                participant="zSfPoSvdSDCmU3A3TRDxAw==">
> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
>            </participantstreamassoc>
> </recording>
>
> Here in the above snapshot the absence of <recv> for participant_id
> srfBElmCRp2QB23b7Mpk0w== (Alice) could be used to indicate that Alice is
> only sending media and not receiving any thing. Same way for Bob.
>
> Partial metadata Snapshot sent when Alice resumes call with Bob:
>
> F3 INVITE SRC --------------> SRS
>
> Content-Type: application/SDP
> ...
> m=audio 49170 RTP/AVP 0
> a=rtpmap:0 PCMU/8000
> a=label:96
> a=sendonly
> ...
>
> m=audio 51372 RTP/AVP 0
> a=rtpmap:0 PCMU/8000
> a=label:97
> a=sendonly
>
> <?xml version="1.0" encoding="UTF-8"?>
>    <recording xmlns='urn:ietf:params:xml:ns:recording'>
>      <dataMode>partial</dataMode>
>    <participantstreamassoc
>               participant_id="srfBElmCRp2QB23b7Mpk0w==">
>               <send>i1Pz3to5hGk8fuXl+PbwCw==</send>
>               <recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
>       </participantstreamassoc>
>    <participantstreamassoc
>                participant="zSfPoSvdSDCmU3A3TRDxAw==">
>              <send>8zc6e0lYTlWIINA6GR+3ag==</send>
>              <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
>        </participantstreamassoc>
>   </recording>
>
>
> Here in the above snapshot both Alice and Bob send and recv streams.
>
> Note the above approach would work for all cases (stream mixed from SRC to
> SRS or one of the endpoint is Focus in which case SRC received mixed
> streams e.t.c). In all the flows the presence /absence of <send> and
> <recv> tags could be used to indicate whether a participant is
> contributing to a stream or not and whether it is receiving a stream or
> not.
>
> Let me know if this approach is fine and if this works for every one in
> the WG.
>
> Regards,
> Ram
>
>> As an example, if the CS is a two party call, a hold of the CS might
>> result in the SRC stopping/pausing the recording. If it is a conference
>> call, one party going on hold would have might have no effect on the
>> direction of the media descriptions in the RS, but may result in the
>> generation of some XML indicating that a specific participant is no
>> longer contributing any media. I thought the existing XML allowed for
>> this, but perhaps I am mistaken about that?
>>
>> Cheers,
>> Charles
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On
>>> Behalf Of Ram Mohan R (rmohanr)
>>> Sent: Wednesday, May 01, 2013 8:21 PM
>>> To: [e-mail]
>>> Subject: Re: [siprec] CS hold/resume clarification in protocol draft
>>>
>>> A question here:
>>>
>>> In the current metadata draft to indicate CS hold/resume from SRC to
>>> SRS
>>> we re-use the SIP/SDP semantics and indicate the same with
>>> a=inactive/a=sendonly respectively.
>>> In the below discussion, I see we want to give a special meaning for
>>> a=inactive/a=sendonly sent from SRC to SRS. This would mean CS
>>> hold /
>>> resume cannot be indicated using SDP semantics from SRC to SRS as
>>> the SRS
>>> cannot differentiate between CS hold/resume and Recording
>>> stop/resume if
>>> we use the same semantics for both.
>>>
>>> The current metadata XML draft does not have any means to indicate
>>> CS
>>> hold/resume in XML. The general approach followed in the metadata
>>> (as a
>>> result of past feedback received) is to re-use SIP/SDP semantics
>>> wherever
>>> possible to represent metadata attributes and have XML
>>> representation for
>>> only those attributes that does not have a semantics in SIP/SDP  to
>>> represent. And hence the current draft re-uses SDP semantics to
>>> represent
>>> CS HOLD/RESUME.
>>>
>>> I want to hear feedback on - if the WG wants CSC hold/resume to be
>>> represented in XML ?
>>>
>>> Ram
>>>
>>>
>>>> On 01/05/13 1:10 PM, "Hutton, Andrew"
>>>> <[e-mail]> wrote:
>>>
>>>> My view is that this is enough of an issue to make it a MUST as you
>>> say
>>>> the fact that this would result in a misunderstanding and therefore
>>>> probably a trouble ticket being raised against the implementation
>>> is
>>>> reason enough.
>>>>
>>>> Andy
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Henry Lum [mailto:[e-mail]]
>>>>> Sent: 01 May 2013 05:39
>>>>> To: Alan Johnston; Hutton, Andrew
>>>>> Cc: [e-mail]
>>>>> Subject: Re: [siprec] CS hold/resume clarification in protocol draft
>>>>>
>>>>> The only interop issue this can cause is an SRS would mistaken a
>>> hold
>>>>> as pause/resume. Would there be any harm done in this case?
>>> It's
>>>>> undesirable but I dont think it's broken as there should be
>>>>> corresponding metadata to note the media stream change.
>>>>>
>>>>> Henry
>>>>>
>>>>>
>>>>> -------- Original message --------
>>>>> From: Alan Johnston <[e-mail]>
>>>>> Date: 04-30-2013 11:00 AM (GMT-05:00)
>>>>> To: "Hutton, Andrew" <[e-mail]>
>>>>> Cc: Henry Lum <[e-mail]>,[e-mail]
>>>>> Subject: Re: [siprec] CS hold/resume clarification in protocol draft
>>>>>
>>>>>
>>>>> We definitely want to discourage this behavior, but MUSTs relate
>>> to
>>>>> interop failures. Is that what we are trying to avoid?
>>>>>
>>>>> Another thought - If an implementer used 1 RS for each CS, would
>>> this
>>>>> hold/resume behavior be wrong?
>>>>>
>>>>> - Alan -
>>>>>
>>>>>
>>>>>
>>>>> On Apr 30, 2013, at 8:19 AM, "Hutton, Andrew"
>>> <andrew.hutton@siemens-
>>>>> enterprise.com> wrote:
>>>>>
>>>>>> Hi Henry,
>>>>>>
>>>>>> Only question I have is whether the "SHOULD NOT" in the
>>> following
>>>>> text could be a "MUST NOT"
>>>>>>
>>>>>> "The SRC SHOULD NOT modify the media stream in the RS to
>>> convey media
>>>>> stream direction changes in the CS"
>>>>>>
>>>>>> What does everybody think?
>>>>>>
>>>>>> Regards
>>>>>> Andy
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: [e-mail] [mailto:siprec-
>>> [e-mail]] On
>>>>>>> Behalf Of Henry Lum
>>>>>>> Sent: 18 April 2013 05:15
>>>>>>> To: [e-mail]
>>>>>>> Subject: [siprec] CS hold/resume clarification in protocol draft
>>>>>>>
>>>>>>> Following up on the clarification in the protocol draft, I
>>> propose
>>>>> to
>>>>>>> re-word the last paragraph in section 7.1.1.1. I removed
>>> mentions on
>>>>>>> the word mute/unmute:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    The SRC can temporarily discontinue streaming and collection
>>> of
>>>>>>>    recorded media from the SRC to the SRS for reason such as
>>> masking
>>>>>>> the
>>>>>>>    recording.  In this case, the SRC sends a new SDP offer and
>>> sets
>>>>> the
>>>>>>>
>>>>>>>    media stream to inactive (a=inactive) for each recorded
>>> stream to
>>>>> be
>>>>>>>    paused, as per the procedures in
>>>>>>> [RFC3264<http://tools.ietf.org/html/rfc3264>].  To resume
>>> streaming
>>>>> and
>>>>>>>    collection of recorded media, the SRC sends a new SDP offer
>>> and
>>>>> sets
>>>>>>>    the media streams with a=sendonly attribute.
>>>>>>>
>>>>>>>
>>>>>>>    Note that a CS itself may change the media stream direction
>>> by
>>>>>>> updating
>>>>>>>
>>>>>>>    the SDP, for example, by setting a=inactive for SDP hold. Media
>>>>>>> stream
>>>>>>>
>>>>>>>    direction changes in CS are conveyed in the metadata by the
>>> SRC.
>>>>> The
>>>>>>> SRC
>>>>>>>
>>>>>>>    SHOULD NOT modify the media stream in the RS to convey
>>> media
>>>>> stream
>>>>>>>
>>>>>>>    direction changes in the CS, as media stream direction
>>> changes in
>>>>>>> the RS
>>>>>>>
>>>>>>>    are reserved for pausing and resuming the recorded media.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Henry
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> siprec mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/siprec
>>
>
>
> _______________________________________________
> siprec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec
>