Subject: Re: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions)

From: Dean Willis <[email-masked]>
Date: Sun, 04 Apr 2010 12:04:13 -0500

Are you saying that the IMS solution is what the service providers need?

"DOLLY, MARTIN C (ATTLABS)" <[email-masked]> wrote:

>Speaking as a Service Provider, the solution being produced by Martini
>does not address what is needed for current to mid-term deployments, and
>creates interoperability problems in the long haul .

-- 
Dean Willis

---

From: "Richard Shockey" <[email-masked]>
Date: Sun, 4 Apr 2010 13:32:05 -0400

The IMS solution could certainly work for large scale enterprise deployments served by ATT and massive PTT's but is ineffectual and cost prohibitive for small and medium business served typically by CLEC's. That's the whole business and technical model behind implicit registration SMB's and competition.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Sunday, April 04, 2010 1:04 PM
To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; [email-masked]
Subject: Re: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions)

"DOLLY, MARTIN C (ATTLABS)" <[email-masked]> wrote:

>does not address what is needed for current to mid-term deployments, 
>and creates interoperability problems in the long haul .

--
Dean Willis

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Apr 2010 12:56:25 +0200

Hi,

>registration SMB's and competition.

As far as I know, you could use the IMS solution without implicit registrations. You could use the forward-whatever-you-get model of GIN (which in my opinion could be claimed to be an implicit registration by itself).

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Sunday, April 04, 2010 1:04 PM
To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; [email-masked]
Subject: Re: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions)

--
Dean Willis

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

---

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

There is low cost IMS deployments to... this is a non-argument. There is
even open source IMS implementations available and some companies are
building solutions based on that just for the kind of parties that you was
referring to. Also CLEC's have business needs that go beyond the SIP
routing, in fact they want to manage their service and earn money.

/Hans Erik van Elburg

On Sun, Apr 4, 2010 at 7:32 PM, Richard Shockey <[email-masked]> wrote:

> The IMS solution could certainly work for large scale enterprise
> deployments served by ATT and massive PTT's but is ineffectual and cost
> prohibitive for small and medium business served typically by CLEC's. That's
> the whole business and technical model behind implicit registration SMB's
> and competition.
>
>

---

From: "Jack Burton" <[email-masked]>
Date: Mon, 05 Apr 2010 09:04:10 -0400

Speaking as another service provider, I agree with Richard.
 
-Jack

>>> "Richard Shockey" <[email-masked]> 4/4/2010 13:32 >>>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Sunday, April 04, 2010 1:04 PM
To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; [email-masked] 
Subject: Re: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions)

--
Dean Willis

-------------------------------------------------------- 
The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain information concerning Cablevision and/or its affiliates and subsidiaries that is proprietary, privileged, confidential and/or subject to copyright.   Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited and may be unlawful.  If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof.
--------------------------------------------------------

---

From: <[email-masked]>
Date: Tue, 6 Apr 2010 10:22:45 +0200

I don't know what Martin was saying but I agree that the GIN solution creates additional interoperability problems, simply because this is yet another solution... Instead of having a single target (i.e. the so-called IMS solution) to converge to, PBX vendors will have two alternative targets in front of them: the IMS solution and the GIN solution.

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Dean Willis
> Envoyé : dimanche 4 avril 2010 19:04
> À : DOLLY, MARTIN C (ATTLABS); Bernard Aboba; [email-masked]
> Objet : Re: [martini] The IETF versus reality (was: problems 
> withexisting SIP trunking solutions)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Apr 2010 09:05:30 -0400

> I don't know what Martin was saying but I agree that the GIN solution creates additional interoperability problems, simply because this is yet another solution... Instead of having a single target…

That's a fine answer if what you have implemented is the "IMS solution".
But others have already implemented something else, such as the 
SIPConnect 1.0 solution. (Which, because it was underspecified, could 
mean a variety of things.)

The bottom line is that there a lot of different things implemented in 
the wild. So either you take a vote, and adopt whatever has been 
implemented "the most", or whatever has been implemented by "the most 
influential", or whatever solution is "better", or you just go back to 
requirements and sort it out again.

No matter what you do, there will be interop problems. That is always 
the case when we standardize something that has already been implemented.

	Thanks,
	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 6 Apr 2010 09:47:14 -0400

Well actually the so called IMS solution has its own interoperability
problems caused by the same poor design the original implicit registration
process had. The problem is the registration proxy does not have sufficient
information on what the message is to often process correctly which is why
after 16 months or so of looking at the problem it was clear to some of us
that some methodology that used a explicit indicator such as a option tag
was the ultimate solution. I still hold that the ETSI solution has a bias in
favor of large scale enterprise deployments which, at least in North America
are not the majority of customers.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Tuesday, April 06, 2010 4:23 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [martini] The IETF versus reality (was: problems withexisting
SIP trunking solutions)

I don't know what Martin was saying but I agree that the GIN solution
creates additional interoperability problems, simply because this is yet
another solution... Instead of having a single target (i.e. the so-called
IMS solution) to converge to, PBX vendors will have two alternative targets
in front of them: the IMS solution and the GIN solution.

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 6 Apr 2010 10:03:11 -0400

Well that is a thoughtful answer Paul. I personally don’t buy argument the
two implicit registration methodologies will somehow cause a new black hole
to be created in the universe. I do want something that uses an option tag
since IMHO that is at the heart of the problem. Though I do understand the
argument that one is easier to implement than two and the fact is that we
now have two widely deployed in the field and neither works all that well.
I'm certainly willing to compromise on a reasonable proposal but what I'm
not very happy about at this time is this "well 3GPP/ETSI does it this way
so suck it up", though I'm very sensitive to Keith's concern about private
numbering. The trend in North America has been to all DID numbering for some
time which is why some of us really haven’t understood that issue.

My larger concern is we do need a solution in the field right now COB
preferably, yesterday in fact, and this WG is a test of how the DISPATCH
process should work on these very specific interoperability issues and up
until this time I was reasonably satisfied that we were making progress.  We
all agree there are two problems here the short term and the long term . The
larger problem is that vendors and service providers are clearly going off
and doing things to make things work because either the standards don’t
exist or it takes too long to get a standard created. I'm certainly seeing
this in the E2MD context among others.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Tuesday, April 06, 2010 9:05 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [martini] The IETF versus reality

	Thanks,
	Paul

---

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

And then the circle is round. If there is one thing that all people seem to
agree on is the need for an explicit indicator.

/Hans Erik van Elburg

---

From: <[email-masked]>
Date: Tue, 6 Apr 2010 16:40:10 +0200

Adding an option tag is fine. That's what the shaken draft was bascially doing on top of the IMS solution. The problem I have  is that the gin draft goes beyond that.

BC

