Subject: [Sip] draft-ietf-sip-sips-04: 403 instead of last hop exception

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 5 Jun 2007 01:20:16 +0200

In section 4.2 
http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-04.txt proposes that 
a proxy should send 403 rather than apply the last hop exception.

Instead, I would propose that it would send a 302 with either the registered 
Contact or the received request URI with a "sip:" scheme. 403 would be 
confusing, because the caller cannot distinguish between this case and the 
callee refusing his call. Perhaps a new response code (4xx Unsecure 
transport not allowed) would be better.

Perhaps a caller preference should be defined to request such behavior, 
similar to "fork" and "no-fork" (RFC3841). Say "no-sips-sip"

Regards,
Jeroen 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 4 Jun 2007 18:40:40 -0500

Actually, 416 would achieve what you want.
302 would not be backward compatible because some proxy somewhere could
recurse on it, resulting in a downgrade.

If people prefer a 416, I can put that. 

I do personaly prefer the 403, because I'd like to avoid any thing that
would cause a proxy to "automatically" recurse, thereby resulting
in a downgrade.

________________________________

	From: Jeroen van Bemmel [mailto:[email-masked]] 
	Sent: Monday, June 04, 2007 16:20
	To: [email-masked]
	Cc: Audet, Francois (SC100:3055)
	Subject: draft-ietf-sip-sips-04: 403 instead of last hop
exception

	In section 4.2
http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-04.txt proposes
that a proxy should send 403 rather than apply the last hop exception.
	 
	Instead, I would propose that it would send a 302 with either
the registered Contact or the received request URI with a "sip:" scheme.
403 would be confusing, because the caller cannot distinguish between
this case and the callee refusing his call. Perhaps a new response code
(4xx Unsecure transport not allowed) would be better.
	 
	Perhaps a caller preference should be defined to request such
behavior, similar to "fork" and "no-fork" (RFC3841). Say "no-sips-sip"
	 
	Regards,
	Jeroen

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 5 Jun 2007 22:55:16 +0200

Francois,

Refer to RFC3261 16.5: if a proxy is not responsible for the request URI it 
MUST NOT recurse on 302

416 does not have the right semantics (since the endpoint may in fact 
support sips, proxies currently should never generate this response) and 
RFC3261 section 16.7 step 4 says that a proxy responsible for the URI should 
recurse on it (should only happen in call forwarding scenarios, but still)

Lots of other error responses would prevent automatic recursion, but that 
does not make them any more suitable than 403 (which is not suitable either, 
IMHO)

If you really want to be on the safe side, a new 4xx response code would be 
best

Regards,
Jeroen

Francois Audet wrote:
> 302 would not be backward compatible because some proxy somewhere
> could recurse on it, resulting in a downgrade.
>
> I do personaly prefer the 403, because I'd like to avoid any thing
> that would cause a proxy to "automatically" recurse, thereby resulting
> in a downgrade.
>
> http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-04.txt
> proposes that a proxy should send 403 rather than apply the last hop
> exception.
>
> the registered Contact or the received request URI with a "sip:"
> scheme. 403 would be confusing, because the caller cannot distinguish
> between this case and the callee refusing his call. Perhaps a new
> response code (4xx Unsecure transport not allowed) would be better.
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 5 Jun 2007 18:54:03 -0500

What we really need is a 302 that prohibits proxy recursion.

That's out-of-scope of this draft IMHO. 

> -----Original Message-----
> Sent: Tuesday, June 05, 2007 13:55
> To: Audet, Francois (SC100:3055); [email-masked]
> Subject: [Sip] Re: draft-ietf-sip-sips-04: 403 instead of 
> last hop exception
> 
> Francois,
> 
> Refer to RFC3261 16.5: if a proxy is not responsible for the 
> request URI it MUST NOT recurse on 302
> 
> 416 does not have the right semantics (since the endpoint may 
> in fact support sips, proxies currently should never generate 
> this response) and
> RFC3261 section 16.7 step 4 says that a proxy responsible for 
> the URI should recurse on it (should only happen in call 
> forwarding scenarios, but still)
> 
> Lots of other error responses would prevent automatic 
> recursion, but that does not make them any more suitable than 
> 403 (which is not suitable either,
> IMHO)
> 
> If you really want to be on the safe side, a new 4xx response 
> code would be best
> 
> Regards,
> Jeroen
> 
> Francois Audet wrote:
> > Subject: draft-ietf-sip-sips-04: 403 instead of last hop exception
> >
> >
> > In section 4.2

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Jun 2007 15:21:33 -0400

Jeroen van Bemmel wrote:

> Francois,
> 
> Refer to RFC3261 16.5: if a proxy is not responsible for the request URI 
> it MUST NOT recurse on 302

It most certainly does not say that.

Perhaps you are referring to this text:

  A proxy MUST NOT add additional targets to the target set if the
    Request-URI of the original request does not indicate a resource this
    proxy is responsible for.

