Re: [siprec] Call Hold / Mute etc,

Brian Rosen <br@brianrosen.net> Tue, 12 March 2013 16:21 UTC

Return-Path: <br@brianrosen.net>
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 7C7CE21F86D5 for <siprec@ietfa.amsl.com>; Tue, 12 Mar 2013 09:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.399
X-Spam-Level:
X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 ab17nzqsHPy9 for <siprec@ietfa.amsl.com>; Tue, 12 Mar 2013 09:21:35 -0700 (PDT)
Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4208C21F89FB for <siprec@ietf.org>; Tue, 12 Mar 2013 09:21:35 -0700 (PDT)
Received: by mail-qa0-f46.google.com with SMTP id o13so1688321qaj.5 for <siprec@ietf.org>; Tue, 12 Mar 2013 09:21:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=89pZh6ZtH44Y5hrvyklIGTDM4L48Fc0dYmBqHC3QkUE=; b=ExBSl4mUX24Qqju2mj3FafoWWn420rHX4qIA8HOSM/BN4Yp/8Rwp9tygHlMo5kkwo/ vaUGWGGTiyUBoCUXYR5ujHNVzY/Dc8iOcfc8A89x5dN9x04VMqV+KqysG8yGRVpANBcm XLkNxdjGJGd5NxVPKJLIqxnCCJjbZGflKk/4yBnISLst/0p3bpeueKS/dU/BKqVRBcVh /MlrnayCOMWQrZkwGOVtD335k6NFqRIVtYZEkC9JO5lE1EAPoTE5wRfoU0bQHoVtLnDm Ou/P1PNMhXk9P3P1w2pJqOFLfmjsjwFcXaOutFMNVq+Zma//v3eLOGS8x4mZHz8RIsZt bJKg==
X-Received: by 10.49.86.35 with SMTP id m3mr26741718qez.13.1363105294601; Tue, 12 Mar 2013 09:21:34 -0700 (PDT)
Received: from [192.168.133.159] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPS id o5sm32319011qao.12.2013.03.12.09.21.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 09:21:33 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B6940561A9B568@SOUEXC01.eu.nice.com>
Date: Tue, 12 Mar 2013 12:21:30 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <77C803CA-6326-4769-A0D3-49698792C2EC@brianrosen.net>
References: <9F33F40F6F2CD847824537F3C4E37DDF06891D0B@MCHP04MSX.global-ad.net><E92E67B176B8B64D8D3A8F5E44E9D8F41F62BD@xmb-aln-x05.cisco.com><9F33F40F6F2CD847824537F3C4E37DDF06892BCA@MCHP04MSX.global-ad.net><F3005B7CDE1DA5498B794C655CE1641E05C9DF@GENSJZMBX03.msg.int.genesyslab.com><00a201ce1f38$76b20190$641604b0$@co.in> <F3005B7CDE1DA5498B794C655CE1641E05E1ED@GENSJZMBX03.msg.int.genesyslab.com> <9B0B6FB9606F4D4AB133C5E9A203B6940561A9B568@SOUEXC01.eu.nice.com>
To: Dave Higton <dave.higton@nice.com>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkRt5Pza2A1/EbZ5xlhrLr/l5byZcREfJgfbC14hUh8FSG/axWtqHfcq3q9Y09TRkVvbcak
Cc: siprec@ietf.org
Subject: Re: [siprec] Call Hold / Mute etc,
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: Tue, 12 Mar 2013 16:21:36 -0000

With my 9-1-1/1-1-2 hat on, it does, or at least it would be helpful to know that there are no packets (or silence packets) for a sustained time.

Brian

On Mar 12, 2013, at 12:11 PM, Dave Higton <dave.higton@nice.com> wrote:

> AFAIK, mute has never been signalled on any telephone system.  The terminal just sends silence.
> 
> In VoIP, there are of course two ways of sending silence: send packets containing silence, or stop sending packets.
> 
> Is knowledge of the mute state important?
> 
> Dave
> 
> -----Original Message-----
> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Henry Lum
> Sent: 12 March 2013 16:05
> To: Parthasarathi R; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; siprec@ietf.org
> Subject: Re: [siprec] Call Hold / Mute etc,
> 
> When a participant goes on hold, then it's a just the direction of the participant stream gets modified like what is shown in section 3.3 of call flow draft. According to what is specified in the protocol draft, the media direction of the RS stream does not change since it also signals that the recorded media is also being paused along with the change of participant stream.
> 
> Regards,
> Henry
> 
> -----Original Message-----
> From: Parthasarathi R [mailto:partha@parthasarathi.co.in]
> Sent: March-12-13 11:44 AM
> To: Henry Lum; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; siprec@ietf.org
> Subject: RE: [siprec] Call Hold / Mute etc,
> 
> Hi all,
> 
> I agree that pause and resume are the only terminology mentioned in SIPREC(RFC 6341). "Call Hold" word is used in Sec 3.3. of draft-ram-siprec-callflows for easy understanding. In case it confuses, we will update with Pause and resume. Also, SIPREC protocol draft has to be updated with pause & resume.
> 
> Pause of the stream shall be achieved by setting inactive as direction attribute and resume has to be mentioned by sendrecv direction attribute.
> 
> IMO, Mute & Unmute are not signaled between SIP entities. call hold shall achieved in multiple ways in SDP like
> 
> 1) Media direction attribute change as inactive
> 2) Media direction attribute change as sendonly (Music on Hold)
> 3) changing the "c" line with 0.0.0.0. (Approach is deprecated)
> 
> So, Sec 7.1.1.1 of SIPREC protocol about mute/unmute has to be removed. 
> The supplementary Service information shall be indicated through metadata extension data if required.
> 
> Thanks
> Partha
> 
> 
>> -----Original Message-----
>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On 
>> Behalf Of Henry Lum
>> Sent: Monday, March 11, 2013 9:50 PM
>> To: Hutton, Andrew; Ram Mohan R (rmohanr); siprec@ietf.org
>> Subject: Re: [siprec] Call Hold / Mute etc,
>> 
>> I found an old discussion about mute/unmute and I think we forgot to 
>> post this on the mailing list and even incorporating the change in the 
>> draft.
>> 
>> The suggestion came from Andy to make a change to avoid using the word 
>> mute/unmute to avoid any confusion of terminology on how mute is 
>> operated by the handsets. The a=inactive is still reserved for pausing 
>> and unpausing the recorded media, while metadata is used for conveying 
>> CS stream changes.
>> 
>> Other than this I don't think there was any other mentions on mute and 
>> this statement on the protocol draft. As Andy mentioned, this 
>> statement has been on the protocol draft since -00.
>> 
>> Regards,
>> Henry
>> 
>>> -----Original Message-----
>>> From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]
>>> Sent: Thursday, October 25, 2012 9:47 AM
>>> To: Charles Eckel (eckelcu); Henry Lum
>>> Cc: leon.portman@gmail.com; alan.b.johnston@gmail.com
>>> Subject: draft-ietf-siprec-protocol mute-unmute
>>> 
>>> Hi,
>>> 
>>> Changing the name of the thread to cover this specific point.
>>> 
>>> Regarding the following part of the chain which refers to 
>>> mute/unmute
>> on
>>> the CS see comment below.
>>> 
>>>>>>> 
>>>>>>> 5) Section 7.1.1.1 ends with:
>>>>>>> 
>>>>>>>   Note that when a CS
>>>>>>>   stream is muted/unmuted, this information is conveyed in
>> the
>>>>>> metadata
>>>>>>>   by the SRC.  The SRC SHOULD NOT modify the media stream
>> with
>>>>>>>   a=inactive for mute since this operation is reserved for
>>>> pausing
>>>>>> the
>>>>>>>   RS media.
>>>>>>> 
>>>>>>> How does the SRC know that the stream is muted/unmuted?
>>>>>>> 
>>>>> 
>>>>> 
>>>>> [hlum] The SRC should know that the stream is being set to
>> inactive
>>>> since
>>>>> the SRC is sending the recorded media from the CS and the SRC is
>> in
>>>> the
>>>>> signaling path of the CS to know that a media stream is being 
>>>>> set
>> to
>>>> inactive.
>>>> 
>>>> In my experience, even within the CS, the media stream does not 
>>>> get changed from sendrecv to inactive during a mute operation. 
>>>> Instead,
>> the
>>>> endpoint that mutes itself does so silently. In some cases, there
>> is
>>>> some proprietary signaling or media packet marking indicating 
>>>> mute,
>> but
>>>> in general the SRC would not know if the endpoint was simply quiet
>> or
>>>> really had done a mute locally.
>>>> 
>>> 
>>> The problem here is terminology in that mute normally implies a 
>>> local operation at the SIP UA rather than a hold operation which 
>>> actually
>> involves
>>> SIP Signaling and an offer/answer. So I would suggest that we do 
>>> need
>> to
>>> make a minor change to the text to clarify what we are referring to.
>>> 
>>> Maybe something like this would help.
>>> 
>>> "Note that when a CS stream's direction is changed, for example to
>> inactive,
>>> this information is conveyed in the metadata by the SRC.  The SRC
>> SHOULD
>>> NOT in this case change the RS media stream direction since this
>> operation
>>> is reserved for pausing the RS media".
>>> 
>>> This would avoid talking about services such as hold, mute etc.
>>> 
>>> Regards
>>> Andy
>>> 
>> 
>> 
>> -----Original Message-----
>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On 
>> Behalf Of Hutton, Andrew
>> Sent: March-10-13 11:52 AM
>> To: Ram Mohan R (rmohanr); siprec@ietf.org
>> Subject: Re: [siprec] Call Hold / Mute etc,
>> 
>> 
>> Om: 10 March 2013 10:26 Of Ram Mohan R (rmohanr) Wrote
>> 
>> 
>>> 
>>> I think we have discussed about representing hold/resume of CS from
>> SRC
>>> to
>>> SRS in the past and the preference has been to use SIP/SDP semantics 
>>> rather than re-inventing another approach in XML. Is there some 
>>> thing that has changed which requires us the re-look at this ?
>> 
>> [AndyH] - Might be my memory that is the issue if you can point me at 
>> the discussion we had that would help. However I checked the protocol 
>> document and this has always stated that "inactive" on the RS means 
>> that the recording is paused and does not imply anything about the CS 
>> direction. The statement about indicating this is metadata was added 
>> in version 01 of the protocol draft and has been unchanged since then.
>> 
>> 
>> 
>>> On the other hand when you say recording is paused, how does SRC /
>> SRS
>>> know it is pause and not hold ? SIP semantics does not indicate any 
>>> thing.
>>> So I believe  SRS/SRC may not really differentiate on whether it is 
>>> pause/hold unless you have a some other means (non-SIP) to learn the 
>>> same.
>> 
>> [AndyH] Which is why I assume the protocol draft states that metadata 
>> is used for this.
>> 
>> 
>>> 
>>> Regards,
>>> Ram
>>> 
>>>> 
>>>> Andy
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> 
> NICE Systems UK Limited ("NICE") is registered in England under company number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 2ZP.
> 
> Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately.
> 
> Monitoring: NICE may monitor incoming and outgoing e-mails.
> 
> Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
> _______________________________________________
> siprec mailing list
> siprec@ietf.org
> https://www.ietf.org/mailman/listinfo/siprec