Subject: [siprec] Call Hold / Mute etc,

From: "Hutton, Andrew" <[email-masked]>
Date: Sat, 9 Mar 2013 12:26:15 +0000

Hi,

Section 3.3 of draft-ram-siprec-call-flows gives an example of a hold/resume on the CS and how it is reflected on the RS and it shows the SDP in the RS being set to a=inactive for a participant.

This does not seem to be consistent with draft-ietf-siprec-protocol which in section 7.1.1.1 states:

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

Is this an inconsistency and how exactly is the muted/unmuted indication conveyed in metadata I could not find this in the metadata draft.

Regards
Andy

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 9 Mar 2013 16:09:00 +0000

> On 09/03/13 5:56 PM, "Hutton, Andrew"
><[email-masked]> wrote:

>Hi,
>
>Section 3.3 of draft-ram-siprec-call-flows gives an example of a
>hold/resume on the CS and how it is reflected on the RS and it shows the
>SDP in the RS being set to a=inactive for a participant.
>

A question here:

How will SRC know a CS stream is muted /unmuted ? If SRC is going to learn
it from SDP direction attribute(a=sendonly/recvonly/inactive) of CS SDP
then it has no way to differentiate whether it is mute or hold from the
SIP semantics

So, indication of mute/unmute could be the same way as hold/resume which
is change in direction attribute in SDP.

Ram

>
>
>Is this an inconsistency and how exactly is the muted/unmuted indication
>conveyed in metadata I could not find this in the metadata draft.
>
>Regards
>Andy
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sat, 9 Mar 2013 23:32:26 +0000

> then it has no way to differentiate whether it is mute or hold from the

As you say the only thing the SRC knows about the CS is from SDP so we are talking about the direction of the CS nothing else. 

> is change in direction attribute in SDP.

We have always stated in the protocol draft that setting the direction of the RS to "a=inactive" is reserved for the case when the recording is paused and does not reflect the direction of the CS.  

Andy

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sun, 10 Mar 2013 14:25:45 +0000

> On 10/03/13 5:02 AM, "Hutton, Andrew"

>As you say the only thing the SRC knows about the CS is from SDP so we
>are talking about the direction of the CS nothing else.
>
>> 
>We have always stated in the protocol draft that setting the direction of
>the RS to "a=inactive" is reserved for the case when the recording is
>paused and does not reflect the direction of the CS.

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 ?
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.

Regards,
Ram

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sun, 10 Mar 2013 15:52:10 +0000

Om: 10 March 2013 10:26 Of Ram Mohan R (rmohanr) Wrote

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

> pause/hold unless you have a some other means (non-SIP) to learn the

[AndyH] Which is why I assume the protocol draft states that metadata is used for this.

---

From: Henry Lum <[email-masked]>
Date: Mon, 11 Mar 2013 16:19:47 +0000

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:[email-masked]]
> Sent: Thursday, October 25, 2012 9:47 AM
> To: Charles Eckel (eckelcu); Henry Lum
> Cc: [email-masked]; [email-masked]
> 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
> > > > >    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
>

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 12 Mar 2013 21:14:13 +0530

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

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Henry Lum
> Sent: Monday, March 11, 2013 9:50 PM
> To: Hutton, Andrew; Ram Mohan R (rmohanr); [email-masked]
> 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
> 
> > > > > >    stream is muted/unmuted, this information is conveyed in
> the
> > > > > metadata
> > I think we have discussed about representing hold/resume of CS from
> SRC
> > to
> [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.
> 
> 
>

---

From: Henry Lum <[email-masked]>
Date: Tue, 12 Mar 2013 16:05:03 +0000

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:[email-masked]] 
Sent: March-12-13 11:44 AM
To: Henry Lum; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; [email-masked]
Subject: RE: [siprec] Call Hold / Mute etc,

Hi all,

Thanks
Partha

> Behalf Of Hutton, Andrew

---

From: "Dave Higton" <[email-masked]>
Date: Tue, 12 Mar 2013 16:11:21 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Henry Lum
Sent: 12 March 2013 16:05
To: Parthasarathi R; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; [email-masked]
Subject: Re: [siprec] Call Hold / Mute etc,

Regards,
Henry

-----Original Message-----
From: Parthasarathi R [mailto:[email-masked]]
Sent: March-12-13 11:44 AM
To: Henry Lum; 'Hutton, Andrew'; 'Ram Mohan R (rmohanr)'; [email-masked]
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

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

> this statement on the protocol draft. As Andy mentioned, this 
> statement has been on the protocol draft since -00.
> 
> Regards,
> Henry
> 
> > Regarding the following part of the chain which refers to 
> > mute/unmute
> on
> > > > 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
> > > some proprietary signaling or media packet marking indicating 
> > > mute,
> but
> > 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
> > rather than re-inventing another approach in XML. Is there some 
> > thing that has changed which requires us the re-look at this ?
> 
> direction. The statement about indicating this is metadata was added 
> in version 01 of the protocol draft and has been unchanged since then.
> 
> 
> 

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.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 12 Mar 2013 12:21:30 -0400

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

---

From: Michael Smith <[email-masked]>
Date: Tue, 12 Mar 2013 16:34:02 +0000

With my 9-1-1/1-1-2 hat on as well, +1 to Brian's comment.

If you put a SIP session on hold, the media stops in both directions. We don't want to do that on an emergency call - we want the caller's media to continue so it can be recorded. So we have the agent mute their own transmit. We want the SRC to continue to receive the caller's audio, even if the agent's UA mutes the caller's audio to the agent's ear (which may be appropriate). 

A similar use case for non-emergency calls would be where we want the caller's comments recorded while the agent's voice is muted. Hearing them gripe about your product, company, or support is good QA info.

Michael Smith
Chief Technologist
Ph: 606.877.2788 | Mobile: 606.231.0243 

DSS Corporation / Equature
18311   W. Ten Mile Road, Suite 200
Southfield, MI - 48075
Tel: 1-888.305.3428
Fax: 1-248.569.6567
www.dss-corp.com
www.dispatchimprovement.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Tuesday, March 12, 2013 12:22 PM
To: Dave Higton
Cc: [email-masked]
Subject: Re: [siprec] Call Hold / Mute etc,

Brian

On Mar 12, 2013, at 12:11 PM, Dave Higton <[email-masked]> wrote:

>> 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 
>>>> changed from sendrecv to inactive during a mute operation.
>>>> Instead,
>> the

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 12 Mar 2013 22:20:46 +0530

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 

> From: Henry Lum [mailto:[email-masked]]
> Sent: Tuesday, March 12, 2013 9:35 PM
> 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
> 
> word
> and
> statement
> > > > > the SRC is sending the recorded media from the CS and the SRC
> is
> > in
> > > > the
> get
> > > > in general the SRC would not know if the endpoint was simply
> quiet
> > or
> local
> thing
> > > that
> in
> > > pause/hold unless you have a some other means (non-SIP) to learn
> the
> > > same.
> >

---

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 12 Mar 2013 22:33:12 +0530

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
 
> Behalf Of Brian Rosen
> Sent: Tuesday, March 12, 2013 9:52 PM
> To: Dave Higton
> Cc: [email-masked]
> 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
> 
> > In VoIP, there are of course two ways of sending silence: send
> packets containing silence, or stop sending packets.
> >
> > 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
> >
> 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.
> >
> >> [AndyH] Which is why I assume the protocol draft states that
> metadata
> >> is used for this.
> >>
> >>
> >>>
> >>> Regards,
> >>> Ram
> >>>
> >>>>
> >>>> Andy
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> > 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.
> >
> > 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Mar 2013 20:39:02 +0800

I don't understand what you and Brian are asking.
It is not the intent of SIPREC to alter in any way what goes on in the 
communication session. (Except for signaling that recording is happening.)

If emergency calls block, or alter the behavior of hold, then so be it. 
The recorder should record whatever happens, unless recording is turned 
off. (And I guess for emergency calls the recording is never turned off.)

	Thanks,
	Paul

---

From: Michael Smith <[email-masked]>
Date: Wed, 13 Mar 2013 14:24:36 +0000

We were responding to Dave Higton's email below, which made general statements about mute - that's all.

Michael Smith
Chief Technologist

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Wednesday, March 13, 2013 8:39 AM
To: [email-masked]
Subject: Re: [siprec] Call Hold / Mute etc,

I don't understand what you and Brian are asking.
It is not the intent of SIPREC to alter in any way what goes on in the communication session. (Except for signaling that recording is happening.)

If emergency calls block, or alter the behavior of hold, then so be it. 
The recorder should record whatever happens, unless recording is turned off. (And I guess for emergency calls the recording is never turned off.)

	Thanks,
	Paul

On 3/13/13 12:34 AM, Michael Smith wrote:
>>> word mute/unmute to avoid any confusion of terminology on how mute 
>>> is operated by the handsets. The a=inactive is still reserved for 
>>>> 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.
>>>
>>>
>>>
>>>> the same.
>>> metadata is used for this.
>>>
>>>
>>>>
>>>> Regards,
>>>> Ram
>>>>
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>