Subject: RE: [Sipping] RE: SIP INFO method for DTMF

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 12 Feb 2002 07:05:48 -0800

Garland,

There are many reasons why RFC2833 is not sufficient or desirable for user
application control - which is what the signaled digits and key-events
drafts are trying to address. We listed many reasons for this in our
key-events draft. Jonathan and Bert have mentioned just a couple recently in
other emails.

However it should be re-iterated that these SUB/NOT proposals _ARE NOT_
attempting to replace RFC2833 for end-to-end DTMF transport. Indeed there
are many scenarios where RFC2833 AND the SUB/NOT methods need to be deployed
together. For instance, in the text-book example of the pre-paid phone card,
a user must have end-to-end DTMF transport so that they can interact with
their destination endpoint (e.g. calling a bank or airline); the pre-paid
calling card application is NOT on the media path at the time (perhaps the
signaling and/or media path between the caller and caller is using
end-to-end encryption) and yet needs to listen for certain trigger events
(such as "***"). This is a simple example but shows that it is not always
desirable OR EVEN POSSIBLE for an application server to use the media plane
via fork DTMF (and that the two schemes are complementary not exclusive).

The SUB/NOT mechanism is simply a method whereby an entity (e.g. application
server) - not necessarily on the media path - can request notification of
user interface activity relating to either a particular SIP dialog or to the
device itself.

As Jonathan says, the end-to-end DTMF transport and on-demand user
appellation control are two entirely different beasts - each with differing
requirements for both functionality and performance. It, therefore, does not
seem unreasonable to me that these are supplied by different mechanisms.

Regards,

Robert.

> -----Original Message-----
> From:	Garland Sharratt [mailto:[email-masked]]
> Sent:	Monday, February 11, 2002 5:41 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	[Sipping] RE: SIP INFO method for DTMF
> 
> Duncan:
> 
> From an architectural point of view, the clean way to carry 
> post-dial DTMF is in RTP using RFC 2833, because this 
> preserves the separation of media (audio) from signaling.  
> 
> Some reasons for keeping the separation include: 
> * the network is architected along this separation, with app 
>   servers and softswitches handling signaling and media 
>   gateways and media servers (Media Resource Functions) 
>   handling media; and
> * when post-dial DTMF is replaced with speech later, it will 
>   no longer fit in the signaling.
> 
> Of course they may be very valid reasons in particular cases 
> to do otherwise.
> 
> Garland
> 
	>  -----Original Message-----
	> From: 	[email-masked] 
	> [mailto:[email-masked]]  On Behalf Of 
	> [email-masked]
	> Sent:	Monday, February 11, 2002 01:55
	> To:	[email-masked]
	> Subject:	SIP INFO method for DTMF
	> 
	> IETF SIPPING experts,
	> 
	> 3GPP standards people have been looking at various potential 
	> solutions for carrying DTMF in the IP Multimedia Subsystem (IMS).
	> 
	> One such solution is the use of the SIP INFO method.  I have 
	> read the expired internet-draft, written by Jiri Kuthan (whom 
	> I tried to contact first, but the e-mail address was no 
	> longer a valid one) and there is support for such a solution 
	> in 3GPP.  I was involved in a telephone conference last week 
	> with other 3GPP delegates, in which we questioned why this 
	> draft expired?  Whilst we have highlighted some potential 
	> problems with using the draft that Jiri wrote, we did at 
	> least see the INFO method as a feasible option (as well as 
	> the RTP payload option - I've had a fair amount of e-mail 
	> discussion with Henning on RFC 2833).
	> 
	> 3GPP may run into problems in the Radio Access Network (RAN) 
	> area if we choose the RTP solution for DTMF.  As such, we are 
	> considering writing an internet-draft on the use of the SIP 
	> INFO method for DTMF.  However, before doing this, I thought 
	> it wise to 'test the water'.
	> 
	> The RTP solution is well documented, and we're currently 
	> looking into those RAN issues.  In the meantime, I'm asking 
	> for opinions on the general concept of using the SIP INFO 
	> method for DTMF.
	> 
	> 
	> Best Regards,
	> 
	> Duncan
	> 
	> 
	> 
	> 
	> Duncan Mills
	> UMTS Standards
	> Technology Team
	> Core Network Development
	> Vodafone Ltd (Networks)
	> 
	> Tel:	+44 1635 676074
	> Fax:	+44 1635 234445
	> mailto:[email-masked]
	> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Garland Sharratt" <[email-masked]>
Date: Tue, 12 Feb 2002 12:17:03 -0800

Good points.  Two thoughts:

1. My statement was based on the these assumptions: (a) there is a media
resource function (MRF) component in the media path, doing the DTMF
detection either from audio or from 2833, and under the control of the
application running in a feature server or app server; and (b) events get
reported from the MRF to the application using either MGCP events or SIP
NOTIFY.

(Physically the MRF is either a media server or built into a media gateway.
If in a media gateway, digits need to be conveyed somehow, in the signaling
path, from the media gateway controller to the application.)

(In the calling card example, during the talking state, the MRF is only
listening for "***" or a long "#".  In the initial, IVR stage the MRF is
playing announcements and collecting digits.)

2. I definitely support the use of SIP SUBSCRIBE/NOTIFY for enabling digit
detection and reporting digits from an MRF (or app server component) to an
application.  I have been trying to drive, through the ISC, the use of SIP
SUBSCRIBE/NOTIFY as a SIP framework for implementing the functionality of
MGCP signals and events, especially for use with MRF to application
interaction.

Garland

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Fairlie-Cuninghame, Robert
Sent: Tuesday, February 12, 2002 07:06
To: 'Garland Sharratt'; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] RE: SIP INFO method for DTMF

Garland,

Regards,

Robert.