Subject: RE: [Sip] gruu and record-route stripping

From: "Gordon Ledgard" <[email-masked]>
Date: Thu, 10 Mar 2005 11:13:15 -0500

I have to wonder: is logically splitting the functionality of the Home
and Edge proxy a common enough scenario that it warrants mucking with RR
just to stop this one-hop loop? Is the transmission/computation time
that critical?
And do you not now add in a whole new computational complexity on the UA
side that defeats the savings?

Gordon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Thursday, March 10, 2005 11:01 AM
To: Jonathan Rosenberg
Cc: IETF SIP List
Subject: Re: [Sip] gruu and record-route stripping

I thought about this more. (How the EP knows it should remove itself 
from the R-R on the response to a dialog establishing request.)

I think this is hard. What does it have to work with to make this 
determination?
- the gruu option in the response
- the value of the contact URI in the response
- the R-URI from the request, or other info from the request
   (could be saved with transaction state if needed to make
   the decision)

Jonathan Rosenberg wrote:
> Paul Kyzivat wrote:

>> I've lost track of the prior discussion. How again does the EP know
it 
>> should remove itself from the R-R in the response? Does it do so
based 
>> on a gruu option in the response? 
> 
> Yes. If the Supported header field in the response contains the "gruu"

> optiong tag.
>
>> I want to be sure we aren't just
>> depending on a different kind of magic to figure that out. The 
>> decision it has to make is: "the contact contains an address that
when 
>> resolved within the dialog will result in the request being delivered

>> to me, with a Route header containing exactly those entries that 
>> precede mine in the R-R header." I'm having trouble getting it clear 
>> in my head how many assumptions about the environment it must make to

>> reach this conclusion.
> 
> The proxy knows this if it inserted a Path header field in a REGISTER 
> request from the client. It can know this when the R-URI of the INVITE

> which matches a contact which was in a REGISTER that the proxy
inserted 
> a Path into.

To do this it needs to determine the following things:
- contact in response is gruu
- that contact is bound to a path
- path contains reference to this proxy

How can it figure out these things?

- contact is a gruu: can plausibly be discovered by examination
   of the contact as long as the registrar and the EP have an
   understanding of how this is done

- that the contact is bound to a path
   and that the path contains a reference to this proxy:

   This seems to require that the EP keep state of its
   own relative to registrations that it has proxied.
   While possible, it doesn't seem like a very
   appealing approach.

   Possibly, it there is sufficient coordination between
   the home proxy and EP, some kind of identification
   of the proxies in the path could be encoded into the
   gruu itself, in a way that the EP could detect. This
   at least requires very close coordination. If it can
   be made to work at all, it probably won't work in
   all interesting cases.

So my conclusion is that this only works for EPs that are "registration 
stateful".

	Paul

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Mar 2005 11:31:12 -0500

I think its a fairly common design. 3gpp, for example, has this split 
(the S-CSCF and the P-CSCF). I'm aware of multiple network deployments 
that have this topology as well.

I don't think there is any extra work in the UA to make this work. What 
UA work do you see?

-Jonathan R.

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