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

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 1 May 2013 07:40:11 +0000

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:[email-masked]]
> Sent: 01 May 2013 05:39
> To: Alan Johnston; Hutton, Andrew
> Cc: [email-masked]
> 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 <[email-masked]>
> Date: 04-30-2013 11:00 AM (GMT-05:00)
> To: "Hutton, Andrew" <[email-masked]>
> Cc: Henry Lum <[email-masked]>,[email-masked]
> 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: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Henry Lum
> >> Sent: 18 April 2013 05:15
> >> To: [email-masked]
> >> 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
> >> [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, 2 May 2013 03:21:01 +0000

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"
><[email-masked]> 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
>
>
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sat, 4 May 2013 04:39:59 +0000

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. 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.
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 

> Behalf Of Ram Mohan R (rmohanr)
> Sent: Wednesday, May 01, 2013 8:21 PM
> To: [email-masked]

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 5 May 2013 20:37:49 +0530

Hi Charles,

As per SIPREC requirement RFC, pause & resume of RS media are the only
operation defined and the definition is as follows:

    Pause: The action of temporarily discontinuing the transmission
      and collection of RS media.
      Resume: The action of recommencing the transmission and collection
      of RS media.

>From Metadata in RS SDP,  it will be clear whether the media is paused or
not using the direction attributes. In case of mixed stream, the media is
not paused but one of the participant media is not mixed and so, it will not
fall under Pause.

As of now, metadata does not consider CS hold as the multiple types of CS
hold are possible which are as follows:

1) Music on hold (Participant put the remote participant to listen
(recvonly) instead of senvrecv.
2) Hold by direction attribute (Both participant are not sending media and
indicated by inactive SDP direction attribute)
3) Hold by setting m-line port as 0
4) Hold by setting c-line IP as invalid (0.0.0.0) or ::
5) One of the participant in the conference is put in hold (Your usecase).
6) Not sending media without any signaling exchange (Bad implementation but
exists in the deployment)

Thanks
Partha

> Behalf Of Charles Eckel (eckelcu)
> Sent: Saturday, May 04, 2013 10:10 AM
> To: Ram Mohan R (rmohanr); [email-masked]
> 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. 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.
> 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
>

---

From: Henry Lum <[email-masked]>
Date: Mon, 6 May 2013 03:17:24 +0000

I agree that an SRC may choose to pause the RS media if the CS is happened
to be placed on hold. What the protocol draft is stating that SRC must use
a=inactive to state that it is pausing media while the metadata is
conveying the information about the CS is being placed on hold.

The way I understand the last sentence of section 6.7 is that the media
stream object can provide this information on media stream direction
change. If this is not correct then we should consider adding this into
the metadata draft.

Henry

On 2013-05-04 12:39 AM, "Charles Eckel (eckelcu)" <[email-masked]>
wrote:

>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. 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.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 9 May 2013 06:30:02 +0000

Hi Charles,

Sorry for delay. Please see inline

> On 04/05/13 10:09 AM, "Charles Eckel (eckelcu)" <[email-masked]>
>wrote:

>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:[email-masked]>
             <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:[email-masked]>
               <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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 9 May 2013 06:37:36 +0000

Please see inline

> On 05/05/13 8:37 PM, "Parthasarathi R" <[email-masked]>
>wrote:

>not paused but one of the participant media is not mixed and so, it will

Pause is an operation from SRC to SRS. This has nothing to do participant
contribution to media stream or a participant receiving a media stream.
A participant contribution to a media stream can be indicated by the
presence/absence of <send> tag which points to a stream element.
Similarly for receive as well.
This would work for mixed stream cases as well where we will have multiple
participants having <send> tag point to the same mixed stream.

>exists in the deployment)

I don¹t think there is a discussion / requirement to indicate the above
level of information in metadata. What we need is the information if a
participant is sending a stream or not and receiving a stream or not which
is already possible. A participant may stop sending a media stream due to
any one of the actions above when it gets negotiated in CS SDP.

Ram

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 May 2013 22:37:07 -0400

WFM

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 10 May 2013 11:12:38 +0000

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" <[email-masked]> wrote:

---

From: Henry Lum <[email-masked]>
Date: Mon, 13 May 2013 18:16:47 +0000

This works for me.

Thanks
Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
Sent: May-10-13 7:13 AM
To: [email-masked]
Subject: Re: [siprec] CS hold/resume clarification in protocol draft

Regards,
Ram

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 15 May 2013 19:25:14 +0000

Me too. Thanks for the detailed example Ram.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Henry Lum
> Sent: Monday, May 13, 2013 11:17 AM

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 17 May 2013 09:18:59 +0000

Looks good to me great work Ram.

Andy

> Sent: 15 May 2013 20:25
> To: Henry Lum; Ram Mohan R (rmohanr); [email-masked]
> Behalf Of
> > >>> 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
> > >>> recording continue, and indicate in XML which participants in the
> CS
> > >>>are
> > >> do with the existing metadata XML. We could use the <send> and
> <recv>
> > >>XML
> > >> why a CS participant is not sending media(like hold e.t.c). I
> don't
> > >>think
> > >> responds with a=recvonly then a snapshot of metadata at that
> instance
> > >>from
> > >> Note the above approach would work for all cases (stream mixed
> from SRC
> > >>to
> > >>>> In the current metadata draft to indicate CS hold/resume from
> SRC to
> > >>>> SRS
> > >>>> resume cannot be indicated using SDP semantics from SRC to SRS
> as
> > >>>> the SRS
> > >>>> 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
> > >>>>> My view is that this is enough of an issue to make it a MUST as
> you
> > >>>> say
> > >>>>> probably a trouble ticket being raised against the
> implementation
> > >>>> is
> > >>>>> reason enough.
> > >>>>>
> > >>>>> Andy
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> The only interop issue this can cause is an SRS would mistaken
> a
> > >>>> hold
> > >>>>>> We definitely want to discourage this behavior, but MUSTs
> relate
> > >>>> to
> > >>>>>> Another thought - If an implementer used 1 RS for each CS,
> would
> > >>>> this
> > >>>>>>>>    The SRC can temporarily discontinue streaming and
> collection
> > >>>> of
> > >>>>>>>>    recording.  In this case, the SRC sends a new SDP offer
> and
> > >>>> sets
> > >>>>>> the
> > >>>>>>>>
> > >>>>>>>>    collection of recorded media, the SRC sends a new SDP
> offer
> > >>>> and
> > >>>>>> sets
> > >>>>>>>>    Note that a CS itself may change the media stream
> direction
> > >>>> by
> > >>>>>>>> updating
> > >>>>>>>>
> > >>>>>>>>    direction changes in CS are conveyed in the metadata by
> the
> > >>>> SRC.
> > >>>>>> The
> > >>>>>>>> SRC
> > >>>>>>>>