Subject: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 3 May 2010 15:27:18 -0400

Howdy,
I have submitted a new draft strawman proposal for reg-event which tries to accomplish the following:
1) Gives reg-event for open-numbering-plans
2) Subscribes for AoRs *in* the PBX, vs. just SSP's
3) Subscribes for all implicitly registered AoRs (e.g., so PBX can check it)
4) Creates an acronym for Vermouth

Any comments/flames welcomed.

-hadriel

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : SIP MARTINI Variant of 'Event-package for Registrations' for Managed Open-ended Username Target Handling (VERMOUTH)
	Author(s)       : H. Kaplan, et al.
	Filename        : draft-kaplan-martini-vermouth-00.txt
	Pages           : 19
	Date            : 2010-05-03

The Martini Working Group is defining a mechanism for SIP IP-PBX type devices to REGISTER and obtain SIP service for E.164-based Address of Records, in [draft-gin].  Another draft [draft-olive] proposes the same for non-E.164-based AoRs.  This document defines a variant of the Registration Event-package [reg-event] for open-ended AoRs for either mechanisms, using a wildcard syntax and specific target handling rules.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kaplan-martini-vermouth-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 3 May 2010 23:43:06 +0200

There is some valid ideas in this and with some work it could be made
to work with several different mechanisms. This does not have to be
gin specific.

Some issues/questions:
- the use of the bnc tag to address the AOR behind the PBX seems
counterintuitive, as one is in fact in this case addressing a normal
registration...
- the use of a special tag to mint subscription requests to address
the AOR behind the PBX assumes knowledge at the subscriber about the
AOR's terminating arrangement. This is in general problematic. As such
arrangement should be possible to be freely changed by the receiving
company, without notifying potential originators. Not to mention the
security issues with revealing the connection topology.
- can there be more range parameters?
- can the range parameter be injected at any place in a string or only
at the end of the user part?
- regarding 5.4 open issue, yes bulk AOR's are only short hand
representation of ranges registered. They themselves are not
registered and should not be used as AOR's themselves and therefore
section 5.4 should be removed. And some statement should be made
somewhere that bulk AOR's can not be used as normal AOR's. In IMS we
call this wildcarded PUI and those can only be used to match distinct
PUI's with, same here maybe it is better to talk about wildcarded
AOR's as it expresses this property better.
- statements (for ex. 5.1) like "Any internal optimization performed
by the SSP location-service database for handling Bulk-AoRs MUST NOT
change this external behavior. " Are not referring to the SUBSCRIBE
mechanism and therefore inappropriate repetition of an opinion in this
draft ;-)
- Appendix A: While I have no problem with simplifying the pattern, to
enable less configuration errors and complaince with RFC3261. You
bring back here the issue of automatically detecting provisioning
mismatches by the PBX. Is this based on something you have seen in
practice? Why would this be an issue at all? Even in the simplified
case I don not think that an IP-PBX can conclude anything when it has
knowledge about the full generated set of AOR's. It suffices to match
each configured AOR with the patterns returned.

/Hans Erik van Elburg

On Mon, May 3, 2010 at 9:27 PM, Hadriel Kaplan <[email-masked]> wrote:
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 4 May 2010 07:04:11 +0200

Hi Hadriel,

Having thought about this a bit more, I do think that the what would
suffice is having the following usages:

  5.    Subscribing for Registration State Resources
      5.1.   Subscribing to AoRs
Where it is in fact "Subscribing to state in the IP-PBX".

      5.2.   Subscribing for all implicitly registered AoRs..........8
As is.

As 5.1 is usefull for other UA's the result will not surprise them and
it will be usefull information.
5.2 is useful for the PBX to monitor its own registration state.

Then there is no need for SUBSCRIBES with awkward bnc parameters.
I know this violates the principle that this is a normal registration,
but that is because it is not a normal registration.

Curious if you think this could be a way forward.

/Hans Erik van Elburg

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 4 May 2010 10:42:50 -0400

Hi Hans Erik,
I _think_ what you're saying is: for the case where a SUBSCRIBE is targeted to an AoR the PBX implicitly registered for, it should be routed to the PBX; and for the case where we want the SSP to process it itself, we should define a new target syntax, such as the "bnc" param I use in the draft.  In other words, swap those two cases in the draft from a target URI perspective.

Correct?

Obviously that's also a reasonable way to go, but I'd like to make that an open issue/decision for WG consensus.

Personally I prefer it the way in the current vermouth draft: a SUBSCRIBE targeted to the AoR gets processed by the SSP just like any other, while a SUBSCRIBE to the AoR with a URI param of "bnc" gets routed to the PBX.

My reasoning is as follows:
Currently, for any "normal" Registration model, a SUBSCRIBE targeted to the AoR gets processed by the SSP.  In effect, the combination of that target URI and the "reg" event package indicator are used as a resource identifier for getting the SSP's registration state of that AoR.  So...

1) Currently, since the SUBSCRIBE's target URI looks like any other AoR of the SSP, *any* proxy in the SSP can make a simple routing decision to send all SUBSCRIBEs for reg-event to a specific app server which handles reg-event, without knowing what "type" of AoR the target URI refers to.  If we make SUBSCRIBEs for implicitly registered AoRs route differently, without some specific indication in the SUBSCRIBE, then that's no longer as simple a thing to do.

2) It really is possible for the SSP to support multiple contacts for any AoR in the set of implicitly registered AoRs.  It's not common of course, but I could see an SSP wanting to offer their customers to Register one or more of those same numbers for home-office or traveling users.  Those users really will be Registered in the SSP, not the PBX.  And the SSP really will have legitimate, "normal" registration state for that same AoR which is also Registered implicitly by the PBX.  So for that case the SUBSCRIBE being routed differently than normal is really screwed up.

3) Personally, I think in hindsight it was a mistake to have SUBSCRIBEs for a target URI route differently than any other request for that same target URI, and route differently for different event packages.  That ship has sailed, obviously, and all kinds of method-specific and header-specific routing occurs in the real world - but it would be nice not to add yet more complexity by having different routing for a combination of {method + event + AoR-type}.  It's not a huge deal, since we're already down that rabbit hole, but still it would be nice.

-hadriel

> -----Original Message-----
> From: Hans Erik van Elburg [mailto:[email-masked]]
> Sent: Tuesday, May 04, 2010 1:04 AM
> To: Hadriel Kaplan
> Cc: [email-masked]
> Subject: Re: [martini] draft-kaplan-martini-vermouth-00: reg-event
> handling for draft-gin and draft-olive
> 
> Hi Hadriel,
> 
> >>        Title           : SIP MARTINI Variant of 'Event-package for
> Registrations' for Managed Open-ended Username Target Handling (VERMOUTH)
> >> The Martini Working Group is defining a mechanism for SIP IP-PBX type
> devices to REGISTER and obtain SIP service for E.164-based Address of
> Records, in [draft-gin].  Another draft [draft-olive] proposes the same
> for non-E.164-based AoRs.  This document defines a variant of the
> Registration Event-package [reg-event] for open-ended AoRs for either
> mechanisms, using a wildcard syntax and specific target handling rules.
> >>
> >> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> >>
> >>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 5 May 2010 11:14:23 +0200

Hadriel,

I am concerned that it is somewhat counter-intuitive from a subscriber point of view to have to put in a special parameter to get to the PBX. I am not sure how the reg-event package is used in practice, but suppose some presence-like application is using reg-event to see whether any device is currently registered for a user. It is not aware that +12345 is behind a PBX, so it subscribes to reg-event at +12345, without any special parameter, gets back the contact sip:[email-masked], and concludes yes, there is a device present. Yet behind the PBX, there may be no device registered against +12345.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 04 May 2010 15:43
> To: Hans Erik van Elburg
> Cc: [email-masked]
> Subject: Re: [martini] draft-kaplan-martini-vermouth-00: 
> reg-event handling for draft-gin and draft-olive
> 
> 
> Hi Hans Erik,
> I _think_ what you're saying is: for the case where a 
> SUBSCRIBE is targeted to an AoR the PBX implicitly registered 
> for, it should be routed to the PBX; and for the case where 
> we want the SSP to process it itself, we should define a new 
> target syntax, such as the "bnc" param I use in the draft.  
> In other words, swap those two cases in the draft from a 
> target URI perspective.
> 
> Correct?
> 
> Obviously that's also a reasonable way to go, but I'd like to 
> make that an open issue/decision for WG consensus.
> 
> Personally I prefer it the way in the current vermouth draft: 
> a SUBSCRIBE targeted to the AoR gets processed by the SSP 
> just like any other, while a SUBSCRIBE to the AoR with a URI 
> param of "bnc" gets routed to the PBX.
> 
> Currently, for any "normal" Registration model, a SUBSCRIBE 
> targeted to the AoR gets processed by the SSP.  In effect, 
> the combination of that target URI and the "reg" event 
> package indicator are used as a resource identifier for 
> getting the SSP's registration state of that AoR.  So...
> 
> 1) Currently, since the SUBSCRIBE's target URI looks like any 
> other AoR of the SSP, *any* proxy in the SSP can make a 
> simple routing decision to send all SUBSCRIBEs for reg-event 
> to a specific app server which handles reg-event, without 
> knowing what "type" of AoR the target URI refers to.  If we 
> make SUBSCRIBEs for implicitly registered AoRs route 
> differently, without some specific indication in the 
> SUBSCRIBE, then that's no longer as simple a thing to do.
> 
> 2) It really is possible for the SSP to support multiple 
> contacts for any AoR in the set of implicitly registered 
> AoRs.  It's not common of course, but I could see an SSP 
> wanting to offer their customers to Register one or more of 
> those same numbers for home-office or traveling users.  Those 
> users really will be Registered in the SSP, not the PBX.  And 
> the SSP really will have legitimate, "normal" registration 
> state for that same AoR which is also Registered implicitly 
> by the PBX.  So for that case the SUBSCRIBE being routed 
> differently than normal is really screwed up.
> 
> 3) Personally, I think in hindsight it was a mistake to have 
> SUBSCRIBEs for a target URI route differently than any other 
> request for that same target URI, and route differently for 
> different event packages.  That ship has sailed, obviously, 
> and all kinds of method-specific and header-specific routing 
> occurs in the real world - but it would be nice not to add 
> yet more complexity by having different routing for a 
> combination of {method + event + AoR-type}.  It's not a huge 
> deal, since we're already down that rabbit hole, but still it 
> would be nice.
> 
> -hadriel
> 
> 
> > > On Mon, May 3, 2010 at 9:27 PM, Hadriel Kaplan 
> <[email-masked]>
> > wrote:
> > >>
> > >> Howdy,
> > >> I have submitted a new draft strawman proposal for 
> reg-event which
> > tries to accomplish the following:
> > >> 3) Subscribes for all implicitly registered AoRs (e.g., 
> so PBX can
> > check it)
> > >> A New Internet-Draft is available from the on-line 
> Internet-Drafts
> > directories.
> > >>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 5 May 2010 16:07:49 +0200

> I _think_ what you're saying is: for the case where a SUBSCRIBE is targeted to an AoR the PBX implicitly registered for, it should be routed to the PBX; and for the case where we want the SSP to pr…
[HE] Yes you could interpret it like that. But I also think there is
no need for the case where the SSP returns the result, so I would just
suggest to remove that unless there is a use case for which this
information is usefull.

> Currently, for any "normal" Registration model, a SUBSCRIBE targeted to the AoR gets processed by the SSP.  In effect, the combination of that target URI and the "reg" event package indicator are u…
Yes for normal registrations you may view it like that.

> 1) Currently, since the SUBSCRIBE's target URI looks like any other AoR of the SSP, *any* proxy in the SSP can make a simple routing decision to send all SUBSCRIBEs for reg-event to a specific app…
I do not agree, the location server can together with the location
where the AOR can be reached return information that this is a bulk
contact. That information can be used by the SSP's proxy to apply
proper handling.

> 2) It really is possible for the SSP to support multiple contacts for any AoR in the set of implicitly registered AoRs.  It's not common of course, but I could see an SSP wanting to offer their cus…
This is a very strange use case, normally you either receive service
from the SSP (centrex scenario) or from the PBX. Mixing those two is
asking for problems. Conflicting service configurations etc. In such a
case the user would rather have two different AOR's.

