Subject: [Sip] Loose Routing draft

From: Robert Sparks <[email-masked]>
Date: Thu, 10 Jan 2002 23:45:31 -0500

I just submitted a draft refining the post I sent
out after IETF52 on the loose routing proposal.

Until it appears in the archive, you can find it at
http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt
or
http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html

RjS

_______________________________________________
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: [email-masked]
Date: Fri, 11 Jan 2002 15:54:00 +0200

Hi Robert et al.!

Intersting I/D! It looks like, that we have a solution
for the problem.

I have a couple of questions/comments:

I assume this new procedure can be applied for initial and
subsequent requests. Is this assumention correct?

Is there a requirement, that loose routing is needed in
subsequent requests?

What would be the impact, if we allow a local policy
(as described in your I/D) for the INITIAL request ONLY,
and leave subsequent requests as before (i.e. strict
source routing).
Or in other words: Apply this local policy for
pre-loaded route headers only.

Therefore we could introduce a new Route parameter, which 
informs about, that the Routing can be loose, or has 
to be strict.

 e.g. Route: [email-masked]; routing=loose
 (or similar)

New proxy implementations would route strict, if no
such paramenter present and apply the local policy
only of this parameter present.
Older proxy implementations would simply ignore this
new parameter.

I see the following advantages of my proposal:

- Changes to existing SIP are fewer
  (only the new case of pre-loaded route headers
  in initial request would be affected)
  - more backwards compatibility
  - Less new error cases (can apear only during session
    first INVITE)

- Pre-loaded Route headers can be defined as
  "loose" or as "strict"

I am looking forward for comments on this proposal!

cheers, 
 Bernie

>-----Original Message-----
>From: ext Robert Sparks [mailto:[email-masked]]
>Sent: 11. January 2002 6:46
>To: [email-masked]
>Subject: [Sip] Loose Routing draft
>
>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 16 Jan 2002 17:52:09 -0500

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2002 4:15 PM
> To: Robert Sparks
> Cc: [email-masked]'; [email-masked]
> Subject: Re: [Sip] Loose Routing draft
> 
> 
> 
> Hi,
> 
> >There are people that want to be able to do this.
> 
> I guess it shall be mentioned that it MUST be used for CANCEL (to the
> INVITE request).

We don't have anything new to deal with wrt CANCEL. The restrictions already
in bis05 on how UACs form CANCELs and how proxies and UASs deal with them
takes care of it. There will be no way for a proxy to choose to loose-route
a CANCEL differently than it routed the associated request.

> 
> Does anything need to be said about ACK, or can it be treated like any
> "subsequent request"?

I sketched through both 200-ACK and non-200-ACK, including non-200-ACK
through stateless proxies, and found no special cases. If you've found one
please let me know.

> Regards,
> Christer Holmberg
> Ericsson Finland

Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip

---

From: [email-masked]
Date: Tue, 22 Jan 2002 18:18:11 +0200

Hi Sean!

>From: ext Sean Olson [mailto:[email-masked]]
>Sent: 22. January 2002 17:29
>To: Honeisen Bernhard (NET/Helsinki); [email-masked]
>Cc: [email-masked]
>Subject: RE: [Sip] Loose Routing draft
>
>
>
>> How can a proxy make the difference between an
>> initial INVITE
>> and a re-INVITE? 
>> I have a feeling, that checking the To tag is not
>> the best solution.
>> Neither it is a good solution, if proxies need to
>> keep session state.
>> What other possibilities are there?
>
>The solution you choose will be based on why
>you care that this is a re-INVITE. I think that
>in almost all cases, if you really care, you
>will maintain session state.

What about cases, where:
- a proxy is dedicated to insert pre-loaded Route headers, and
- only in initial request, and
- doesn't want to keep session state
Or is such a case unrealistic?
I guess, we could find more examples, where we need this.

>> I would go one step further, and at least discourage
>> people from
>> loose-routing _subsequent_ requests (e.g.
>> re-INVIVEs).
>
>I see no reason to do this. Loose routing is all
>about local policy. As long as the strict
>route is honored, it shouldn't matter what happens
>in subsequent requests.

Especially in cases, where you some element keeps
session state it should get also e.g. the BYE
concerning this session, in order to release the
resources. If a proxy before is allowed to just
modify the Request-URI (which has been recorded
earlier in Record-Route), it cannot be totally
sure anymore.
This is way, we cannot claim the loose-routing
to be 100% backwards compatible, if such things are
possible.

I have the feeling, that we have to: 

 1) be able to distinguish whether a Route
    header has been preloaded or not
    e.g. we could introduce a new Route parameter,
    informing about "preloaded"
    
 2) maybe even restrict the loose-routing in
    preloaded case so much, that we can ensure that 
    every request passes the proxies, which
    had record-routed.

If we make the difference between pre-loaded and
not pre-loaded (instead of between first and
sub-sequest requests), we still can have a (limited)
loose routing possibility in subsequent requests.

cheers
 Bernie

---

From: Robert Sparks <[email-masked]>
Date: Thu, 24 Jan 2002 16:07:21 -0500

Resend - it looks like mail issues ate my first attempt.
Apologies if this appears twice.

-----Original Message-----

> to be 100% backwards compatible, if such things are

The restrictions on the loose route policies are 
intended to make sure that any resource listed on a
route set gets visited - it does not give a proxy
license to say the request doesn't really need to
visit the rest of the Route stack. It does allow
other things to be visited along the way.

That said, here's an example of the kind of thing
that's concerning you (let me know if I misunderstood
where you were going). Consider this BYE
with a Route header established by Record-Route
in a previous INVITE:

(sent to p1)
BYE sip:res@p1
Route <sip:res@p2>,<sip:res@B>

Assume p1 has a policy of popping the topmost
route header into the reqeust-URI, but then sending
the request off to some third place, 

(sent to p3)
BYE sip:res@p2
Route <sip:res@B>

Now if p3 has a policy to just rewrite the request-URI
and sent things along to whatever was indicated in the 
topmost route, it might emit

(sent to B)
BYE sip:newres@elsewhere
Route <sip:res@B>

p2 never sees the request - this is bad.

It turns out that nothing is special about this
being a subsequent request - you can construct the
same failure for initial requests.

I can propose a restriction that plugs this hole, but
that falls into treating a symptom instead of
treating the problem. What the looseroute text needs to
reflect is that a hop only exercises a non-strict-route
policy when it knows what policy of the next hop is.
If it doesn't have that knowledge, an element needs to
strict route. So, p1 above would not send a request 
formatted as it is to a p3 that it didn't expect to send 
the request to what the Request-URI explicitly identified.  

So, how would p1 know to expect that? How does p1 know
about such a p3 in the first place? Some administrative
policy gave p1 the information about the existance of p3
- through protocol or configuration. The thing providing
that configuration must have some knowledge of what p3
is expected to do. 

RjS

>     informing about "preloaded"
Wouldn't help (as above)
>     every request passes the proxies, which

This is the real goal, whether the request is initial
or within the route-set of an established dialog.

---

From: [email-masked]
Date: Tue, 29 Jan 2002 18:38:11 +0200

Hi Robert!

Comments inline.

cheers,
 Bernie

>Sent: 24. January 2002 23:07
>To: [email-masked]'
>Subject: FW: [Sip] Loose Routing draft
>
>

That's right, but in initial requests this is not so important.

- Session stateful proxies might hold resources, which are
  not released timely, if we cannot garantee, that the BYE
  is coming

- The system Record-Routing system is not anymore
  backwards-compatible, we cannot guarantee anymore
  the the subsequent requests are routed through this
  element as forseen by RFC2543 and bis'.