Re: [siprec] Call Hold / Mute etc,

["Parthasarathi R" <[e-mail]>]

Brian,

SIPREC pause operation is indicated to SRS from SRC. This helps
emergency calls. Also, SRS shall identify "no packets" from RS
RTP streams.

Having said that, Mute does not falls under SIPREC pause operation 
as there is no signaling involved. In case SRC has to 
monitor RTP (media) layer and report as "SIPREC pause from SRC to 
SRS" based on no RTP packets for sustained time, then it is new
Requirement for SRC.

Thanks
Partha
 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Brian Rosen
> Sent: Tuesday, March 12, 2013 9:52 PM
> To: Dave Higton
> Cc: [e-mail]
> Subject: Re: [siprec] Call Hold / Mute etc,
> 
> 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 <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Henry Lum
> > Sent: 12 March 2013 16:05
> > To: Parthasarathi R; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)';
> [e-mail]
> > 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:[e-mail]]
> > Sent: March-12-13 11:44 AM
> > To: Henry Lum; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)';
> [e-mail]
> > 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: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Henry Lum
> >> Sent: Monday, March 11, 2013 9:50 PM
> >> To: Hutton, Andrew; Ram Mohan R (rmohanr); [e-mail]
> >> 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:[e-mail]]
> >>> Sent: Thursday, October 25, 2012 9:47 AM
> >>> To: Charles Eckel (eckelcu); Henry Lum
> >>> Cc: [e-mail]; [e-mail]
> >>> 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: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Hutton, Andrew
> >> Sent: March-10-13 11:52 AM
> >> To: Ram Mohan R (rmohanr); [e-mail]
> >> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/siprec
> >> _______________________________________________
> >> siprec mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/siprec
> >>
> >> _______________________________________________
> >> siprec mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/siprec
> >
> >
> > _______________________________________________
> > siprec mailing list
> > [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/siprec
> 
> _______________________________________________
> siprec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec