Subject: [martini] martini-gin-02: explicit registration & Reg Event

From: Martien Huysmans <[email-masked]>
Date: Fri, 21 May 2010 08:09:37 +0200

Hi

martini-gin-02 states in chapter 5.2:

A further implication of this property is that an
   individual extension that is implicitly registered may also be
   explicitly registered using a normal, non-bulk registration (subject
   to SSP policy).

Assume that an individual extension does a "normal, non-bulk" registratration
in additional to it's implcit registration.

Question:
How is a "reg" event SUBSCRIBE in such a case handled? Is it forwarded to the PBX?
If so, does that PBX have knowledge of the "normal, non-bulk" registration?

Regards Martien

---

From: Adam Roach <[email-masked]>
Date: Fri, 21 May 2010 08:24:38 -0500

> If so, does that PBX have knowledge of the "normal, non-bulk" 

I don't think so. It's not a GIN registration, so normal processing applies.

/a

---

From: Martien Huysmans <[email-masked]>
Date: Tue, 25 May 2010 12:52:05 +0200

Adam

Ok, so for such an "individual extension" always normal processing applies.
I am still somewhat confused by the existing text.

GIN, chapter 5.2 says that an "individual extension that is implicitly registered" may ALSO be explicitly registered.
This text suggests that an such an individual extension has 2 Contacts, one from bulk registration and one from the normal registration.

A related question:
what if such an individual extension has no active normal registrations, e.g. because the device is turned of.
I guess that normal processing shall apply. Agree?

Perhaps it would be better if the text talks about "an individual extension for which through provisioning it
has been defined that normal registration/processing" applies.

/Martiem

________________________________
From: Adam Roach [mailto:[email-masked]]
Sent: Friday, May 21, 2010 3:25 PM
To: Martien Huysmans
Cc: [email-masked]
Subject: Re: [martini] martini-gin-02: explicit registration & Reg Event

Question:

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 May 2010 20:17:22 +0200

Hi,

I also have more or less the same question/issue as Martien, but my question is more from a core 3261 perspective.

So, since the explicit registration of an individual extension (AOR), that IS also part of the bulk registration, is described as a "non-bulk registration" (I assume that means a vanilla 3261 registration), does that mean
that we are talking about an addition of a binding for an existing extension, as described in section 10.2.1 of 3261?

If so, shouldn't the registration responses (both for the bulk REGISTER and the individual REGISTER) then also contain BOTH contacts (the bulk and the individual), since there now exists two contacts for the same extension?

Second, where is the requirement for being able to perform the individual extension registration in the first place?

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Martien Huysmans [[email-masked]]
Sent: Tuesday, May 25, 2010 1:52 PM
To: Adam Roach
Cc: [email-masked]
Subject: Re: [martini] martini-gin-02: explicit registration & Reg Event

Adam

A related question:

/Martiem

Question:

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 25 May 2010 13:30:18 -0500

On 5/25/10 1:17 PM, Christer Holmberg wrote:
> [W]here is the requirement for being able to perform the individual extension registration in the first place?
>    

It's not an additional behavior that we're specifying -- it's an 
observation. We would need to go out of our way to normatively prohibit 
it if we don't want it to happen. So far, there has been no reason to 
normatively prohibit it.

I guess whether we go out of our way to prohibit it comes down to where 
we want to take things philosophically. Do we:

   1. Prohibit only those things that harm interoperability?
   2. Prohibit everything that we can't imagine a use case for right now?

My reading of most IETF-developed protocols is that we lean towards the 
first behavior, not the second. It allows people to come up with new and 
useful use cases that we may lack the ability to invent at the moment.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 May 2010 20:37:56 +0200

Hi,

>It's not an additional behavior that we're specifying -- it's an observation. We would need to go out of our way to normatively prohibit it if we don't want it to happen. So far, there has been no reason to normatively prohibit it.

IF it is just an addition of contact/binding (see my comment), then one could say that it is just an observation of existing 3261 behavior. If it is something else, then I think it is new functionality.

>I guess whether we go out of our way to prohibit it comes down to where we want to take things philosophically. Do we: 
>
>Prohibit only those things that harm interoperability?
>
>Prohibit everything that we can't imagine a use case for right now? 
>My reading of most IETF-developed protocols is that we lean towards the first behavior, not the second. It allows people to come up with new and useful use cases that we may lack the ability to invent at the moment.

My experience is that we, unfortunately, sometimes have prohibited things just because we haven't seen a use-case at the moment - without any real technical reason.

Regards,

Christer