Subject: RE: [Sip] Changes in bis-05

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 26 Oct 2001 11:54:42 -0400

> -----Original Message-----
> From: James Undery [mailto:[email-masked]]
> Sent: Friday, October 26, 2001 6:11 AM
> To: SIP
> Subject: [Sip] Changes in bis-05
> 
> 
> Hi,
> 
> Whilst welcoming the intent of the re-write, there are some obvious
> (first read) changes I'd disagree with (and a lot I like).
> 
> e.g.
> Section 16.5, step 2 Updating the Request-URI, replacing it is a MUST
> !! this is a totally unnecessary and contradictory to all the loose
> routing discussions at the last IETF.
> 

Well, its not different from how its always been. This text is not a
statement of a decision, just a no-change from previous versions. I believe
this issue to be the largest open issue at the moment in the spec, and I
believe its even called out in bis-05.

> In light of the massive changes, can I suggest that a more realistic
> timetable for the draft going to the IESG is produced to allow a
> sufficient review.

Dean and Brian need to address that one.

> 
> Also on the minor nit side,
> 
> Section 22, table 2 has Route and Record-Route as optional headers for
> REGISTER, this contradicts section 10.3 where they are forbidden.

OK, thanks.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://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: "James Undery" <[email-masked]>
Date: Mon, 29 Oct 2001 09:01:36 -0000

> From: Jonathan Rosenberg [mailto:[email-masked]]

> believe its even called out in bis-05.

I never realised outbound proxies were illegal :-) Sorry my fault for
being vaugue this section is describing standard proxy behaviour. I
hope rewritting Request-URI was always optional.

James

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 30 Oct 2001 13:09:00 -0600

Much of the bis-05 disucssion has been around handling of record-routes,
outbound proxies, and which nodes update the request-URI for routing
purposes, and when they do so. Occasionally we also speculate on how this
will interact with proposed loose routing.

This is probably one of the most confusing issues in SIP. I've seen many
conflicting approaches, including 3GPP discussions that implement local
routing policy by inserting a new Route (not derived from a Record-Route)
and replacing the request-URI.

This has to stop -- it makes my head hurt.

I'd like to propose that we consider two approaches:

1) ALWAYS replace the request-URI, even for local outbound proxy
applications. We might use the 3GPP approach and put the original
request-URI in a Route header, then put the host of the local outbound proxy
into the request-URI. In essence, this implements a route-stack, with the
request-URI being the top of the stack.

2) NEVER replace the request-URI, as proposed in the loose-routing
discssion. Just pop the route header and send the request to the destination
described by the popped Route. This also provides a route-stack, with the
topmost Route header being the top of the stack, and the request-URI not
being referenced until the route stack is exhausted.

Personally, I'd vote for number 2: I think the only time the request-URI
should change is when the request is being retargetted as a result of
application logic. Think of IP routing -- the destination address of a
packet doesn't change just because the packet was processed by an
intermediary router. Or SMTP routing -- the Rcpt To: email address doesn't
change as the message is propagated from server to server.

Of course, we'd need to consider the backward-compatibility implications. I
haven't thought this all the way through, but I don't think either approach
is trivial to resolve. My hunch is that approach number 1 might be closer to
compatible.

--
Dean