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

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

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
>