Subject: [martini] #21: 3.2.2 describes an issue with some PBX

From: "martini issue tracker" <[email-masked]>
Date: Tue, 23 Mar 2010 17:42:12 -0000

#21: 3.2.2 describes an issue with some PBX
-------------------------------------+--------------------------------------
 Reporter:  ietf.hanserik@…          |       Owner:            
     Type:  defect                   |      Status:  new       
 Priority:  minor                    |   Milestone:  milestone1
Component:  reqs                     |     Version:  1.0       
 Severity:  In WG Last Call          |    Keywords:            
-------------------------------------+--------------------------------------
 It is not clear why this document mentions an issue with some PBX, where
 these PBX do not comply with any of the trunking mechanisms defined.

 This chapter should focus on technical issues of the existing defined
 mechanisms not on issues with arbitrary PBX not interworking with a
 specified mechanism just for the reason they have not implemented the
 mechanism.

 Suggest to remove this section.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/21>
martini <http://tools.ietf.org/martini/>

---

From: "martini issue tracker" <[email-masked]>
Date: Thu, 25 Mar 2010 20:22:15 -0000

#21: 3.2.2 describes an issue with some PBX
-------------------------------------+--------------------------------------
 Reporter:  ietf.hanserik@…          |        Owner:            
     Type:  defect                   |       Status:  closed    
 Priority:  minor                    |    Milestone:  milestone1
Component:  reqs                     |      Version:  1.0       
 Severity:  In WG Last Call          |   Resolution:  invalid   
 Keywords:                           |  
-------------------------------------+--------------------------------------
Changes (by john.elwell@…):

  * status:  new => closed
  * resolution:  => invalid

Comment:

 The text of 3.2.2 just underlines the fact that there are different
 implementations around. A PBX that expects the loose route mechanism to be
 used would fail to interwork with SSPs using a different mechanism (e.g.,
 SIPconnect 1.0), and a PBX not expecting the loose route mechanism to be
 used would fail to interwork with a loose route implementation (e.g.,
 ETSI/3GPP). Hence the urgent need for a standard.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/21#comment:1>
martini <http://tools.ietf.org/martini/>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 26 Mar 2010 10:21:03 +0100

Then you should rephrase to what the real issue is:
"

Request-URI vs. loose-route acceptance

Some IP-PBX do not implement international standards or SIP profiles for SIP
trunking. As a consequence some SIP-PBXs expect that inbound SIP requests
from the SSP will have the registered Contact-URI in the Request-URI, and
thus not interoperate with the loose-route scheme of 3GPP and ETSI. Other
SIP-PBXs are fine with the Request-URI being the intended target, but cannot
handle receiving a Route header field identifying their registered
Contact-URI as a loose-route entry."

Is this an issue, yes. Does introducing yet another profile help? No.

/Hans Erik van Elburg

On Thu, Mar 25, 2010 at 9:22 PM, martini issue tracker
<[email-masked]>wrote:

> Ticket URL: <
> http://trac.tools.ietf.org/wg/martini/trac/ticket/21#comment:1>
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 26 Mar 2010 21:03:52 +0100

The IETF does not have a mechanism, and that is the reason for the MARTINI work. In particular, the IETF has not published the so-called loose-route mechanism. Hence the reason for the IETF, as owner of SIP, to publish a mechanism for bulk registrations.

John

> -----Original Message-----
> From: Hans Erik van Elburg [mailto:[email-masked]] 
> Sent: 26 March 2010 02:21
> To: [email-masked]
> Cc: Elwell, John; [email-masked]
> Subject: Re: [martini] #21: 3.2.2 describes an issue with some PBX
> 
> 
> Some IP-PBX do not implement international standards or SIP 
> profiles for SIP trunking. As a consequence some SIP-PBXs 
> expect that inbound SIP requests from the SSP will have the 
> registered Contact-URI in the Request-URI, and thus not 
> interoperate with the loose-route scheme of 3GPP and ETSI. 
> Other SIP-PBXs are fine with the Request-URI being the 
> intended target, but cannot handle receiving a Route header 
> field identifying their registered Contact-URI as a 
> loose-route entry."
> 
> 
> <[email-masked]> wrote:
> 
> 
> 	 Reporter:  ietf.hanserik@...          |        Owner:
> 	
> 	Changes (by john.elwell@...):
> 	
> 	 * status:  new => closed
> 	 * resolution:  => invalid
> 	
> 	
> 	Comment:
> 	
> 	
> 	Ticket URL: 
> <http://trac.tools.ietf.org/wg/martini/trac/ticket/21#comment:1>
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Sat, 27 Mar 2010 00:03:13 +0100

I will not argue with you about the validity of that argument.

Can you agree to the modified text?

"Request-URI vs. loose-route acceptance

BR,
/Hans Erik van Elburg

On Fri, Mar 26, 2010 at 9:03 PM, Elwell, John <
[email-masked]> wrote:

> The IETF does not have a mechanism, and that is the reason for the MARTINI
> work. In particular, the IETF has not published the so-called loose-route
> mechanism. Hence the reason for the IETF, as owner of SIP, to publish a
> mechanism for bulk registrations.
>
> John
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 26 Mar 2010 23:09:23 -0400

Actually that's not really the problem, or the motivation for the work, imho.

Prroblem-1 is there is absolutely no way the SSP's equipment will know whether the IP-PBX does international standard X, Y or Z from the REGISTER request in those international standards.  And there is no way for the IP-PBX to know what international standard the SSP does.  Now obviously you can have the operator provision every single trunk with X, Y or Z mode, based on some big list of every IP-PBX vendor's product and version number and whether it supports mode X, Y or Z.  For medium-to-large Enterprise trunks that's ok - manual configuration and such is perfectly reasonable/justified for them.  But for the small-business market with high- volume and low margin per sale, it's a barrier to deployment.

But that's only problem-1.  Problem-2 is the 3GPP/ETSI specs say "loose-routing", but if that's followed verbatim then the PBX will get a request-URI with a domain of the SSP, which again some support and some don't. (and I think even ETSI would admit was a mistake, if they wanted the signaling to act the same as a peering model)  Some PBX's are ok with "loose-routing", but expect their own domain; others are ok getting the SSP's domain.  So that's mode X.a and X.b to provision.  And that provisioning is often not done in the HSS, but rather in the border proxy that "fixes" it, and that's another barrier to deployment.

And I don't think anyone's blaming 3GPP or ETSI for this, by the way - the IETF doesn't have a perfect record by a long shot either on this type of stuff, and really this all started in SIP-Forum in SIP-Connect 1.0 years ago when we punted on truly specifying Registration mode and thereby caused a lot more interop issues. (at least it seems to me it all started there)  We're trying to fix our mistakes, not ETSI's, but with the benefit of experience gained from all of the international standards.

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
Sent: Friday, March 26, 2010 7:03 PM
To: Elwell, John
Cc: [email-masked]
Subject: Re: [martini] #21: 3.2.2 describes an issue with some PBX

"Request-URI vs. loose-route acceptance
Some IP-PBX do not implement international standards or SIP profiles for SIP trunking. As a consequence some SIP-PBXs expect that inbound SIP requests from the SSP will have the registered Contact-URI in the Request-URI, and thus not interoperate with the loose-route scheme of 3GPP and ETSI. Other SIP-PBXs are fine with the Request-URI being the intended target, but cannot handle receiving a Route header field identifying their registered Contact-URI as a loose-route entry."

BR,
/Hans Erik van Elburg
On Fri, Mar 26, 2010 at 9:03 PM, Elwell, John <[email-masked]<mailto:[email-masked]>> wrote:
The IETF does not have a mechanism, and that is the reason for the MARTINI work. In particular, the IETF has not published the so-called loose-route mechanism. Hence the reason for the IETF, as owner of SIP, to publish a mechanism for bulk registrations.

John

> From: Hans Erik van Elburg [mailto:[email-masked]<mailto:[email-masked]>]
> To: [email-masked]<mailto:[email-masked]>
> Cc: Elwell, John; [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>       [email-masked]<mailto:[email-masked]>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 29 Mar 2010 17:56:37 +0200

Hans Erik,

As an individual, I disagree with the proposed text, since it is misleading. The "international standards" to which you prefer are standards specific to an IMS environment. The implication of the wording as proposed is that SIP-PBXs ought to implement IMS specifications. And as Hadriel points out, implementing those IMS specifications does not eliminate the problems that the SIPconnect people are trying to solve. I believe the existing text in draft-03 is sufficient.

John

> Sent: 26 March 2010 23:03
> To: Elwell, John
> Cc: [email-masked]
> On Fri, Mar 26, 2010 at 9:03 PM, Elwell, John 
> <[email-masked]> wrote:
> 
> 
> 	The IETF does not have a mechanism, and that is the 
> reason for the MARTINI work. In particular, the IETF has not 
> published the so-called loose-route mechanism. Hence the 
> reason for the IETF, as owner of SIP, to publish a mechanism 
> for bulk registrations.
> 	
> 	John
> 	
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 29 Mar 2010 18:27:02 +0200

Hi John,

I was just trying to find a text that describes the issue.

But now the issue reads like "some PBX like apples, some like bananas". To
me that does not sound like a usefull issue to describe in an RFC.

So I think one or two more sentence would make clear why this is an issue.

I think there is multiple underlying issues here:
- PBX have different SIP profiles or all SIP-PBX are different
- PBX support SIP trunking flavour A, or support SIP trunking flavour B
- SSP systems don't know what mechanism the PBX support (can be resolved
with explicit indicator, this draft proposes an indicator for flavour B but
for another purpose it seems)
- PBX do not know what SIP trunking flavour the SSP supports (not addressed
it seems)

I don't seem to have a lucky hand with proposing an improved text, so maybe
you should have a go at it.

BR,
/Hans Erik van Elburg

p.s. I never said or implied that a SIP-PBX shall implement IMS. But it
would be really, really, really good if they would interwork on the UNI with
the IMS business trunking.  I think that should also be in your interest and
in fact you have been part of that work...

On Mon, Mar 29, 2010 at 5:56 PM, Elwell, John <
[email-masked]> wrote:

> Hans Erik,
>
> As an individual, I disagree with the proposed text, since it is
> misleading. The "international standards" to which you prefer are standards
> specific to an IMS environment. The implication of the wording as proposed
> is that SIP-PBXs ought to implement IMS specifications. And as Hadriel
> points out, implementing those IMS specifications does not eliminate the
> problems that the SIPconnect people are trying to solve. I believe the
> existing text in draft-03 is sufficient.
>
> John
>

---

From: <[email-masked]>
Date: Mon, 29 Mar 2010 18:34:34 +0200

I fully agree with what Hans Erik has said in the Postscriptum "it would be really, really, really good if they (the IP PBX) would interwork on the UNI with the IMS business trunking". I believe that most operators share the same view... and presumably some vendors as well...

De : [email-masked] [mailto:[email-masked]] De la part de Hans Erik van Elburg
Envoyé : lundi 29 mars 2010 18:27
À : Elwell, John
Cc : [email-masked]
Objet : Re: [martini] #21: 3.2.2 describes an issue with some PBX

	Hi John,

	But now the issue reads like "some PBX like apples, some like bananas". To me that does not sound like a usefull issue to describe in an RFC.

	I think there is multiple underlying issues here:
	- PBX have different SIP profiles or all SIP-PBX are different
	- PBX support SIP trunking flavour A, or support SIP trunking flavour B
	- SSP systems don't know what mechanism the PBX support (can be resolved with explicit indicator, this draft proposes an indicator for flavour B but for another purpose it seems)
	- PBX do not know what SIP trunking flavour the SSP supports (not addressed it seems)
	
	I don't seem to have a lucky hand with proposing an improved text, so maybe you should have a go at it.
	
	BR,
	/Hans Erik van Elburg
	
	p.s. I never said or implied that a SIP-PBX shall implement IMS. But it would be really, really, really good if they would interwork on the UNI with the IMS business trunking.  I think that should also be in your interest and in fact you have been part of that work...

	On Mon, Mar 29, 2010 at 5:56 PM, Elwell, John <[email-masked]> wrote:

		Hans Erik,

		John

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 29 Mar 2010 13:07:36 -0400

Has any of this IMS business trunking stuff actually deployed?

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Monday, March 29, 2010 12:35 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [martini] #21: 3.2.2 describes an issue with some PBX

I fully agree with what Hans Erik has said in the Postscriptum "it would be
really, really, really good if they (the IP PBX) would interwork on the UNI
with the IMS business trunking". I believe that most operators share the
same view... and presumably some vendors as well...

  _____  

De : [email-masked] [mailto:[email-masked]] De la part
de Hans Erik van Elburg
Envoyé : lundi 29 mars 2010 18:27
À : Elwell, John
Cc : [email-masked]
Objet : Re: [martini] #21: 3.2.2 describes an issue with some PBX

Hi John,

BR,
/Hans Erik van Elburg

On Mon, Mar 29, 2010 at 5:56 PM, Elwell, John
<[email-masked]> wrote:

Hans Erik,

As an individual, I disagree with the proposed text, since it is misleading.
The "international standards" to which you prefer are standards specific to
an IMS environment. The implication of the wording as proposed is that
SIP-PBXs ought to implement IMS specifications. And as Hadriel points out,
implementing those IMS specifications does not eliminate the problems that
the SIPconnect people are trying to solve. I believe the existing text in
draft-03 is sufficient.

John

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 29 Mar 2010 19:18:09 +0200

Yes, there exist IMS business trunking solutions in several countries.

/Hans Erik van Elburg

On Mon, Mar 29, 2010 at 7:07 PM, Richard Shockey <[email-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of [email-masked]
> *Sent:* Monday, March 29, 2010 12:35 PM
> *To:* [email-masked]; [email-masked]
>
> *Cc:* [email-masked]
> *Subject:* Re: [martini] #21: 3.2.2 describes an issue with some PBX
>
>
>
>  ------------------------------
>
> *De :* [email-masked] [mailto:[email-masked]] *De la
> part de* Hans Erik van Elburg
> *Envoyé :* lundi 29 mars 2010 18:27
> *À :* Elwell, John
> *Cc :* [email-masked]
> *Objet :* Re: [martini] #21: 3.2.2 describes an issue with some PBX
>
> Hi John,
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Mar 2010 14:59:53 -0400

Yes, in several large IMS deployments.  That's where we discovered some of the problems identified in the drafts.
-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Monday, March 29, 2010 1:08 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [martini] #21: 3.2.2 describes an issue with some PBX

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Mar 2010 15:15:49 -0400

Absolutely - that's one of the advantages of the Martini mechanism having an options-tag.  If the IP-PBX indicates the option-tag but the REGISTER response does not (i.e., is rejected with 420), then the IP-PBX would revert to doing whatever it is it "normally" does.  Unfortunately there was no explicit indicator of the ETSI nor SIP-Connect 1.0 models, so how the IP-PBX behaves "normally" is unknown a priori.

And of course the IP-PBX could always be configured to just do ETSI or SIP-Connect 1.0 models, as has previously been the case; and the nice thing with Martini is if the SSP only supports Martini then it can indicate the option-tag is required in its response (by responding to the REGISTER with a 421).

-hadriel

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Mar 2010 15:21:54 -0400

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
Sent: Monday, March 29, 2010 12:27 PM
To: Elwell, John

I think there is multiple underlying issues here:
- PBX have different SIP profiles or all SIP-PBX are different
- PBX support SIP trunking flavour A, or support SIP trunking flavour B
- SSP systems don't know what mechanism the PBX support (can be resolved with explicit indicator, this draft proposes an indicator for flavour B but for another purpose it seems)
Actually I did assume the use of the options-tag would indicate to the SSP "this is what I do". (as well as "this is what I need you to do too", hence in Require and Proxy-Require headers)
That was one of the main drivers for the options-tag - we needed to know the IP-PBX implemented Martini.

- PBX do not know what SIP trunking flavour the SSP supports (not addressed it seems)
There was no way to indicate the SSP supports SIP Connect 1.0 or ETSI, but for Martini the SSP would respond with a 421 with the options-tag, if it needs/expects Martini.
-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 29 Mar 2010 21:55:53 +0200

Hans Erik,

I think the point you are trying to make is that it is not one-sided. The fact is, each side has different ways of working, and you need to have the two sides operating in compatible manners for it to work. In practice, I think there are other variants, besides the two cited in the present 3.2.2. I would suggest:

        <t>Even where all information needed by the SIP-PBX is provided, in some deployments inbound SIP requests from the SSP have the registered Contact URI in the Request-URI, whereas in other deployments inbound SIP requests have the intended target (AOR) in the Request-URI and the Contact URI in the Route header field. There are other variants too. Interoperability problems arise when a PBX designed for or configured for one variant attempts to interwork with an SSP designed for or configured for another variant.</t>

To accompany this, I think the title of the section should be changed too: "Inconsistent placement of information in inbound requests"

John 

> Sent: 29 March 2010 17:27
> To: Elwell, John
> Cc: [email-masked]
> But now the issue reads like "some PBX like apples, some like 
> bananas". To me that does not sound like a usefull issue to 
> describe in an RFC.
> 
> - SSP systems don't know what mechanism the PBX support (can 
> be resolved with explicit indicator, this draft proposes an 
> indicator for flavour B but for another purpose it seems)
> I don't seem to have a lucky hand with proposing an improved 
> text, so maybe you should have a go at it.
> 
> BR,
> /Hans Erik van Elburg
> 
> p.s. I never said or implied that a SIP-PBX shall implement 
> IMS. But it would be really, really, really good if they 
> would interwork on the UNI with the IMS business trunking.  I 
> think that should also be in your interest and in fact you 
> have been part of that work...
> 
> 
> 
> 	As an individual, I disagree with the proposed text, 
> since it is misleading. The "international standards" to 
> which you prefer are standards specific to an IMS 
> environment. The implication of the wording as proposed is 
> that SIP-PBXs ought to implement IMS specifications. And as 
> Hadriel points out, implementing those IMS specifications 
> does not eliminate the problems that the SIPconnect people 
> are trying to solve. I believe the existing text in draft-03 
> is sufficient.
> 	
> 
> 	John
> 	
> 	>       >        The text of 3.2.2 just underlines the 
> fact that there
> 	>       > are different
> 	>       >        implementations around. A PBX that 
> expects the loose
> 	>       > route mechanism to be
> 	>       >        SIPconnect 1.0), and a PBX not 
> expecting the loose
> 	>       > route mechanism to be

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 29 Mar 2010 22:09:23 +0200

> have been part of that work...
[JRE] Yes, I was part of that work. We based it on the loose route mechanism, which was never adopted by the IETF, and furthermore some of the issues I had at the time with domain names and routing were never properly answered by TISPAN. TISPAN's working method was to adopt only what 3GPP adopted for IMS, and I understood that 3GPP's working method was to adopt only protocol specified by the IETF. Something went wrong at some stage, and the TISPAN work has turned out not to be IETF compliant. At least that is how many of the IETF SIP experts view it - if you can convince them otherwise, fine, but unfortunately that is the situation.

I just want to see a solution coming out of MARTINI that works and does not have too much impact on SIP-PBXs. The gin- proposal is in fact quite close to some of our existing deployments (with non-IMS SSPs, I guess) so I don't have a problem with that, and that seems to be the direction the WG is going.

John

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Mar 2010 05:40:31 +0200

Hi,

Having an option-tag is fine, but it will only help for negotiation, and to figure out what is supported. You are still going to end up having two different solutions that do not interwork with each other.

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: 29. maaliskuuta 2010 22:16
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [martini] #21: 3.2.2 describes an issue with some PBX

-hadriel

---

From: <[email-masked]>
Date: Tue, 30 Mar 2010 09:32:23 +0200

I guess the large IMS deployments where you discovered the problems identified in the drafts were based on versions of the IMS that did not include the "loose-route" mechanism (e.g. Release 7) and/or were using IP PBX that were not compliant to IMS Release 8. Right?

	De : Hadriel Kaplan [mailto:[email-masked]] 
	Envoyé : lundi 29 mars 2010 21:00
	À : Richard Shockey; CHATRAS Bruno RD-CORE-ISS; [email-masked]; [email-masked]
	Cc : [email-masked]
	Objet : RE: [martini] #21: 3.2.2 describes an issue with some PBX

	-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 30 Mar 2010 12:49:06 +0200

Hi John,

Inline...

/Hans Erik van Elburg

On Mon, Mar 29, 2010 at 9:55 PM, Elwell, John <
[email-masked]> wrote:

> Hans Erik,
>
> I think the point you are trying to make is that it is not one-sided. The
> fact is, each side has different ways of working, and you need to have the
> two sides operating in compatible manners for it to work. In practice, I
> think there are other variants, besides the two cited in the present 3.2.2.

Yes. And there is no objective way to automatically determine what variant
the PBX or the SSP is supporting. Which is what an options tag could
resolve.

> I would suggest:
>
>        <t>Even where all information needed by the SIP-PBX is provided, in
> some deployments inbound SIP requests from the SSP have the registered
> Contact URI in the Request-URI, whereas in other deployments inbound SIP
> requests have the intended target (AOR) in the Request-URI and the Contact
> URI in the Route header field. There are other variants too.
> Interoperability problems arise when a PBX designed for or configured for
> one variant attempts to interwork with an SSP designed for or configured for
> another variant.</t>
>
Yes, slightly modified to add the objective means issue:
 <t>Even where all information needed by the SIP-PBX is provided, in some
deployments inbound SIP requests from the SSP have the registered PBX
Contact URI in the Request-URI, whereas in other deployments inbound SIP
requests have the intended target PBX user (AOR) in the Request-URI and the
Contact URI in the Route header field. There are other variants too.
Interoperability problems arise when a PBX designed for or configured for
one variant attempts to interwork with an SSP designed for or configured for
another variant. There is currently no objective means in the signalling
during registration for either party to discover what mechanism the other
side supports.</t>

> To accompany this, I think the title of the section should be changed too:
> "Inconsistent placement of information in inbound requests"
>
> Yes, slightly modified to make it more specific: "Inconsistent placement of
target URI information in inbound requests".

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 30 Mar 2010 13:03:17 -0400

Some of them must have included the loose-route, because we had to go fix our own behavior for that mode (we previously expected the registered contact to be the req-uri).
Whether the IP-PBX's are compliant or not I don't know - I just know we have to modify/fix the req-uri on a case-by-case basis, requiring per-trunk config/behavior.

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 30, 2010 3:32 AM
To: Hadriel Kaplan; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [martini] #21: 3.2.2 describes an issue with some PBX

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 30 Mar 2010 13:10:00 -0400

Sure, if you have a box that can only do X, and another than can only do Y, you've got a problem.
You're already in that situation now, if you have a SIP-Connect 1.0 PBX and an IMS network, or a SIP-Connect 1.0 network and an IMS IP-PBX.  Heck, SIP-Connect 1.0 talking to itself has problems, since the registration mechanism was so under-specified in it.
There's not much we can do about that, is there?

-hadriel

________________________________
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, March 29, 2010 11:41 PM
To: Hadriel Kaplan; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [martini] #21: 3.2.2 describes an issue with some PBX

Hi,

Regards,

Christer

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 30 Mar 2010 19:11:23 +0200

OK, fixed in my working copy.

John

________________________________
From: Hans Erik van Elburg [mailto:[email-masked]]
Sent: 30 March 2010 11:49
To: Elwell, John
Cc: [email-masked]
Subject: Re: [martini] #21: 3.2.2 describes an issue with some PBX

Hi John,

Inline...

/Hans Erik van Elburg

On Mon, Mar 29, 2010 at 9:55 PM, Elwell, John <[email-masked]<mailto:[email-masked]>> wrote:
Hans Erik,

I think the point you are trying to make is that it is not one-sided. The fact is, each side has different ways of working, and you need to have the two sides operating in compatible manners for it to work. In practice, I think there are other variants, besides the two cited in the present 3.2.2.
Yes. And there is no objective way to automatically determine what variant the PBX or the SSP is supporting. Which is what an options tag could resolve.

I would suggest:

       <t>Even where all information needed by the SIP-PBX is provided, in some deployments inbound SIP requests from the SSP have the registered Contact URI in the Request-URI, whereas in other deployments inbound SIP requests have the intended target (AOR) in the Request-URI and the Contact URI in the Route header field. There are other variants too. Interoperability problems arise when a PBX designed for or configured for one variant attempts to interwork with an SSP designed for or configured for another variant.</t>
Yes, slightly modified to add the objective means issue:
 <t>Even where all information needed by the SIP-PBX is provided, in some deployments inbound SIP requests from the SSP have the registered PBX Contact URI in the Request-URI, whereas in other deployments inbound SIP requests have the intended target PBX user (AOR) in the Request-URI and the Contact URI in the Route header field. There are other variants too. Interoperability problems arise when a PBX designed for or configured for one variant attempts to interwork with an SSP designed for or configured for another variant. There is currently no objective means in the signalling during registration for either party to discover what mechanism the other side supports.</t>

Yes, slightly modified to make it more specific: "Inconsistent placement of target URI information in inbound requests".

John

> Cc: [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>       Hans Erik,
>
>       > Cc: [email-masked]<mailto:[email-masked]>
>       > <[email-masked]<mailto:[email-masked]>> wrote:
>       >
>       >
>       >       > From: Hans Erik van Elburg
> [mailto:[email-masked]<mailto:[email-masked]>]

---

From: <[email-masked]>
Date: Tue, 30 Mar 2010 19:15:52 +0200

OK. If loose-route was implemented in some of these IMS networks (I guess I know at least one of them) and you had to modify the R-URI on a per-trunk basis, it just means that some of the IP-PBXs connected to them were not IMS-compliant. Quite predictable as this loose-route mechanism is relatively new and therefore not yet available on all systems. Similarly, if a network implements the GIN solution, you will have to modify the R-URI on per-trunk basis because some of the IP-PBXs will be loose-route compliant and will therefore not be GIN-compliant. Where is the improvement compared to the current situation?

De : Hadriel Kaplan [mailto:[email-masked]] 
Envoyé : mardi 30 mars 2010 19:03
À : CHATRAS Bruno RD-CORE-ISS; [email-masked]; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: [martini] #21: 3.2.2 describes an issue with some PBX

	-hadriel

		 

		-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 30 Mar 2010 13:28:08 -0400

So ..what your point??  

I'm not a great fan of one size fits all or "there can only be one"
solution. Its why you have markets.

The Option Tag IMHO is the real key here as you correctly point out the
problem is figuring out what is supported and returning an appropriate
response. That is the issue with both the IMS and SIP Connect 1.0
implementations.

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Christer Holmberg
Sent: Monday, March 29, 2010 11:41 PM
To: 'Hadriel Kaplan'; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [martini] #21: 3.2.2 describes an issue with some PBX

Hi,

Having an option-tag is fine, but it will only help for negotiation, and to
figure out what is supported. You are still going to end up having two
different solutions that do not interwork with each other.

Regards,

Christer

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hadriel Kaplan
Sent: 29. maaliskuuta 2010 22:16
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: Re: [martini] #21: 3.2.2 describes an issue with some PBX

Absolutely - that's one of the advantages of the Martini mechanism having an
options-tag.  If the IP-PBX indicates the option-tag but the REGISTER
response does not (i.e., is rejected with 420), then the IP-PBX would revert
to doing whatever it is it "normally" does.  Unfortunately there was no
explicit indicator of the ETSI nor SIP-Connect 1.0 models, so how the IP-PBX
behaves "normally" is unknown a priori.  

And of course the IP-PBX could always be configured to just do ETSI or
SIP-Connect 1.0 models, as has previously been the case; and the nice thing
with Martini is if the SSP only supports Martini then it can indicate the
option-tag is required in its response (by responding to the REGISTER with a
421).

-hadriel

  _____

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 30 Mar 2010 14:35:29 -0400

Sent: Tuesday, March 30, 2010 1:16 PM

Because then for the GIN-compliant devices you know they're GIN compliant from their signaling.  There is no per-trunk guessing/config for the GIN-compliant case.  It's true that some operators will have legacy IP-PBX's, but now they'll know which ones are not legacy anymore - right now they don't.  They don't know when an IP-PBX gets upgraded to support IMS, and they don't know whether it is IMS to begin with.

The current situation isn't that bad, when dealing with medium-to-large Enterprise trunks.  Provisioning is fine for that.  But in SIP-Connect 1.1 we were faced with trying to handle/support the large-volume small-business trunk case, and for that we're trying to keep provisioning as low as possible, in as few systems as possible.  And we needed the tools to help find mismatches.  Hence the option-tag.

Personally I was hoping to just take IMS/ETSI and add the option-tag and minor tweaks - that was the "shaken" draft in essence, but the WG was split and we needed to move forward.  And GIN really isn't that much different either - is there something you'd like to see in GIN to make it more like the ETSI/IMS mechanism?

-hadriel
p.s. Actually my guess is that even if all sides think they're IMS compliant, that we'd have to re-write the req-uri on a case-by-case basis.  Because it's not clear what it should be.  Is the domain-portion the PBX gets supposed to be "ssp.com", or "pbx.com"?  Is it either/both?  Could it be "ims.ssp.com", or even "s-cscf.ssp.com"?  Because those last two type/forms of host/domain names appear in the request-uri of requests received at the S-CSCF all the time in some IMS networks, so if IMS "loose-route" literally means "do-not-touch-the-request-uri", it will be fraught with issues.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Mar 2010 07:50:37 +0200

Hi, 

>So ..what your point??  
>
>I'm not a great fan of one size fits all or "there can only be one" solution. Its why you have markets.

That is true, if you have fundamentally different requirements, use-cases etc. 

But, is that really the case here? The only thing I've heard is that "the IMS solution cannot be made to work", and that we therefor need a different solution.

And, if people are ok with two solutions, why was there a suggestion to send an LS to 3GPP and ask them to adopt the IETF solution?

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Monday, March 29, 2010 11:41 PM
To: 'Hadriel Kaplan'; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [martini] #21: 3.2.2 describes an issue with some PBX

Hi,

Regards,

Christer

-hadriel

---

From: <[email-masked]>
Date: Wed, 31 Mar 2010 09:26:13 +0200

De : Hadriel Kaplan [mailto:[email-masked]] 
	Envoyé : mardi 30 mars 2010 20:35
	À : CHATRAS Bruno RD-CORE-ISS; [email-masked]; [email-masked]; [email-masked]
	Cc : [email-masked]
	Objet : RE: [martini] #21: 3.2.2 describes an issue with some PBX

	 

	Personally I was hoping to just take IMS/ETSI and add the option-tag and minor tweaks - that was the "shaken" draft in essence
	[==>BC:] Yes I remember that and would have preferred going down this route.

	 , but the WG was split and we needed to move forward.  And GIN really isn't that much different either - is there something you'd like to see in GIN to make it more like the ETSI/IMS mechanism?
	[==>BC:] Of course. I would like the R-URI to contain the initial target identity rather than this special contact address. 

	-hadriel

	p.s. Actually my guess is that even if all sides think they're IMS compliant, that we'd have to re-write the req-uri on a case-by-case basis.  Because it's not clear what it should be.  Is the domain-portion the PBX gets supposed to be "ssp.com", or "pbx.com"?  Is it either/both?  Could it be "ims.ssp.com", or even "s-cscf.ssp.com"?  
	[==>BC:] The domain portion can be "xxx.ssp.com" or "xxx.entreprise.com" with the understanding that the DNS maps "xxx.entreprise.com" to the SSP's network entry point.

	 Because those last two type/forms of host/domain names appear in the request-uri of requests received at the S-CSCF all the time in some IMS networks, so if IMS "loose-route" literally means "do-not-touch-the-request-uri", it will be fraught with issues.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 31 Mar 2010 13:18:30 +0200

So assuming that this text is accepted, I guess the key argument of providing this distinction is not that both behaviours are non-standard, but that some means is needed to distinguish the two.

While I do not have a problem with that specifically, I still have an issue that providing some signalling to do this solves all the issues. There are all sorts of other issues associated with what the PBX "expects" that also cause all sorts of issues, such as whether it expects a tel URI in tel URI format or SIP URI format, and so on, that are not signalled.

Therefore at the end of the day, one is still going to end up with configuration information at either end of this interface that is not explicitly signalled, and in the absence of both sides having preconfigured knowledge of that information, the interface is not going to work.

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Tuesday, March 30, 2010 6:11 PM
To: Hans Erik van Elburg
Cc: [email-masked]
Subject: Re: [martini] #21: 3.2.2 describes an issue with some PBX

John

Hi John,

Inline...

/Hans Erik van Elburg

I would suggest:

John

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 31 Mar 2010 08:47:55 -0500

Hi, Christer,

> And, if people are ok with two solutions, why was there a suggestion to 
> send an LS to 3GPP and ask them to adopt the IETF solution?

Speaking as chair, a lot of things get suggested in IETF working group 
meetings, especially the ones that happen after lunch on Friday, but I 
wouldn't read too much into the face that this suggestion was raised.

As of IETF 77, I'm now the IAB liaison shepherd for 3GPP, and Gonzalo is 
continuing as liaison for 3GPP. We talked after MARTINI broke up, and I 
don't think either one of us thought sending a liaison statement to 3GPP 
with this suggestion was on the list of action items after the meeting...

:D

Spencer

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 31 Mar 2010 08:51:00 -0500

Just fixing a typo...

> wouldn't read too much into the face that this suggestion was raised.

"... the fact that ..."

Sorry!

Spencer

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 31 Mar 2010 10:02:22 -0400

> Sent: Wednesday, March 31, 2010 1:51 AM
> To: 'Richard Shockey'; Hadriel Kaplan; [email-masked];
> 

I didn't mean they had to deprecate the old way - they can if they feel so inclined - but all I was asking was that they support Martini as well, so that IP-PBX's which do Martini could be supported by IMS networks.

-hadriel

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 31 Mar 2010 16:10:58 +0200

So you want 3GPP to also support a mechanism that has less functionality just because IETF has decided to go off in a different direction.

The 3GPP solution adequately handles private numbering plans, SIP URIs, interworking with Centrex type solutions, provision of special services for private networked calls, all of which have been omitted from the current martini solution.

regards

Keith 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: Wednesday, March 31, 2010 3:02 PM
> To: Christer Holmberg; 'Richard Shockey'; 
> [email-masked]; [email-masked]; 
> > And, if people are ok with two solutions, why was there a 
> suggestion 
> > to send an LS to 3GPP and ask them to adopt the IETF solution?
> 
> I didn't mean they had to deprecate the old way - they can if 
> they feel so inclined - but all I was asking was that they 
> support Martini as well, so that IP-PBX's which do Martini 
> could be supported by IMS networks.
> 
> -hadriel

---

From: Adam Roach <[email-masked]>
Date: Wed, 31 Mar 2010 09:13:11 -0500

On 3/31/10 6:18 AM, DRAGE, Keith (Keith) wrote:
> ...I still have an issue that providing some signalling to do this 
> solves all the issues. There are all sorts of other issues associated 
> with what the PBX "expects" that also cause all sorts of issues, such 
> as whether it expects a tel URI in tel URI format or SIP URI format...

What are you talking about? GIN nails down the format what shows up at 
the PBX: they're SIP (or SIPS) URIs.

> ...and so on, that are not signalled.

Regarding the other things that GIN does not solve: keep in mind that 
we're not addressing every possible PBX/SSP interconnect issue here. 
MARTINI has a refreshingly narrow charter, and that is by design. From 
an IETF perspective, the rest of the peering problem space is being 
solved mostly in SPEERMINT and DRINKS.

I suggest you and Hans Erik take a moment to refresh your memories about 
what we're working on here: https://datatracker.ietf.org/wg/martini/charter/

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 31 Mar 2010 16:15:52 +0200

We are talking about the an issue on the requirements document here - not a solutions document that as far as I am concerned does not have consensus

Keith

________________________________
From: Adam Roach [mailto:[email-masked]]
Sent: Wednesday, March 31, 2010 3:13 PM
To: DRAGE, Keith (Keith)
Cc: Elwell, John; Hans Erik van Elburg; [email-masked]
Subject: Re: [martini] #21: 3.2.2 describes an issue with some PBX

On 3/31/10 6:18 AM, DRAGE, Keith (Keith) wrote:
...I still have an issue that providing some signalling to do this solves all the issues. There are all sorts of other issues associated with what the PBX "expects" that also cause all sorts of issues, such as whether it expects a tel URI in tel URI format or SIP URI format...

What are you talking about? GIN nails down the format what shows up at the PBX: they're SIP (or SIPS) URIs.

Regarding the other things that GIN does not solve: keep in mind that we're not addressing every possible PBX/SSP interconnect issue here. MARTINI has a refreshingly narrow charter, and that is by design. From an IETF perspective, the rest of the peering problem space is being solved mostly in SPEERMINT and DRINKS.

I suggest you and Hans Erik take a moment to refresh your memories about what we're working on here: https://datatracker.ietf.org/wg/martini/charter/

/a

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 31 Mar 2010 16:17:28 +0200

Adam,

Did that several times:
"The task of this working group is to to standardize a multiple-AoR
registration mechanism for SIP that can be widely deployed by service
providers at large scale."

/Hans Erik van Elburg

On Wed, Mar 31, 2010 at 4:13 PM, Adam Roach <[email-masked]> wrote:

>  ...I still have an issue that providing some signalling to do this solves
> all the issues. There are all sorts of other issues associated with what the
> PBX "expects" that also cause all sorts of issues, such as whether it
> expects a tel URI in tel URI format or SIP URI format...
>
>
> Regarding the other things that GIN does not solve: keep in mind that we're
> not addressing every possible PBX/SSP interconnect issue here. MARTINI has a
> refreshingly narrow charter, and that is by design. From an IETF
> perspective, the rest of the peering problem space is being solved mostly in
> SPEERMINT and DRINKS.
>
> what we're working on here:
> https://datatracker.ietf.org/wg/martini/charter/
>
> /a
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 31 Mar 2010 09:20:21 -0500

> providers at large scale."

And, from that, you deduced that we need to talk about SDP profiles?

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 Mar 2010 10:38:52 -0400

DRAGE, Keith (Keith) wrote:
> So assuming that this text is accepted, I guess the key argument of 
> providing this distinction is not that both behaviours are non-standard, 
> but that some means is needed to distinguish the two.
>  
> While I do not have a problem with that specifically, I still have an 
> issue that providing some signalling to do this solves all the issues. 
> There are all sorts of other issues associated with what the PBX 
> "expects" that also cause all sorts of issues, such as whether it 
> expects a tel URI in tel URI format or SIP URI format, and so on, that 
> are not signalled.

> Therefore at the end of the day, one is still going to end up with 
> configuration information at either end of this interface that is not 
> explicitly signalled, and in the absence of both sides having 
> preconfigured knowledge of that information, the interface is not going 
> to work.

The simple answer to this is that such "expectations" should be 
abandoned, in favor of supporting all valid usage that conforms to the 
basic standards and specified options. It is not rocket science to 
support a tel URI. (Though I'm not certain what the context is where 
that particular issue would come up.)

	Thanks,
	Paul

> regards
>  
> Keith
>  
> ------------------------------------------------------------------------
> Behalf Of *Elwell, John
> *Sent:* Tuesday, March 30, 2010 6:11 PM
> *To:* Hans Erik van Elburg
> *Cc:* [email-masked]
>         ------------------------------------------------------------------------
>         *From:* Hans Erik van Elburg [mailto:[email-masked]]
>         *Sent:* 30 March 2010 11:49
>         *To:* Elwell, John
>         *Cc:* [email-masked]
>         On Mon, Mar 29, 2010 at 9:55 PM, Elwell, John
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
> 
>             Hans Erik,
> 
>             I think the point you are trying to make is that it is not
>             one-sided. The fact is, each side has different ways of
>             working, and you need to have the two sides operating in
>             compatible manners for it to work. In practice, I think
>             there are other variants, besides the two cited in the
>             present 3.2.2.
> 
>         Yes. And there is no objective way to automatically determine
>         what variant the PBX or the SSP is supporting. Which is what an
>         options tag could resolve.
>          
> 
>             I would suggest:
> 
>                    <t>Even where all information needed by the SIP-PBX
>             is provided, in some deployments inbound SIP requests from
>             the SSP have the registered Contact URI in the Request-URI,
>             whereas in other deployments inbound SIP requests have the
>             intended target (AOR) in the Request-URI and the Contact URI
>             in the Route header field. There are other variants too.
>             Interoperability problems arise when a PBX designed for or
>             configured for one variant attempts to interwork with an SSP
>             designed for or configured for another variant.</t>
> 
>          <t>Even where all information needed by the SIP-PBX is
>         provided, in some deployments inbound SIP requests from the SSP
>         have the registered PBX Contact URI in the Request-URI, whereas
>         in other deployments inbound SIP requests have the intended
>         target PBX user (AOR) in the Request-URI and the Contact URI in
>         the Route header field. There are other variants too.
>         Interoperability problems arise when a PBX designed for or
>         configured for one variant attempts to interwork with an SSP
>         designed for or configured for another variant. There is
>         currently no objective means in the signalling during
>         registration for either party to discover what mechanism the
>         other side supports.</t>
>          
> 
>             To accompany this, I think the title of the section should
>             be changed too: "Inconsistent placement of information in
>             inbound requests"
> 
>         Yes, slightly modified to make it more specific: "Inconsistent
>         placement of target URI information in inbound requests".
>          
> 
>             John
> 
>              > Cc: [email-masked] <mailto:[email-masked]>
>              > <[email-masked]
>             <mailto:[email-masked]>> wrote:
>              >
>              >
>              >       Hans Erik,
>              >
>              >       > Cc: [email-masked] <mailto:[email-masked]>
>              >       > <[email-masked]
>             <mailto:[email-masked]>> wrote:
>              >       >
>              >       >
>             <mailto:[email-masked]>
>             <mailto:[email-masked]>
>              >       >       > Subject: Re: [martini] #21: 3.2.2
>             describes an issue
>              >       > with some PBX
>              >       >       >
>              >       >       >
>              >       >       > Is this an issue, yes. Does introducing
>             yet another
>              >       > profile help? No.
>              >       >       >
>              >       >       > /Hans Erik van Elburg
>              >       >       >
>              >       >       >
>              >       >       >        used would fail to interwork with
>             SSPs using a
>              >       >       > different mechanism (e.g.,
>              >       >       >        used would fail to interwork with
>             a loose route
>              >       >       > implementation (e.g.,
>             <mailto:[email-masked]>
>              >       >       >      
> ------------------------------------------------------------------------
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 31 Mar 2010 10:28:55 -0500

Speaking as chair ... and the chairs have not declared consensus on the solutions document. We have agreed to adopt GIN as a working group draft for the solutions milestone, and this would be a great time for the working group to start working on that draft.

Spencer
  ----- Original Message ----- 
  From: DRAGE, Keith (Keith) 
  To: Adam Roach 
  Cc: [email-masked] 
  Sent: Wednesday, March 31, 2010 9:15 AM
  Subject: Re: [martini] #21: 3.2.2 describes an issue with some PBX

  Keith

----------------------------------------------------------------------------

    Regarding the other things that GIN does not solve: keep in mind that we're not addressing every possible PBX/SSP interconnect issue here. MARTINI has a refreshingly narrow charter, and that is by design. >From an IETF perspective, the rest of the peering problem space is being solved mostly in SPEERMINT and DRINKS.

    /a

------------------------------------------------------------------------------