> 3) Personally, I think in hindsight it was a mistake to have SUBSCRIBEs for a target URI route differently than any other request for that same target URI, and route differently for different event…
The more impportant criterion is if the result that the subscriber
expects is usefull and meaningful. That there will be slight
differences certain behaviours for bulk registrations is completely
OK. And the complexity added is minor really.

/Hans Erik

---

From: Martien Huysmans <[email-masked]>
Date: Thu, 6 May 2010 17:01:01 +0200

The email below contain the following statement:

----
This is a very strange use case, normally you either receive service from the SSP (centrex scenario) or from the PBX. Mixing those two is asking for problems. Conflicting service configurations etc. In such a case the user would rather have two different AOR's.
----

I think that SIP Connect 1.1 mentions the combination of a user registered at the PBX 
could have a VoiceMail service from the SSP.

I als remember a previous email from Adam where I asked
  Are you saying that the current martini-gin draft supports an 
  architecture where for sip:[email-masked] the presence server 
  resides at the SSP and where the IPPBX would provide voice services?
and Adam replied:  
  It certainly does. It also supports one in which the presence server resides at the PBX. 
  This also true for voicemail, and pretty much any other service typically 
  provided in the network.

So I am left a little bit puzzled, what the architecture supports.

/Martien
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
Sent: Wednesday, May 05, 2010 4:08 PM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive

> I _think_ what you're saying is: for the case where a SUBSCRIBE is targeted to an AoR the PBX implicitly registered for, it should be routed to the PBX; and for the case where we want the SSP to pr…
[HE] Yes you could interpret it like that. But I also think there is no need for the case where the SSP returns the result, so I would just suggest to remove that unless there is a use case for which this information is usefull.

> 1) Currently, since the SUBSCRIBE's target URI looks like any other AoR of the SSP, *any* proxy in the SSP can make a simple routing decision to send all SUBSCRIBEs for reg-event to a specific app…
I do not agree, the location server can together with the location where the AOR can be reached return information that this is a bulk contact. That information can be used by the SSP's proxy to apply proper handling.

> 2) It really is possible for the SSP to support multiple contacts for any AoR in the set of implicitly registered AoRs.  It's not common of course, but I could see an SSP wanting to offer their cus…
This is a very strange use case, normally you either receive service from the SSP (centrex scenario) or from the PBX. Mixing those two is asking for problems. Conflicting service configurations etc. In such a case the user would rather have two different AOR's.

> 3) Personally, I think in hindsight it was a mistake to have SUBSCRIBEs for a target URI route differently than any other request for that same target URI, and route differently for different event…
The more impportant criterion is if the result that the subscriber expects is usefull and meaningful. That there will be slight differences certain behaviours for bulk registrations is completely OK. And the complexity added is minor really.

/Hans Erik

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 May 2010 00:25:09 -0400

> Sent: Monday, May 03, 2010 5:43 PM
> To: Hadriel Kaplan
>

Yes, unfortunately it's been a real issue.  For example, there was a service outage just a couple weeks ago in a big carrier which impacted service for a bunch of Enterprise trunks.  Several things were configured incorrectly to make it become an actual outage of service for a bunch of Enterprise trunks, but the initial trigger which brought it down was the SSP thought the PBX owned a number and the PBX did not.  It caused an infinite loop, and due to poor configuration (and no throttles) several systems went to max utilization until humans stopped it.

So having a PBX just run a regex against the numbers it knows about is not enough - because that doesn't tell it what *additional* numbers the SSP thinks the PBX has which the PBX doesn't.  One could design a PBX to also use the regex against SIP Requests themselves, and decide that if the regex matches the Request's URI then it does own the username, and then return a 404 if it doesn't really have provisioning for that username.  But even that would get complicated fast.  These regex's are provisioned by people, and in my experience most people are really bad at creating _good_ regex patterns.  Unless we really need the complete flexibility of a regex pattern, I would recommend we avoid it.

-hadriel