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