Subject: [siprec] Issue from meeting: DTMF - data or metadata?

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Oct 2010 15:35:27 +0200

During the meeting there was an unresolved discussion in the context of req-03 on whether DTMF should be considered data or metadata. I am not sure this is important from the requirements perspective, but it certainly will impact other discussions, e.g., on metadata model. For the time being I will not open a tracker ticket on this for the requirements document, but please continue the discussion.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Oct 2010 12:57:51 -0400

> During the meeting there was an unresolved discussion in the context of req-03 on whether DTMF should be considered data or metadata. I am not sure this is important from the requirements perspecti…

IMO DTMF is just part of the media. In a typical case where you are 
talking to an IVR, you might be entering responses via DTMF or speech 
with voice recognition. They are functionally equivalent. That does 
present a potential problem if DTMF is being transmitted in the 
signaling channel, because then how does it get captured and correlated 
with the media. (At the right point in time.) That is indeed a generic 
problem with DTMF in the signaling. The easiest way for us to deal with 
that is to make it the responsibility of the SRC to get it back into the 
media stream as 2833/4733 packets.

IIUC, Leon was asking for DTMF to be associated with the CS as metadata, 
unrelated to the time it arrived. I find that strange.

The most sense I can make out of it is that the SRC is interpreting the 
DTMF in some application-specific way in order to derive a CS-specific 
attribute that it wants to attach as metadata. If that is the case, then 
I think we are covered by application-specific metadata.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Fri, 15 Oct 2010 10:26:28 -0700

Agree with Paul that DTMF should be treated as part of media as RFC2833.
SRC should convert DTMF carried over signaling into 2833 if possible (or
best effort) since timing won't be accurate. Also, you don't get the
rising and falling edge of a DTMF if carried over signaling.

The reason why I asked for application data in metadata is that if you
have an IVR as an SRC, the SRC can interpret the DTMF in an
application-specific way that can be captured by the SRS as application
data. This way you don't need to capture DTMF as metadata.

Regards,
Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Friday, October 15, 2010 12:58 PM
> To: [email-masked]
> Subject: Re: [siprec] Issue from meeting: DTMF - data or metadata?
> 
> 
> 
> > During the meeting there was an unresolved discussion in the context
> of req-03 on whether DTMF should be considered data or metadata. I am
> not sure this is important from the requirements perspective, but it
> certainly will impact other discussions, e.g., on metadata model. For
> the time being I will not open a tracker ticket on this for the
> requirements document, but please continue the discussion.
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Dave Smith" <[email-masked]>
Date: Fri, 15 Oct 2010 16:20:22 -0700

I agree that there is a need for DTMF to be treated as part of the media
- that is, as long as the end result is that we can provide an accurate
replay of what was actually "heard in the conversation/CS"...that is, we
would want all  DTMF "beeps" to be audible (e.g., as a participant heard
them in the conversation) when one plays back the recording.  

We need to ensure that this is covered somehow.....between REQ-007 and
Use Case 6.

I see the idea of "SRC interpreting DTMF" not as a req't but as a
solution to REQ-022/023.  

Regards,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henry Lum
Sent: Friday, October 15, 2010 10:26 AM
To: Paul Kyzivat; [email-masked]
Subject: Re: [siprec] Issue from meeting: DTMF - data or metadata?

Regards,
Henry

> I think we are covered by application-specific metadata.

------------------------------------------------------------------------
-------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
confidential and proprietary information of Alcatel-Lucent and/or its
affiliated entities. Access by the intended recipient only is
authorized. Any liability arising from any party acting, or refraining
from acting, on any information contained in this e-mail is hereby
excluded. If you are not the intended recipient, please notify the
sender immediately, destroy the original transmission and its
attachments and do not disclose the contents to any other person, use it
for any purpose, or store or copy the information in any medium.
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
and/or its affiliated entities.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Oct 2010 19:49:25 -0400

