Re: [siprec] CS hold/resume clarification in protocol draft
Henry Lum <Henry.Lum@genesyslab.com> Mon, 13 May 2013 18:17 UTC
Return-Path: <henry.lum@genesyslab.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE8621F87B1 for <siprec@ietfa.amsl.com>; Mon, 13 May 2013 11:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o40tnOYdT4jX for <siprec@ietfa.amsl.com>; Mon, 13 May 2013 11:16:56 -0700 (PDT)
Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id E9DA721F8545 for <siprec@ietf.org>; Mon, 13 May 2013 11:16:52 -0700 (PDT)
Received: from webmail-us.genesyslab.com (168.75.250.3 [168.75.250.3]) (Using TLS) by service107-us.mimecast.com; Mon, 13 May 2013 14:16:49 -0400
Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE01.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Mon, 13 May 2013 11:16:48 -0700
From: Henry Lum <Henry.Lum@genesyslab.com>
To: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>, "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: [siprec] CS hold/resume clarification in protocol draft
Thread-Index: AQHOO+tNF7ba1a4UI0aEaGdIgkhTUZju0VdAgACS/YCAAG94YYAAMcNQgAHAF4CAAzq6gIAH+mcAgAFRQYCAAJAJAIAEuCGA
Date: Mon, 13 May 2013 18:16:47 +0000
Message-ID: <F3005B7CDE1DA5498B794C655CE1641E08D0FA@GENSJZMBX03.msg.int.genesyslab.com>
References: <518C5D53.30101@alum.mit.edu> <E92E67B176B8B64D8D3A8F5E44E9D8F41EBD0799@xmb-aln-x05.cisco.com>
In-Reply-To: <E92E67B176B8B64D8D3A8F5E44E9D8F41EBD0799@xmb-aln-x05.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.17.178.77]
MIME-Version: 1.0
X-MC-Unique: 113051314165001201
Content-Type: text/plain; charset="WINDOWS-1252"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [siprec] CS hold/resume clarification in protocol draft
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/siprec>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 May 2013 18:17:01 -0000
This works for me. Thanks Henry -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: May-10-13 7:13 AM To: siprec@ietf.org 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" <pkyzivat@alum.mit.edu> 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)" <eckelcu@cisco.com> >>> 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:Alice@atlanta.com> >> <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:Bob@biloxy.com> >> <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: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>> Behalf Of Ram Mohan R (rmohanr) >>>> Sent: Wednesday, May 01, 2013 8:21 PM >>>> To: siprec@ietf.org >>>> 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" >>>>> <andrew.hutton@siemens-enterprise.com> 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:Henry.Lum@genesyslab.com] >>>>>> Sent: 01 May 2013 05:39 >>>>>> To: Alan Johnston; Hutton, Andrew >>>>>> Cc: siprec@ietf.org >>>>>> 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 <alan.b.johnston@gmail.com> >>>>>> Date: 04-30-2013 11:00 AM (GMT-05:00) >>>>>> To: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> >>>>>> Cc: Henry Lum <Henry.Lum@genesyslab.com>,siprec@ietf.org >>>>>> 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: siprec-bounces@ietf.org [mailto:siprec- >>>> bounces@ietf.org] On >>>>>>>> Behalf Of Henry Lum >>>>>>>> Sent: 18 April 2013 05:15 >>>>>>>> To: siprec@ietf.org >>>>>>>> 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 >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>> >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec
- [siprec] CS hold/resume clarification in protocol… Henry Lum
- Re: [siprec] CS hold/resume clarification in prot… Hutton, Andrew
- Re: [siprec] CS hold/resume clarification in prot… Alan Johnston
- Re: [siprec] CS hold/resume clarification in prot… Paul Kyzivat
- Re: [siprec] CS hold/resume clarification in prot… Henry Lum
- Re: [siprec] CS hold/resume clarification in prot… Hutton, Andrew
- Re: [siprec] CS hold/resume clarification in prot… Ram Mohan R (rmohanr)
- Re: [siprec] CS hold/resume clarification in prot… Charles Eckel (eckelcu)
- Re: [siprec] CS hold/resume clarification in prot… Parthasarathi R
- Re: [siprec] CS hold/resume clarification in prot… Henry Lum
- Re: [siprec] CS hold/resume clarification in prot… Ram Mohan R (rmohanr)
- Re: [siprec] CS hold/resume clarification in prot… Ram Mohan R (rmohanr)
- Re: [siprec] CS hold/resume clarification in prot… Paul Kyzivat
- Re: [siprec] CS hold/resume clarification in prot… Ram Mohan R (rmohanr)
- Re: [siprec] CS hold/resume clarification in prot… Henry Lum
- Re: [siprec] CS hold/resume clarification in prot… Charles Eckel (eckelcu)
- Re: [siprec] CS hold/resume clarification in prot… Hutton, Andrew