Subject: [martini] Comments on draft-kaplan-martini-mixing-problems-00

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 6 Jan 2010 15:50:34 +0100

I've just starting trying to work my way through these drafts.

Firstly can I point out that we have elements in the set of drafts of trying to standardise beyond the event, where is some cases that event was 3GPP release 5 (which was frozen in 2002). So please remember that IETF may well not be the prime place of specification of these issues.

Now to the draft draft-kaplan-martini-mixing-problems-00.

1)	Additional indicator
--------------------------

draft-kaplan-martini-mixing-problems-00 seems to be arguing for an indicator, but I am left in doubt as to what that indicator is for. While I am not opposed to the creation of new indicators, any indicator needs clear requirements, and a clear understanding of why it is needed.

Is it:

A)	to indicate that implicit registration is being used. But implicit registration has existed for all IMS usages since day one. It is reflected in the requirements in RFC 4083 as follows:

4.10.2.2.  Registration of Public User IDs

   It must be possible to register globally (i.e., through one single UA
   request) a user that has more than one public identity that belongs
   to the same user profile, via a mechanism within the IMS.  In this
   case, the user will be registered with all the public identities
   associated to a user profile.

   We believe this requirement may be accomplished by external
   procedures.  For example, the user's profile may contain a list of
   alias identities that the registrar considers active if the primary
   identity is registered.  The user may get informed of the
   automatically registered public user IDs by subscribing to its own
   registration state.

Implicit registration is therefore not specific to PBX usage, and is normal for IMS usage.

B)	to indicate that "loose routeing" is being used. Note that this is poor naming because it is not really that. Secondly the usage of this is intended to be standard for all subscription based approachs. What in essence TISPAN and 3GPP were trying to do is provide compatible usages in incoming requests for normal peering type connections (where the PBX is routed to using standard DNS mechanisms), and this registration based approach. Thus the solution adopted for IMS treates the attached PBX as if calls were being routed to it using a standard SIP routeing proxy, and the registration mechanism is an adjunct to essentially set up the pseudo DNS to drive it. On this basis I would argue this is what PBXs based on SIP networks should expect, and the REGISTER is an add on to the standard SIP interconnect at the interface itself, in order to kick the IMS into doing the DNS type job. As such the indicator should not be added for this function, because it would also have to be added for any peering based approach as well. Rather, it is the SIP location server functionality that is the exception, and therefore an indicator should be added that the Request-URI has been modified as a result of location server. This of course will impact all SIP UAs that are out there in the field.

I would also note that any SBC in the IMS environment has to follow the IMS rules. IMS will not support the generation of indicators merely to allow the insertion of IMS non-compliant devices in the IMS environment. Some of the behaviour being discussed in this draft for edge proxies is not IMS compliant.

2)	Handling of P-Associated-URI
----------------------------------

The document talks about the PBX learning about the implicit registration using the P-Associated-URI, but does not actually say what the requirement from the PBX side is. By default (i.e. because it is there in release 5) there are two mechanisms provided in IMS.

A)	The P-Associated-URI mechanism. This will tell you the URIs that were registered as a result of the usage of the REGISTER method. 

B)	Subscription to the reg event package. 

It is only the latter that will inform a connected device about the actual state of registrations on a continuous basis. Note that IMS can remove registrations for various reasons (e.g. prepay account is empty). In the absence of requirements does the PBX need either mechanism. It cannot turn off A), but it can certainly ignore the information as it should do as UA functionality on any unrecognised header. On this basis, it just assumed that the implicit registration it asked for is granted.

Note that IMS does use the reg event package to indicate essentially to the UA that authentication has been removed (and all the registrations have been removed because IMS associates registration with authentication). Essentially in this state on IMS, the attached device can do nothing except REGISTER, and therefore there are other indicators that this has occurred.

3)	Trust domains
-------------------

I don't think you are going to solve this issue.

You will only solve it by rewriting RFC 3324 and RFC 3325.

4)	Wildcarding
-----------------

I believe this is something that IETF can usefully extend to tel-URIs. It is a powerful and efficient mechanism for defining a range of identifiers, and works equally for tel URIs and SIP URIs. Its usage is an advantage and not a hindrance.

Conclusion
----------

I do not think this document adequately addresses a set of requirements, and I suspect a set of clearly stated requirements do need to be put in place before further significant further work is performed.

regards

Keith

---

From: Adam Roach <[email-masked]>
Date: Wed, 06 Jan 2010 10:17:23 -0600

On 1/6/10 8:50 AM, DRAGE, Keith (Keith) wrote:
> A)	to indicate that implicit registration is being used. But implicit registration has existed for all IMS usages since day one.

There is a massive and radical difference between the kind of implicit 
registration used by IMS and what is being proposed in MARTINI. 
Specifically: when IMS performs implicit registration, it is for several 
AORs that correspond to the exact same user. The MARTINI problem 
involves registering information for several AORs that correspond to a 
multitude of users. From a semantic perspective, that is a very 
different kind of operation. We need to be careful not to conflate these 
two different operations.

> I do not think this document adequately addresses a set of 
> requirements, and I suspect a set of clearly stated requirements do 
> need to be put in place before further significant further work is 
> performed.

I agree. I think the problem here is that the requirements were written 
primarily to support an already-developed solution, without first 
analyzing whether the solution really makes sense. Rather than working 
backwards from the broken solutions that have been deployed so far, 
let's actually figure out the requirements, and then work forwards from 
there.

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 6 Jan 2010 18:05:59 +0100

You wrote:

> There is a massive and radical difference between the kind of 
> implicit registration used by IMS and what is being proposed 
> in MARTINI. 
> Specifically: when IMS performs implicit registration, it is 
> for several AORs that correspond to the exact same user. The 
> MARTINI problem involves registering information for several 
> AORs that correspond to a multitude of users. From a semantic 
> perspective, that is a very different kind of operation. We 
> need to be careful not to conflate these two different operations.
> 

Whatever we end up doing is a frig as far as I can see. The problem space we are addressing here is how to deal with the support of URIs hosted in network B when a request is received containing that URI by network A. The correct solution for that is DNS and / or ENUM. That is defined as one solution by 3GPP and ETSI, and is called the peering-based solution.

However service providers want a mechanism of using the existing interface they give to normal customers to support PBXs. So the question is how to take a normal inbound / outbound proxy interface and make it look like a peering based interface as much as possible, because that is what the PBX should be expecting at its gateway proxies. In other words, how do we get such interfaces to simulate the normal gateway proxy behaviour for incoming calls. 3GPP / ETSI call this the subscription-based approach. That is the only reason REGISTER is used, because it forms an integral part of such interfaces in the first place. Service providers want this solution because among other things, it gives a means of managing their PBX customers in the same manner as they manage their other subscribers, i.e. the same interface to the subscriber database gets used.

Use a different method, and you essentially say we are creating a new interface to service providers, not frigging the existing UA one. As soon as one does that, then you are back to essentially the normal peering, and any justification for the work you are suggesting should be supported by requirements coming out of SPEERMINT, because it there should be no different to the requirements for peering any two networks using standard mechanisms.

I would stress that in the scenario we are talking about the customer subscription is NOT that of the end user. It is the subscription of the PBX operator, and tells the SSP how it requires the URIs that it owns to be managed by the SSP. The PBX operator decides how it delivers service to its own end users. So as far as the SSP is concerned there is ONE user, it is the PBX operator.

There are obviously two issues here we need to hammer out on the call tomorrow.

regards

Keith

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]] 
> Sent: Wednesday, January 06, 2010 4:17 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [martini] Comments on 
> draft-kaplan-martini-mixing-problems-00
> 
> > draft-kaplan-martini-mixing-problems-00 seems to be arguing 
> for an indicator, but I am left in doubt as to what that 
> indicator is for. While I am not opposed to the creation of 
> new indicators, any indicator needs clear requirements, and a 
> clear understanding of why it is needed.
> >
> > Is it:
> >
> > A)	to indicate that implicit registration is being used. 
> But implicit registration has existed for all IMS usages 
> since day one.
> 
> 
> There is a massive and radical difference between the kind of 
> implicit registration used by IMS and what is being proposed 
> in MARTINI. 
> Specifically: when IMS performs implicit registration, it is 
> for several AORs that correspond to the exact same user. The 
> MARTINI problem involves registering information for several 
> AORs that correspond to a multitude of users. From a semantic 
> perspective, that is a very different kind of operation. We 
> need to be careful not to conflate these two different operations.
> 
> I agree. I think the problem here is that the requirements 
> were written primarily to support an already-developed 
> solution, without first analyzing whether the solution really 
> makes sense. Rather than working backwards from the broken 
> solutions that have been deployed so far, let's actually 
> figure out the requirements, and then work forwards from there.
> 
> /a
>

---

From: <[email-masked]>
Date: Wed, 6 Jan 2010 18:24:16 +0100

Two comments [BC] 

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de DRAGE, Keith (Keith)
> Envoyé : mercredi 6 janvier 2010 18:06
> À : Adam Roach
> Cc : [email-masked]
> Objet : Re: [martini] Comments on 
> > Specifically: when IMS performs implicit registration, it is for 
> > several AORs that correspond to the exact same user. The MARTINI 
> > problem involves registering information for several AORs that 
> > correspond to a multitude of users. From a semantic 
> perspective, that 
> > is a very different kind of operation. We need to be careful not to 
> > conflate these two different operations.
> > 
> 
> Whatever we end up doing is a frig as far as I can see. The 
> problem space we are addressing here is how to deal with the 
> support of URIs hosted in network B when a request is 
> received containing that URI by network A. The correct 
> solution for that is DNS and / or ENUM. That is defined as 
> one solution by 3GPP and ETSI, and is called the 
> peering-based solution.
> 
> However service providers want a mechanism of using the 
> existing interface they give to normal customers to support 
> PBXs. So the question is how to take a normal inbound / 
> outbound proxy interface and make it look like a peering 
> based interface as much as possible, because that is what the 
> PBX should be expecting at its gateway proxies. In other 
> words, how do we get such interfaces to simulate the normal 
> gateway proxy behaviour for incoming calls. 3GPP / ETSI call 
> this the subscription-based approach. That is the only reason 
> REGISTER is used, because it forms an integral part of such 
> interfaces in the first place. Service providers want this 
> solution because among other things, it gives a means of 
> managing their PBX customers in the same manner as they 
> manage their other subscribers, i.e. the same interface to 
> the subscriber database gets used.

[BC]: Another reason why (some) service providers want this solution is actually mentioned in draft-kaplan-martini-shaken-implicit-registrations-00 -> less provisioning.

> 
> Use a different method, and you essentially say we are 
> creating a new interface to service providers, not frigging 
> the existing UA one. As soon as one does that, then you are 
> back to essentially the normal peering, and any justification 
> for the work you are suggesting should be supported by 
> requirements coming out of SPEERMINT, because it there should 
> be no different to the requirements for peering any two 
> networks using standard mechanisms.
> 
> I would stress that in the scenario we are talking about the 
> customer subscription is NOT that of the end user. It is the 
> subscription of the PBX operator, and tells the SSP how it 
> requires the URIs that it owns to be managed by the SSP. The 
> PBX operator decides how it delivers service to its own end 
> users. So as far as the SSP is concerned there is ONE user, 
> it is the PBX operator.

[BC]: I fully agree. From my point of view this is also why using the PAU still makes sense in this case.

> indicator is 
> > for. While I am not opposed to the creation of new indicators, any 
> > indicator needs clear requirements, and a clear 
> understanding of why 
> > it is needed.
> > >
> > > Is it:
> > >
> > But implicit registration has existed for all IMS usages since day 
> > one.
> > 
> > 
> > Specifically: when IMS performs implicit registration, it is for 
> > several AORs that correspond to the exact same user. The MARTINI 
> > problem involves registering information for several AORs that 
> > correspond to a multitude of users. From a semantic 
> perspective, that 
> > is a very different kind of operation. We need to be careful not to 
> > conflate these two different operations.
> > 
> > I agree. I think the problem here is that the requirements were 
> > written primarily to support an already-developed solution, without 
> > first analyzing whether the solution really makes sense. 
> Rather than 
> > working backwards from the broken solutions that have been 
> deployed so 
> > far, let's actually figure out the requirements, and then work 
> > forwards from there.
> > 
> > /a
> > 
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
> 

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 6 Jan 2010 18:25:00 +0100

I agree with Keith that from the PBX point of view the basic way to do things is the peering-based approach (known as static mode in the SIPconnect spec) - this involves normal RFC 3261/3263 procedures.