> De : Richard Shockey [mailto:[email-masked]] 
> Envoyé : mardi 6 avril 2010 15:47
> À : CHATRAS Bruno RD-CORE-ISS; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Objet : RE: [martini] The IETF versus reality (was: problems 
> Well actually the so called IMS solution has its own 
> interoperability problems caused by the same poor design the 
> original implicit registration process had. The problem is 
> the registration proxy does not have sufficient information 
> on what the message is to often process correctly which is 
> why after 16 months or so of looking at the problem it was 
> clear to some of us that some methodology that used a 
> explicit indicator such as a option tag was the ultimate 
> solution. I still hold that the ETSI solution has a bias in 
> favor of large scale enterprise deployments which, at least 
> in North America are not the majority of customers.
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [martini] The IETF versus reality (was: problems 
> I don't know what Martin was saying but I agree that the GIN 
> solution creates additional interoperability problems, simply 
> because this is yet another solution... Instead of having a 
> single target (i.e. the so-called IMS solution) to converge 
> to, PBX vendors will have two alternative targets in front of 
> them: the IMS solution and the GIN solution.
> 
> Envoyé : 
> > dimanche 4 avril 2010 19:04 À : DOLLY, MARTIN C (ATTLABS); Bernard 
> > Aboba; [email-masked] Objet : Re: [martini] The IETF 
> versus reality 
> > (was: problems withexisting SIP trunking solutions)
> >

---

From: Adam Roach <[email-masked]>
Date: Tue, 06 Apr 2010 10:11:52 -0500

The changes proposed in GIN are not mere caprice, nor are they simply 
aesthetic differences of opinion. We've been round and round on the list 
about the shortcomings of the ETSI/3GPP/IMS/etc solutions. The closest 
anyone favoring the IMS solutions have come to "solving" these problems 
is outright dismissal. The response has largely been of the form "it 
works for my walled gardens, and I don't care whether it works on the 
Internet at large."

The problem is that the stuff we work on here in the Internet 
Engineering Task Force must work on the Internet at large. You might not 
care whether it does -- but we, as a working group, must.

/a

On 4/6/10 09:40, Apr 6, [email-masked] wrote:
>>> "DOLLY, MARTIN C (ATTLABS)"<[email-masked]>  wrote:
>>>
>>>        
>>>> Speaking as a Service Provider, the solution being produced
>>>>          
>>> by Martini
>>>        
>>>> does not address what is needed for current to mid-term
>>>>          
>> deployments,
>>

---

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Tue, 6 Apr 2010 11:18:38 -0400

Adam,

But GIN does not address the Internet at large either?? 

The IMS solution addresses the majority of the business model needs. Creating a solution that is "pure", does not serve anyone.

Martin

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, April 06, 2010 11:12 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; DOLLY, MARTIN C (ATTLABS); [email-masked]; [email-masked]
Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions)

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Apr 2010 19:14:17 +0200

Hi,

I have no problem with an option-tag either, if that's an issue.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Tuesday, April 06, 2010 5:40 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [martini] The IETF versus reality (was:    problems        withexisting    SIP trunking solutions)

BC

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Apr 2010 19:24:22 +0200

Hi Adam,

>works for my walled gardens, and I don't care whether it works on the

If that was the case I don't think people would be here arguing for the IMS solution.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Tue, 06 Apr 2010 12:33:08 -0500

> But GIN does not address the Internet at large either??

That is both true and unfortunate -- but it is a very different kind of 
shortcoming. The GIN solution is scoped to registration of telephone 
numbers, not general user IDs. This represents a significant compromise 
for the sake of expediency.

Initially, I did come up with a solution that addressed the general case 
(http://tools.ietf.org/html/draft-roach-martini-up-00), but it did not 
receive particularly strong support right out of the gate. Now, don't 
read that as "The martini-up proposal had no support" -- at the first 
interim phone call, a quick straw poll of martini-up versus 
martini-shaken resulted in 7 supporting the approach in martini-up, 
versus 12 supporting that of martini-shaken. But it was clear that the 
martini-up approach would take a lot of explaining and consensus 
building if it were to be accepted. In other words, it would take a long 
time.

In deference to the SIP Forum, which is eagerly awaiting the output of 
the MARTINI working group, we decided to move forward with a solution 
scoped to just phone numbers. This decision was made out of a belief 
that we could complete such work in a fairly short timeframe.

So the lack of generality is a compromise, and a fairly significant one. 
I don't like it, but it's much less architecturally harmful than doing 
things like contravening the core SIP routing model described in RFC 
3263, ignoring the RFC 3261 rules around domain responsibility, or 
flirting with behavior that effectively creates a DNS alternate root.

GIN's lack of generality limits its usefulness. That is the extent of 
it's failure to address the Internet model. The IMS and shaken models' 
of URI handling runs contrary to core SIP protocol handling.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 06 Apr 2010 13:15:36 -0500

> If that was the case I don't think people would be here arguing for the IMS solution.

Without meaning to cast any aspersions on motives, I think a careful 
examination of the activities of those most vocally advocating adoption 
of the IMS solution would reveal to you that the preponderance[1] of 
them are relatively new to the IETF (approximately one year of active 
participation or less), and have worked in 3GPP and/or ETSI for a 
substantial amount of time. I love the fact that we're seeing new 
participation, but I fear that some of the reactions may be somewhat 
partisan in nature.

In particular, this appearance of partisanship is starkly amplified by 
the fact that the arguments raised against GIN are nearly uniformly 
statements that it isn't identical to the ETSI/3GPP solution. That's not 
helpful feedback. If MARTINI simply intended to republish another SDO's 
documents, then this has all been a colossal waste of everyone's time.

/a

[1] Before you raise objections along the lines of "but person X 
objects, and he or she's been here for longer than that," I encourage 
you to meditate on the meaning of the word "preponderance."

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 6 Apr 2010 12:27:17 -0700

Richard Shockey said:

"Well actually the so called IMS solution has its own interoperability
problems caused by the same poor design the original implicit registration
process had. The problem is the registration proxy does not have sufficient
information on what the message is to often process correctly which is why
after 16 months or so of looking at the problem it was clear to some of us
that some methodology that used a explicit indicator such as a option tag
was the ultimate solution. I still hold that the ETSI solution has a bias in
favor of large scale enterprise deployments which, at least in North America
are not the majority of customers."

[BA] I assume you're referring to "branch office" deployments in enterprise, rather than central campuses (which are more likely to use static mode, in my experience).   Out of curiosity, what features of the ETSI solution would tend to appeal to those customers?  Personally, I have not seen any "branch office" deployments using the ETSI solution, mostly variants of SIPconnect 1.0.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Apr 2010 22:46:27 +0200

Hi,

>participation, but I fear that some of the reactions may be somewhat

[Yes, I did read the text at the end of your e-mail before writing the following]

I can't speak for others, but personally I've never been religious when it comes to SDOs, so I don't really care where a solution is defined. I guess I belong to a minority in that sense :)

Yes, I'm obviously involved in IMS, but keep in mind that most of IMS is build upon IETF standards.

>documents, then this has all been a colossal waste of everyone's time.

The ETSI/3GPP solution has been has been part of the discussion more or less all the way from the beginning of the work, so I don't it's fair that it has now suddenly came up, and therefor we have wasted our time.

Regards.

Christer

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 06 Apr 2010 17:01:34 -0500

On 4/6/10 15:46, Apr 6, Christer Holmberg wrote:
> The ETSI/3GPP solution has been has been part of the discussion more 
> or less all the way from the beginning of the work, so I don't it's 
> fair that it has now suddenly came up, and therefor we have wasted our 
> time.

You missed my point. I'll rephrase what I was trying to say: if we're 
just re-publishing someone else's mechanism as-is, then all the work in 
DISPATCH and all the work in DREGS was a terrible waste of time. If the 
problem is already solved and working, then we didn't (and don't) need 
to do anything.

I think discussion of the IMS solution is perfectly reasonable, as long 
as people are willing to investigate and accept technical fixes to the 
issues that have been raised on the list. But that's not happening. 
Somehow, people think that slapping an options tag into the ETSI/3GPP 
solution will magically fix all its issues. You have enough SIP 
background that you should know that's simply not the case.

So, until someone shows the initiative to actually tackle the routing 
and URI issues in the ETSI/3GPP solution, it's a non-starter. I fear, 
however, that the very property that the advocates of that solution hold 
most dear is quite precisely the property that makes it run afoul core 
SIP routing behavior.

/a

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 6 Apr 2010 16:13:03 -0700

Adam Roach said:

"You missed my point. I'll rephrase what I was trying to say: if we're 
just re-publishing someone else's mechanism as-is, then all the work in 
DISPATCH and all the work in DREGS was a terrible waste of time. If the 
problem is already solved and working, then we didn't (and don't) need 
to do anything."

[BA]  Believe me, if there were any easy way out of the mess we're currently in, we'd have taken it by now.  I'd be one of the first people to argue for the documentation of widely deployed protocols (regardless of flaws).  If that had been a viable approach in this case, SIPconnect 1.0 would have been a rousing success and SIPconnect 1.1 would be done by now.  

The formation of MARTINI WG was made necessary by the reality that multiple mechanisms were already deployed, each with their own set of issues, but none of the variants seemed to have gotten to critical mass.  SIPconnect 1.1 contained one of those variants, but so many ballot issues were raised about exactly how it would work (and if it would work), that after months and months of discussion by at lots and lots of people, the issue was brought to the IETF. 

At this point, we're well beyond assertions like "the dogs SHOULD like the dogfood, look how nutritious it is!" or "the dogs will eat the dogfood if you put an IETF stamp on it."  In general, "IETF" doesn't mean much to a dog, they go by smell and taste.  A number of varieties have been put out, the dogs have either refused to eat, or in some cases, have gotten sick and misbehaved in various ways after tasting it.

---

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

I think most people are willing to investigate and accept technical fixes as
long as there arguments are taken seriously and can agree that issues raised
are really issues.

Now where are the issues "the routing and URI issues in the ETSI/3GPP
solution" enumerated? Then we can address them one by one. Apparently some
people have joined the discussion after the wg already hummed to some
preliminary conclusion, it does not harm to reiterate those. If these are
all really issues I guess we are all lead to the same conclusion in some
way.

Another way forward could be that martini recognises that its main task is
the definition of a SIP protocol extension for signalling the SIP trunking
variant, that the PBX supports. That would solve the main issues that are
presented in the requirements document. I have nothing against such a
framework also describing the GIN variant as one of the alternatives. If it
is so good for pure SIP proxy implementations, why not?

There is another alternative that is that martini only creates a SIP forum
specific solution, nothing wrong with that. But then please state it in the
title and make this an informative draft.  This will allow you to do a quick
and expedient specification and people will let you do. Thats how other
SDO's also need to do their extensions, as they are building walled garden
solutions...

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 12:01 AM, Adam Roach <[email-masked]> wrote:

>> The ETSI/3GPP solution has been has been part of the discussion more or
>> less all the way from the beginning of the work, so I don't it's fair that
>> it has now suddenly came up, and therefor we have wasted our time.
>>
>
> You missed my point. I'll rephrase what I was trying to say: if we're just
> re-publishing someone else's mechanism as-is, then all the work in DISPATCH
> and all the work in DREGS was a terrible waste of time. If the problem is
> already solved and working, then we didn't (and don't) need to do anything.
>
> I think discussion of the IMS solution is perfectly reasonable, as long as
> people are willing to investigate and accept technical fixes to the issues
> that have been raised on the list. But that's not happening. Somehow, people
> think that slapping an options tag into the ETSI/3GPP solution will
> magically fix all its issues. You have enough SIP background that you should
> know that's simply not the case.
>
> So, until someone shows the initiative to actually tackle the routing and
> URI issues in the ETSI/3GPP solution, it's a non-starter. I fear, however,
> that the very property that the advocates of that solution hold most dear is
> quite precisely the property that makes it run afoul core SIP routing
> behavior.
>
> /a
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Apr 2010 23:04:10 -0400

Let me try and cut to the chase, by trying to provide a road map for how we got here.  Some of this history may be from the sip-forum and not Martini or Dispatch, but it gets to the general issue.

Probably the biggest issue we hit/debated about ETSI/3gpp/draft-shaken was the specific details of how to route requests to the IP-PBX.  I think that's also the change that most people are upset about being different from 3gpp.  So I'll just cover that.

The problems found in the field are that different IP-PBX's expect different things in the request-uri: some expect only SIP URI's; some can't handle their contact-URI being in a Route header; some expect their registered contact in the req-uri; some expect various username formats.  It's all over the map.

So we were trying to say "well if you do this option-tag then you must accept XYZ".  So then we got into what is the XYZ.

We started with loose-route: the SSP just inserts the Registered Contact-URI as a loose-route, and leaves the req-URI alone.

And then we hit the first snag: what req-uri user portion does the IP-PBX actually expect/understand?  We've seen problems with that in the field too - some expect a leading "+", some don't; some expect a country-code, some don't; some can handle the visual-separators, some can't; some do Tel-URI, some don't.  What the SSP gets is any/all forms with all kinds of number transform rules, but the IP-PBX type we're targeting is simple.  There were several proposals for how to handle this, including even just normalizing the username to some common format/scheme before sending it to the IP-PBX.  OK, so now the SSP is modifying the req-uri username, but that's do-able.

Then we hit the second snag: what req-uri host portion does the IP-PBX actually expect/understand?  In practice it usually expects its own (its hostname/ip/domain).  It's not *actually* in the SSP's domain, after all.  But we figured we'll just mandate it is for its specific AoR's, or that it least owns/controls/is-authoritative for those AoR's.  But then we realized that the req-uri the SSP Proxy literally gets (before looking it up and routing it) isn't always known to the IP-PBX either - it's not always the domain, for example - it could be and often is the SSP's Proxy's hostname or IP or sub-domain in the SSP.

So now we're transforming the host portion too, to become the SSP's domain, just so the IP-PBX recognizes that it's NOT the SSP's domain but instead one of its AoR's, which were really one of the SSP's AoR's.  Confusing, huh?

So now we're deep into defining a request-uri transformation model, to make sure the req-uri the IP-PBX gets looks like a "canonical" AoR it will expect to get. The original concept was to "leave it alone", but it's not _really_ left alone.  And trust me it's virtually NEVER left alone, in practice.  Think about all the number translations, number manipulations, host replacement rules, etc., the Proxy and SBC vendors have.  They're incredibly popular, because they're what make calls actually succeed.  But we're trying to cover that SMB market thing, without unique rules per IP-PBX vendor/model, and with frankly dumb, cheap, crappy IP-PBX's. (no offense to IP-PBX vendors - but I'm not talking about the vendors that go to standards bodies :)

Meanwhile, another group of folks were saying "wait a minute, we already have a request-uri 'transformation' and routing model for Registered AoR's: it's called RFC 3261. Why re-create the wheel, when there's already a wheel around that's proven to work?"  That's a pretty strong argument.

There were also arguments that we technically have no loose-route mechanism for Registered AoR's - there was JDR's draft, but it got nixed.  I personally wasn't buying that argument much (after all, we're defining a standards-track spec, so we could just do it, and there's enough wiggle room in 3261's language that one could claim it's just a specific "local policy" step).  

But in fairness there may well be unintended consequences for doing loose-route in draft-shaken/IMS/etc. model for E.164 AoR's.  For example, if the IP-PBX *was* misconfigured and doesn't think it owns an AoR the SSP thinks it owns, what happens?  The SSP routes it to the IP-PBX.  The IP-PBX then routes it to the SSP (in some cases).  Nice loop.  But that's not the problem - it's a symptom, not the cause - the cause is we sent a request from domain A to domain B, with domain *A* as the target.

-hadriel

---

From: <[email-masked]>
Date: Wed, 7 Apr 2010 09:22:21 +0200

> De : Adam Roach [mailto:[email-masked]] 
> Envoyé : mardi 6 avril 2010 20:16
> À : Christer Holmberg
> Cc : DOLLY, MARTIN C (ATTLABS); CHATRAS Bruno RD-CORE-ISS; 
> >> aesthetic differences of opinion. We've been round and 
> round on the 
> >> list about the shortcomings of the ETSI/3GPP/IMS/etc 
> solutions. The 
> >> closest anyone favoring the IMS solutions have come to "solving" 
> >> these problems is outright dismissal. The response has 
> largely been 
> >> of the form "it works for my walled gardens, and I don't 
> care whether 
> >> it works on the Internet at large."
> >>      
> Without meaning to cast any aspersions on motives, I think a 
> careful examination of the activities of those most vocally 
> advocating adoption of the IMS solution would reveal to you 
> that the preponderance[1] of them are relatively new to the 
> IETF (approximately one year of active participation or 
> less), and have worked in 3GPP and/or ETSI for a substantial 
> amount of time. I love the fact that we're seeing new 
> participation, but I fear that some of the reactions may be 
> somewhat partisan in nature.
> 
> In particular, this appearance of partisanship is starkly 
> amplified by the fact that the arguments raised against GIN 
> are nearly uniformly statements that it isn't identical to 
> the ETSI/3GPP solution. That's not helpful feedback. 

==>BC: The real concern is that there will be two non-compatible alternative standards to comply with: GIN and 3GPP/ETSI. That's why some people including myself are advocating alignment/consistency between MARTINI and the 3GPP/ETSI solution. It's obsioulsy not because the solution comes from SDOs where some of us are more involved than in IETF. On the other hand I hope that the 3GPP/ETSI solution is not discarded by some other people just because it comes from 3GPP and ETSI...

 GIN draft creates 
> If MARTINI simply intended to republish another SDO's documents, 
> then this has all been a colossal waste of everyone's time.
==>BC: MARTINI could have elected to improve the 3GPP/ETSI solution (e.g. by adopting the "shaken" draft as a work item) rather than creating something completely different. 

> 
> /a
> 
> [1] Before you raise objections along the lines of "but 
> person X objects, and he or she's been here for longer than 
> that," I encourage you to meditate on the meaning of the word 
> "preponderance."
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 7 Apr 2010 07:43:38 -0500

Hi, Bruno...

See <spencer> below... and this time, I'm speaking as an individual.

> the ETSI/3GPP solution. That's not helpful feedback.

==>BC: The real concern is that there will be two non-compatible alternative 
standards to comply with: GIN and 3GPP/ETSI. That's why some people 
including myself are advocating alignment/consistency between MARTINI and 
the 3GPP/ETSI solution. It's obsioulsy not because the solution comes from 
SDOs where some of us are more involved than in IETF. On the other hand I 
hope that the 3GPP/ETSI solution is not discarded by some other people just 
because it comes from 3GPP and ETSI...

<spencer>Oh, I can promise you that this wasn't what happened. (1) the 
CableLabs types use an IMS-based architecture, and would love to be using 
the same mechanism, and (2) if we were going to blow off the 3GPP/ETSI 
solution because it came from 3GPP/ETSI, we wouldn't have taken an entire 
IETF cycle to do that...

</spencer>

 GIN draft creates
> then this has all been a colossal waste of everyone's time.
==>BC: MARTINI could have elected to improve the 3GPP/ETSI solution (e.g. by 
adopting the "shaken" draft as a work item) rather than creating something 
completely different.

<spencer>

Not sure if you have had a chance to look at Hadriel's Hitchhiker's Guide 
post (sent just a few hours before your note), but in my 
individual-contributor opinion, it actually understates one key concern:

> But in fairness there may well be unintended consequences for doing
> loose-route in draft-shaken/IMS/etc. model for E.164 AoR's.  For example,
> if the IP-PBX *was* misconfigured and doesn't think it owns an AoR the
> SSP thinks it owns, what happens?  The SSP routes it to the IP-PBX.  The
> IP-PBX then routes it to the SSP (in some cases).  Nice loop.  But that's
> not the problem - it's a symptom, not the cause - the cause is we sent a
> request from domain A to domain B, with domain *A* as the target.

When we actually said this out loud, we realized that we were entering a 
land where we expect SIP nodes to ignore domain names in the request URI and 
route based on "something else" from a SIP node that was authoritative for 
the domain to a destination that wasn't authoritative for the domain.

Hadriel was actually pretty eloquent, arguing that this was a "local policy" 
routing decision, allowed by RFC 3261, but he got shot down. My impression, 
speaking as an individual, was that the IETF would never standardize this 
mode of operation.

And that's how we got to GIN.

</spencer>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 7 Apr 2010 15:25:47 +0200

Thanks Hadriel for providing the excellent overview, hope this gets the
discussion back on track.

Just to put this remark from Spencer on the right thread, it seems important
and the crucial fundamental point where people have different opinions:
<spencer>
  <hadriel>

> request from domain A to domain B, with domain *A* as the target.
   </hadriel>

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 5:04 AM, Hadriel Kaplan <[email-masked]>wrote:

>
> Let me try and cut to the chase, by trying to provide a road map for how we
> got here.  Some of this history may be from the sip-forum and not Martini or
> Dispatch, but it gets to the general issue.
>
> Probably the biggest issue we hit/debated about ETSI/3gpp/draft-shaken was
> the specific details of how to route requests to the IP-PBX.  I think that's
> also the change that most people are upset about being different from 3gpp.
>  So I'll just cover that.
>
> The problems found in the field are that different IP-PBX's expect
> different things in the request-uri: some expect only SIP URI's; some can't
> handle their contact-URI being in a Route header; some expect their
> registered contact in the req-uri; some expect various username formats.
>  It's all over the map.
>
> So we were trying to say "well if you do this option-tag then you must
> accept XYZ".  So then we got into what is the XYZ.
>
> We started with loose-route: the SSP just inserts the Registered
> Contact-URI as a loose-route, and leaves the req-URI alone.
>
> And then we hit the first snag: what req-uri user portion does the IP-PBX
> actually expect/understand?  We've seen problems with that in the field too
> - some expect a leading "+", some don't; some expect a country-code, some
> don't; some can handle the visual-separators, some can't; some do Tel-URI,
> some don't.  What the SSP gets is any/all forms with all kinds of number
> transform rules, but the IP-PBX type we're targeting is simple.  There were
> several proposals for how to handle this, including even just normalizing
> the username to some common format/scheme before sending it to the IP-PBX.
>  OK, so now the SSP is modifying the req-uri username, but that's do-able.
>
> Then we hit the second snag: what req-uri host portion does the IP-PBX
> actually expect/understand?  In practice it usually expects its own (its
> hostname/ip/domain).  It's not *actually* in the SSP's domain, after all.
>  But we figured we'll just mandate it is for its specific AoR's, or that it
> least owns/controls/is-authoritative for those AoR's.  But then we realized
> that the req-uri the SSP Proxy literally gets (before looking it up and
> routing it) isn't always known to the IP-PBX either - it's not always the
> domain, for example - it could be and often is the SSP's Proxy's hostname or
> IP or sub-domain in the SSP.
>
> So now we're transforming the host portion too, to become the SSP's domain,
> just so the IP-PBX recognizes that it's NOT the SSP's domain but instead one
> of its AoR's, which were really one of the SSP's AoR's.  Confusing, huh?
>
> So now we're deep into defining a request-uri transformation model, to make
> sure the req-uri the IP-PBX gets looks like a "canonical" AoR it will expect
> to get. The original concept was to "leave it alone", but it's not _really_
> left alone.  And trust me it's virtually NEVER left alone, in practice.
>  Think about all the number translations, number manipulations, host
> replacement rules, etc., the Proxy and SBC vendors have.  They're incredibly
> popular, because they're what make calls actually succeed.  But we're trying
> to cover that SMB market thing, without unique rules per IP-PBX
> vendor/model, and with frankly dumb, cheap, crappy IP-PBX's. (no offense to
> IP-PBX vendors - but I'm not talking about the vendors that go to standards
> bodies :)
>
> Meanwhile, another group of folks were saying "wait a minute, we already
> have a request-uri 'transformation' and routing model for Registered AoR's:
> it's called RFC 3261. Why re-create the wheel, when there's already a wheel
> around that's proven to work?"  That's a pretty strong argument.
>
> There were also arguments that we technically have no loose-route mechanism
> for Registered AoR's - there was JDR's draft, but it got nixed.  I
> personally wasn't buying that argument much (after all, we're defining a
> standards-track spec, so we could just do it, and there's enough wiggle room
> in 3261's language that one could claim it's just a specific "local policy"
> step).
>
> loose-route in draft-shaken/IMS/etc. model for E.164 AoR's.  For example, if
> the IP-PBX *was* misconfigured and doesn't think it owns an AoR the SSP
> thinks it owns, what happens?  The SSP routes it to the IP-PBX.  The IP-PBX
> then routes it to the SSP (in some cases).  Nice loop.  But that's not the
> problem - it's a symptom, not the cause - the cause is we sent a request
> from domain A to domain B, with domain *A* as the target.
>
> -hadriel
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Apr 2010 09:37:20 -0400

Hadriel,

Thank you! This is a superb job of explaining where we are.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Apr 2010 10:04:55 -0400

> ==>BC: The real concern is that there will be two non-compatible alternative standards to comply with: GIN and 3GPP/ETSI. That's why some people including myself are advocating alignment/consistenc…

There are *already* two (or more incompatible "standards" to comply 
with): 3gpp/etsi and SipConnect1.0. And there are others that aren't 
standards, but that are deployed.

	Thanks,
	Paul

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 7 Apr 2010 09:14:45 -0500

Speaking as individual,

And, expanding slightly ...

>> ==>BC: The real concern is that there will be two non-compatible 
>> alternative standards to comply with: GIN and 3GPP/ETSI. That's why some 
>> people including myself are advocating alignment/consistency between 
>> MARTINI and the 3GPP/ETSI solution. It's obsioulsy not because the 
>> solution comes from SDOs where some of us are more involved than in IETF. 
>> On the other hand I hope that the 3GPP/ETSI solution is not discarded by 
>> some other people just because it comes from 3GPP and ETSI...
>
> There are *already* two (or more incompatible "standards" to comply with): 
> 3gpp/etsi and SipConnect1.0. And there are others that aren't standards, 
> but that are deployed.

The reason Paul said "two or more" is because there are enough variants that 
comply with SIPconnect 1.0 that it's not clear how many times we should be 
counting SIPconnect 1.0 :-o

Several of the variants that are described in section 3 of the requirements 
draft would comply with SIPconnect 1.0,  but they're incompatible enough 
that they have interworking problems.

Thanks,

Spencer, as individual

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2010 19:29:50 +0200

Hi,

>> ==>BC: The real concern is that there will be two non-compatible alternative standards to comply with: 
>>GIN and 3GPP/ETSI. That's why some people including myself are advocating alignment/consistency 
>>between MARTINI and the 3GPP/ETSI solution. It's obsioulsy not because the solution comes from SDOs 
>>where some of us are more involved than in IETF. On the other hand I hope that the 3GPP/ETSI solution is 
>>not discarded by some other people just because it comes from 3GPP and ETSI...
>
>There are *already* two (or more incompatible "standards" to comply with): 3gpp/etsi and SipConnect1.0.

Yes, but it seems like the SipConnect people aren't very happy with their current standard :)

>And there are others that aren't standards, but that are deployed.

Anyone is welcome to suggest such solution as an alternative to the WG. I don't think MARTINI needs to go out and look for them.

Regards,

Christer

---

From: David Hancock <[email-masked]>
Date: Wed, 7 Apr 2010 11:52:32 -0600

Thanks for the concise summary, Hadriel. 

I'm sympathetic to the arguments being put forward now by the IMS camp on this issue. IMS has a well-defined procedure for support of IP-PBX registration, IMS is being adopted by a pretty sizeable portion of the industry, so why introduce a new/alternate bulk-registration procedure now just to resolve some esoteric/academic/philosophical issues? And during most of this debate, I've been a proponent of a solution that aligns as closely as possible to the IMS model. However, I've lately come to the conclusion that the GIN solution has some real technical merit that is worth considering.  

During the original discussion on the domain-ownership-ambiguity issue (where PBX uses the SSP domain), we resolved the issue as suggested in your summary below -- by saying the PBX will apply local policy to route the request based on the E.164 number in the user part. The downside is the potential of a routing loop you mentioned (although I think legacy (TDM) PBXs would have the same routing-loop issue if they were similarly misconfigured). However, that's not the only issue with the shared-domain case. Another issue we discussed at length was how to support temp-gruus. If the IP-PBX assigns and uses a temporary GRUU that has the SSP domain, the SSP network has no way to associate that GRUU with the PBX. GIN solves this problem, whereas IMS/SHAKEN solutions do not.

Another way to avoid the shared-domain routing & temp-gruu issues that exist with an IMS/SHAKEN implicit registration models is to assign the IP-PBX a unique domain -- say a sub-domain of the SSP network. In this case the SSP is able to route requests addressed to a PBX-assigned temp-gruu because the domain of the temp-gruu points to that PBX. But assigning and managing these sub-domains becomes burden for the Service Provider, especially at the small end of the SMB market, where the number of served PBXs can grow pretty large. 

Another issue with this per-PBX sub-domain approach is that the sub-domains would not be known to the outside world. A call initiating from a peer SSP would arrive at the home SSP with a Request-URI containing the E.164 number of the PBX user at the *SSP domain*. The home SSP would have to re-target the Request-URI to the sub-domain assigned of the target PBX. SHAKEN didn't address this issue (was considered out-of-scope), and as far as I know IMS does not have any explicit procedures for this retargeting step either. This issue does not exist with the GIN solution, since the home/terminating SSP network retargets incoming requests destined for the IP-PBX based on normal RFC 3261 section 16.5 routing procedures.

David

> Of Hadriel Kaplan
> Sent: Tuesday, April 06, 2010 9:04 PM
> To: Hans Erik van Elburg; Adam Roach
> Subject: [martini] Hitchhiker's Guide to Making Martini (was: The IETF
> versus reality)
> 
> 
> Let me try and cut to the chase, by trying to provide a road map for how
> we got here.  Some of this history may be from the sip-forum and not
> Martini or Dispatch, but it gets to the general issue.
> 
> the specific details of how to route requests to the IP-PBX.  I think
> that's also the change that most people are upset about being different
> from 3gpp.  So I'll just cover that.
> 
> different things in the request-uri: some expect only SIP URI's; some
> can't handle their contact-URI being in a Route header; some expect their
> We started with loose-route: the SSP just inserts the Registered Contact-
> URI as a loose-route, and leaves the req-URI alone.
> 
> actually expect/understand?  We've seen problems with that in the field
> too - some expect a leading "+", some don't; some expect a country-code,
> some don't; some can handle the visual-separators, some can't; some do
> Tel-URI, some don't.  What the SSP gets is any/all forms with all kinds of
> number transform rules, but the IP-PBX type we're targeting is simple.
> There were several proposals for how to handle this, including even just
> normalizing the username to some common format/scheme before sending it to
> the IP-PBX.  OK, so now the SSP is modifying the req-uri username, but
> that's do-able.
> 
> least owns/controls/is-authoritative for those AoR's.  But then we
> realized that the req-uri the SSP Proxy literally gets (before looking it
> up and routing it) isn't always known to the IP-PBX either - it's not
> always the domain, for example - it could be and often is the SSP's
> Proxy's hostname or IP or sub-domain in the SSP.
> 
> So now we're transforming the host portion too, to become the SSP's
> domain, just so the IP-PBX recognizes that it's NOT the SSP's domain but
> instead one of its AoR's, which were really one of the SSP's AoR's.
> Confusing, huh?
> 
> So now we're deep into defining a request-uri transformation model, to
> make sure the req-uri the IP-PBX gets looks like a "canonical" AoR it will
> expect to get. The original concept was to "leave it alone", but it's not
> _really_ left alone.  And trust me it's virtually NEVER left alone, in
> practice.  Think about all the number translations, number manipulations,
> host replacement rules, etc., the Proxy and SBC vendors have.  They're
> incredibly popular, because they're what make calls actually succeed.  But
> we're trying to cover that SMB market thing, without unique rules per IP-
> PBX vendor/model, and with frankly dumb, cheap, crappy IP-PBX's. (no
> offense to IP-PBX vendors - but I'm not talking about the vendors that go
> to standards bodies :)
> 
> have a request-uri 'transformation' and routing model for Registered
> AoR's: it's called RFC 3261. Why re-create the wheel, when there's already
> a wheel around that's proven to work?"  That's a pretty strong argument.
> 
> There were also arguments that we technically have no loose-route
> mechanism for Registered AoR's - there was JDR's draft, but it got nixed.
> I personally wasn't buying that argument much (after all, we're defining a
> standards-track spec, so we could just do it, and there's enough wiggle
> room in 3261's language that one could claim it's just a specific "local
> policy" step).
> 
> But in fairness there may well be unintended consequences for doing loose-
> route in draft-shaken/IMS/etc. model for E.164 AoR's.  For example, if the
> IP-PBX *was* misconfigured and doesn't think it owns an AoR the SSP thinks
> it owns, what happens?  The SSP routes it to the IP-PBX.  The IP-PBX then
> routes it to the SSP (in some cases).  Nice loop.  But that's not the

---

From: <[email-masked]>
Date: Thu, 8 Apr 2010 08:37:23 +0200

Hi guys,

To my opinion the network and protocol is not and should not be responsible for solving (human) errors like misconfiguration !

Kind regards

Jan Van Geel
IT and Network Development Specialist
Belgacom SDE/SDV/PSE/NST/NCP
Tel: +32 2 202 1035
Tel: +32 2 207 9032
Email : [email-masked]
www.cyberwezz.tk

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
Sent: 07 April 2010 15:26
To: Hadriel Kaplan; Spencer Dawkins
Cc: [email-masked]; [email-masked]
Subject: Re: [martini] Hitchhiker's Guide to Making Martini (was: The IETF versus reality)

Thanks Hadriel for providing the excellent overview, hope this gets the discussion back on track.

Just to put this remark from Spencer on the right thread, it seems important and the crucial fundamental point where people have different opinions:
<spencer>
  <hadriel>

When we actually said this out loud, we realized that we were entering a land where we expect SIP nodes to ignore domain names in the request URI and route based on "something else" from a SIP node that was authoritative for the domain to a destination that wasn't authoritative for the domain.

Hadriel was actually pretty eloquent, arguing that this was a "local policy" routing decision, allowed by RFC 3261, but he got shot down. My impression, speaking as an individual, was that the IETF would never standardize this mode of operation.

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 5:04 AM, Hadriel Kaplan <[email-masked]<mailto:[email-masked]>> wrote:

-hadriel

**** DISCLAIMER ****
http://www.belgacom.be/maildisclaimer

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 8 Apr 2010 10:56:05 +0200

I agree misconfiguration is a pretty weak argument as it can be used to
derail any solution. Although some solutions are more robust then others in
the presence of some misconfigured elements.

As PBX is generally owned by another party then the SSP, the effect of such
misconfigured PBX could therefore be a factor that weighs in on selecting a
solution.

I have the feeling that the core philosophical issue is this: "the cause is
we sent a request from domain A to domain B, with domain *A* as the target."
or more general "entering a land where we expect SIP nodes to ignore domain
names in the request URI and route based on "something else" from a SIP node
that was authoritative for the domain to a destination that wasn't
authoritative for the domain."

I don't think that this is implied by the use of the Route header for
routing. For some reason people think that this is implied by using the
Route-header-to-PBX solution. I do think this aspect is underspecified in
the Route-header-to-PBX solution.

I don't think that it is bad in all cases to "entering a land where we
expect [specific PBX or SSPentities in trunking arrangement] SIP nodes to
ignore [replace] domain names in the request URI and route based on
"something else" [configured policy, i own this user allthough i don't own
the number (my operator owns it)] from a SIP node that was authoritative for
the domain to a destination that wasn't authoritative for the domain." text
in [] brackets added by me.

Because otherwise we would forbid certain business models where certain
activities (routing to the end user) are delegated to another party (PBX),
which can not be the intent of a standard. That is actually what martini is
trying to achieve.

The fundamental issue is whether it is allowed to delegate authority to
other parties. My question would be, why should that be forbidden?

/Hans Erik van Elburg

On Thu, Apr 8, 2010 at 8:37 AM, <[email-masked]> wrote:

>  Hi guys,
>
>
>
> To my opinion the network and protocol is not and should not be responsible
> for solving (human) errors like misconfiguration !
>
>
>
> Kind regards
>
>
>
> *Jan Van Geel*
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Hans Erik van Elburg
> *Sent:* 07 April 2010 15:26
> *To:* Hadriel Kaplan; Spencer Dawkins
>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [martini] Hitchhiker's Guide to Making Martini (was: The
> IETF versus reality)
>
>
>
> Just to put this remark from Spencer on the right thread, it seems
> important and the crucial fundamental point where people have different
> opinions:
> <spencer>
>   <hadriel>
>
> Hadriel was actually pretty eloquent, arguing that this was a "local
> policy" routing decision, allowed by RFC 3261, but he got shot down. My
> impression, speaking as an individual, was that the IETF would never
> standardize this mode of operation.
>
> **** DISCLAIMER ****http://www.belgacom.be/maildisclaimer
>
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 8 Apr 2010 11:08:01 +0200

I agree misconfiguration is a pretty weak argument as it can be used to
derail any solution. Although some solutions are more robust then others in
the presence of some msiconfigured elements.

I don't think that this is implied by the use of the Route header for
routing. For some reason people think that this is implied by using the
shaken solution. I do think this aspect is underspecified in the shaken
solution.

/Hans Erik van Elburg

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 05:14:43 -0400

Hi Jan,
It wasn't that we were worried about loops - the protocol already protects against loops ultimately (through max-forwards and possibly via-branches) - it was what the problem exposed.  It exposed that we had screwed up.  We had changed the routing model of SIP, without intending to change the routing model of SIP. :(

-hadriel

> Of [email-masked]
> Sent: Thursday, April 08, 2010 2:37 AM
>
> Hi guys,
> To my opinion the network and protocol is not and should not be 
> responsible for solving (human) errors like misconfiguration !
> Kind regards
> Jan Van Geel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 05:33:35 -0400

Hi Hans Erik,
Comments inline...

> From: Hans Erik van Elburg [mailto:[email-masked]] 
> Sent: Thursday, April 08, 2010 4:56 AM
>
> the number (my operator owns it)] from a SIP node that was authoritative 
> for the domain to a destination that wasn't authoritative for the domain." 
> text in [] brackets added by me.

I'll reply to that in a separate thread.

> which can not be the intent of a standard. That is actually what martini 
> is trying to achieve.
>

That was the argument I was using to defend the loose-route proposal, along with other arguments.

The problem is more subtle, however.  SIP's dependence on the Request-URI identifying the intended target, including the domain, is deeply entrenched.  Obviously there is a loose-route model, but when it is used it does not change the intended target.  For example, there are dependencies on that domain for TLS certificate authentication, which we would have to explain away.  In fact, we would probably have to go and review each and every RFC ever written for SIP, to see if there is any interaction.

Based on the concerns people had, I am pretty sure we would not get consensus in the IETF to go that path, without a lot more worry/work/time.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 06:03:19 -0400

Hi Hans Erik,
Comments inline...

> text in [] brackets added by me.

Right, so that was another one of my arguments. :)

I was saying these AoRs are effectively delegated to the IP-PBX, as if it was a distributed proxy system all of the same domain where the proxy in the Enterprise just handles those AoRs.  But that raised red flags of "but it's NOT the same domain - prove to us there are no interactions with every SIP RFC, because SIP always assumed a proxy within a domain is authoritative for that domain, and this Enterprise proxy is NOT authoritative for the SSP domain at all".

So then I was thinking we'd just replace the domain. (in fact, I had always meant to leave the possibility of changing the domain as an open issue for WG decision in draft-shaken)  

The only one who could do that (legally) would be the SSP, so I was prepared-for/fine-with the SSP changing the domain to be the IP-PBX.  But then it occurred to me we're now changing the user portion, and changing the domain, so what are we NOT changing?  The "@" character? ;)

The only thing we would gain, by circumventing rfc3261's rules, would be "saving" the request-URI parameters.  But that just goes right back to the debate about loose-route vs. Target vs. hist-info, and subverting hist-info.  And I'm definitely no fan of hist-info, but that's what we're stuck with for handling those. :(

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 8 Apr 2010 14:10:20 +0200

Hi Hadriel,

In priciple there is never a problem with changing the name of the domain on
numbers (expressed as a SIP URI) as it is not identifieing the target user
in any way. For numbers the only use of the domain name is in fact for
routing purposes. It does not bear any other meaning.

For alphanumeric SIP-uri's this is not true but martini just choose to
ignore that case... You can't say on one hand oh oh oh how awful that
approach breaks SIP routing and on the other hand accept a solution that
breaks ... SIP routing. To use equally strong wording. In both cases this
strong wording does not apply and non-constructive fights are preprogrammed.

Did not understand what you ment with that the user part needs changing as
well.

I do believe that there might be some way forward in accepting both
approaches and PBX's can indicate what they like to support. For example 1
pbx registers with bnc=1 (shaken), and another with bnc=2 (gin). That would
resolve this debate. And the RFC can then note the particular tricky issues
that in the different type of  deployments need to be taken care of.

It would resolve an issue with existing approaches and at the same time let
the pbx or SSP choose what kind of broken SIP routing flavour it prefers on
the SIP trunk.

Note that the ETSI/3GPP solution also still allows the use of a third method
that is that the contact is placed in the Request-URI and the target in the
P-Called-Party-Identity... this however also requires special behaviour on
the PBX side. BTW I view the History-Info way of providing target info to
the UE ok for presentation purposes and the like, but for some reason I
think it is not fit to use for routing. But also this is merely an opinion,
because you could equally make that work.

/Hans Erik van Elburg

On Thu, Apr 8, 2010 at 12:03 PM, Hadriel Kaplan <[email-masked]>wrote:

> I was saying these AoRs are effectively delegated to the IP-PBX, as if it
> was a distributed proxy system all of the same domain where the proxy in the
> Enterprise just handles those AoRs.  But that raised red flags of "but it's
> NOT the same domain - prove to us there are no interactions with every SIP
> RFC, because SIP always assumed a proxy within a domain is authoritative for
> that domain, and this Enterprise proxy is NOT authoritative for the SSP
> domain at all".
>
> So then I was thinking we'd just replace the domain. (in fact, I had always
> meant to leave the possibility of changing the domain as an open issue for
> WG decision in draft-shaken)
>
> The only one who could do that (legally) would be the SSP, so I was
> prepared-for/fine-with the SSP changing the domain to be the IP-PBX.  But
> then it occurred to me we're now changing the user portion, and changing the
> domain, so what are we NOT changing?  The "@" character? ;)
>
> The only thing we would gain, by circumventing rfc3261's rules, would be
> "saving" the request-URI parameters.  But that just goes right back to the
> debate about loose-route vs. Target vs. hist-info, and subverting hist-info.
>  And I'm definitely no fan of hist-info, but that's what we're stuck with
> for handling those. :(
>
> -hadriel
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 09:38:48 -0400

Hi Hans Erik,
I think you are getting angry at the wrong person.  I was the main advocate for following the ETSI/3gpp loose-route model. (or one of the advocates anyway)

I am just trying to explain how we got to where we are, over the course of 2 years of SIP-Forum and 4 Martini WG meetings of debate.

I'm doing that because I want to get us all on the same page, so we can turn the page and get closer to the end. :)

Other comments inline...

> Sent: Thursday, April 08, 2010 8:10 AM
>

In what way does GIN break SIP routing??

> Did not understand what you ment with that the user part needs changing as 

That was explained in the hitchhiker's guide. :)

> It would resolve an issue with existing approaches and at the same time 
> let the pbx or SSP choose what kind of broken SIP routing flavour it 
> prefers on the SIP trunk. 

By definition, the *instant* you introduce a Required option-tag into ETSI/3GPP/IMS or SIP-Connect 1.0, it is no longer the "current" mechanism.  

That's the rub, no matter what happens.  So now you're saying, "we have more than 2 current mechanisms, let's add 2 more"?

And as a side note, though not the main issue: for the GIN draft the REGISTER is actually formatted differently from SIP Connect 1.0 and ETSI/3gpp, in its contact URI.  You can't mix these models in the same REGISTER request.

-hadriel

---

From: "Brian Lindsay" <[email-masked]>
Date: Thu, 8 Apr 2010 09:40:56 -0400

Hi Hadriel,

  You've discussed changing the user portion below. Can you clarify why
the user portion would change in the Shaken approach? 

  I had assumed Shaken would go down the path of having the host portion
reflect the IP PBX domain given that was what the not-yet-completed SIP
Connect 1.1 Draft had ended up doing, and also some of the prior
discussion on this list suggested that was where things would head.

  Thanks
     Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
Sent: Thursday, April 08, 2010 6:03 AM
To: Hans Erik van Elburg; [email-masked]
Subject: [martini] Changing the domain (was: Hitchhiker's Guide to
MakingMartini)

Hi Hans Erik,
Comments inline...

> routing. For some reason people think that this is implied by using 
> the Route-header-to-PBX solution. I do think this aspect is 
> underspecified in the Route-header-to-PBX solution.
>

> expect [specific PBX or SSPentities in trunking arrangement] SIP nodes

> to ignore [replace] domain names in the request URI and route based on

> "something else" [configured policy, i own this user allthough i don't

> own the number (my operator owns it)] from a SIP node that was 
> authoritative for the domain to a destination that wasn't

I was saying these AoRs are effectively delegated to the IP-PBX, as if
it was a distributed proxy system all of the same domain where the proxy
in the Enterprise just handles those AoRs.  But that raised red flags of
"but it's NOT the same domain - prove to us there are no interactions
with every SIP RFC, because SIP always assumed a proxy within a domain
is authoritative for that domain, and this Enterprise proxy is NOT
authoritative for the SSP domain at all".

So then I was thinking we'd just replace the domain. (in fact, I had
always meant to leave the possibility of changing the domain as an open
issue for WG decision in draft-shaken)  

The only one who could do that (legally) would be the SSP, so I was
prepared-for/fine-with the SSP changing the domain to be the IP-PBX.
But then it occurred to me we're now changing the user portion, and
changing the domain, so what are we NOT changing?  The "@" character? ;)

The only thing we would gain, by circumventing rfc3261's rules, would be
"saving" the request-URI parameters.  But that just goes right back to
the debate about loose-route vs. Target vs. hist-info, and subverting
hist-info.  And I'm definitely no fan of hist-info, but that's what
we're stuck with for handling those. :(

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 8 Apr 2010 16:12:53 +0200

After rereading the martiniHHguide I think that Hadriel is referring to the
number normalisation/RFC3966 number format error fixing required in current
scenarios. Not sure if that is an issue at all that this solution has to
address.

/Hans Erik van Elburg

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 10:45:09 -0400

> From: Brian Lindsay [mailto:[email-masked]]
> Sent: Thursday, April 08, 2010 9:41 AM
> 

I explained it in the hitchhiker's guide.  It was not in draft-shaken, just like it's not in ETSI/3gpp/et-al.  But it actually makes a ton of sense, imo - so I was going to suggest we add it to draft-shaken, because normalizing the user name isn't that hard and does not require per-name or per-pbx config.  And it is a relatively common interop issue, which I failed to add to the "problems" draft.

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 8 Apr 2010 16:45:30 +0200

Hi Hadriel,

Inline..

/Hans Erik van Elburg

On Thu, Apr 8, 2010 at 3:38 PM, Hadriel Kaplan <[email-masked]>wrote:

> Hi Hans Erik,
> I think you are getting angry at the wrong person.  I was the main advocate
> for following the ETSI/3gpp loose-route model. (or one of the advocates
> anyway)
>
> I am not angry, but thankful for your wise words on that.

> I am just trying to explain how we got to where we are, over the course of
> 2 years of SIP-Forum and 4 Martini WG meetings of debate.
>
> It took ETSI/TISPAN also 2 painful years to get to an acceptable solution.

> I'm doing that because I want to get us all on the same page, so we can
> turn the page and get closer to the end. :)
>
> Believe me I want the same.

> Try to fire anything else then a number on it and it will break the SIP
routing of that. Now I always saw alphanumeric SIP URI's as what represents
SIP communication the most. Therefore this breaks the SIP routing model.

I can not without blinking the eyes say hej your shaken solution need to be
interoperable with all the SIP extensions in the world and then propose a
solution that violates that and don't apply the same criteria. That is just
an unfair comparison. Yeah maybe that makes me angry ;-)

> That was explained in the hitchhiker's guide. :)

OK, but that is not part of the solution is it.

> By definition, the *instant* you introduce a Required option-tag into
> ETSI/3GPP/IMS or SIP-Connect 1.0, it is no longer the "current" mechanism.
>
> Agree, but I have always been saying that we need to mutually align the
solutions. Fix the issues in the IMS solution as well. The IMS solution also
adresses alphanumeric SIP URI's so for that reason a solution that breaks
routing of those will be hard to get alignment on. Even if the charter of
martini has been carefully written to allow such solutions.

> That's the rub, no matter what happens.  So now you're saying, "we have
> more than 2 current mechanisms, let's add 2 more"?
>
> Ha ha. No, see previous answers.

> And as a side note, though not the main issue: for the GIN draft the
> REGISTER is actually formatted differently from SIP Connect 1.0 and
> ETSI/3gpp, in its contact URI.  You can't mix these models in the same
> REGISTER request.
>
> That's not a problem that we can't fix. We can do it in the mix.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 10:57:53 -0400

In my opinion it really is worth it to do that.  In fact, I'm ashamed to not have realized how critical that piece really is. :(  

If we had actually gone forward with JDR's loose-route mechanism in the IETF, we should/would have hit this same issue. (hopefully before publication!)
I'm not saying it would have been a deal breaker for loose-route - normalizing is relatively straight-forward - it just would have been important to address/fix. 

-hadriel

________________________________________
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 10:13 AM
To: Brian Lindsay
Cc: Hadriel Kaplan; [email-masked]
Subject: Re: [martini] Changing the domain (was: Hitchhiker's Guide to MakingMartini)

After rereading the martiniHHguide I think that Hadriel is referring to the number normalisation/RFC3966 number format error fixing required in current scenarios. Not sure if that is an issue at all that this solution has to address. 

/Hans Erik van Elburg

---

From: Doug Sauder <[email-masked]>
Date: Thu, 08 Apr 2010 10:05:40 -0500

A different way to look at this situation is that there are two ways we 
want to use the domain.

On the one hand, a SIP URI is a _name_ that identifies a subscriber, and 
the domain name allows the URI to be uniquely defined based on ownership 
of a domain name.  This is what is needed to allow the PBX to delegate 
the URI to the SSP for routing.   It's key for the IMS/ETSI solution to 
work correctly.

On the other hand, a SIP URI is an _address_, and the domain name is 
used in routing via RFC 3263 procedures.

The "URI as address" concept causes many of the problems that have been 
discussed on the list.  And the decision to limit the solution to public 
telephone numbers solves the problem of "URI as address", since a 
telephone number is really a name.

Hadriel's "is deeply entrenched" comment below could be understood to 
apply to the "URI as address" concept.  As long as a SIP URI is viewed 
primarily as an address, I can't see a shaken-type solution gaining any 
traction.

--
Doug Sauder

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Apr 2010 11:12:23 -0400

Hans Erik van Elburg wrote:

> routing of that. Now I always saw alphanumeric SIP URI's as what 
> represents SIP communication the most. Therefore this breaks the SIP 
> routing model.

We defined that out of scope, so of course it isn't addressed.

If we take it up again there are many rat holes to go down, and it will 
take time that people don't want to wait for.

Primarily, the whole issue of responsibility for domains, or parts of 
domains, will have to be confronted. It is vastly underspecified in 
3261, and I gather it was simply assumed not to be a problem in the 3gpp 
solution.

If you want to discuss that, this almost certainly isn't the right WG 
for it.

	Thanks,
	Paul