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:
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 PROTECTED]
Sent: Monday, June 04, 2007 16:20
To: [email protected]
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
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
