Re: [siprec] Call Hold / Mute etc,

Henry,

I'm not very clear about your conclusion. I'm modifying you statement for
clarification:

"When a participant pause the stream, 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."

The above statement just calls for the update in draft-ram-siprec-callflows
and we will do it in the next revision.

" 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" 

Please note that SIPREC metadata is the combination of XML + SDP because
stream element does not indicate about the SDP information but it provides
the label for linking SDP in RS. Pausing of the stream is the matter of SDP
which will be indicated by direction attribute of the specific "m" line in
RS. So, there is a need to change in SIPREC protocol draft. Please clarify
in case I'm missing something.

Thanks
Partha 

> -----Original Message-----
> From: Henry Lum [mailto:Henry.Lum@genesyslab.com]
> Sent: Tuesday, March 12, 2013 9:35 PM
> 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