Subject: RE: [Sip] Attention - comment on Loose Routing draft

From: [email-masked]
Date: Fri, 18 Jan 2002 08:20:29 -0700

The UAC considers it a re-Invite even when a proxy later re-writes the
r-uri (a common action).  I'm not clear where you are headed with this line
of thought wrt Robert's draft.

John Hearty
Level3

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Friday, January 18, 2002 7:06 AM
To: Hearty, John
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sip] Attention - comment on Loose Routing draft

Changing the request-URI in a reinvite makes it not a reinvite, right?

--
Dean

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, January 17, 2002 9:22 AM
Subject: RE: [Sip] Attention - comment on Loose Routing draft

>
>  I would have to disagree with you too.  This sounds like trouble brewing,
> especially in transactions subsequent to the first.  Take for example a
> firewall control proxy downstream from X.  An initial Invite sets up
> firewall resources.  If a re-Invite comes through and X decides service
> route points downstream from X don't matter anymore, you just stranded
> firewall resources.
>
> John Hearty
> Level3
>
> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 3:55 AM
> To: Honeisen Bernhard (NET/Helsinki); [email-masked]
> Cc: 'ext Robert Sparks'
> Subject: Re: [Sip] Attention - comment on Loose Routing draft
>
>
> Hmm, RjS may disagree, but I think that the retargeting of the message at
X
> might override the service routing in the original request. Changing the
> request URI means to me "don't send it to where it was being sent, send it
> to this other place instead". Given this logic, service route points
> downstream from X probably don't matter anymore.
>
> --
> Dean
>
> ----- Original Message -----
> From: "Honeisen Bernhard (NET/Helsinki)" <[email-masked]>
> To: <[email-masked]>
> Cc: "'ext Robert Sparks'" <[email-masked]>
> Sent: Tuesday, January 15, 2002 9:05 AM
> Subject: RE: [Sip] Attention - comment on Loose Routing draft
>
>
> > Hi RjS!
> >
> > Some question:
> >
> > Consider a situation, where a request is directed
> > to (B) and two service elements (X) and (Y) have
> > to be visited before.
> > (X) performs a service, which replaces the intended
> > destination URL, i.e. (B), whereas (Y) executes
> > some feature, which depends on the output of (X).
> >
> > When the request arrives at (X), the R-URI / Route
> > could look like:
> > - R-URI: <X>
> > - Route: <Y>,<B>
> > (The intended destination has been appended earlier
> > to Route as per section 5.2 in your I/D)
> >
> > How can (X) now apply the destination URL relacing feature?
> > My first guess was, that (X) would modify the last entry
> > in the Route, i.e. (B).
> >
> > Your first proposal in section 2 prohibits such behavior:
> > "[...] an element [...] MUST NOT modify or remove
> > subsequent Route header field values."
> >
> > Is this restriction intended also for such cases or could
> > we relax it to allow modifying of the last entry in Route?
> > Would marking the last Route entry as the intended
> > destination (and allow modifying of such only) solve
> > this issue?
> >
> > Greetings,
> >  Bernie
> >
> >
> > PS: Some Typos:
> >
> > - section 5.5, F7-F12:
> >   s/Contact: sip:[email-masked]/Contact: sip:[email-masked]/
> >
> > - section 5.5. F3/F4:
> >   - Shouldn't maddr in F4 contain a different IP-address
> >     than in F3?
> >   - Maybe add a FQDN <-> IP mapping table to ease
> >     the understanding of the examples.
> >
> > - section 5.8:
> >   s/senting/sending/
> >
> >
> >
> > >-----Original Message-----
> > >From: ext Robert Sparks [mailto:[email-masked]]
> > >Sent: 14. January 2002 20:58
> > >To: [email-masked]'
> > >Subject: [Sip] Attention - comment on Loose Routing draft
> > >
> > >
> > >The draft below contains the resolution to a large
> > >set of open issues around processing of the Route header,
> > >preloaded routes, and the use of default outbound proxies.
> > >The plan is to modify bis to reflect these proposals.
> > >
> > >Please review it as soon as you can and comment if you
> > >see real problems. Silence will be taken as consent.
> > >
> > >RjS
> > >
> > >> -----Original Message-----
> > >> From: Robert Sparks [mailto:[email-masked]]
> > >> Sent: Thursday, January 10, 2002 10:46 PM
> > >> To: [email-masked]'
> > >> Subject: [Sip] Loose Routing draft
> > >>
> > >>
> > >> 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
> > >>
> > >
> > >_______________________________________________
> > >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
> > >
> >
> > _______________________________________________
> > 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
> >
> >
>
>
> _______________________________________________
> 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
>
>

_______________________________________________
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: "Dean Willis" <[email-masked]>
Date: Sun, 20 Jan 2002 12:01:33 -0600

I'll give an example that describes the problem I think you're seeing -- I'm
probably understanding you wrong, so flame on . . .

Ok, let's say we have established a dialog routed UA1, P1, P2, UA2. P2 has
resources tied up.

After some time, P1 decides to "retarget" the dialog by altering the
destination of a reINVITE issued by P1. P1 rewrites the request-URI and/or
routes such that the reinvite traverses P3 and arrives at UA3.

Yes, this is bad, as it leaves P2 holding resources. But it's bogus more
ways than that . . .

But what if P1 has knowledge that P2 has failed, and it re-routes thru P3
in order to get to UA2, the original target?

--
Dean