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

["Hutton, Andrew" <[e-mail]>]

Looks good to me great work Ram.

Andy

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Charles Eckel (eckelcu)
> Sent: 15 May 2013 20:25
> To: Henry Lum; Ram Mohan R (rmohanr); [e-mail]
> Subject: Re: [siprec] CS hold/resume clarification in protocol draft
> 
> 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
> _______________________________________________
> siprec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec