Subject: [Sip] Relationship between GRUU and callee capabilities

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 5 Jul 2006 07:50:49 +0200

In http://www.jdrosen.net/papers/draft-ietf-sip-gruu-09.txt section 6 figure 1, a GRUU is shown to be associated with 0..n Contacts. Does this include callee capabilities that were indicated in the registration of that contact? In other words, should the GRUU proxy be able to reconstruct those capabilities, e.g. for caller preference processing purposes?

Thanks,

Jeroen

_______________________________________________
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: Wed, 26 Jul 2006 22:08:40 -0400

Jeroen van Bemmel wrote:

> In http://www.jdrosen.net/papers/draft-ietf-sip-gruu-09.txt section 6 
> figure 1, a GRUU is shown to be associated with 0..n Contacts. Does this 
> include callee capabilities that were indicated in the registration of 
> that contact?

Yes.

> In other words, should the GRUU proxy be able to 
> reconstruct those capabilities, e.g. for caller preference processing 
> purposes?

Yes. Here is what I have done to clarify. In the section on register 
processing:

<t> Registration processing then continues as defined in RFC 3261. If,
after that processing, that contact is bound to the AOR, it also
becomes bound to the GRUU associated with that instance ID/AOR
pair. In addition, if that contact had callee capabilities associated
with it <xref target="RFC3840"/>, those capabilities continue to be
associated with the contact as it is bound to the GRUU. If, after that
processing, the contact was not bound to the AOR (due, for example, to
an expiration of zero), the contact is not bound to the GRUU either.
</t>

and in the section on proxy processing:

<t> Otherwise, handling of the GRUU proceeds as specified in RFC 3261
Section 16. For GRUUs, the abstract location service described in
Section 16.5 is utilized, producing a set of zero or more contacts,
each of which is associated with the same instance ID. If the proxy
supports the caller preferences specification <xref
target="RFC3841"/>, and the request contained Accept-Contact or
Reject-Contact header fields, caller preferences are applied to the
contact set.  If there are more than one contact with the same
instance ID, and those contact were registered using the procedures of
<xref target="I-D.ietf-sip-outbound"/>, those procedures are used to
select one. Otherwise, the most recently updated contact is used.
This produces zero or one contacts. The server MUST copy the "grid"
parameter from the Request-URI (if present) into the new target URI
obtained from the registered contact. If there was no "grid" parameter
in the Request-URI, the proxy MUST insert a "grid" parameter into the
new target URI obtained from the registered contact, and MUST omit a
value for the parameter. Note that the "gruu" URI parameter is not
copied. If the grid was already present in the contact bound to the
GRUU, it is overwritten in this process. If no contacts were bound to
the GRUU, the lookup of the GRUU in the abstract location service will
result in zero target URIs, eventually causing the proxy to reject the
request with a 480 (Temporarily Unavailable) response.  </t>

Thanks,
Jonathan R.

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