Re: [siprec] Call Hold / Mute etc,

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.