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

["Charles Eckel (eckelcu)" <[e-mail]>]

Me too. Thanks for the detailed example Ram.

Cheers,
Charles

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Henry Lum
> Sent: Monday, May 13, 2013 11:17 AM
> To: Ram Mohan R (rmohanr); [e-mail]
> Subject: Re: [siprec] CS hold/resume clarification in protocol draft
> 
> This works for me.
> 
> Thanks
> Henry
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Ram Mohan R (rmohanr)
> Sent: May-10-13 7:13 AM
> To: [e-mail]
> Subject: Re: [siprec] CS hold/resume clarification in protocol draft
> 
> 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
> >
> 
> 
> _______________________________________________
> siprec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec
> 
> _______________________________________________
> siprec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec