Subject: SIP spec nit

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 27 Jul 1999 16:17:55 -0500 (CDT)

Section 6.37 of RFC 2543 has the following statement:

"A SIP server returns a 400 (Bad Request) response if it receives a
request with a To header field containing a URI with a scheme it
does not recognize."

Since To and From headers are mainly used for correlation
purposes at either end, this seems to add some potentially
undesirable behavior. Let's say that, for argument's sake,
I use a redirect server that understands a URI scheme of "name:".
(I'm not proposing this as a new URI scheme; I'm just using
it for an example. If it gives you problems, imagine that it's
"tel:" or something). The UAS on the far end, though, doesn't
understand any scheme except for "sip:".

UAC (ragnarok.spleen.mil) -> Redir Server

  INVITE name:adam+roach SIP/2.0
  To: <name:adam+roach>
  From: <sip:[email-masked]>

Redir Server -> UAC (ragnarok.spleen.mil)

  SIP/2.0 302 Temporarily Moved
  Contact: <sip:[email-masked]>

UAC (ragnarok.spleen.mil) -> UAS (ws1208.ericsson.com)

  INVITE sip:[email-masked] SIP/2.0
  To: <name:adam+roach>
  From: <sip:[email-masked]>

It seems to me as if my client should be able to proceed with this 
call quite happily; however, according to the spec, I must reject
it with a 400 unless I understand the "name:" URI scheme.

Am I missing some subtle logic for including this restriction in SIP,
or should it be removed?

-- 
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: [email-masked]
Date: Wed, 28 Jul 1999 18:43:49 +0300

Hi Adam,

> request with a To header field containing a URI with a scheme it

The 'To' header is useful also for knowing who the caller is calling to...(this
sentence sounds stupid, but I'll explain what I mean :o) ).

For example, if I am calling the help_desk of Ericsson, the INVITE request that
the guy working there will receive (after passing thru different servers in the
middle) will look like:

INVITE sip:[email-masked] 
To: sip:[email-masked]
...

So, this guy can filter his calls using the 'To' header. He may not want to
receive calls addressed to the help_desk after 5 p.m., but he still wants to
receive his personal calls, addressed to Bob...
The request-URI will be the same for both types of calls...

But even though this is an interesting feature, it may be part of the
implementation of the UAS, instead of part of the protocol itself. This way,
when a UAS received a request with a request-URI that can be understood, but
with a 'To' field that cannot be parsed, the behaviour would be up to the UAS.

I'll see you later,

Gonzalo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Jul 1999 18:03:39 -0400

> The request-URI will be the same for both types of calls...

This is why the UAS should understand the scheme in the To field. It
can't really successfully filter it if it doesn't understand it. I do
believe this restriction only applies to a UAS; understanding the scheme
for a proxy or redirect is not really important. I think it says this
somewhere in the spec but I'm not certain.

-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: "Adam B. Roach" <[email-masked]>
Date: Wed, 28 Jul 1999 17:37:43 -0500 (CDT)

Gonzalo>> So, this guy can filter his calls using the 'To' header. He may 
Gonzalo>> not want to receive calls addressed to the help_desk after 5 p.m., 
Gonzalo>> but he still wants to receive his personal calls, addressed to 
Gonzalo>> Bob...
Gonzalo>> The request-URI will be the same for both types of calls...

Jonathan> This is why the UAS should understand the scheme in the To field. It
Jonathan> can't really successfully filter it if it doesn't understand it.

I understand, if you're doing filtering, that you may choose to
reject calls which have an unknown scheme in the To: field; however,
saying that this is correct behavior for a client *in* *general* seems
very restrictive. I'll gave a more realistic example than before.

Let's say that we have a SIP network that is being used to transit
PSTN calls. On one end, I have a PSTN gateway which requires an external
redirection server to perform phone number routing. It does so by sending
all dialed requests to this server with a URI with a "tel:" scheme.

In the particular call I'm trying to complete, it ends up proxying
or redirecting the call to a gateway which does not understand the 
"tel:" scheme. No call filtering is being performed.

Ingress Gateway (austin1.bell.com) -> Routing Server

  INVITE tel:+12145551212 SIP/2.0
  To: <tel:+12145551212>
  From: <tel:+15125551234>
  Contact: <sip:[email-masked]>

Routing Server -> Egress Gateway (dallas4.bell.com)

  INVITE sip:[email-masked] SIP/2.0
  To: <tel:+12145551212>
  From: <tel:+15125551234>
  Contact: <sip:[email-masked]>

Should this call, under these *particular* circumstances, be rejected
by the egress gateway?  If so, what has been gained?

---

From: [email-masked]
Date: Thu, 29 Jul 1999 03:21:37 +0300

Hi,

> with a 'To' field that cannot be parsed, the behaviour would be up to the UAS.

In certain situations, the UAS may want to accept the call even when it does not
understand the 'To' header.

We could rephrase and say:

> Section 6.37 of RFC 2543:
> 
> "A SIP server MAY return a 400 (Bad Request) response if it receives a

and add that this behaviour is really up to the application (UAS). 

This way, if the application is configured to do so, it will still send back the
400 response... 

How does it sound?

Regards,

Gonzalo (+1 214 850 8618)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Jul 1999 09:13:16 -0400

"Adam B. Roach" wrote:

> by the egress gateway?  If so, what has been gained?

I don't feel that strongly here, but I would argue that in this case
your gateway does know about the tel URL. It simply knows not to reject
calls with a tel URL scheme in the To field. 

-Jonathan R.