Subject: [martini] Questions about draft-kaplan-martini-with-olive

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 11 Apr 2010 01:46:33 -0700

Section 3.2.1

   One of the initial benefits cited for only supporting E.164 is that
   an E.164 user name is globally unique by itself, and thus changing
   the host portion of the Request-URI does not impact the identity of
   the intended target of the Request.

[BA] Is the issue really the global uniqueness of the AOR or the global
uniqueness of the

user portion?   Using single AOR registration, it's possible to cause a
Request-URI of 

"[email-masked]" to be mapped to a contact of "[email-masked]".   

To make sure this is ok, it's not enough just to authenticate the REGISTER;
the 

SSP also needs to check that the mapping is authorized (e.g. the PBX 

sending the registration really is authorized to utilize pbx.example.com as
a contact domain).  

In the case of multiple AOR registration, presumably the SSP has
pre-provisioned a list of AORs 

that may be implicitly registered, and the same authorization checks would
apply to the contact 

domain.    So while multiple AOR registration may not make this usage case
more problematic,

using a globally unique user portion (e.g. E.164 number) makes the
authorization check less

necessary.  

Section 3.2.2

   For example, if the IP-PBX has multiple SSPs it Registers
   into, it can't just receive a request to
   "sip:[email-masked]", because it won't know if that's to
   "sip:[email-masked]" or "sip:[email-masked]", which may
   be different users.
 
[BA] Presumably, this paragraph is describing the problem created by having 
multiple SSPs map different Request-URIs (e.g. [email-masked], 
[email-masked]) to the same registered contact
([email-masked]),
right?
 
While I understand the potential issues raised by this, a question that this

(and other examples) raise for me, is the extent to which the issues are
unique 
to multiple AOR registration.  For example, it's possible to use multiple
single AOR registrations to bind multiple AORs to the same contact, causing
the same problem.  Given that, is this issue really intrinsic to multiple
AOR registration?  Or is it speaking to the problems created by having a
single
contact (created implicitly or explicitly) map to multiple Request-URIs?

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 11 Apr 2010 11:57:01 -0400

Hey Bernard,
Comments inline...

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Sunday, April 11, 2010 4:47 AM
To: [email-masked]
Subject: [martini] Questions about draft-kaplan-martini-with-olive

Section 3.2.1

[BA] Is the issue really the global uniqueness of the AOR or the global uniqueness of the
user portion?   Using single AOR registration, it's possible to cause a Request-URI of
"[email-masked]" to be mapped to a contact of "[email-masked]".
To make sure this is ok, it's not enough just to authenticate the REGISTER;  the
SSP also needs to check that the mapping is authorized (e.g. the PBX
sending the registration really is authorized to utilize pbx.example.com as a contact domain).

[hsk] As far as I know, there is no authorization checking for single Registrations which does not also occur in, or apply to, [draft-gin] bulk Registrations.

[BA] In the case of multiple AOR registration, presumably the SSP has pre-provisioned a list of AORs
that may be implicitly registered, and the same authorization checks would apply to the contact
domain.    So while multiple AOR registration may not make this usage case more problematic,
using a globally unique user portion (e.g. E.164 number) makes the authorization check less
necessary.

[hsk] How is it any less necessary?  We were ok with E.164 because the SSP was as authoritative as could be for that identity - well who's more authoritative for the AoR "sip:[email-masked]" than ssp.com??

[hsk] The point of draft-olive is to say: instead of Registering separately for "[email-masked]" and "[email-masked]", use the [draft-gin] bulk registration to do it in one Registration.  Those AoR's are both of ssp.com, and it is wholly authoritative for them.  Whatever policy decisions the SSP makes about the individual Registrations would necessarily be the same that it makes for the bulk Registration.

Section 3.2.2

   be different users.

[email-masked]) to the same registered contact ([email-masked]),

right?

[hsk] yup.

(and other examples) raise for me, is the extent to which the issues are unique

AOR registration?  Or is it speaking to the problems created by having a single

[hsk] The same issue arises for single AoR Registrations, but it was raised as an issue for bulk Registrations previously.  I believe the concern was that with single Registrations the Registered Contact URI usually has a user portion, and it's often unique per single Registration, so people were thinking that without a user portion they couldn't make it unique.  So I put this discussion into the draft to point out that (1) it's a property of the Contact that needs to be unique, not the AoR, and (2) we can still have the Contact be unique because the PBX can just put in a unique Contact URI param per bulk REGISTER.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 11 Apr 2010 13:24:33 -0400

BTW, I sent this in HTML format because my email client (made by some big company near Seattle) can't cleanly convert from HTML to plain text with the ">" indentation thing if the original email started as HTML, and I got tired of doing it by hand.  It does the below instead.

-hadriel

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Sunday, April 11, 2010 11:57 AM
To: Bernard Aboba; [email-masked]
Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive

Hey Bernard,
Comments inline.

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Sunday, April 11, 2010 4:47 AM
To: [email-masked]
Subject: [martini] Questions about draft-kaplan-martini-with-olive

Section 3.2.1

Section 3.2.2

[hsk] yup.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 12 Apr 2010 08:41:40 -0500

Just to follow along with Hadriel's note below...

All of the mail readers I use (Outlook and Outlook Express) allow you to set 
"send plain text only" for each userid in the address book, so you can (and 
I do) normally send HTML, but have your mailer do the check and prompt you 
to convert if you forget to "format as plain text" something that's going to 
an IETF mailing list.

We have a strong preference for plain text in the IETF (when I started 
attending, some area directors did not accept e-mail that wasn't plaintext), 
and my own preference (as working group chair) is that it's a lot easier to 
make sure I'm following a thread if I can easily find the text that's not 
prefixed, rather than trying to figure out which color is who, where the 
"[SD]" blocks actually end, etc.

Please set [email-masked] up for plain text in your address books - it 
will make losing your valuable comments less likely!

Thank you,

Spencer, as co-chair

----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, April 11, 2010 12:24 PM
Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive

BTW, I sent this in HTML format because my email client (made by some big 
company near Seattle) can't cleanly convert from HTML to plain text with the 
">" indentation thing if the original email started as HTML, and I got tired 
of doing it by hand.  It does the below instead.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Apr 2010 10:37:06 -0400

I think I'm the source of the original complaint on this.
I use Thunderbird for mail. It can do both HTML and plain text mail and 
convert between them. I read all the html mail in html format, but have 
set up to always reply in text format.

I don't fully understand what it is that results in some html mail being 
nicely readable while some other html mail is difficult to follow. In 
the nice cases there is color coding but also bars in the margin 
corresponding to the "> " indenting of replies in friendly text mail.

But in some other cases there is no indenting, no bars, just color 
coding and people's initials run into the text. And sometimes not even 
initials - just the color coding.

While I find the text that has initials hard to read after a few 
replies, I never complain about it because it is a personal preference 
item and I can live with it.

Where I complained was when the only distinction I could see was between 
black text and blue text (that doesn't look very much different than 
black to me.)

My main concern is that replies be formatted in such a way that its 
reasonably feasible to figure out who said what in response to what 
after there have been multiple replies. If that can be achieved with 
html mail, then fine. But I think I will continue to reply in plaintext 
until I see a better alternative.

	Sorry to have been a pain,
	Paul

Spencer Dawkins wrote:
> All of the mail readers I use (Outlook and Outlook Express) allow you to 
> set "send plain text only" for each userid in the address book, so you 
> can (and I do) normally send HTML, but have your mailer do the check and 
> prompt you to convert if you forget to "format as plain text" something 
> that's going to an IETF mailing list.
> 
> attending, some area directors did not accept e-mail that wasn't 
> plaintext), and my own preference (as working group chair) is that it's 
> a lot easier to make sure I'm following a thread if I can easily find 
> the text that's not prefixed, rather than trying to figure out which 
> color is who, where the "[SD]" blocks actually end, etc.
> 
> ----- Original Message ----- From: "Hadriel Kaplan" 
> <[email-masked]>
> To: <[email-masked]>
> BTW, I sent this in HTML format because my email client (made by some 
> big company near Seattle) can't cleanly convert from HTML to plain text 
> with the ">" indentation thing if the original email started as HTML, 
> and I got tired of doing it by hand.  It does the below instead.
> 
> -hadriel
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 12 Apr 2010 14:20:49 -0500

Hi, Paul,

I didn't mean to pick on a particular person - only to ask people to keep an 
eye on this.

Thanks for your help with major technical topics AND with with administrivia 
like mail formats!

Spencer

> nicely readable while some other html mail is difficult to follow. In the 
> nice cases there is color coding but also bars in the margin corresponding 
> to the "> " indenting of replies in friendly text mail.
>
> But in some other cases there is no indenting, no bars, just color coding 
> and people's initials run into the text. And sometimes not even initials - 
> just the color coding.
>
> While I find the text that has initials hard to read after a few replies, 
> I never complain about it because it is a personal preference item and I 
> can live with it.
>
> black text and blue text (that doesn't look very much different than black 
> to me.)
>
> reasonably feasible to figure out who said what in response to what after 
> there have been multiple replies. If that can be achieved with html mail, 
> then fine. But I think I will continue to reply in plaintext until I see a 
> better alternative.
>
>> plaintext), and my own preference (as working group chair) is that it's a 
>> lot easier to make sure I'm following a thread if I can easily find the 
>> text that's not prefixed, rather than trying to figure out which color is 
>> who, where the "[SD]" blocks actually end, etc.
>>
>> company near Seattle) can't cleanly convert from HTML to plain text with 
>> the ">" indentation thing if the original email started as HTML, and I 
>> got tired of doing it by hand.  It does the below instead.
>>
>> -hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 13 Apr 2010 00:13:52 +0200

On Sun, Apr 11, 2010 at 10:46 AM, Bernard Aboba
<[email-masked]>wrote:

>    "sip:[email-masked] <[email-masked]>", because it won't know if that's to
>
>    "sip:[email-masked] <[email-masked]>" or "sip:[email-masked] <[email-masked]>", which may
>
>    be different users.
>
>
>
[HE] Yes it is the same and no it is not the same.
A UE like a phone that can receive calls for  different AOR's of the same
user can get the target delivered in the P-Called-Party-Identity like is
done in IMS or it could use the History-Info as described in the 4244bis.
This target info is merely used for presentation purposes.

A PBX on the other hand that uses bulkregistration is not the last entity,
but has to deliver the incoming call to the end user device. This enduser
device's user may also deliver calls for multiple AOR's of the same user.
P-Called-Party-Identity does not work there anymore as it will be either
overwritten with a contact address or there will be two
P-Called-Party-Identy values, if the PBX also implements that mechanism.
(not sure if this case is defined at all) Also here the History-Info from
4244bis could be used, but it requires traversal of some more History-Info
entries to find the target information.

One of the observation of the ua-loose-route/target-uri discussion was that
it is actually a design flaw in SIP that Request-URI is rewritten for
routing. There are means to alleviate the consequences when it happens on
the last hop. But it is certainly not a good idea to start introducing a
mechanism that forces such behaviour on intermediary hops (between the SSP
and the PBX). This discussion is a symptom of forcing Request-URI rewrites
to be used for routing over the SIP trunk.

/Hans Erik

---

From: Dean Willis <[email-masked]>
Date: Mon, 12 Apr 2010 22:54:13 -0400

"Hans Erik van Elburg" <[email-masked]> wrote:
>to be used for routing over the SIP 

Very true. But this particularly abhorrent element of SIP is encoded directly in the DNA of the REGISTER method. Fixing it right requires either resequencing said DNA into SIP 3.0 or using a request-method that is not REGISTER. 

Pick one.

-- 
Dean Willis

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Apr 2010 23:36:59 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dean Willis
> 
> Very true. But this particularly abhorrent element of SIP is encoded
> directly in the DNA of the REGISTER method. Fixing it right requires
> either resequencing said DNA into SIP 3.0 or using a request-method that
> is not REGISTER.
> Pick one.

I don't buy that.  It doesn't matter if the request was named REGISTER or PUBLISH or FOOBAR.  The language for routing in 3261 is loose enough to drive a Mac truck through, and any extension can extend/apply-to any method including REGISTER.  Heck, we could have defined a mime body for REGISTER if we wanted to. 

But you're not going to get me to go back in time to rehash those arguments again... no really you won't...
:)

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Tue, 13 Apr 2010 00:08:16 -0400

"Hadriel Kaplan" <[email-masked]> wrote:
>But you're not ygoing to get me to go back in time to rehash those arguments again... no really you won't...
>:)

No, Hadriel. You cannot borrow the DeLorean tonight.  I am using it to revisit my before-SIP 30's. Back when I actually thought I knew something important.

-- 
Dean Willis

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 13 Apr 2010 00:16:11 -0400

I'm not so sure that request-URI re-writing is actually a design flaw for this case.
Ultimately, there really is a problem with leaving the Request-URI "alone" when it goes from one authoritative domain to another.  

Think about it - how could we really expect that the original full URI for domain foo.com has any meaning to domain bar.com?   Just re-writing the domain portion doesn't suddenly make it understandable to bar.com.  Simple things like URI user-params may (and in fact do in practice) mean different things to foo.com than they do to bar.com.

For example, the "rn", "cic", and "tgrp" TEL URI params (SIP URI user params) are quite popular.  These are essentially only understandable to the SSP(s) - that's completely legitimate, because the URI is of the SSP.  Would you *really* expect to pass those on untouched in the Request-URI to a SIP UA, or IP-PBX?

-hadriel

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
Sent: Monday, April 12, 2010 6:14 PM

One of the observation of the ua-loose-route/target-uri discussion was that it is actually a design flaw in SIP that Request-URI is rewritten for routing. There are means to alleviate the consequences when it happens on the last hop. But it is certainly not a good idea to start introducing a mechanism that forces such behaviour on intermediary hops (between the SSP and the PBX). This discussion is a symptom of forcing Request-URI rewrites to be used for routing over the SIP trunk.
 
/Hans Erik

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 13 Apr 2010 09:33:37 +0200

REGISTER with bnc option tag did not exist before. We are actually
defining that mechanism...

/Hans Erik van Elburg

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 13 Apr 2010 09:37:53 +0200

> Ultimately, there really is a problem with leaving the Request-URI "alone" when it goes from one authoritative domain to another.
[HE] Agree. But that is something else then choosing a mechanims that
forces you in ALL case to do such rewrite.

> For example, the "rn", "cic", and "tgrp" TEL URI params (SIP URI user params) are quite popular.  These are essentially only understandable to the SSP(s) - that's completely legitimate, because the…
[HE] Yeah, but we are not specifying a solution based on those or? I
agree you want might want to strip them of. That is still something
else then choosing a solution that forces you in ALL situations to
perform rewrites.

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 13 Apr 2010 12:33:08 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
> Sent: 12 April 2010 23:14
> To: Bernard Aboba
> Cc: [email-masked]
> <[email-masked]> wrote:
> 
> 
> 	   "sip:[email-masked] 
> <mailto:[email-masked]> ", because it won't 
> know if that's to
> 	   "sip:[email-masked] 
> <mailto:[email-masked]> " or 
> "sip:[email-masked] <mailto:[email-masked]> 
> ", which may
> 	   be different users.
> 	 
> A UE like a phone that can receive calls for  different AOR's 
> of the same user can get the target delivered in the 
> P-Called-Party-Identity like is done in IMS or it could use 
> the History-Info as described in the 4244bis. This target 
> info is merely used for presentation purposes.
[JRE] In my experience, a UA behind a PBX is far more likely to register each AOR separately, with a separate contact URI for each, so there is no ambiguity when an inbound request arrives (no need for P-Called-Party-ID, no need for History-Info).

> 
> A PBX on the other hand that uses bulkregistration is not the 
> last entity, but has to deliver the incoming call to the end 
> user device. This enduser device's user may also deliver 
> calls for multiple AOR's of the same user. 
> P-Called-Party-Identity does not work there anymore as it 
> will be either overwritten with a contact address or there 
> will be two P-Called-Party-Identy values, if the PBX also 
> implements that mechanism. (not sure if this case is defined 
> at all) Also here the History-Info from 4244bis could be 
> used, but it requires traversal of some more History-Info 
[JRE] I don't see the problem. As part of bulk registration according to gin, the PBX will register all AORs on all its UAs with the SSP, registering separate contact URIs for each. Therefore, when an inbound request arrives, the PBX knows what AOR is targeted. It can then go to its own location service and find the appropriate contact URI for routing to the UA. It all seems to work just fine, and very much in line with current practice.

John

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 13 Apr 2010 12:47:14 +0200

> [JRE] In my experience, a UA behind a PBX is far more likely to register each AOR separately, with a separate contact URI for each, so there is no ambiguity when an inbound request arrives (no need…
[HE] Yes likely, but not guaranteed. Especially if a PBX supports its
own variant of implicit registration. We can't base a specification on
likely behavior.

> [JRE] I don't see the problem. As part of bulk registration according to gin, the PBX will register all AORs on all its UAs with the SSP, registering separate contact URIs for each.
[HE] You can not conclude that, that would enforce a company to make
all its numbers used internally externally exposed DIDs.

[JRE] Therefore, when an inbound request arrives, the PBX knows what
AOR is targeted. It can then go to its own location service and find
the appropriate contact URI for routing to the UA. It all seems to
work just fine, and very much in line with current practice.
[HE] Which current practice?? There is no uniform current practice,
otherwise there would not be this frenzy martini discussion.

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 13 Apr 2010 13:07:23 +0200

> From: Hans Erik van Elburg [mailto:[email-masked]] 
> Sent: 13 April 2010 11:47
> To: Elwell, John
> Cc: Bernard Aboba; [email-masked]
> > [JRE] In my experience, a UA behind a PBX is far more 
> likely to register each AOR separately, with a separate 
> contact URI for each, so there is no ambiguity when an 
> inbound request arrives (no need for P-Called-Party-ID, no 
> need for History-Info).
JRE] In any case, that is an issue for the PBX to solve, not MARTINI. I am just stating what, in my limited experience, is common practice.

> > [JRE] I don't see the problem. As part of bulk registration 
> according to gin, the PBX will register all AORs on all its 
> UAs with the SSP, registering separate contact URIs for each.
[JRE] You are correct that there might be some AORs that are not DIDs, so are not directly reachable from an SSP (only via some sort of human or automated attendant service), but this is outside the scope of MARTINI, surely?

> otherwise there would not be this frenzy martini discussion.
[JRE] Current practice certainly varies in detail - that is the reason for MARTINI. But the principles are the same - information in the inbound request to the PBX identifies the target AOR somehow, and that is used by the PBX to query its location service for onward routing to a UA.

John

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 13 Apr 2010 13:16:36 +0200

> JRE] In any case, that is an issue for the PBX to solve, not MARTINI. I am just stating what, in my limited experience, is common practice.
[HE] Disagree. Your making unjustified assumptions.

> [JRE] You are correct that there might be some AORs that are not DIDs, so are not directly reachable from an SSP (only via some sort of human or automated attendant service), but this is outside th…
[HE] It is in so far relevant if the mechanism chosen by martini, will
have impact on such deployments.

> [JRE] Current practice certainly varies in detail - that is the reason for MARTINI. But the principles are the same - information in the inbound request to the PBX identifies the target AOR somehow…
[HE] Somehow ;-)

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 13 Apr 2010 14:42:44 +0200

> Sent: 13 April 2010 12:17
> To: Elwell, John
> > JRE] In any case, that is an issue for the PBX to solve, 
> not MARTINI. I am just stating what, in my limited 
> experience, is common practice.
[JRE] I fail to understand why, provided MARTINI delivers information that allows the PBX to identify the target AOR, onward handling of this within the PBX should be an issue for MARTINI.

> > [JRE] You are correct that there might be some AORs that 
> are not DIDs, so are not directly reachable from an SSP (only 
> via some sort of human or automated attendant service), but 
> this is outside the scope of MARTINI, surely?
[JRE] Again, provided MARTINI delivers information that allows the PBX to identify the target AOR, which in this case would be that of an attendant function, what else does it need to do? Delivery of additional information for identifying the target beyond the attendant function has to be conducted by some other means that is unrelated to the method by which MARTINI delivers the request to the attendant function, e.g., it might be done in the media stream, by an INFO application, by something along the lines of draft-johnston-dispatch-sip-cc-uui, etc.. Outside scope of MARTINI.

> 
> > [JRE] Current practice certainly varies in detail - that is 
> the reason for MARTINI. But the principles are the same - 
> information in the inbound request to the PBX identifies the 
> target AOR somehow, and that is used by the PBX to query its 
> location service for onward routing to a UA.
> [HE] Somehow ;-)
[JRE] Yes - the gin draft is one suitable mechanism.

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 13 Apr 2010 12:27:01 -0400

I think there's confusion about what the problem is, because people keep raising issues which do not appear to be germane to the problem [draft-gin] addresses.

The goal of SIP-Forum's SIP-Connect 1.1 which instigated this was to support IP-PBX's in the SMB market.  That market has some rather strict demands in terms of interoperability out-of-the-box, without separate/unique per-PBX "rules" in the SSP, without a lot of config on the PBX itself, and with a high expectation of things working without operator NOC/install folks having to handle each new IP-PBX customer with the same level of attention/effort as they would a big customer or peering partner.

Say what you will about 3GPP, ETSI, or IETF models - but at the end of the day most peering and IP-PBX deployments today in any/all of those models require a high degree of per-PBX configuration and customization to deploy.  That may be fine for those situations, because it's cost-justified, but for SMB deployments it's not.

So [draft-gin] is meant to address that, by specifying what a PBX sending a REGISTER using the option-tags will minimally expect and accept.

It does NOT restrict you from doing other things.  All [draft-gin] does is provide a guarantee that if the PBX sent the options-tag, that it is doing a bulk Register and will accept requests for the AoR's of the bulk Register to the expanded contacts.  Of course the PBX may accept requests for other URI's, but we can't possibly specify the form of all its possible URI's, nor how they would be transformed from the SSP's URI in a programmatic/consistent fashion in every possible case.

NOTHING else is made "illegal" by [draft-gin] - it just isn't covered by [draft-gin], and relies on local policy instead, and thus goes back to per-PBX config/customization/rules.  And it does NOT mean you can't use a [draft-gin] REGISTER to do other things.  It just isn't covered by the draft, so there's no guarantee the PBX will accept or understand your request.

The question is really: does [draft-gin] cover the 95% use-case, or not? 

-hadriel

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 13 Apr 2010 18:29:37 +0200

If we are only doing this work for the "SIP-Forum" market place, then I shall make an immediate request to close the working group down.

Keith 

> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: Tuesday, April 13, 2010 5:27 PM
> To: [email-masked]
> Subject: [martini] The Problem we're trying to solve (was 
> Questions about draft-kaplan-martini-with-olive)
> 
> 
> I think there's confusion about what the problem is, because 
> people keep raising issues which do not appear to be germane 
> to the problem [draft-gin] addresses.
> 
> The goal of SIP-Forum's SIP-Connect 1.1 which instigated this 
> was to support IP-PBX's in the SMB market.  That market has 
> some rather strict demands in terms of interoperability 
> out-of-the-box, without separate/unique per-PBX "rules" in 
> the SSP, without a lot of config on the PBX itself, and with 
> a high expectation of things working without operator 
> NOC/install folks having to handle each new IP-PBX customer 
> with the same level of attention/effort as they would a big 
> customer or peering partner.
> 
> Say what you will about 3GPP, ETSI, or IETF models - but at 
> the end of the day most peering and IP-PBX deployments today 
> in any/all of those models require a high degree of per-PBX 
> configuration and customization to deploy.  That may be fine 
> for those situations, because it's cost-justified, but for 
> SMB deployments it's not.
> 
> So [draft-gin] is meant to address that, by specifying what a 
> PBX sending a REGISTER using the option-tags will minimally 
> expect and accept.
> 
> It does NOT restrict you from doing other things.  All 
> [draft-gin] does is provide a guarantee that if the PBX sent 
> the options-tag, that it is doing a bulk Register and will 
> accept requests for the AoR's of the bulk Register to the 
> expanded contacts.  Of course the PBX may accept requests for 
> other URI's, but we can't possibly specify the form of all 
> its possible URI's, nor how they would be transformed from 
> the SSP's URI in a programmatic/consistent fashion in every 
> possible case.
> 
> NOTHING else is made "illegal" by [draft-gin] - it just isn't 
> covered by [draft-gin], and relies on local policy instead, 
> and thus goes back to per-PBX config/customization/rules.  
> And it does NOT mean you can't use a [draft-gin] REGISTER to 
> do other things.  It just isn't covered by the draft, so 
> there's no guarantee the PBX will accept or understand your request.
>

---

From: <[email-masked]>
Date: Tue, 13 Apr 2010 18:35:28 +0200

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Hadriel Kaplan
> Envoyé : mardi 13 avril 2010 18:27
> À : [email-masked]
> Objet : [martini] The Problem we're trying to solve (was 

==BC: If you think that 95% of the use cases will not be IMS-based and will use E.164 numbers only, the answer is probably yes. But I don't share the same view.

---

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Tue, 13 Apr 2010 12:40:37 -0400

I support Bruno's point of view, in that the % of IMS-based deployments would be higher.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 13 Apr 2010 12:53:34 -0400

> Of Hans Erik van Elburg
> Sent: Tuesday, April 13, 2010 3:38 AM
> 
> > Ultimately, there really is a problem with leaving the Request-URI
> "alone" when it goes from one authoritative domain to another.

It does NOT "force you in all cases to do a rewrite".  It can't force you to, because you can simply ignore it.  And I don't just mean you can ignore the draft - I mean RFC 3261 allows you to do whatever you want, in section 16.5:
   ... this implies that the element is responsible for the
   domain in the Request-URI, and the element MAY use whatever mechanism
   it desires to determine where to send the request.  Any of these
   mechanisms can be modeled as accessing an abstract Location Service.
   This may consist of obtaining information from a location service
   created by a SIP Registrar, reading a database, consulting a presence
   server, utilizing other protocols, or simply performing an
   algorithmic substitution on the Request-URI.  

So let's say you received a request for "sip:123456;foo=[email-masked];bar=no" and decided that you needed to send to the IP-PBX a URI of:
"sip:123456;foo=[email-masked];bar=no", but you wanted to use the Path info and Contact URI learned from the [draft-gin] REGISTER.  You can do that.  The original AoR URI is the SSP's, and thus it can do whatever it wants to it.  You can, for example, simply claim to have a static local policy to do it, which by *sheer coincidence* happens to have pre-loaded Route headers matching the same URI's of the REGISTER Paths and Contact.

As a side note, from a logical perspective you are NOT "just changing the domain portion", you are actually retargeting the request to a new URI, which you just happened to have constructed based on an algorithm of the original URI.

Will it work??  Well that's the rub.  How do you know the PBX knows what the "foo" and "bar" params mean, or what their values mean?   You need to know what URI syntax and semantics the PBX expects to get - essentially you need to agree on the "algorithm".  Today, that "algorithm" is done by per-trunk configuration on both sides.  That's fine for big trunks.  Not so good for 5-line pizza shops.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 13 Apr 2010 13:00:03 -0400

Of course, and so do I.  I meant more that "does handling E.164 cover 95% of the use-cases?"

My hope is that 3GPP will consider Martini's output and adopt it as well.  It already supports 2 modes for PBX trunking today: loose-route and req-uri-replacement.  This would be a third, but the nice thing is this third mode is really just what you do for basic subscribers, and really similar to the req-uri-replacement mode you already support now.

-hadriel

> Of DOLLY, MARTIN C (ATTLABS)
> Sent: Tuesday, April 13, 2010 12:41 PM
> 
> ==BC: If you think that 95% of the use cases will not be IMS-based and
> will use E.164 numbers only, the answer is probably yes. But I don't share
> the same view.
> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 13 Apr 2010 13:02:32 -0400

> Of DRAGE, Keith (Keith)
> Sent: Tuesday, April 13, 2010 12:30 PM
> To: Hadriel Kaplan; [email-masked]
> 
> If we are only doing this work for the "SIP-Forum" market place, then I
> shall make an immediate request to close the working group down.
 
No, you know that's not what I meant.  

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 13 Apr 2010 20:28:53 +0200

How does it help that I can  ignore it? It would require the PBX to be
able to signal that it wants the Registrar (location service) to
return a no-op and at the same time have its Contact address added to
the Route. (Utilizing 16.6 step 2 and step 6).

/Hans Erik van Elburg

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 13 Apr 2010 20:38:42 +0200

> I think there's confusion about what the problem is, because people keep raising issues which do not appear to be germane to the problem [draft-gin] addresses.

Don't think there is confusion really, there is disagreement ;-)

> Say what you will about 3GPP, ETSI, or IETF models - but at the end of the day most peering and IP-PBX deployments today in any/all of those models require a high degree of per-PBX configuration an…

That is not fine for those situations. Subscription based business
trunking is exactly targeting that segment. Similar motivations as are
listed in martini for using registration etc.

/Hans Erik

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 13 Apr 2010 20:39:16 +0200

+1

/Hans Erik van Elburg

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 13 Apr 2010 16:32:11 -0400

OK Keith please. I deeply respect your opinion here and am very concerned
about the local number issues since it represents a profound difference in
how some jurisdictions deal with E.164 number allocations. North America is
increasingly DID numbering centric. But there are clear operational support
issues and OPEX issues for SSP's supporting large enterprises vs SMB and the
proposed MARTINI framework is trying to recognize this. It is also trying
desperately address short term problems in the field while understand there
may be long term solutions here. If we could bifurcate the option tag to if
you see this do "foo" if you see that do "bar" we'd be a lot closer to
consensus here.  The lack of a clear option tag is endemic to the issues
with the IMS solution vs what the SIP Forum has proposed. What some of us
are convinced of there is not a "one size fits all solution".

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of DRAGE, Keith (Keith)
Sent: Tuesday, April 13, 2010 12:30 PM
To: Hadriel Kaplan; [email-masked]
Subject: Re: [martini] The Problem we're trying to solve (was Questions
about draft-kaplan-martini-with-olive)

Keith

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 13 Apr 2010 16:46:32 -0400

Hadriel is right here ..the whole justification for the SIP Connect
investigation of this problem was to simplify the process of registering
PBX's in the SMB market which IMHO is the fastest growing segment of the SIP
trunking business. We saw the problem we knew a option tag was necessary.
All of the participants in the SIP Connect process are full paid up members
of the RAI club. 

Look guys we have to start thinking about making SIP simpler to deploy.
Whether its PBX's or CUA's for the residential markets etc it needs to work
better than our current SIP architecture is designed for.  Maybe a little
duct tape and bailing wire is necessary in the short term. But truth be told
..if we don’t start addressing simplicity in operational deployment of SIP
our common friends at Skype and Google are just going to pick us all off at
the economic margins. 

Turning this into a SIP Forum vs IMS/ETSI cage match is not helping. Skype
will be laughing all the way to a very profitable IPO. 

Yes this was targeted as a E.164 centric solution since DUH that’s what
people use. Yes gin will address at least 90% of the issues noted in the
field.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hans Erik van Elburg
Sent: Tuesday, April 13, 2010 2:39 PM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [martini] The Problem we're trying to solve (was Questions
about draft-kaplan-martini-with-olive)

