Subject: Re: SIP/PSTN interworking draft

From: Sean Olson <[email-masked]>
Date: Thu, 22 Jul 1999 14:44:13 -0500 (CDT)

> 
> 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. 
> 

This is an interesting approach to providing calling card services, but 
I don't see a need to standardize this. In fact, I see a great deal of 
value in different service providers doing this in different ways.

> 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. 
> 

Certainly, but then again, I wouldn't propose sending all of those digits
in one continuous stream. 

> 
> 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? 
>

I think this is a reasonable approach. To address the calling card problem,
I would recommend sending a multipart/parallel body where each section could
contain AVT encoded DTMF, appropriate strings, or base64/encrypted data for
"carriers name, the owner's name, the calling card number, perhaps a few bytes 
of special restrictions". Again though, I don't see that this needs to be
standardized. I think the important primitive here for building services is 
standardized way of relaying DTMF information along the signalling path.

-----------------------------------------------------------------
Sean Olson            E-mail: [email-masked]
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Jul 1999 11:31:51 -0500

Scott said:
> . . .

> standardized way of relaying DTMF information along the signalling path.

I think you guys are missing the "interworking" part of the problem. Let's
get back to the (I think Steve's) example of a calling-card service.

We start with a phone -- you know, black plastic thing, ten key interface?
Simple analog electronics?

In the calling card scenario, the phone's user places a PSTN call to a
calling card platform -- which is front-ended by a PSTN to SIP gateway, then
on to a calling card platform which is also a UAC/UAS.

user--->phone--->gateway--->card-platform

In the normal mode of utilization, the card platform plays a greeting which
prompts the user to enter an authentication PIN. The user keys in a PIN,
which is turned into DTMF by the circuitry in the phone. The DTMF digits
propagate over the PSTN to the gateway.

This is where it gets interesting. We have several scenarios:

1) Today's model: the gateway samples the DTMF, encodes it (G.711, etc), and
ships it downstream just like it would do voice. The card-platform then
applies DSP resources to detect and decode the DTMF digits.

2) The In-band model: The gateway detects and decodes the DTMF and inserts
it into an RTP(DTMF) stream headed for the card-platform. The card-platform
no longer needs dedicated DSP resources.

3) The out-of-band model: The gateway detects and decodes the DTMF and sends
appropriate INFO or NOTIFY or whatever SIP messages to the card-platform.
The card-platform no longer needs dedicated DSP resources.

Note that the gateway is effectively the user's UAC -- it is NOT AWARE that
it is being used to support a credit-card transaction, and could be standard
off-the-shelf hardware. Since it by definition has DSP resources which are
quite likely to be applied to any call, it is most efficient to have the
DTMF detection and decoding (an recoding to a character format) occur in the
gateway. Remember, from a carrier perspective, gateway ports are a
cost-dominating factor -- we want gateways to be very simple and very
generic, but useful for all different sorts of applications.

There's a separate discussion to be had about the applicability differences
between in-band and out-of-band.

--
Dean Willis