Subject: PINT and generic Profiles/Extensions to SDP and SIP

From: "Scott Petrack"<[email-masked]>
Date: Sun, 22 Mar 1998 01:46:41 +0200

This letter requests some small tweaks to SIP and SDP in order to enable
SIP/SDP to do the basic PINT services.  There are a few general questions
about SIP and SDP extensions/profiles (not just the PINT ones). My claim is
that with a very small and natural set of extensions to SDP and SIP, all
the PINT basics are covered.

Yes I know that this should be a draft. I want to get it out as soon as I
have something.

1. A few extensions and tweaks to SDP.

a. We need to define the address types possible when the network type in
the c= field is "PSTN".
     Henning in his sip-pint draft used "PSTN" as a network type.  (Is this
PSTN network type in the latest SDP spec?) Suggestions might be E.163 and
E.164.

b. Two of the important PINT services are "fax a Web Page" and "read out
some Web Page over the phone". This requires profiles/extensions to SDP in
order to specify the descriptions of these two kinds of "multimedia
sessions". Here is my solution:

In case the connection data says that the receiver is on the PSTN, as in:
     c= PSTN    E.164   0097299562867

then use a media announcement ("m=  " field) with media type equals "data"
or "text"  to mean that the data or text is to faxed or read out to the
indicated number.  (This seems natural in that the m= field indicates media
to be sent).  The <transport> could be used to indicate if "voice
transport" or "fax transport" is to be used. (The <port> tag doesn't make
any sense for media received on a PSTN device - I set to 0 not to break
existing parsers). This would make tags like:
     m= text       0  voice                     (read out some text over
the phone)
     m= data    0  voice          (read out some data over the phone)
     m= text      0  fax                               (fax out some text
over the phone)
     m= data    0 fax                            (fax out some data over
the phone)

I propose using an "a=uri:" attribute to give the URI of the text or data
to be sent. Here are two examples of parts of session descriptions which
might appear in a request from a PINT client:

c= PSTN    E.164   0097299562867
m= text  0  voice
a=uri:http://www.weather.org/LAX/290398

This describes a session where a server calls a phone number and reads out,
say, a weather report via text-to-speech.

c= PSTN    E.164   0097299562867
m= data  0  fax
a=uri:http://www.vocaltec.com

This describes a session where a server sends a fax of the VocalTec home
page to some number.
(BTW, maybe separate "text" and "data" tags are not needed,  but they are
already in SIP, and can help the server. Also, I played with some extra
media-format tags for fax transport to list the client fax machine's
capabilities, but left it out for simplicity).

d. If these extensions do indeed become "PINT extensions" rather than part
of SDP, then there is a need to signal within the SDP packet that the PINT
extensions are being used. We could define a "PINT" attribute and say that
if

a=org.ietf.pint01

is present, this means that the session description uses the pint01
extensions. Is this a bad use of the a= field?  Is IANA charged with
registration of attribute tags, so that the PINT WG can "own" this tag?

Are these reasonable? Do they belong more as final tweaks to SDP, or as
PINT extensions?

2. SIP:

A new 1xx message is needed saying that "OK so far". This is an
informational message, not final status, different from  "Trying" ,
"Ringing" or  "queued". The particular PINT need is for the case when an
INVITE is sent to have a remote server fax something to a PSTN fax machine.
The client may want to get a response back saying "the server fax machine
has connected to your fax machine and trasmission is proceeding".   Note
that when SIP hands off to someother protocol like RTSP you don't need
this, but within PINT SIP is used to initiate a service like "faxback", and
it is just not enough that the fax machines connect. The SIP request cannot
send a final OK back until the fax has been sent successfully.

I think that with these tweaks I believe all of PINT's "basic test
services" can be enabled by SIP and SDP.  (For the benefit of non PINT
people, the basic test services are: "request to call", "request to fax a
URL",  "request to read out a URL".)

Scott Petrack
VocalTec Communications Ltd.
[email-masked]

Visit us at CeBIT 98'
Hannover Messe
March 19 - 25, 1998

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 21 Mar 1998 20:25:03 -0500

> PSTN network type in the latest SDP spec?) Suggestions might be E.163

Political correctness would suggest that I revise that to GSTN. The
network type is one of the token types that can be registered with IANA,
without extending the base spec. The format of the GSTN address should
probably follow some of the recent work on basic addresses for email
(see Fax WG) or URLs.

> extensions are being used. We could define a "PINT" attribute and say

Not sure that is needed, as the combined presence of these media types
and GSTN addresses should avoid any ambiguity.

> has connected to your fax machine and trasmission is proceeding".

No objection. While "Trying" seems generic enough, there is no harm
adding another, more specific code. Another alternative is to leave the
"Trying" code, but add a more specific messages, as in

180 Trying
180 Sent 1 of 3 pages
180 Sent 2 of 3 pages
180 Sent 3 of 3 pages
200 OK