On Tue, Apr 13, 2010 at 6:27 PM, Hadriel Kaplan <[email-masked]>
wrote:
>
> I think there's confusion about what the problem is, because people keep
raising issues which do not appear to be germane to the problem [draft-gin]
addresses.

> Say what you will about 3GPP, ETSI, or IETF models - but at the end of the
day most peering and IP-PBX deployments today in any/all of those models
require a high degree of per-PBX configuration and customization to deploy.
 That may be fine for those situations, because it's cost-justified, but for
SMB deployments it's not.

/Hans Erik

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 13 Apr 2010 23:18:59 +0200

On Tue, Apr 13, 2010 at 10:46 PM, Richard Shockey <[email-masked]> wrote:

> Turning this into a SIP Forum vs IMS/ETSI cage match is not helping.
>
Agree very much with that, so lets cooperate and create clarity in the market.

/Hans Erik

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 13 Apr 2010 16:45:18 -0500

Speaking as chair,

> Agree very much with that, so lets cooperate and create clarity in the 

That would be awesome :D

Thanks,

Spencer, as chair

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 13 Apr 2010 21:56:08 -0400

> Sent: Tuesday, April 13, 2010 2:29 PM
> 

Can I ask why do you need to?  By that I mean why do you need to leave the req-uri alone and insert a Contact as a Route header?  What's the problem you are solving that [draft-gin] doesn't solve for you?  'Cause I think the answer to that may change the answer to your question.

I can think of several reasons, but none for simple SMB IP-PBX's.  But it could easily be I'm missing something that seems obvious to you. 

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Apr 2010 07:27:43 +0200

+1

Regards,

Christer 

> Sent: 13. huhtikuuta 2010 21:39
> To: DOLLY, MARTIN C (ATTLABS)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [martini] The Problem we're trying to solve (was 
> Questionsabout draft-kaplan-martini-with-olive)
> 
> +1
> 
> /Hans Erik van Elburg
> 
> 
> 
> >> [mailto:[email-masked]] De la part de Hadriel 
> Kaplan Envoyé 
> >> : mardi 13 avril 2010 18:27 À : [email-masked] Objet : [martini] 
> >> The Problem we're trying to solve (was Questions about 
> >> draft-kaplan-martini-with-olive)
> >>
> >>
> >> I think there's confusion about what the problem is, 
> because people 
> >> keep raising issues which do not appear to be germane to 
> the problem 
> >> [draft-gin] addresses.
> >>
> >> The goal of SIP-Forum's SIP-Connect 1.1 which instigated 
> this was to 
> >> support IP-PBX's in the SMB market.  That market has some rather 
> >> strict demands in terms of interoperability 
> out-of-the-box, without 
> >> separate/unique per-PBX "rules" in the SSP, without a lot 
> of config 
> >> on the PBX itself, and with a high expectation of things working 
> >> without operator NOC/install folks having to handle each 
> new IP-PBX 
> >> customer with the same level of attention/effort as they 
> would a big 
> >> Say what you will about 3GPP, ETSI, or IETF models - but 
> at the end 
> >> of the day most peering and IP-PBX deployments today in any/all of 
> >> those models require a high degree of per-PBX configuration and 
> >> customization to deploy.  That may be fine for those situations, 
> >> because it's cost-justified, but for SMB deployments it's not.
> >>
> >> So [draft-gin] is meant to address that, by specifying what a PBX 
> >> sending a REGISTER using the option-tags will minimally expect and 
> >> accept.
> >>
> >> It does NOT restrict you from doing other things.  All [draft-gin] 
> >> does is provide a guarantee that if the PBX sent the options-tag, 
> >> that it is doing a bulk Register and will accept requests for the 
> >> AoR's of the bulk Register to the expanded contacts.  Of 
> course the 
> >> PBX may accept requests for other URI's, but we can't possibly 
> >> specify the form of all its possible URI's, nor how they would be 
> >> transformed from the SSP's URI in a 
> programmatic/consistent fashion 
> >> in every possible case.
> >>
> >> NOTHING else is made "illegal" by [draft-gin] - it just 
> isn't covered 
> >> by [draft-gin], and relies on local policy instead, and thus goes 
> >> back to per-PBX config/customization/rules.
> >> And it does NOT mean you can't use a [draft-gin] REGISTER 
> to do other 
> >> things.  It just isn't covered by the draft, so there's no 
> guarantee 
> >> the PBX will accept or understand your request.
> >>
> >> The question is really: does [draft-gin] cover the 95% 
> use-case, or 
> >> not?
> >
> > ==BC: If you think that 95% of the use cases will not be 
> IMS-based and will use E.164 numbers only, the answer is 
> probably yes. But I don't share the same view.
> >>
> >> -hadriel
> >>