Subject: Re: [P2PSIP] What is SipRegistrationData.contact_prefs?

From: "Michael Chen" <[email-masked]>
Date: Wed, 06 Jan 2010 20:53:35 -0700

Found it. RFC3261 Section 10.2.1.2. Suggest quoting just that so it reads:

SipRegistration.SipRegistrationData.contact_prefs

o  If the registration is of type "sip_registration_route", then the
contents are an opaque string containing the callee's contact
preferences (as defined in RFC3261 Section 10.2.1.2) and a destination

list for the peer.

I assume the actual value of the contact preference will be a string like

"0.7" or "0.1", etc.

Thanks

--Michael

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

Subject: What is SipRegistrationData.contact_prefs?

From: "Michael Chen" <[email-masked]>

Date: Tue, January 05, 2010 4:59 pm

To: [email-masked]

Hi,

In the current draft-ietf-p2psip-sip-03, there is no definition for field:

SipRegistration.SipRegistrationData.contact_prefs

o  If the registration is of type "sip_registration_route", then the
contents are an opaque string containing the callee's contact
preferences and a destination list for the peer.

What is contact preferences?

Thanks

--Michael

---

From: Michael Chen <[email-masked]>
Date: Sat, 16 Jan 2010 08:51:19 -0800

Cullen,

There are some related problems for the sip-03 draft:

1. When multiple destinations are specified in the structure, the draft 
is not clear how the contact preference for each destination is 
specified in the single contac_prefs, e.g. comma separated or space 
separated? does it allow white spaces?

2. GRUUs can also contain a destination list, but there is no mechanism 
to specify contact preferences.

3. The draft allow a single SIP registration kind to carry multiple 
dictionary entries (multiple device for the same AOR). There is no 
mechanism to specify contact preference across dictionary entries.

Perhaps the draft can simply mandate that the order of the multi-entry 
destination list implies their call preference, which means the owner of 
the registration must pre-sort the list before storing it. This can 
eliminate the contact preference field and have a unified way that also 
covers GRUU.

Thanks

--Michael

Cullen Jennings wrote:
> Just wanted to say yep, this is what we meant.
>
> On Jan 6, 2010, at 8:53 PM, Michael Chen wrote:
>
>

---

From: jc <[email-masked]>
Date: Sat, 16 Jan 2010 12:34:27 -0500

On Jan 16, 2010, at 11:51 AM, Michael Chen wrote:

> 1. When multiple destinations are specified in the structure, the draft is not clear how the contact preference for each destination is specified in the single contac_prefs, e.g. comma separated or space separated? does it allow white spaces?
> 
> 2. GRUUs can also contain a destination list, but there is no mechanism to specify contact preferences.
> 
> 3. The draft allow a single SIP registration kind to carry multiple dictionary entries (multiple device for the same AOR). There is no mechanism to specify contact preference across dictionary entries.
> 
> Perhaps the draft can simply mandate that the order of the multi-entry destination list implies their call preference, which means the owner of the registration must pre-sort the list before storing it. This can eliminate the contact preference field and have a unified way that also covers GRUU.

Who would the "owner" of the registration be? For instance with my implementation my iphone registers as a peer, a few desktops as peers and nodes all under the same AOR and I Join a single other AOR as a Callee to test. All of my devices ring and receive chat messages however again who actually owns the registration? Nobody, the certificate belonging to the AOR owns the registration correct?

> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip