Subject: [siprec] Issue from meeting: KPML

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

During discussion on recording DTMF, there was a suggestion we should consider KPML. My assumption is that this was to do with the CS, i.e., whether to record DTMF that has been delivered, in the context of the CS, to the SRC using KPML. I don't think the concern was to do with delivery via KPML from the SRC to the SRS. Would the person concerned (without replaying the recording I don't recall who it was) please clarify what was intended. Based on such clarification we can then create a tracker ticket on the requirements document if needed.	

John

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 14 Oct 2010 19:48:55 +0530

John,

SIP UA which support KPML for the communication session may prefer to
record DTMF using KPML mechanism for recording session because there is
no need to conversion to another DTMF mechanism like RFC 2833. 

In case SIPREC restricts for RFC 2833 DTMF only, SIP UA must do the
conversion of DTMF from RFC 2833 to KPML for recording alone.

Thanks
Partha 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Thursday, October 14, 2010 7:06 PM
To: <[email-masked]>
Subject: [siprec] Issue from meeting: KPML

During discussion on recording DTMF, there was a suggestion we should
consider KPML. My assumption is that this was to do with the CS, i.e.,
whether to record DTMF that has been delivered, in the context of the
CS, to the SRC using KPML. I don't think the concern was to do with
delivery via KPML from the SRC to the SRS. Would the person concerned
(without replaying the recording I don't recall who it was) please
clarify what was intended. Based on such clarification we can then
create a tracker ticket on the requirements document if needed.	

John
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Oct 2010 16:51:22 +0200

> From: Parthasarathi R (partr) [mailto:[email-masked]] 
> Sent: 14 October 2010 15:19
> To: Elwell, John; [email-masked]
> Subject: RE: [siprec] Issue from meeting: KPML
> 
> John,
> 
[JRE] That makes sense to some extent, but how often will it apply in practice? I am not aware of much deployment of KPML currently, compared to RFC 4733. It requires both sides to support it, so in many situations it will not be available, whereas RFC 4733 might well be available.

The SRC needs to be on the media path, so that it can send media to the SRS, so the SRC should be in a position to pick of DTMF from the media path. If the SRC doesn't pick up DTMF from the media path, it needs to know of some other entity on the media path that it can subscribe to in order to get this information using KPML, and needs to have a means of identifying the dialog from which DTMF events are to be extracted. It sounds like quite a complex mechanism, compared to RFC 4733.
 
> conversion of DTMF from RFC 2833 to KPML for recording alone.
[JRE] In this case, the SIP UA (i.e., the SRC) would need to support both RFC 4733 and KPML. It would make more sense, if it receives DTMF via RFC 4733 on the CS, also to send it to the SRS using RFC 4733.

John (as individual)

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Elwell, John

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Sat, 16 Oct 2010 16:49:22 +0530

John,
 
I agree with you that KPML complicates the recording solution and RFC 4733 simplifies the solution by sending it in the recording dialog between SRC and SRS. We will go ahead with RFC 4733 as a SIPREC DTMF mechanism as long as the wider team has no objection.
 
Thanks
Partha

________________________________

From: Elwell, John [mailto:[email-masked]]
Sent: Thu 10/14/2010 8:21 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] Issue from meeting: KPML

John (as individual)

---

From: Leon Portman <[email-masked]>
Date: Sun, 17 Oct 2010 10:45:23 +0200

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.
I think we should support both methods:  RFC 4733 and as part of the metadata

Leon

From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Saturday, October 16, 2010 1:19 PM
To: Elwell, John; [email-masked]
Subject: Re: [siprec] Issue from meeting: KPML

John,

Thanks
Partha

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Oct 2010 09:53:56 +0200

Leon,

This is posted to the wrong thread. This response seems to relate more to the data versus metadata thread, and doesn't mention KPML. Please post an appropriate response on that thread. 

However, I think what you also suggest here is that information might be needed by the Policy Server in order to decide whether to record a call or not. If the Policy Server is separate from the SRC, KPML might be a suitable solution for the Policy Server to obtain DTMF. But I believe that is outside the scope of SIPREC.

John

> From: Leon Portman [mailto:[email-masked]] 
> Sent: 17 October 2010 09:45
> To: Parthasarathi R (partr); Elwell, John; [email-masked]
> 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.
> 
> 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.
> 
> [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
> I agree with you that KPML complicates the recording solution 
> and RFC 4733 simplifies the solution by sending it in the 
> recording dialog between SRC and SRS. We will go ahead with 
> RFC 4733 as a SIPREC DTMF mechanism as long as the wider team 
> has no objection.
> 
>  
> 
> Thanks
> 
> Partha
> 
>  
> 
> [JRE] That makes sense to some extent, but how often will it 
> apply in practice? I am not aware of much deployment of KPML 
> currently, compared to RFC 4733. It requires both sides to 
> support it, so in many situations it will not be available, 
> whereas RFC 4733 might well be available.
> 
> The SRC needs to be on the media path, so that it can send 
> media to the SRS, so the SRC should be in a position to pick 
> of DTMF from the media path. If the SRC doesn't pick up DTMF 
> from the media path, it needs to know of some other entity on 
> the media path that it can subscribe to in order to get this 
> information using KPML, and needs to have a means of 
> identifying the dialog from which DTMF events are to be 
> extracted. It sounds like quite a complex mechanism, compared 
> to RFC 4733.
> 
> >
> [JRE] In this case, the SIP UA (i.e., the SRC) would need to 
> support both RFC 4733 and KPML. It would make more sense, if 
> it receives DTMF via RFC 4733 on the CS, also to send it to 
> the SRS using RFC 4733.
> 
> John (as individual)
> 
> >
> > Thanks
> > Partha

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Oct 2010 10:00:29 -0400

Leon,

If the SRC has the understanding to extract semantic information like 
pin or credit card info from the media stream (whether given as DTMF, 
voice, or whatever) then I have no problem with it sending that as 
application-specific metadata. But it is *application specific*, and so 
I don't think we can/should say much about it.

But I don't think it makes sense for the SRC to extract DTMF in an 
application-independent way and insert it into the metadata, because 
that provides too little information about its context to be useful for 
anything.

	Thanks,
	Paul

On 10/17/2010 4:45 AM, Leon Portman wrote:
> 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
>
> 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.
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Parthasarathi R (partr)
> *Sent:* Saturday, October 16, 2010 1:19 PM
> *To:* Elwell, John; [email-masked]
> *Subject:* Re: [siprec] Issue from meeting: KPML
>
> John,
>
> I agree with you that KPML complicates the recording solution and RFC
> 4733 simplifies the solution by sending it in the recording dialog
> between SRC and SRS. We will go ahead with RFC 4733 as a SIPREC DTMF
> mechanism as long as the wider team has no objection.
>
> Thanks
>
> Partha
>
> ------------------------------------------------------------------------
>
> *From:* Elwell, John [mailto:[email-masked]]
> *Sent:* Thu 10/14/2010 8:21 PM
> *To:* Parthasarathi R (partr); [email-masked]
> *Subject:* RE: [siprec] Issue from meeting: KPML
>
>
>
> [JRE] That makes sense to some extent, but how often will it apply in
> practice? I am not aware of much deployment of KPML currently, compared
> to RFC 4733. It requires both sides to support it, so in many situations
> it will not be available, whereas RFC 4733 might well be available.
>
> The SRC needs to be on the media path, so that it can send media to the
> SRS, so the SRC should be in a position to pick of DTMF from the media
> path. If the SRC doesn't pick up DTMF from the media path, it needs to
> know of some other entity on the media path that it can subscribe to in
> order to get this information using KPML, and needs to have a means of
> identifying the dialog from which DTMF events are to be extracted. It
> sounds like quite a complex mechanism, compared to RFC 4733.
>
>>
> [JRE] In this case, the SIP UA (i.e., the SRC) would need to support
> both RFC 4733 and KPML. It would make more sense, if it receives DTMF
> via RFC 4733 on the CS, also to send it to the SRS using RFC 4733.
>
> John (as individual)
>
>>
>>  Thanks
>>  Partha