> We need to ensure that this is covered somehow.....between REQ-007 and

Yes. Of course the fidelity of this will depend on those supplying the 
media. If they have screwed it up in some way there is nothing the SRC 
or the SRS can do to fix it. E.g. If the tones were stripped from the 
media and sent via signaling, and then reinserted into the media by the 
SRC, the result may not be quite "right".

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Oct 2010 08:26:38 +0200

So the conclusion I see from this thread is that:
- the reqs document is not impacted;
- we do not need to cover DTMF in the metadata model.

Clearly DTMF will need to be considered further as part of the solution.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 16 October 2010 00:49
> To: Dave Smith
> Cc: [email-masked]; Henry Lum
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> > Of Henry Lum
> >> that is to make it the responsibility of the SRC to get it 
> back into
> >> the
> --------------------------------------------------------------
> -----------------------------------------------------
> > CONFIDENTIALITY NOTICE: This e-mail and any files attached 
> may contain confidential and proprietary information of 
> Alcatel-Lucent and/or its affiliated entities. Access by the 
> intended recipient only is authorized. Any liability arising 
> from any party acting, or refraining from acting, on any 
> information contained in this e-mail is hereby excluded. If 
> you are not the intended recipient, please notify the sender 
> immediately, destroy the original transmission and its 
> attachments and do not disclose the contents to any other 
> person, use it for any purpose, or store or copy the 
> information in any medium. Copyright in this e-mail and any 
> attachments belongs to Alcatel-Lucent and/or its affiliated entities.
> > 					
> >

---

From: Leon Portman <[email-masked]>
Date: Mon, 18 Oct 2010 11:44:16 +0200

I am just reposting here my other post in wrong thread. It seems to be a
concesnus here that DTMF is data and not metadata however i am still not
comfortable that it will be the only approach.

I agree that using RFC 4733 (DTMF inside RTP packet as a special payload
type) will be most simple solution from SRC point of view, however still
think that in the case that SRC has access to the media and can extract DTMF
sequences, they should be represented in metadata updates as well.
It will greatly simplify SRS implementation.
Because the main use cases why SRS should receive DTMF are as follows:
1.    Customer identification (pin code)
2.    Credit card information – it will require media encryption between SRC
and SRC
3.    Customer intent – IVR scripts selection
The above information is frequently used by SRS in order to decide if to
record specific call so it should be received even before establishment of
the media session.

But it is not only the use case of Policy Server like John raised. For
example, it is also relevant for the case of recording only parts of the
call and DTMF were sent during the pause session. What about also mixing and
transcoding of Received media, is it going to influence DTMF payload?

I think we should support both methods:  RFC 4733 and as part of the
metadata

Leon

nt of view, however still think that in the case that SRC has access to the
media and can extract DTMF sequences, they should be represented in metadata
updates as well.
It will greatly simplify SRS implementation.
Because the main use cases why SRS should receive DTMF are as follows:
1.    Customer identification (pin code)
2.    Credit card information – it will require media encryption between SRC
and SRC
3.    Customer intent – IVR scripts selection
The above information is frequently used by SRS in order to decide if to
record specific call so it should be received even before establishment of
the media session.
I think we should support both methods:  RFC 4733 and as part of the
metadata

Leon

On Mon, Oct 18, 2010 at 8:26 AM, Elwell, John <
[email-masked]> wrote:

> > ----------
> > may contain
> > person, use it

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 18 Oct 2010 16:02:52 +0530

DTMF within the recording session is a data and not metadata. But in
case RFC 4733 capability is indicated from SRC to SRS then RFC 4733
capability (SDP) is a metadata. This is inline with other media
information like audio, video. 
 
The mixing and transcoding of Received DTMF/Media is upto SRC
implementation.
 
Thanks
Partha

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Leon Portman
Sent: Monday, October 18, 2010 3:14 PM
To: Elwell, John
Cc: Dave Smith; [email-masked]; Henry Lum
Subject: Re: [siprec] Issue from meeting: DTMF - data or metadata?

