Subject: PINT-Parser, questions & proposuals

From: Bernie Höneisen <[email-masked]>
Date: Tue, 10 Aug 1999 11:40:16 +0300 (EET DST)

Hi,

I've started to work with PINT only a 3 month ago. I am implementing a
prototype of PINT application (currenttly only the IP side). The main
weight is at the moment the parser (and lexer) for SIP and PINT messages.

Out of my work there came the following questions/proposuals:

* About CSeq:
  -----------

In the PINT the CSeq field seems to be not used. But it provides useful
information, what e.g. a response refers to. e.g. "CSeq 2 BYE" indicates,
that the corresponsing response is belonging to a BYE request (following
RFC2543). It would be easier to detect duplicates or wrongly sent packets.

Proposual: Mandatory field CSeq in all PINT requests and responses

* About from / To fields:
  -----------------------

Following RFC2543 to From and To line have to have the following grammar:

 From  =  ( "From" | "f" ) ":" ( name-addr | addr-spec )  *( ";" addr-params )

 To  =  ( "To" | "t" ) ":" ( name-addr | addr-spec )  *( ";" addr-params )

 name-addr   = [ display-name ] "<" addr-spec ">"

 addr-spec   = SIP-URL | URI

 URI         =  SIP-URL

 SIP-URL     = "sip:" [ userinfo "@" ] hostport

This doesn't allow From-lines as "From: [email-masked]" or
"To:0345-123456;user=phone;phone-context=+44" as you use in the examples,
since the string "sip:" is missing.

Question: Is this a bug or delibertly?

* About recognition of PINT requests/responses:
  ---------------------------------------------

The implementation of the PINT protocol would be much easier and programs
more efficient, if it was possible to detect in an easy way, whether the
received packet belongs to PINT or not. Especially if you are running a
normal sip server and a pint server together. Parsers could be written
more specific (recognize more errors, if it was be recognizeable that it
belongs to PINT).
I propose something, which make the pint requests / responses easyly
recognizable. This could be done e.g. in the call-id, so that the call-Id
mandatory contains the string "PINT":
e.g "Call-ID:[email-masked]". 

Question: What is the gerneral opinion among the PINT-reponsable about
this?

* About examples: 
  ---------------

I had some problems to understand the message flow in PINT. I think it is
something like this (a certain case, UA=UserAgent, GW=PINT-Gateway):

UA->GW: INVITE Request
GW->UA: INVITE Response
UA->GW: ACK Request
GW->UA: ACK Response
GW->UA: BYE Request
UA->GW: BYE Response

Questions/Request: Did I understand this correctly? Would it be possible
to put more examples in the next update of the protocol, containing more
about possible message flows?

Looking forward to your answers/comments.

br,
 Bernie Höneisen

---------
This message came from the IETF PINT Working Group Mailing List.

---

From: Scott Petrack <[email-masked]>
Date: Tue, 10 Aug 1999 10:39:41 -0400 (EDT)

See comments below

> * About CSeq:

A PINT exchange is a SIP exchange, and of course CSeq is mandatory in all
SIP messages, in order to match requests and responses. So CSeq is already
mandatory.

> * About from / To fields:

This is a bug -- the To: and From: lines must be a URI of course. In fact,
my guess is that sometimes you'll want to use a sip: URI and sometimes a
tel: URI.

Thanks for noticing.

> * About recognition of PINT requests/responses:
PINT requests *are* SIP requests, there are some extra tokens that are 
recognized by every PINT implementation. A request is a "pint request" if
and only iff it has SDP with a network type of "TN".

At some point we discussed
defining a string to be used in a Require: header to signal to the server
that it must understand PINT requests (org.ietf.pint), but it was decided
that either the parser understands the TN network type and the RFC2543
address type or it doesn't. 

> * About examples: 

The successful response to an INVITE is an OK, and then the UA sends an
ACK back. THere is never a response to an ACK. 

The basic idea is that a PINT exchange *is* a SIP/SDP exchange, so we
wanted to concentrate in the PINT spec on just the new tokens that had to
be defined to signal the new kinds of parameters for the session. So you
really need to understand the SIP spec as is, and this should give 
the complete message flows.

But perhaps one complete flow example would be useful., I agree.

Scott

---------

---

From: Bernie Höneisen <[email-masked]>
Date: Tue, 10 Aug 1999 18:54:17 +0300 (EET DST)

Hi Scott,

Thanks for your answer.

> SIP messages, in order to match requests and responses. So CSeq is already

I was not anymore sure, after considering the Examples in section 4 of
draft-ietf-pint-protocol-01.txt, which omit the CSeq field.

