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

["Ram Mohan R (rmohanr)" <[e-mail]>]

Let me know if others have any concern with this proposal before 5/17.

If no concern I will go ahead and update the metadata draft with text and
call-flow draft with examples to have the below notation for pause/resume
and CS hold/CS resume indication.

Regards,
Ram

> On 10/05/13 8:07 AM, "Paul Kyzivat" <[e-mail]> wrote:

>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
>>
>
>_______________________________________________
>siprec mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/siprec
>