However, for the reasons Keith has stated, SSPs want to make small PBXs look as much like ordinary subscribers as possible, so that they can manage them the same way. In addition, such small PBXs, for various reasons stated in the mixing-problems draft, might not be in a position to advertise through DNS. From the PBX point of view, this necessitates some departure from the basic RFC 3261/3263 approach. That departure essentially involves being able to REGISTER with the SSP, i.e., register the PBX, as an entity that acts on behalf of its multiple users. Other than that, it is desirable from the PBX's perspective that SIP operates as close as possible to how it operates in the peering-based approach.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
> Sent: 06 January 2010 17:06
> To: Adam Roach
> Cc: [email-masked]

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 6 Jan 2010 13:02:42 -0500

Below...

>  [BC]: Another reason why (some) service providers want this solution
>  is actually mentioned in draft-kaplan-martini-shaken-implicit-
>  registrations-00 -> less provisioning.

Precisely, thank you and its not just some service providers its lots of
them, especially those smaller SSP's who are dealing with what I often refer
to as the fractional T1/E1 market. Small and medium businesses.  Typically
systems where there are less than 24 concurrent sessions deployed. It is the
cost of provisioning for competitive service providers that has been a
principal driver in the shaken-implicit concept. In addition using
shaken-implicit makes it trivial to add additional DID numbers to a
customer. 

I would like folks to consider for a moment the real business drivers here
and not just the technical issues.

IMHO the martini-shaken concept fixes known interoperability problems in the
field RIGHT NOW with thousands of deployments and would be very easy to
modify existing code to do this.  IMHO there are real long term provisioning
issues between PBX's and SSP's, but it could take 24 months in the IETF to
do that,  if at all ( for lots of reasons I don't think the IETF does
provisioning very well) and I don't think that is logically where MARTINI
should go.

---

From: Adam Roach <[email-masked]>
Date: Wed, 06 Jan 2010 12:26:33 -0600

On 1/6/10 11:05 AM, DRAGE, Keith (Keith) wrote:
> I would stress that in the scenario we are talking about the customer 
> subscription is NOT that of the end user. It is the subscription of 
> the PBX operator, and tells the SSP how it requires the URIs that it 
> owns to be managed by the SSP. The PBX operator decides how it 
> delivers service to its own end users. So as far as the SSP is 
> concerned there is ONE user, it is the PBX operator.

The issue is that the PBX needs to be able to differentiate among its 
own users for proper call processing -- hence the issues with "losing 
target information" that the mixing problems draft talks about. So, 
while the SSP treats the PBX as a single billing entity, there is still 
a need to differentiate among the individual users behind the PBX.

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 7 Jan 2010 15:57:18 +0100

I'm lost.

Are you referring to the loss of the Request-URI in incoming requests?

If so you will note that I commented in another message that at least in IMS, the replacement does is not intended to occur on attached PBXs. This is the misnamed "loose route" that is referred to in the drafts. This mechanism is meant to be generally applied to anyone creating a subscription as a PBX.

regards

Keith 

> Sent: Wednesday, January 06, 2010 6:27 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> The issue is that the PBX needs to be able to differentiate 
> among its own users for proper call processing -- hence the 
> issues with "losing target information" that the mixing 
> problems draft talks about. So, while the SSP treats the PBX 
> as a single billing entity, there is still a need to 
> differentiate among the individual users behind the PBX.
> 
> /a
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 7 Jan 2010 14:09:07 -0500

BTW, in my defense, this wasn't a Requirements document/draft.
A call went out asking for drafts on "Discussions of currently deployed mechanisms for multiple AOR registration, and their pros and cons."  And that's basically what I tried to write up, though more as a problems list.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of DRAGE, Keith (Keith)
> Sent: Wednesday, January 06, 2010 9:51 AM
> To: [email-masked]
> Subject: [martini] Comments on draft-kaplan-martini-mixing-problems-00
> 
> 
> I do not think this document adequately addresses a set of requirements,
> and I suspect a set of clearly stated requirements do need to be put in
> place before further significant further work is performed.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 7 Jan 2010 16:10:47 -0600

Hadriel,

Thanks for putting this document forward.

Spencer

----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: "DRAGE, Keith (Keith)" <[email-masked]>; <[email-masked]>
Sent: Thursday, January 07, 2010 1:09 PM
Subject: Re: [martini] Comments on draft-kaplan-martini-mixing-problems-00

> A call went out asking for drafts on "Discussions of currently deployed 
> mechanisms for multiple AOR registration, and their pros and cons."  And 
> that's basically what I tried to write up, though more as a problems list.
>
> -hadriel
>