In this case it is a bug in the examples!

> > Following RFC2543
> > ... 

> my guess is that sometimes you'll want to use a sip: URI and sometimes a

What you mean here with "tel: URI" ?

t. Bernie

---------

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 10 Aug 1999 18:01:02 -0400

> What you mean here with "tel: URI" ?

Actually, according to RFC 2396, the whole thing "tel: <SOMETHING>" (rather than
SOMETHING by itself) would be an URI. (And, as such, it should be URL in this
particular case.) The reference here is to telephony URLs, on which Scott, I
believe, has been working. I thought that SIP actually defined them, but
prompted by Bernie's query, I checked RFC 2543 and found that was not the case.
We have been discussing the necessity for defining telephony URLs for a quite a
while (the first proposal I remember came to the PINT BOF).

The thing is that (unless I miss something and the telephony URLs have been
registered) we could not use unregistered URLs even in examples.

Igor

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Aug 1999 22:38:18 -0400

> registered) we could not use unregistered URLs even in examples.

There is a draft which defines the telephony URL:

http://search.ietf.org/internet-drafts/draft-antti-telephony-url-08.txt

We wanted SIP to just reference this for the BNF for
telephone-subscriber, but we could not, since it was a draft, and would
have been a normative reference. So, we were forced to copy the BNF into
RFC2543.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---------

---

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

I forgot that telephony URLs don't exist ;-). I would just use them 
anyway, personally. (This is a very practical advantage of text encoding,
btw ;-)).

There is a dead horse lying around which has written on it something like:

"You can use a 'user=phone' parameter in a sip URL to help the parser know
that the userinfo field in the SIP URL refers to a phone number."

You might think that this solves the problem, but unfortunately not quite,
because a URL like:

sip:+16177387225;user=phone

is not a valid SIP url, because there is no hostport part. (i.e. there
is no "@hostname" part after the +16177387225). Personally, I think that
this is unfortunate. Just like 'josephine' is a perfectly reasonable
email address (it just is not globally routable), I wish that that 
'sip:josephine' were equally legal (although once again it would not be
globally routable. So it is not a "universal" resource locator, but it
would certainly locate the resource within the SIP system of a single
administrative domain). But I digress....

The bottom line is that it makes most sense to use the tel: URL, even
though this doesn't exist;-).

The current PINT draft just leaves off the label, and I guess that this
is illegal -- what should we do?? Here are some alternatives:

1) Just extend the definition of sip: URLs to allow for non-routable
	ones like "sip:josephine" and "sip:5556789". I personally wish
	we could do this, but I imagine that the owners of SIP will block
	this suggestion.

2) Specify that PINT messages which don't have URLs in the right place
	better have instead a telephone number? This sounds awful to me. 

3) Somehow get the telephony URL draft advanced and then use the tel: URL?
	Can someone tell me what is holding this up?

4) Specify a tel: URL within the PINT draft? I would rather not do this.

Something more clever? All suggestions welcome.

Scott

---------

---

From: Bernie Höneisen <[email-masked]>
Date: Fri, 13 Aug 1999 11:33:10 +0300 (EET DST)

On Thu, 12 Aug 1999, Scott Petrack wrote:

> is not a valid SIP url, because there is no hostport part.
> ...

I don't know whether it is really more clever, but what about defining a
reserved word for hostname e.g. 'pint' in PINT-spec for these cases ?

 sip:+16177387225@pint;user=phone

The locater wouldn't be universal, but parseable without errors following
RFC2543 (SIP).

(except if some smart parsers check the top-level domain label--as which
'pint' here would be interpreted by the parser--and disclaim the 'pint' is
not an allocated toplabel or sth like this.)

Comments?

---

For the future I think, we should consider the next version of SIP to
allow these telephony URLs. Then we'd habe a proper solution.
I just don't know when this next version of SIP will be launched...

t. Bernie

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Aug 1999 08:58:17 -0400

> The locater wouldn't be universal, but parseable without errors following

The problem is then, that proxy behavior depends on the semantics of the
value
of the host field of the URI (if its pint, don't look it up in DNS, but
if
its something else, then do so). That can make things very confusing.

> I just don't know when this next version of SIP will be launched...

SIP already allows non-SIP URLs. For example, look at the BNF for
name-addr:

notice how URI is there - which means any URI can be used. I believe
that the
right solution is telephony URL's. SIP can handle them fine as is. In
fact,
I have seen people use SIP with http URL's (in Contact fields of
redirects, for
example) and mailto URL's also. 

-Jonathan R.

---------