This is referring to the R-URI in the original INVITE, not the one in 
the contact in the 3xx.

> support sips, proxies currently should never generate this response)

WHy is that? Section 21.4.14 says nothing about UA vs. proxies. It talks 
about servers. I think 416 is not far off.

However to be honest we need to explicitly indicate that the problem was 
sips-to-sip so that the original UA can decide whether to retry. Thus 
I'd suggest a new 4xx code.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 7 Jun 2007 16:14:14 -0500

> However to be honest we need to explicitly indicate that the 
> problem was sips-to-sip so that the original UA can decide 
> whether to retry. Thus I'd suggest a new 4xx code.

I'm fine with this.

Let me propose 418 (SIPS Not Allowed)

With the following description:

	The server cannot process the request because the SIPS scheme is
not 
	allowed. The UAC SHOULD retry the request, this time, using a
SIP URI.
	This response differs from 416 in that the server recognizes the
SIPS
	URI, but it is not allowed (e.g., because the UAS registered
with
	a SIP Contact header field).

(And the current text on proxies not recursing on this will apply)

(Note: existing implementations will treat it as 400, which is intended 
behavior, i.e., it will not automatically re-attempt anything).

If you support this, or are against this, please voice your opinion. If
you don't 
care that much, just don't say anything :^)

Now, the next logical quesiton is for sip-to-sips.

Currently, the text has this text about proxies that may decide to use
either 403 or 3XX to redirect to a SIPS URI. We have a similar problem
here
that some proxy in the middle may decide to recurse on it (which would
break
the last hop upgrade prohibition).

Do we need a 419 (SIPS Required) as well? Or are we happy with the
current text?

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 7 Jun 2007 23:28:00 +0200

Jonathan,

Yes, that is the text I was refering to. As a consequence of that a proxy 
MUST NOT recurse on 302 if not responsible for the request URI (but this 
text is not literally in RFC3261). Still, a 302 sent by the callee's proxy 
could result in recursion in case of call forwarding scenarios, so 
conclusion remains that a new 4xx is better

Regards,
Jeroen

Jonathan Rosenberg wrote:
> Jeroen van Bemmel wrote:
>
>> Francois,
>>
>> Refer to RFC3261 16.5: if a proxy is not responsible for the request
>> URI it MUST NOT recurse on 302
>
>    Request-URI of the original request does not indicate a resource
>    this proxy is responsible for.
>
> WHy is that? Section 21.4.14 says nothing about UA vs. proxies. It
> talks about servers. I think 416 is not far off.
>
> However to be honest we need to explicitly indicate that the problem
> was sips-to-sip so that the original UA can decide whether to retry.
> Thus I'd suggest a new 4xx code.
>
> -Jonathan R.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 12 Jun 2007 19:27:08 -0500

I didn't get any feedback from the list on this topic that I'm trying
to close.

Comments? 

> From: Audet, Francois (SC100:3055) 
> Sent: Thursday, June 07, 2007 14:14
> To: Jonathan Rosenberg; Jeroen van Bemmel
> Cc: [email-masked]
> Subject: RE: [Sip] Re: draft-ietf-sip-sips-04: 403 instead of 
> last hop exception
> 
>  
> 
> 	The server cannot process the request because the SIPS 
> scheme is not 
> 	allowed. The UAC SHOULD retry the request, this time, 
> using a SIP URI.
> 	This response differs from 416 in that the server 
> recognizes the SIPS
> 	URI, but it is not allowed (e.g., because the UAS 
> registered with
> (Note: existing implementations will treat it as 400, which 
> is intended behavior, i.e., it will not automatically 
> re-attempt anything).
> 
> If you support this, or are against this, please voice your 
> opinion. If you don't care that much, just don't say anything :^)
> 
> Currently, the text has this text about proxies that may 
> decide to use either 403 or 3XX to redirect to a SIPS URI. We 
> have a similar problem here that some proxy in the middle may 
> decide to recurse on it (which would break the last hop 
> upgrade prohibition).
> 
> Do we need a 419 (SIPS Required) as well? Or are we happy 
> with the current text?
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 15 Jun 2007 22:35:07 -0500

I'm having some second toughts on the idea of defining new error
responses for "SIPS Not Allowed" and "SIPS Not Supported" instead of
3XX.

The rationale was the semantic was somewhat different, and that 
it would avoid the problems of proxies that "automatically recurse on
3XX".

However, now I'm thinking that 4XX may actually introduce a bigger
problem.

Because of HERFP, the new 4XX response codes are likely to be swalloed
by
proxies that do not support this specification. Which means the request
will not be resent, causing a "hard failure" if no other branch
responds.

Using a 3XX on the other hand has a much greater chance of working
through
HERF since they tend to be forwarded. (Of course, they may suffer from
the
problem caused by proxies that are too keen on recursing).

Comments?