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

From: [email-masked]
Date: Mon, 11 Feb 2002 17:15:20 -0000

Hi All,

Thanks for your rapid responses.  The interested parties in this DTMF
discussion in 3GPP have already considered the SUBSCRIBE/NOTIFY solution and
rejected it as unsuitable.

Firstly, it appeared to us that for every mobile originated voice call, the
network would have to SUBSCRIBE to the UA making the call, on the off-chance
that at some point during the call the user wishes to send DTMF in NOTIFY
messages.  This was seen as unacceptable.

Any views?

Regards,

Duncan

-----Original Message-----
From: Bert Culpepper [mailto:[email-masked]]
Sent: 11 February 2002 15:30
To: 'Alan Johnston'; 'Tom-PT Taylor'; [email-masked];
[email-masked]
Subject: RE: [Sipping] RE: SIP INFO method for DTMF

I agree with the comments below when it's desired to transmit actual tone
data in an IP network.  If on the other hand, it's desired to have "user
indications" transmitted to points in the SIP network in addition to the
endpoints involved in the multi-media session, I believe a suitable approach
is one myself and a couple of others have proposed.  See
http://search.ietf.org/internet-drafts/draft-culpepper-sip-key-events-00.txt
. This is an initial draft and if thought worthwhile by the community, will
be revised as necessary.

Best regards,
Bert

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Alan Johnston
> Sent: Monday, February 11, 2002 9:39 AM
> To: 'Tom-PT Taylor'; [email-masked]; [email-masked]
> Subject: RE: [Sipping] RE: SIP INFO method for DTMF
>
>
> If you must send DTMF over SIP, then the NOTIFY method is preferred.
> See:
>
> http://search.ietf.org/internet-drafts/draft-mahy-sipping-sign
> aled-digit
> s-00.txt
>
> Thanks,
> Alan Johnston
> WorldCom
> sip:[email-masked]
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > On Behalf Of Tom-PT Taylor
> > Sent: Monday, February 11, 2002 6:52 AM
> > To: [email-masked]'; [email-masked]
> > Subject: [Sipping] RE: SIP INFO method for DTMF
> >
> >
> > The key point to bear in mind is that your architecture has
> > to make sure someone can't bring down network equipment
> > simply by pressing their keypad repeatedly.  The INFO method
> > may produce unacceptably high volumes of messaging on the
> > signalling path unless filtering is applied at the point of ingress.
> >
> > >  -----Original Message-----
> > > From: 	[email-masked]
> > > [mailto:[email-masked]]
> > > Sent:	Monday, February 11, 2002 10:55 AM
> > > 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
> >
>
>
> _______________________________________________
> 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

_______________________________________________
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

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Feb 2002 13:34:37 -0500

> messages.  This was seen as unacceptable.

Yes, of course. SUB/NOT alone is an awful solution, even worse than INFO
alone. The proposal is that its rfc2833 for normal e2e usage, and then
allow applications to SUBSCRIBE as needed. I have posted more details on
that in a follow up note.

THanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Bert Culpepper" <[email-masked]>
Date: Mon, 11 Feb 2002 15:24:47 -0500

> messages.  This was seen as unacceptable.

Well, if one was to presume subscription state for DTMF was established in a
device using a non-SUBSCRIBE mechanism, sending DTMF in NOTIFYs would be
equivalent to using INFO in many respects.  However, this suffers from the
issues Jonathan pointed out.  Also, as Jonathan says actual DTMF needs to be
transmitted end-to-end, with latency, etc. issues mitigated.  For this
there's rfc2833.

Anyway...it seems you have something else in mind other than simply
transporting DTMF, that you think the DTMF in INFO approach would work for.
If so, I'd like to hear what that might be, as I'm interested in a standard
solution for my problem set.

Now given what's written above concerning 3GPP, is it not possible to create
subscriptions (through some means) during the registration process?  In that
way, SUBSCRIBEs don't have to be sent to each UA at each call
origination/termination.  Subsequent NOTIFYs could use the Path mechanism to
traverse only those proxies that were required.  Just some thoughts here...

Regards,
Bert