I agree that using RFC 4733 (DTMF inside RTP packet as a special payload
type) will be most simple solution from SRC point of view, however still
think that in the case that SRC has access to the media and can extract
DTMF sequences, they should be represented in metadata updates as well.
It will greatly simplify SRS implementation. 
Because the main use cases why SRS should receive DTMF are as follows:
1.    Customer identification (pin code)
2.    Credit card information - it will require media encryption between
SRC and SRC
3.    Customer intent - IVR scripts selection
The above information is frequently used by SRS in order to decide if to
record specific call so it should be received even before establishment
of the media session. 
 
But it is not only the use case of Policy Server like John raised. For
example, it is also relevant for the case of recording only parts of the
call and DTMF were sent during the pause session. What about also mixing
and transcoding of Received media, is it going to influence DTMF
payload?

Leon
 
nt of view, however still think that in the case that SRC has access to
the media and can extract DTMF sequences, they should be represented in
metadata updates as well.
It will greatly simplify SRS implementation. 
Because the main use cases why SRS should receive DTMF are as follows:
1.    Customer identification (pin code)
2.    Credit card information - it will require media encryption between
SRC and SRC
3.    Customer intent - IVR scripts selection
The above information is frequently used by SRS in order to decide if to
record specific call so it should be received even before establishment
of the media session.
I think we should support both methods:  RFC 4733 and as part of the
metadata
 
Leon

On Mon, Oct 18, 2010 at 8:26 AM, Elwell, John
<[email-masked]> wrote:

	Clearly DTMF will need to be considered further as part of the
solution.
	
	John

	> >> From: [email-masked]
[mailto:[email-masked]] On
	> >> signaling channel, because then how does it get captured
and
	> > correlated
	> >> problem with DTMF in the signaling. The easiest way for us
to deal
	> > with
	> >> IIUC, Leon was asking for DTMF to be associated with the CS
as
	> >> metadata,
	> >> The most sense I can make out of it is that the SRC is
interpreting
	> >> attribute that it wants to attach as metadata. If that is
the case,
	> >> then

---

From: Brian Rosen <[email-masked]>
Date: Mon, 18 Oct 2010 09:53:33 -0400

<as individual>
Does this not get us into the mess of timing, trying to relate timing of the media to timing in the metadata stream? 

Brian

On Oct 18, 2010, at 5:44 AM, Leon Portman wrote:

> I am just reposting here my other post in wrong thread. It seems to be a concesnus here that DTMF is data and not metadata however i am still not comfortable that it will be the only approach.
>  
> I agree that using RFC 4733 (DTMF inside RTP packet as a special payload type) will be most simple solution from SRC point of view, however still think that in the case that SRC has access to the media and can extract DTMF sequences, they should be represented in metadata updates as well.
> 2.    Credit card information – it will require media encryption between SRC and SRC
> The above information is frequently used by SRS in order to decide if to record specific call so it should be received even before establishment of the media session.
>  
> But it is not only the use case of Policy Server like John raised. For example, it is also relevant for the case of recording only parts of the call and DTMF were sent during the pause session. What about also mixing and transcoding of Received media, is it going to influence DTMF payload?
> 
> I think we should support both methods:  RFC 4733 and as part of the metadata
>  
> Leon
>  
> nt of view, however still think that in the case that SRC has access to the media and can extract DTMF sequences, they should be represented in metadata updates as well.
> 2.    Credit card information – it will require media encryption between SRC and SRC
> The above information is frequently used by SRS in order to decide if to record specific call so it should be received even before establishment of the media session.
> I think we should support both methods:  RFC 4733 and as part of the metadata
>  
> Leon
> 
> On Mon, Oct 18, 2010 at 8:26 AM, Elwell, John <[email-masked]> wrote: