Subject: SIP/PSTN interworking draft

From: "Adam B. Roach" <[email-masked]>
Date: Wed, 21 Jul 1999 10:39:10 -0500 (CDT)

My interpretation of the feedback I had at last week's MMUSIC meeting 
on draft-roach-mmusic-sip-pstn-require-header-00.txt is as follows:

1. In-band DTMF transmission should be removed from the draft.

2. Call-control services should be removed from the draft.

3. Out-of-band DTMF transit is controversial.

My purpose in this message is to check if there are any counter-arguments
to the first two points which anyone would like to present, and to
begin a dialogue on the third point. 

To summarize what I beleive the main arguements for and against inclusion
of OOB DTMF:

- Christian Huitema made the point that an interworking draft should
  limit itself to those features absolutely necessary for signalling
  interworking. Since DTMF isn't a necessary part of call setup and
  teardown, it doesn't belong in this draft.

- Steve Donovan contends that, without having a requirement to send
  DTMF information in a format understood by SIP nodes, the most
  basic services (such as calling card services) will be impossible
  to implement. PSTN interworking is of limited value if you can't
  authenticate users.

I'm on the fence, myself. Both seem like valid arguments. I'd appreciate
it if anyone who has a stake in this arena would weigh in on one side
or the other. Thanks.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Scott Petrack <[email-masked]>
Date: Thu, 22 Jul 1999 10:10:36 -0400 (EDT)

It would be a very interesting thing to have a standard 
format for Calling Card Information, so that it could be 
included within, among other things a SIP payload. 
This would include the information on a "usual" calling
card, such as the carriers name, the owner's name, the
calling card number, perhaps a few bytes of special
restrictions. The whole thing would be protected via
either a password (analogous to the PIN) or via 
public-key. 

The point of all that is -- surely the correct format
has nothing to do with OOB dtmf. In fact, dtmf could
not be used, since the only way to tell in a stream
of random dtmf digits which is the calling card number,
which is the pin, etc., is to correlate the digits
with other real-time prompts. ("please enter your pin",
"please enter your calling card number"). Therefore, 
such dtmf information would need to be in band. 

Bottom line -- calling card info, yes. 
DTMF strings within SIP, no.

Final suggestion -- if there really is some 
need to send DTMF within SIP, I humbly suggest
that the dtmf be put into a MIME payload of type:
audio/telephone-events which is being defined
right now in AVT. The encoding of this MIME
type should be exactly -- the RTP dtmf payload
type. Why invent a new encoding? 

Scott