Subject: RE: [Sip] Some comments on GRUUs

From: "Dale Worley" <[email-masked]>
Date: Fri, 1 Jul 2005 14:49:13 -0400

> From: Nils Ohlmeier [mailto:[email-masked]]
>
> My concerns with such a solution are:
> - how can the UA A determine its address a.example.com?
> Especially with NAT's
> between the UA and the proxies this a big problem again, or?

That task is simpler than I've made it appear, I think.  Though I wrote the
address as "a.example.com", it has to be "the address by which EP accesses
A", which is most likely expressed by an absolute IP address.  In any case,
it comes from a "Record-Route: a.example.com" that UA A adds to the
route-set, so UA A *must* know what that address is.

> - the UA needs to implement Route processing logic, which was
> not necessary up to now.

That is true, though the Route processing logic can be fairly simple, as it
only has to recognize and discard Route headers for the one address
"a.example.com".  (It shouldn't see any others.)

Though there is more obscure processing problem -- the request-URI will be
"[email-masked]", and the UA has to be able to recognize its own GRUUs
and not forward them to the central server for resolution.

> I think it would make more sense to not solve such routing
> problems not in the
> implementation but by the particular installation, because
> they know a lot
> better which instance is able to handle what. For the given
> example two
> possible routing sets could look like this:
>
>   <sip:hp.example.com;lr>
>   <sip:[email-masked]>
>
> Or
>
>   <sip:hp.example.com;lr>
>   <sip:ep.example.com;lr>
>   <sip:hp.example.com;lr>
>   <sip:[email-masked]>
>
> Both are transparent for the UAs. But I admit that they will result in a
new
> connection between the UA A and hp for in-dialog requests (which are send
by
> UA A) which might not be desired.

More exactly, that is the problem I'm attempting to solve.

> In any case it seems to be a very bad idea to install any required
"services"
> which need to see in-dialog requests on proxies which can not resolve the
> GRUU contact (ep in this case.) If accounting etc. is handled at hp and ep
is
> not required in the Route this prevents a lot of problems.

True, but that is the particular case I'm trying to solve.  Not so much when
EP provides some sort of AAA service, but when it sits on an
address-translation boundary and must remain in the route set because A and
HP cannot talk directly.

Dale

_______________________________________________
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, 07 Jul 2005 02:23:45 -0400

inline.

Dale Worley wrote:

> 
>>>* Syntax of URNs
>>>
>>>The "sip.instance" parameter has a value which is a URN.  However, a
>>>number of examples in draft-ietf-sip-gruu-03 show the URN surrounded
>>>with "<...>", which is not strictly valid.  Though this would be
>>>unlikely to cause functional problems in real implmentations, the
>>>examples should be corrected:
>>
>>The <> is part of the syntax defined in 3840.3841 for callerprefs
>>feature parameters. It indicates that the enclosed is a string rather
>>than a list of tokens.
> 
> 
> OK, thanks for explaining that.  Looking at 3840, I guess I never realized
> that the "feature predicates" it discusses were to be used for declaring the
> features that a UA possesses, rather than what one would expect from the
> name, a predicate *filtering* the features of some arbitrary UA.  And
> looking at the definition of "Contact Predicate" in section 3, I notice that
> it does not really define what the contact predicate is a predicate *of*.
> Has there been any clarification of that?

The definitions are all lifted from RFC2533.

The presence of the <>s has been a source of confusion in the gruu spec. 
They do need to be there. I've clarified the text in the spec to make it 
clear that this is the case.

Thanks,
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