From bruno.chatras@orange-ftgroup.com Thu Apr 1 01:38:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24D43A6ACF for ; Thu, 1 Apr 2010 01:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIodUQPCnDLq for ; Thu, 1 Apr 2010 01:38:22 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 760633A6A00 for ; Thu, 1 Apr 2010 01:38:18 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 20A3B8B800A; Thu, 1 Apr 2010 10:38:45 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 232218B8005; Thu, 1 Apr 2010 10:38:41 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 10:38:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD176.B4EBE634" Date: Thu, 1 Apr 2010 10:38:30 +0200 Message-ID: <9ECCF01B52E7AB408A7EB853526421410148EF0F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX Thread-Index: AcrQ23D3EqrCTe1bR2izj67MexoX3wAO4MiAABfuF9A= References: <430FC6BDED356B4C8498F634416644A91A79E92C83@mail> From: To: , , X-OriginalArrivalTime: 01 Apr 2010 08:38:29.0961 (UTC) FILETIME=[B496D390:01CAD176] Cc: martini@ietf.org Subject: Re: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 08:38:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD176.B4EBE634 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree as well of course! ________________________________ De : martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] De la = part de Christer Holmberg Envoy=E9 : mercredi 31 mars 2010 23:16 =C0 : 'Hans Erik van Elburg'; Hadriel Kaplan Cc : martini@ietf.org Objet : Re: [martini] Issue with existing SIP trunking solutions, was = Re: #21: 3.2.2 describes an issue with some PBX =09 =09 Hi, =20 I agree with Hans Erik. =20 If it is about issues within existing solutions, wouldn't it be better = to try to address those (by communicating with 3GPP/ETSI) instead of = defining a completely new mechanism? =20 Regards, =20 Christer ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of Hans Erik van Elburg Sent: 31. maaliskuuta 2010 17:07 To: Hadriel Kaplan Cc: martini@ietf.org Subject: Re: [martini] Issue with existing SIP trunking solutions, was = Re: #21: 3.2.2 describes an issue with some PBX =09 =09 Hi Hadriel, =09 People say there is a mistake in the ETSI/3GPP solution that martini is = addressing. I'm only trying to see if there really is a mistake or if = this is just an opinion about a design choice being made. I am not yet = convinced that it is a mistake.=20 =09 Also I think we need to be fair on this, martini is not addressing the = issues with existing solutions and fixing them, it is creating a new = solution trying to avoid some issues with existing solutions. That is a = different approach. =09 I think nobody denies the need for an option tag. In fact having an = option tag for the IMS method would make sense. And would fix an issue = with that solution. =09 /Hans Erik van Elburg =09 =09 =09 On Wed, Mar 31, 2010 at 3:52 PM, Hadriel Kaplan = wrote: =09 =20 Hi, I'm not sure I understand the question exactly. My only point was that in practice we've found that what IP-PBX's = expect to receive in the request-uri is inconsistent, and that even if = the IP-PBX thinks it is following the ETSI model it's not clear what it = will or should expect to get. But really we're also focusing too much on this particular issue I = think - there're other reasons to have the options-tag. =20 -hadriel =20 =09 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Wednesday, March 31, 2010 5:35 AM To: bruno.chatras@orange-ftgroup.com Cc: Hadriel Kaplan; richard@shockey.us; = john.elwell@siemens-enterprise.com; martini@ietf.org Subject: Issue with existing SIP trunking solutions, was Re: [martini] = #21: 3.2.2 describes an issue with some PBX =20 Hi Hadriel, =09 (Changed the thread name.) =09 Is your point that the use of a loose-route to the PBX as such is not = so much of a problem, but that SSP's would use it to deliver = Request-URI's containing the SSP's domain to the IP-PBX? =09 BR, /Hans Erik van Elburg =20 ------_=_NextPart_001_01CAD176.B4EBE634 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree as well of = course!

De : martini-bounces@ietf.org = [mailto:martini-bounces@ietf.org] De la part de Christer=20 Holmberg
Envoy=E9 : mercredi 31 mars 2010=20 23:16
=C0 : 'Hans Erik van Elburg'; Hadriel=20 Kaplan
Cc : martini@ietf.org
Objet : Re: = [martini] Issue with existing SIP trunking solutions, was Re: #21: = 3.2.2=20 describes an issue with some PBX

Hi,
 
I agree with Hans Erik.
 
If it is about issues within existing = solutions, wouldn't=20 it be better to try to address those (by communicating with 3GPP/ETSI) = instead=20 of defining a completely new mechanism?
 
Regards,
 
Christer

From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf Of Hans Erik van=20 Elburg
Sent: 31. maaliskuuta 2010 17:07
To: = Hadriel=20 Kaplan
Cc: martini@ietf.org
Subject: Re: [martini] = Issue=20 with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an = issue=20 with some PBX

Hi Hadriel,

People say there is a mistake in the = ETSI/3GPP=20 solution that martini is addressing. I'm only trying to see if there = really is=20 a mistake or if this is just an opinion about a design choice being = made. I am=20 not yet convinced that it is a mistake.

Also I think we need = to be=20 fair on this, martini is not addressing the issues with existing = solutions and=20 fixing them, it is creating a new solution trying to avoid some issues = with=20 existing solutions. That is a different approach.

I think = nobody denies=20 the need for an option tag. In fact having an option tag for the IMS = method=20 would make sense. And would fix an issue with that solution.
/Hans Erik van Elburg


On Wed, Mar 31, 2010 at 3:52 PM, Hadriel = Kaplan <HKaplan@acmepacket.com>=20 wrote:

 

Hi,

I=92m not = sure I=20 understand the question exactly.

My only = point was=20 that in practice we=92ve found that what IP-PBX=92s expect to = receive in the=20 request-uri is inconsistent, and that even if the IP-PBX thinks it = is=20 following the ETSI model it=92s not clear what it will or should = expect to=20 get.

But = really we=92re=20 also focusing too much on this particular issue I think =96 = there=92re other=20 reasons to have the options-tag.

 

-hadriel

 

From: Hans=20 Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Wednesday, March 31, = 2010 5:35=20 AM
To: bruno.chatras@orange-ftgroup.com
Cc: Hadriel Kaplan; richard@shockey.us; john.elwell@siemens-enterprise.com; martini@ietf.org
Subject: Issue with existing = SIP=20 trunking solutions, was Re: [martini] #21: 3.2.2 describes an issue = with=20 some PBX

 

Hi Hadriel,

(Changed = the thread=20 name.)

Is your point that the use of a loose-route to the PBX = as such=20 is not so much of a problem, but that SSP's would use it to deliver=20 Request-URI's containing the SSP's domain to the = IP-PBX?

BR,/Hans Erik van Elburg

 

=
------_=_NextPart_001_01CAD176.B4EBE634-- From christer.holmberg@ericsson.com Thu Apr 1 02:02:16 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9FC3A6911 for ; Thu, 1 Apr 2010 02:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsI4QGaqc5ck for ; Thu, 1 Apr 2010 02:02:12 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5EFDF3A67A4 for ; Thu, 1 Apr 2010 02:02:12 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-76-4bb4613309f6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 24.9E.23532.33164BB4; Thu, 1 Apr 2010 11:02:43 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 1 Apr 2010 11:02:42 +0200 From: Christer Holmberg To: Dean Willis , Hadriel Kaplan Date: Thu, 1 Apr 2010 11:01:53 +0200 Thread-Topic: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX Thread-Index: AcrRKwOGMsAdEGQRSte0E9EsJZPb1gATqQ+A Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79E92C83@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 09:02:16 -0000 Hi,=20 >>I'm not sure I understand the question exactly. >>My only point was that in practice we've found that what IP-PBX's=20 >>expect to receive in the request-uri is inconsistent, and=20 >>that even if the IP-PBX thinks it is following the ETSI model it's not=20 >>clear what it will or should expect to get. >>But really we're also focusing too much on this particular issue I=20 >>think - there're other reasons to have the options-tag. > >The ETSI model for PBX behavior is currently underspecified.=20 That is not completely true. It is true that 3GPP do not specify what happens inside the PBX (which is a= lso true for IETF). However, 3GPP does specify the interface that is used between a UE and the = core network, and that interface is used as base also for the PBX. Regards, Christer > The IETF model is currently unspecified: we think of PBXes as=20 > big phones, and our phone model is underspecified. >=20 > You expected this stuff to actually work without a more rigid=20 > interop spec? >=20 > And yeah, we need the options-tag anyhow. >=20 > -- > Dean (who expects to be struck by a meteor tomorrow, just=20 > after the alarm clock goes off, and will be pleasantly=20 > surprised if it doesn't, assuming he hasn't died first of=20 > something else and is therefore unable to appreciate having=20 > not been hit by a meteor). > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From richard@shockey.us Thu Apr 1 08:06:28 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F483A692C for ; Thu, 1 Apr 2010 08:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73CnwPPFmg4a for ; Thu, 1 Apr 2010 08:06:22 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (oproxy2-pub.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 55DCA3A67DA for ; Thu, 1 Apr 2010 08:06:22 -0700 (PDT) Received: (qmail 16464 invoked by uid 0); 1 Apr 2010 15:06:54 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 1 Apr 2010 15:06:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=J0NZYW3vwT8krfmfRfo0cA4V7ovfjOzaSAl5YTfMXVkSuG+8mPVjs+UK3XimBXuLLAtFJ3UTMOJ8+6bEz/zRM2fugsAqMz+r0tvva2UIj/I+3TXC5wUN5j992dD1B40V; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NxLyw-0008AW-8A; Thu, 01 Apr 2010 09:06:54 -0600 From: "Richard Shockey" To: "'Christer Holmberg'" , "'Hans Erik van Elburg'" , "'Hadriel Kaplan'" References: <430FC6BDED356B4C8498F634416644A91A79E92C83@mail> In-Reply-To: Date: Thu, 1 Apr 2010 11:06:49 -0400 Message-ID: <000401cad1ac$f5111d00$df335700$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01CAD18B.6DFF7D00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrQ23D3EqrCTe1bR2izj67MexoX3wAO4MiAACVdHdA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: martini@ietf.org Subject: Re: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 15:06:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01CAD18B.6DFF7D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit No thank you. Some of us want to get this done before the next US presidential election. Both specifications have "issues" but with an well understood option tag the problems go away and BTW if it didn't take a full RFC to get a option tag this WG would never have been formed. From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Wednesday, March 31, 2010 5:16 PM To: 'Hans Erik van Elburg'; Hadriel Kaplan Cc: martini@ietf.org Subject: Re: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX Hi, I agree with Hans Erik. If it is about issues within existing solutions, wouldn't it be better to try to address those (by communicating with 3GPP/ETSI) instead of defining a completely new mechanism? Regards, Christer _____ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Hans Erik van Elburg Sent: 31. maaliskuuta 2010 17:07 To: Hadriel Kaplan Cc: martini@ietf.org Subject: Re: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX Hi Hadriel, People say there is a mistake in the ETSI/3GPP solution that martini is addressing. I'm only trying to see if there really is a mistake or if this is just an opinion about a design choice being made. I am not yet convinced that it is a mistake. Also I think we need to be fair on this, martini is not addressing the issues with existing solutions and fixing them, it is creating a new solution trying to avoid some issues with existing solutions. That is a different approach. I think nobody denies the need for an option tag. In fact having an option tag for the IMS method would make sense. And would fix an issue with that solution. /Hans Erik van Elburg On Wed, Mar 31, 2010 at 3:52 PM, Hadriel Kaplan wrote: Hi, I'm not sure I understand the question exactly. My only point was that in practice we've found that what IP-PBX's expect to receive in the request-uri is inconsistent, and that even if the IP-PBX thinks it is following the ETSI model it's not clear what it will or should expect to get. But really we're also focusing too much on this particular issue I think - there're other reasons to have the options-tag. -hadriel _____ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: Wednesday, March 31, 2010 5:35 AM To: bruno.chatras@orange-ftgroup.com Cc: Hadriel Kaplan; richard@shockey.us; john.elwell@siemens-enterprise.com; martini@ietf.org Subject: Issue with existing SIP trunking solutions, was Re: [martini] #21: 3.2.2 describes an issue with some PBX Hi Hadriel, (Changed the thread name.) Is your point that the use of a loose-route to the PBX as such is not so much of a problem, but that SSP's would use it to deliver Request-URI's containing the SSP's domain to the IP-PBX? BR, /Hans Erik van Elburg ------=_NextPart_000_0005_01CAD18B.6DFF7D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No thank you.  Some of us  want to get this = done before the next US presidential election.

 

Both specifications have “issues” but with an = well understood option tag the problems go away and BTW if it didn’t  take a full = RFC to get a option tag this WG would never have been formed.

 

From:= martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Christer Holmberg
Sent: Wednesday, March 31, 2010 5:16 PM
To: 'Hans Erik van Elburg'; Hadriel Kaplan
Cc: martini@ietf.org
Subject: Re: [martini] Issue with existing SIP trunking = solutions, was Re: #21: 3.2.2 describes an issue with some PBX

 

Hi,

 

I agree with Hans Erik.

 

If it is about issues within existing solutions, wouldn't it = be better to try to address those (by communicating with 3GPP/ETSI) instead = of defining a completely new mechanism?

 

Regards,

 

Christer

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Hans Erik van = Elburg
Sent: 31. maaliskuuta 2010 17:07
To: Hadriel Kaplan
Cc: martini@ietf.org
Subject: Re: [martini] Issue with existing SIP trunking = solutions, was Re: #21: 3.2.2 describes an issue with some PBX

Hi Hadriel,

People say there is a mistake in the ETSI/3GPP solution that martini is addressing. I'm only trying to see if there really is a mistake or if = this is just an opinion about a design choice being made. I am not yet convinced = that it is a mistake.

Also I think we need to be fair on this, martini is not addressing the = issues with existing solutions and fixing them, it is creating a new solution = trying to avoid some issues with existing solutions. That is a different = approach.

I think nobody denies the need for an option tag. In fact having an = option tag for the IMS method would make sense. And would fix an issue with that = solution.

/Hans Erik van Elburg

On Wed, Mar 31, 2010 at 3:52 PM, Hadriel Kaplan = <HKaplan@acmepacket.com> = wrote:

 <= /o:p>

Hi= ,

I&= #8217;m not sure I understand the question exactly.

My= only point was that in practice we’ve found that what IP-PBX’s = expect to receive in the request-uri is inconsistent, and that even if the IP-PBX thinks it = is following the ETSI model it’s not clear what it will or should = expect to get.

Bu= t really we’re also focusing too much on this particular issue I think = – there’re other reasons to have the options-tag.

 <= /o:p>

-h= adriel

 <= /o:p>

From:= Hans Erik = van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Wednesday, March 31, 2010 5:35 AM
To: bruno.chatras@orange-ftgroup.com
Cc: Hadriel Kaplan; richard@shockey.us; john.elwell@siemens-enterprise.com; martini@ietf.org
Subject: Issue with existing SIP trunking solutions, was Re: = [martini] #21: 3.2.2 describes an issue with some PBX

 <= /o:p>

Hi Hadriel,

(Changed the thread name.)

Is your point that the use of a loose-route to the PBX as such is not so = much of a problem, but that SSP's would use it to deliver Request-URI's = containing the SSP's domain to the IP-PBX?

BR,
/Hans Erik van Elburg

 <= /o:p>

 

------=_NextPart_000_0005_01CAD18B.6DFF7D00-- From christer.holmberg@ericsson.com Sat Apr 3 01:40:41 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D8A33A691F for ; Sat, 3 Apr 2010 01:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=-1.193, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtC9uMD0ZUXz for ; Sat, 3 Apr 2010 01:40:40 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 12BD43A6A60 for ; Sat, 3 Apr 2010 01:30:54 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-e6-4bb6fcbcb50f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id C9.35.23740.CBCF6BB4; Sat, 3 Apr 2010 10:30:53 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sat, 3 Apr 2010 10:30:52 +0200 From: Christer Holmberg To: 'Richard Shockey' , 'Hans Erik van Elburg' , 'Hadriel Kaplan' Date: Sat, 3 Apr 2010 10:30:51 +0200 Thread-Topic: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX Thread-Index: AcrQ23D3EqrCTe1bR2izj67MexoX3wAO4MiAACVdHdAAVrMb0A== Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79E92C83@mail> <000401cad1ac$f5111d00$df335700$@us> In-Reply-To: <000401cad1ac$f5111d00$df335700$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 08:40:41 -0000 Hi, =20 >No thank you. Some of us want to get this done before the next US presid= ential election. =20 Is that a valid argument for not trying to re-use things? Can we use that a= rgument in other IETF WGs also? :) Also, I guess it is then ok for other SDOs (e.g. 3GPP) to start defining th= eir own protocol extensions etc, instead of bringing them to IETF - simply = based on the argument (whether it's true or not) that it will take too long= to do it in IETF...=20 Also, based on what argument do you think it would take a long time to do t= his with 3GPP/ETSI? In addition, as indicated by Keith a number of times, the current IETF solu= tion lacks a number of features, which the 3GPP/ETSI solution provides. >Both specifications have "issues" but with an well understood option tag t= he problems go away and BTW if it didn't take a full RFC to get a option t= ag this WG would never have been formed. The problem does not go away if you end up having to implement two solution= s - no matter if you have an option tag to indicate which is used or not. Regards, Christer =20 From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: Wednesday, March 31, 2010 5:16 PM To: 'Hans Erik van Elburg'; Hadriel Kaplan Cc: martini@ietf.org Subject: Re: [martini] Issue with existing SIP trunking solutions, was Re: = #21: 3.2.2 describes an issue with some PBX =20 Hi, =20 I agree with Hans Erik. =20 If it is about issues within existing solutions, wouldn't it be better to t= ry to address those (by communicating with 3GPP/ETSI) instead of defining a= completely new mechanism? =20 Regards, =20 Christer =20 ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Hans Erik van Elburg Sent: 31. maaliskuuta 2010 17:07 To: Hadriel Kaplan Cc: martini@ietf.org Subject: Re: [martini] Issue with existing SIP trunking solutions, was Re: = #21: 3.2.2 describes an issue with some PBX Hi Hadriel, People say there is a mistake in the ETSI/3GPP solution that martini is add= ressing. I'm only trying to see if there really is a mistake or if this is = just an opinion about a design choice being made. I am not yet convinced th= at it is a mistake.=20 Also I think we need to be fair on this, martini is not addressing the issu= es with existing solutions and fixing them, it is creating a new solution t= rying to avoid some issues with existing solutions. That is a different app= roach. I think nobody denies the need for an option tag. In fact having an option = tag for the IMS method would make sense. And would fix an issue with that s= olution. /Hans Erik van Elburg On Wed, Mar 31, 2010 at 3:52 PM, Hadriel Kaplan wr= ote: =20 Hi, I'm not sure I understand the question exactly. My only point was that in practice we've found that what IP-PBX's expect to= receive in the request-uri is inconsistent, and that even if the IP-PBX th= inks it is following the ETSI model it's not clear what it will or should e= xpect to get. But really we're also focusing too much on this particular issue I think - = there're other reasons to have the options-tag. =20 -hadriel =20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Wednesday, March 31, 2010 5:35 AM To: bruno.chatras@orange-ftgroup.com Cc: Hadriel Kaplan; richard@shockey.us; john.elwell@siemens-enterprise.com;= martini@ietf.org Subject: Issue with existing SIP trunking solutions, was Re: [martini] #21:= 3.2.2 describes an issue with some PBX =20 Hi Hadriel, (Changed the thread name.) Is your point that the use of a loose-route to the PBX as such is not so mu= ch of a problem, but that SSP's would use it to deliver Request-URI's conta= ining the SSP's domain to the IP-PBX? BR, /Hans Erik van Elburg =20 =20 From HKaplan@acmepacket.com Sat Apr 3 10:09:16 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236BF3A68F9 for ; Sat, 3 Apr 2010 10:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.13 X-Spam-Level: * X-Spam-Status: No, score=1.13 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaBgI1761NFY for ; Sat, 3 Apr 2010 10:09:15 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9A5553A68F8 for ; Sat, 3 Apr 2010 10:09:11 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 3 Apr 2010 13:09:07 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 3 Apr 2010 13:09:07 -0400 From: Hadriel Kaplan To: Christer Holmberg , 'Richard Shockey' , 'Hans Erik van Elburg' Date: Sat, 3 Apr 2010 13:09:05 -0400 Thread-Topic: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX Thread-Index: AcrQ23D3EqrCTe1bR2izj67MexoX3wAO4MiAACVdHdAAVrMb0AARaLKA Message-ID: <430FC6BDED356B4C8498F634416644A91A79E93278@mail> References: <430FC6BDED356B4C8498F634416644A91A79E92C83@mail> <000401cad1ac$f5111d00$df335700$@us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 17:09:16 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Saturday, April 03, 2010 4:31 AM > To: 'Richard Shockey'; 'Hans Erik van Elburg'; Hadriel Kaplan >=20 >=20 > >No thank you. Some of us want to get this done before the next US > presidential election. >=20 > Also, I guess it is then ok for other SDOs (e.g. 3GPP) to start defining > their own protocol extensions etc, instead of bringing them to IETF - > simply based on the argument (whether it's true or not) that it will take > too long to do it in IETF... Umm... you do realize that is what some folks believe happened in this case= , right? Some folks view ETSI's usage of a loose-route model for Registered contacts= as conflicting with the current 3261 model. (i.e., extending it) Personally I think a good lawyer could make the case it isn't, but we could= n't get consensus to go that way. =20 > Also, based on what argument do you think it would take a long time to do > this with 3GPP/ETSI? I think he meant in the context of your suggested "communicating changes wi= th 3gpp". I too have been told that trying to coordinate changes/updates t= o specs with both IETF and 3GPP at the same time through liaisons takes a l= ong time. And it _would_ still require something to be published in the IETF. There = are plenty of SIP networks in existence which are not IMS, and won't be IMS= . -hadriel=20 p.s. And I'm not disparaging IMS (most of my revenue comes from IMS!) - but= it's not the only game in town. IP-PBX SIP trunks need to work with any S= SP network architecture. From bernard_aboba@hotmail.com Sat Apr 3 18:20:50 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 783DB3A693B for ; Sat, 3 Apr 2010 18:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.501 X-Spam-Level: *** X-Spam-Status: No, score=3.501 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k28d9XywbETR for ; Sat, 3 Apr 2010 18:20:49 -0700 (PDT) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by core3.amsl.com (Postfix) with ESMTP id 5F8323A67FD for ; Sat, 3 Apr 2010 18:20:42 -0700 (PDT) Received: from BLU137-W26 ([65.55.111.73]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 3 Apr 2010 18:20:41 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_8181907c-3f99-4699-ba64-1ba3500241d8_" X-Originating-IP: [72.11.69.66] From: Bernard Aboba To: Date: Sat, 3 Apr 2010 18:20:41 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 04 Apr 2010 01:20:41.0483 (UTC) FILETIME=[0A986DB0:01CAD395] Subject: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 01:20:50 -0000 --_8181907c-3f99-4699-ba64-1ba3500241d8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hans Erik Von Elburg said: "Also I think we need to be fair on this=2C martini is not addressing the=20 issues with existing solutions and fixing them=2C it is creating a new solution=20 trying to avoid some issues with existing solutions. That is a different=20 approach." [BA] Too often the IETF has attempted to solve an interoperability problem = by creating yet another solution=2C rather than refining an existing=20 deployed approach. Very often=2C this approach has been (mis)guided by the= need to meet an exhaustive set of "requirements" that exist mainly in the = minds of the requirements document authors. Typically=2C the result is an = unnecessary new protocol that is either ignored by industry or actually mak= es the interoperability problem worse. If there were one thing I would cha= nge about the IETF=2C it would probably be to discourage that kind of pointless meddling. Mark Handley's excellen= t paper "Why the Internet Only Just Works" (see=20 http://www.cs.ucl.ac.uk/staff/M.Handley/papers/only-just-works.pdf )=20 describes why the IETF's protocol design methodology has failed so consiste= ntly.=20 However=2C in this particular case=2C the Requirements document authors hav= e been thoughtful in their arguments. The indictment against the existing s= olutions outlined in the=20 Requirements document is not merely based on the diversity of existing=20 deployed solutions=3B if this were the case=2C then indeed adoption and=20 refinement of one of the existing approaches would be preferred.=20 The authors make the case that the problems with existing solutions are fun= damental rather than merely representing a series of nits. This indictment= has been backed up by testimony from PBX vendors and SSPs who have experie= nced problems accommodating one or more of the existing approaches within t= heir architectures.=20 The authors also do not appear to have fallen into the trap of making=20 perfection the enemy of the good. Rather than throwing together a list of = "nice to haves" as many IETF requirements docs do=2C the document authors h= ave attempted to put together a list representing the union of requirements= .=20 Essentially=2C the requirements document makes the argument that there is n= ot any existing solution that "only just works" -- that is=2C a solution=2C= that while not perfect=2C can meet the bare minimum of requirements necess= ary to address an essential need=2C thereby achieving widespread deployment= . Indeed=2C it appears that none of the existing deployed approaches=20 is on a path to achieve a critical mass in both SSP and PBX=20 implementations.=20 If the requirements document is correct in its reasoning=2C then none of th= e existing solutions have what it takes to be successful in the real world.= Of course=2C that does not mean that a new approach will necessary be suc= cessful. But it does imply that the arguments made in the requirements docu= ment cannot be dismissed out of hand=2C and need to be argued on their meri= ts.=20 = --_8181907c-3f99-4699-ba64-1ba3500241d8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hans Erik Von Elburg said:

"Also I think we need to be fair on this= =2C martini is not addressing the=20 issues with existing solutions and fixing them=2C it is creating a new solution=20 trying to avoid some issues with existing solutions. That is a different=20 approach."

[BA] Too often the IETF has attempted to solve an interop= erability problem by creating yet another solution=2C rather than refining an existing=20 deployed approach. =3B Very often=2C this approach has been (mis)guided= by the need to meet an exhaustive set of "requirements" that exist mainly = in the minds of the requirements document authors. =3B Typically=2C the= result is an unnecessary new protocol that is either ignored by industry o= r actually makes the interoperability problem worse. =3B If there were = one thing I would change about the IETF=2C it would probably be to discourage that kind of pointless meddling. =3B Mark Handley's e= xcellent paper "Why the Internet Only Just Works" (see=20 http://www.cs.ucl.ac.uk/staff/M.Handley/papers/only-just-works.pdf )=20 describes why the IETF's protocol design methodology has failed so consiste= ntly.

However=2C in this particular case=2C the Requirements docume= nt authors have been thoughtful in their arguments. The indictment against = the existing solutions outlined in the=20 Requirements document is not merely based on the diversity of existing=20 deployed solutions=3B =3B if this were the case=2C then indeed adoption= and=20 refinement of one of the existing approaches would be preferred.

The authors make the case that the problems with existing solutions are= fundamental rather than merely representing a series of nits. =3B This= indictment has been backed up by testimony from PBX vendors and SSPs who h= ave experienced problems accommodating one or more of the existing approach= es within their architectures.

The authors also do not appear to h= ave fallen into the trap of making=20 perfection the enemy of the good. =3B Rather than throwing together a l= ist of "nice to haves" as many IETF requirements docs do=2C the document au= thors have attempted to put together a list representing the union of requi= rements.

Essentially=2C the requirements document makes the argumen= t that there is not any existing solution that "only just works" -- that is= =2C a solution=2C that while not perfect=2C can meet the bare minimum of re= quirements necessary to address an essential need=2C thereby achieving wide= spread deployment. =3B Indeed=2C it appears that none of the existing d= eployed approaches=20 is on a path to achieve a critical mass in both SSP and PBX=20 implementations.

If the requirements document is correct in its rea= soning=2C then none of the existing solutions have what it takes to be succ= essful in the real world. =3B Of course=2C that does not mean that a ne= w approach will necessary be successful. But it does imply that the argumen= ts made in the requirements document cannot be dismissed out of hand=2C and= need to be argued on their merits.







= = --_8181907c-3f99-4699-ba64-1ba3500241d8_-- From md3135@att.com Sun Apr 4 02:29:01 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD38F3A67FF for ; Sun, 4 Apr 2010 02:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.998 X-Spam-Level: X-Spam-Status: No, score=-103.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg+KEaVT4O-Z for ; Sun, 4 Apr 2010 02:28:55 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id A1BBC3A676A for ; Sun, 4 Apr 2010 02:28:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-3.tower-129.messagelabs.com!1270373331!36600079!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 23878 invoked from network); 4 Apr 2010 09:28:51 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Apr 2010 09:28:51 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o349Scw1004495; Sun, 4 Apr 2010 05:28:38 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o349SWIR004479; Sun, 4 Apr 2010 05:28:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AXEY DmNC F4ek H8dU KrCt K8JK Mxbx Ndhm PNMa VpIU XAiy YGW8 ZOMy b7sD cTWi g/jl; 3; YgBlAHIAbgBhAHIAZABfAGEAYgBvAGIAYQBAAGgAbwB0AG0AYQBpAGwALgBjAG8AbQA7AGMAaAByAGkAcwB0AGUAcgAuAGgAbwBsAG0AYgBlAHIAZwBAAGUAcgBpAGMAcwBzAG8AbgAuAGMAbwBtADsAbQBhAHIAdABpAG4AaQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {042EC938-F92A-49EE-A25B-858E8A7DC514}; bQBkADMAMQAzADUAQABhAHQAdAAuAGMAbwBtAA==; Sun, 04 Apr 2010 09:28:33 GMT; UgBFADoAIABbAG0AYQByAHQAaQBuAGkAXQAgAFQAaABlACAASQBFAFQARgAgAHYAZQByAHMAdQBzACAAcgBlAGEAbABpAHQAeQAgACgAdwBhAHMAOgAgAHAAcgBvAGIAbABlAG0AcwAgAHcAaQB0AGgAIABlAHgAaQBzAHQAaQBuAGcAIABTAEkAUAAgAHQAcgB1AG4AawBpAG4AZwAgAHMAbwBsAHUAdABpAG8AbgBzACkA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD3D9.38EE6AB4" x-cr-puzzleid: {042EC938-F92A-49EE-A25B-858E8A7DC514} Content-class: urn:content-classes:message Date: Sun, 4 Apr 2010 05:28:33 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA061F4FBF@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions) Thread-Index: AcrTlRUen/0m9g1oRF2eqmdhkzOavgAQ6+Bw References: From: "DOLLY, MARTIN C (ATTLABS)" To: "Bernard Aboba" , Subject: Re: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 09:29:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD3D9.38EE6AB4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 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.=20 =20 Yet again, the IETF gives us the best of both worlds.... =20 From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Saturday, April 03, 2010 9:21 PM To: martini@ietf.org Subject: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions) =20 Hans Erik Von Elburg said: "Also I think we need to be fair on this, martini is not addressing the issues with existing solutions and fixing them, it is creating a new solution trying to avoid some issues with existing solutions. That is a different approach." [BA] Too often the IETF has attempted to solve an interoperability problem by creating yet another solution, rather than refining an existing deployed approach. Very often, this approach has been (mis)guided by the need to meet an exhaustive set of "requirements" that exist mainly in the minds of the requirements document authors. Typically, the result is an unnecessary new protocol that is either ignored by industry or actually makes the interoperability problem worse. If there were one thing I would change about the IETF, it would probably be to discourage that kind of pointless meddling. Mark Handley's excellent paper "Why the Internet Only Just Works" (see http://www.cs.ucl.ac.uk/staff/M.Handley/papers/only-just-works.pdf ) describes why the IETF's protocol design methodology has failed so consistently.=20 However, in this particular case, the Requirements document authors have been thoughtful in their arguments. The indictment against the existing solutions outlined in the Requirements document is not merely based on the diversity of existing deployed solutions; if this were the case, then indeed adoption and refinement of one of the existing approaches would be preferred.=20 The authors make the case that the problems with existing solutions are fundamental rather than merely representing a series of nits. This indictment has been backed up by testimony from PBX vendors and SSPs who have experienced problems accommodating one or more of the existing approaches within their architectures.=20 The authors also do not appear to have fallen into the trap of making perfection the enemy of the good. Rather than throwing together a list of "nice to haves" as many IETF requirements docs do, the document authors have attempted to put together a list representing the union of requirements.=20 Essentially, the requirements document makes the argument that there is not any existing solution that "only just works" -- that is, a solution, that while not perfect, can meet the bare minimum of requirements necessary to address an essential need, thereby achieving widespread deployment. Indeed, it appears that none of the existing deployed approaches is on a path to achieve a critical mass in both SSP and PBX implementations.=20 If the requirements document is correct in its reasoning, then none of the existing solutions have what it takes to be successful in the real world. Of course, that does not mean that a new approach will necessary be successful. But it does imply that the arguments made in the requirements document cannot be dismissed out of hand, and need to be argued on their merits.=20 =09 =20 ------_=_NextPart_001_01CAD3D9.38EE6AB4 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

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. =

 

Yet again, the IETF gives us the best of both = worlds….

 

From:= = martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Saturday, April 03, 2010 9:21 PM
To: martini@ietf.org
Subject: [martini] The IETF versus reality (was: problems with = existing SIP trunking solutions)

 

Hans Erik Von Elburg said:

"Also I think we need to be fair on this, martini is not addressing = the issues with existing solutions and fixing them, it is creating a new = solution trying to avoid some issues with existing solutions. That is a different = approach."

[BA] Too often the IETF has attempted to solve an interoperability = problem by creating yet another solution, rather than refining an existing deployed approach.  Very often, this approach has been (mis)guided by the = need to meet an exhaustive set of "requirements" that exist mainly in = the minds of the requirements document authors.  Typically, the result = is an unnecessary new protocol that is either ignored by industry or actually = makes the interoperability problem worse.  If there were one thing I = would change about the IETF, it would probably be to discourage that kind of pointless meddling.  Mark Handley's excellent paper "Why the = Internet Only Just Works" (see http://www.cs.ucl.ac.uk/staff/M.Handley/papers/only-just-works.pdf ) = describes why the IETF's protocol design methodology has failed so consistently. =

However, in this particular case, the Requirements document authors have = been thoughtful in their arguments. The indictment against the existing = solutions outlined in the Requirements document is not merely based on the = diversity of existing deployed solutions;  if this were the case, then indeed = adoption and refinement of one of the existing approaches would be preferred. =

The authors make the case that the problems with existing solutions are fundamental rather than merely representing a series of nits.  This indictment has been backed up by testimony from PBX vendors and SSPs who = have experienced problems accommodating one or more of the existing = approaches within their architectures.

The authors also do not appear to have fallen into the trap of making perfection the enemy of the good.  Rather than throwing together a = list of "nice to haves" as many IETF requirements docs do, the = document authors have attempted to put together a list representing the union of requirements.

Essentially, the requirements document makes the argument that there is = not any existing solution that "only just works" -- that is, a = solution, that while not perfect, can meet the bare minimum of requirements necessary = to address an essential need, thereby achieving widespread = deployment.  Indeed, it appears that none of the existing deployed approaches is on a = path to achieve a critical mass in both SSP and PBX implementations.

If the requirements document is correct in its reasoning, then none of = the existing solutions have what it takes to be successful in the real = world.  Of course, that does not mean that a new approach will necessary be = successful. But it does imply that the arguments made in the requirements document = cannot be dismissed out of hand, and need to be argued on their merits.





 

------_=_NextPart_001_01CAD3D9.38EE6AB4-- From dean.willis@softarmor.com Sun Apr 4 10:04:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927463A6A87 for ; Sun, 4 Apr 2010 10:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gsqFNM9lJyq for ; Sun, 4 Apr 2010 10:04:24 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B95A63A6905 for ; Sun, 4 Apr 2010 10:04:24 -0700 (PDT) Received: from localhost.localdomain (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o34H4Iok032207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 4 Apr 2010 12:04:20 -0500 X-User-Agent: K-9 Mail for Android Content-Type: multipart/mixed; boundary="----W53EUWXWD0JWCD2V21RMLKFX1F84DQ" MIME-Version: 1.0 From: Dean Willis Date: Sun, 04 Apr 2010 12:04:13 -0500 To: "DOLLY, MARTIN C (ATTLABS)" , Bernard Aboba , martini@ietf.org Message-ID: Subject: Re: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 17:04:25 -0000 ------W53EUWXWD0JWCD2V21RMLKFX1F84DQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QXJlIHlvdSBzYXlpbmcgdGhhdCB0aGUgSU1TIHNvbHV0aW9uIGlzIHdoYXQgdGhlIHNlcnZpY2Ug cHJvdmlkZXJzIG5lZWQ/CiAKCgoiRE9MTFksIE1BUlRJTiBDIChBVFRMQUJTKSIgPG1kMzEzNUBh dHQuY29tPiB3cm90ZToKCj5TcGVha2luZyBhcyBhIFNlcnZpY2UgUHJvdmlkZXIsIHRoZSBzb2x1 dGlvbiBiZWluZyBwcm9kdWNlZCBieSBNYXJ0aW5pCj5kb2VzIG5vdCBhZGRyZXNzIHdoYXQgaXMg bmVlZGVkIGZvciBjdXJyZW50IHRvIG1pZC10ZXJtIGRlcGxveW1lbnRzLCBhbmQKPmNyZWF0ZXMg aW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcyBpbiB0aGUgbG9uZyBoYXVsIC4KCi0tIApEZWFuIFdp bGxpcw== ------W53EUWXWD0JWCD2V21RMLKFX1F84DQ-- From richard@shockey.us Sun Apr 4 10:32:11 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C550E3A68FE for ; Sun, 4 Apr 2010 10:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.876 X-Spam-Level: X-Spam-Status: No, score=0.876 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hxze+HxeL9Ry for ; Sun, 4 Apr 2010 10:32:10 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (oproxy2-pub.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id AEFC23A6892 for ; Sun, 4 Apr 2010 10:32:10 -0700 (PDT) Received: (qmail 6022 invoked by uid 0); 4 Apr 2010 17:32:09 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 4 Apr 2010 17:32:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=Qxwd4pFQq+aYyqW+URZCfhPwi6GDkgcNkIIwjNvDbhpnpF06gNjqmwik4avwQ3hSvM66yK7yAPyP8Qtli5HdRvZ9Tuwj2A8iCFYUQuzeQKpuYlW7nknNfE1AEG9EXtkz; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NyTg9-0007V7-9j; Sun, 04 Apr 2010 11:32:09 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'DOLLY, MARTIN C \(ATTLABS\)'" , "'Bernard Aboba'" , References: In-Reply-To: Date: Sun, 4 Apr 2010 13:32:05 -0400 Message-ID: <005701cad41c$bf4e1a20$3dea4e60$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrUGOFw/+/GyV50S1eRQmil/aja0wAA0KcQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Subject: Re: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 17:32:11 -0000 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: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of Dean Willis Sent: Sunday, April 04, 2010 1:04 PM To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org Subject: Re: [martini] The IETF versus reality (was: problems with = existing SIP trunking solutions) Are you saying that the IMS solution is what the service providers need? =20 "DOLLY, MARTIN C (ATTLABS)" wrote: >Speaking as a Service Provider, the solution being produced by Martini=20 >does not address what is needed for current to mid-term deployments,=20 >and creates interoperability problems in the long haul . -- Dean Willis From bernard_aboba@hotmail.com Sun Apr 4 11:53:06 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3D43A69B7 for ; Sun, 4 Apr 2010 11:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.752 X-Spam-Level: * X-Spam-Status: No, score=1.752 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwQMOcRgeDXY for ; Sun, 4 Apr 2010 11:53:05 -0700 (PDT) Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by core3.amsl.com (Postfix) with ESMTP id 8ABA13A6AB1 for ; Sun, 4 Apr 2010 11:47:09 -0700 (PDT) Received: from BLU137-DS12 ([65.55.111.72]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Apr 2010 11:45:17 -0700 X-Originating-IP: [68.178.109.243] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Sun, 4 Apr 2010 11:45:59 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01CAD3EC.658F4070" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrUJxGTX5RsXaNfRgeZZ0DpqqrwEg== Content-Language: en-us X-OriginalArrivalTime: 04 Apr 2010 18:45:17.0941 (UTC) FILETIME=[F8ACF250:01CAD426] Subject: Re: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 18:53:06 -0000 ------=_NextPart_000_0040_01CAD3EC.658F4070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Richard Shockey said: "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." [BA] To make the argument that the IETF is once again attempting to "gild the lily", its necessary to demonstrate that an existing solution "only just works" and is well on its way to achieving widespread deployment in both SSPs and PBXes. I don't believe that the IMS solution can make this claim -- while the IMS approach has been implemented by some SSPs, I am not aware of widespread implementation on PBXes within any market (enterprise, SMB, etc.). Given that the IMS specifications have been available for several years now, if PBX implementations are either not available or in progress, a sudden upsurge in interest is unlikely. The only approach that *might* meet the criteria would be the "implicit registration" functionality now commonly implemented in SMB PBXes (e.g. Asterisk, Linksys, Grandstream, Response Point, etc.). As I understand it, in this approach the packet exchanges look exactly like a conventional RFC 3261 registration (e.g. no option tags, contact routing, etc.). Since the registration packets (and code path) are unchanged whether a single line is being registered or multiple, this approach is relatively trivial to implement on the PBX side (though more work is required on the SSP side). Unfortunately, the "magic" that occurs on the SSP side appears to differ significantly enough between providers that it would be difficult to develop a specification and or a conformance or interoperability test. Also, this approach does not satisfy requirement 8 (explicit indication), and perhaps requirement 4 (registration of individual AORs is typically not allowed). ------=_NextPart_000_0040_01CAD3EC.658F4070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Richard Shockey said:

 

"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."

 

[BA] To make the argument that the IETF is once = again attempting to "gild the lily", its necessary to demonstrate = that an existing solution "only just works" and is well on its way to achieving widespread deployment in both SSPs and PBXes.  I don't = believe that the IMS solution can make this claim -- while the IMS approach has been implemented by some SSPs, I am not aware of widespread implementation on = PBXes within any market (enterprise, SMB, etc.).  Given that the IMS specifications have been available for several years now, if PBX = implementations are either not available or in progress, a sudden upsurge in interest is = unlikely.  

 

The only approach that *might* meet the =  criteria would be the "implicit registration" functionality now commonly = implemented in SMB PBXes (e.g. Asterisk, Linksys, Grandstream, Response Point, = etc.).  As I understand it, in this approach the packet exchanges look exactly = like a conventional RFC 3261 registration (e.g. no option tags, contact = routing, etc.).  Since the registration packets (and code path) are unchanged = whether a single line is being registered or multiple, this approach is relatively trivial to implement on the PBX side (though more work is required on = the SSP side).  Unfortunately, the "magic" that occurs on the SSP = side appears to differ significantly enough between providers that it would = be difficult to develop a specification and or a conformance or = interoperability test.  Also, this approach does not satisfy requirement 8 (explicit = indication), and perhaps requirement 4 (registration of individual AORs is typically not allowed).

 

------=_NextPart_000_0040_01CAD3EC.658F4070-- From christer.holmberg@ericsson.com Mon Apr 5 03:55:31 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B44D3A691C for ; Mon, 5 Apr 2010 03:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5HsvF92xXDU for ; Mon, 5 Apr 2010 03:55:30 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E84C33A6922 for ; Mon, 5 Apr 2010 03:55:27 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-4f-4bb9c19c1edb Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 68.5E.23740.C91C9BB4; Mon, 5 Apr 2010 12:55:24 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 5 Apr 2010 12:55:24 +0200 From: Christer Holmberg To: Bernard Aboba , "martini@ietf.org" Date: Mon, 5 Apr 2010 12:55:23 +0200 Thread-Topic: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions) Thread-Index: AcrUJxGTX5RsXaNfRgeZZ0DpqqrwEgAheBh0 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 10:55:31 -0000 Hi, >Richard Shockey said: > >"The IMS solution could certainly work for large scale enterprise deployme= nts served by ATT and massive PTT's but is >ineffectual and cost prohibitive for small and medium business served typi= cally by CLEC's. That's the whole business >and technical model behind implicit registration SMB's and competition." > >[BA] To make the argument that the IETF is once again attempting to "gild = the lily", its necessary to demonstrate that an existing solution "only jus= t works" and is well on its way to achieving widespread deployment in both = SSPs and PBXes. I don't believe that the >IMS solution can make this claim -- while the IMS approach has been implem= ented by some SSPs, I am not aware of widespread implementation on PBXes wi= thin any market (enterprise, SMB, etc.). Given that the IMS specifications= have been available for several >years now, if PBX implementations are either not available or in progress,= a sudden upsurge in interest is unlikely. >From my experience, very few things IETF produces "just work". In many case= s it takes clarifications, interop tests, sometimes even bis documents, in = order to get it all right... SIP itself, offer/answer etc, are good example= s of that... >The only approach that *might* meet the criteria would be the "implicit r= egistration" functionality now commonly implemented in SMB PBXes (e.g. Aste= risk, Linksys, Grandstream, Response Point, etc.). As I understand it, in = this approach the packet exchanges look >exactly like a conventional RFC 3261 registration (e.g. no option tags, co= ntact routing, etc.). Since the registration packets (and code path) are u= nchanged whether a single line is being registered or multiple, this approa= ch is relatively trivial to implement on the PBX >side (though more work is required on the SSP side). Unfortunately, the "= magic" that occurs on the SSP side appears to differ significantly enough b= etween providers that it would be difficult to develop a specification and = or a conformance or interoperability test. >Also, this approach does not satisfy requirement 8 (explicit indication), = and perhaps requirement 4 (registration of individual AORs is typically not= allowed). As people have indicated, different SSP configurations and assumptions most= likely will be needed also for the current GIN solution, based on what the= PBX expect etc. Regards, Christer From christer.holmberg@ericsson.com Mon Apr 5 03:57:53 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E453A6920 for ; Mon, 5 Apr 2010 03:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[AWL=2.967, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hq3cPQd5FPNm for ; Mon, 5 Apr 2010 03:57:52 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 826663A691A for ; Mon, 5 Apr 2010 03:57:52 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-35-4bb9c22da7f8 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 0D.60.23532.D22C9BB4; Mon, 5 Apr 2010 12:57:49 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 5 Apr 2010 12:57:48 +0200 From: Christer Holmberg To: Richard Shockey , 'Dean Willis' , "'DOLLY, MARTIN C (ATTLABS)'" , 'Bernard Aboba' , "martini@ietf.org" Date: Mon, 5 Apr 2010 12:56:25 +0200 Thread-Topic: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions) Thread-Index: AcrUGOFw/+/GyV50S1eRQmil/aja0wAA0KcQACSfoh8= Message-ID: References: , <005701cad41c$bf4e1a20$3dea4e60$@us> In-Reply-To: <005701cad41c$bf4e1a20$3dea4e60$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 10:57:53 -0000 Hi, >The IMS solution could certainly work for large scale enterprise deploymen= ts 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=20 >registration SMB's and competition. As far as I know, you could use the IMS solution without implicit registrat= ions. 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: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Dean Willis Sent: Sunday, April 04, 2010 1:04 PM To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org Subject: Re: [martini] The IETF versus reality (was: problems with existing= SIP trunking solutions) Are you saying that the IMS solution is what the service providers need? "DOLLY, MARTIN C (ATTLABS)" 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 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini= From ietf.hanserik@gmail.com Mon Apr 5 04:06:11 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1DC23A692F for ; Mon, 5 Apr 2010 04:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh7RVKsL26en for ; Mon, 5 Apr 2010 04:06:10 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 875C93A6933 for ; Mon, 5 Apr 2010 04:06:05 -0700 (PDT) Received: by ewy24 with SMTP id 24so1160470ewy.13 for ; Mon, 05 Apr 2010 04:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=C43kdrP5KXfyfeghLy74/oJGh3z3nZlO+54R7F8EL2o=; b=HAoenkhkVOa/sPWfqPAwN5ssRomA3fFXV+Pq0/PtBpXHhUpmt5x8jkjpFj6ushPiVi yXBGKv44zdXRjlSTj2q4KEqux9EOtjYhYl3o/E5bJgqS6eMdCp2EJ+GYZ0549LPnget3 TdqROmLbT5BiwpMASQXMcHh6B5TozkEM2MnuQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oOXfCNOG2bXznVVjG4ho2Ri6T9JoBExDqc/F6iNh0/p6nlCBWUXuQhVlCj2VYbmxf/ GCu0FGCpb6LgB9Qk7iwv4ZXrAMvT3hmZaYQuMSg8WnVtMdMNBgWCuPcmvGMdpEm42d90 wpkzCdj7GiEOLm6YZMtr+X0fOVGXWErC+LUYk= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Mon, 5 Apr 2010 04:06:00 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Apr 2010 13:06:00 +0200 Received: by 10.213.97.24 with SMTP id j24mr2825658ebn.48.1270465560906; Mon, 05 Apr 2010 04:06:00 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Bernard Aboba Content-Type: multipart/alternative; boundary=001636c5bc62750d9404837b50bb Cc: martini@ietf.org Subject: Re: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 11:06:12 -0000 --001636c5bc62750d9404837b50bb Content-Type: text/plain; charset=ISO-8859-1 On Sun, Apr 4, 2010 at 3:20 AM, Bernard Aboba wrote: > Hans Erik Von Elburg said: > > "Also I think we need to be fair on this, martini is not addressing the > issues with existing solutions and fixing them, it is creating a new > solution trying to avoid some issues with existing solutions. That is a > different approach." > > [BA] Too often the IETF has attempted to solve an interoperability problem > by creating yet another solution, rather than refining an existing deployed > approach. Very often, this approach has been (mis)guided by the need to > meet an exhaustive set of "requirements" that exist mainly in the minds of > the requirements document authors. Typically, the result is an unnecessary > new protocol that is either ignored by industry or actually makes the > interoperability problem worse. If there were one thing I would change > about the IETF, it would probably be to discourage that kind of pointless > meddling. Mark Handley's excellent paper "Why the Internet Only Just Works" > (see http://www.cs.ucl.ac.uk/staff/M.Handley/papers/only-just-works.pdf ) > describes why the IETF's protocol design methodology has failed so > consistently. > > However, in this particular case, the Requirements document authors have > been thoughtful in their arguments. The indictment against the existing > solutions outlined in the Requirements document is not merely based on the > diversity of existing deployed solutions; if this were the case, then > indeed adoption and refinement of one of the existing approaches would be > preferred. > > The requirement document does not describe a solution, does it? The requirement document does leave enough room for a common solution, because as you say the requirement authors have done a thoughtful and carefull work and take into account comments from other participants on the list. > The authors make the case that the problems with existing solutions are > fundamental rather than merely representing a series of nits. This > indictment has been backed up by testimony from PBX vendors and SSPs who > have experienced problems accommodating one or more of the existing > approaches within their architectures. > > It has been clarified already that these problems are less fundamental properties of those solutions sometimes then opinions. For this reason some discussion has taken place to improve the text. > The authors also do not appear to have fallen into the trap of making > perfection the enemy of the good. Rather than throwing together a list of > "nice to haves" as many IETF requirements docs do, the document authors have > attempted to put together a list representing the union of requirements. > > Essentially, the requirements document makes the argument that there is not > any existing solution that "only just works" -- that is, a solution, that > while not perfect, can meet the bare minimum of requirements necessary to > address an essential need, thereby achieving widespread deployment. Indeed, > it appears that none of the existing deployed approaches is on a path to > achieve a critical mass in both SSP and PBX implementations. > > I dont think that the requirement document makes that argument. > If the requirements document is correct in its reasoning, then none of the > existing solutions have what it takes to be successful in the real world. > Of course, that does not mean that a new approach will necessary be > successful. But it does imply that the arguments made in the requirements > document cannot be dismissed out of hand, and need to be argued on their > merits. > > I rather think the requirements document is listing some issues with existing solutions and from that lists requirements that a solution without such issues should fulfill. It does not imply a particular solution. --001636c5bc62750d9404837b50bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Apr 4, 2010 at 3:20 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
Hans Erik Von Elburg said:

"Also I think we need to be fair on = this, martini is not addressing the=20 issues with existing solutions and fixing them, it is creating a new solution=20 trying to avoid some issues with existing solutions. That is a different=20 approach."

[BA] Too often the IETF has attempted to solve an in= teroperability problem by creating yet another solution, rather than refining an existing=20 deployed approach.=A0 Very often, this approach has been (mis)guided by the= need to meet an exhaustive set of "requirements" that exist main= ly in the minds of the requirements document authors.=A0 Typically, the res= ult is an unnecessary new protocol that is either ignored by industry or ac= tually makes the interoperability problem worse.=A0 If there were one thing= I would change about the IETF, it would probably be to discourage that kind of pointless meddling.=A0 Mark Handley's ex= cellent paper "Why the Internet Only Just Works" (see=20 http://www.cs.ucl.ac.uk/staff/M.Handley/papers/only-j= ust-works.pdf )=20 describes why the IETF's protocol design methodology has failed so cons= istently.

However, in this particular case, the Requirements docume= nt authors have been thoughtful in their arguments. The indictment against = the existing solutions outlined in the=20 Requirements document is not merely based on the diversity of existing=20 deployed solutions;=A0 if this were the case, then indeed adoption and=20 refinement of one of the existing approaches would be preferred.

The requirement document does not describe a so= lution, does it?
The requirement document does leave enough room for a c= ommon solution, because as you say the requirement authors have done a thou= ghtful and carefull work and take into account comments from other particip= ants on the list.
=A0
The= authors make the case that the problems with existing solutions are fundam= ental rather than merely representing a series of nits.=A0 This indictment = has been backed up by testimony from PBX vendors and SSPs who have experien= ced problems accommodating one or more of the existing approaches within th= eir architectures.

It has been clarified already that these proble= ms are less fundamental properties of those solutions sometimes then opinio= ns. For this reason some discussion has taken place to improve the text. =A0
Th= e authors also do not appear to have fallen into the trap of making=20 perfection the enemy of the good.=A0 Rather than throwing together a list o= f "nice to haves" as many IETF requirements docs do, the document= authors have attempted to put together a list representing the union of re= quirements.

Essentially, the requirements document makes the argument that there is= not any existing solution that "only just works" -- that is, a s= olution, that while not perfect, can meet the bare minimum of requirements = necessary to address an essential need, thereby achieving widespread deploy= ment.=A0 Indeed, it appears that none of the existing deployed approaches= =20 is on a path to achieve a critical mass in both SSP and PBX=20 implementations.

I dont think that the requ= irement document makes that argument.
=A0
If the requirements document is correct in its reasoning, then none of= the existing solutions have what it takes to be successful in the real wor= ld.=A0 Of course, that does not mean that a new approach will necessary be = successful. But it does imply that the arguments made in the requirements d= ocument cannot be dismissed out of hand, and need to be argued on their mer= its.

I rather think the requirements document is lis= ting some issues with existing solutions and from that lists requirements t= hat a solution without such issues should fulfill. It does not imply a part= icular solution.
--001636c5bc62750d9404837b50bb-- From ietf.hanserik@gmail.com Mon Apr 5 04:16:31 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1B93A68DE for ; Mon, 5 Apr 2010 04:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwoiGGhXKWBc for ; Mon, 5 Apr 2010 04:16:30 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 1C7BA3A694A for ; Mon, 5 Apr 2010 04:16:23 -0700 (PDT) Received: by ewy24 with SMTP id 24so1162284ewy.13 for ; Mon, 05 Apr 2010 04:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=EpEORbCH/iQTpzlvQuhYsc9z8YsJnqI0WmSD0aYs46A=; b=IOQy7yiWgBGvfY2j/iXx0R6RfdrR2Yxas1vlBH2O0pG6p4wSxS9rmMgYApi5FACSyn z6Qr+1jf2u05O02QpGuHn+Cf7ye4hAxNjttbKnvD/tVf9Cmw2TdK41R2k+zxRBaCSwGO nduHYw2qRCaLZFvfJ/BxsIYeWydJ8Zx+qLNu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RUHOHBQy+GqhvmGhvMQhO07EQ4lcdJlGuiooGuhjht2pBAIqHguzSs5BqQAnxg+s29 0EmR0GbwYk/uJUYcTbBWC1f4+B/iNbJGPOg9KBZwVxfCq1o3658KvoAv6vYuwtUrZkd0 dAbcDmPwi4yAWsCD6/OjQO7LkdbgMQ66EaZEE= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Mon, 5 Apr 2010 04:16:18 -0700 (PDT) In-Reply-To: <005701cad41c$bf4e1a20$3dea4e60$@us> References: <005701cad41c$bf4e1a20$3dea4e60$@us> Date: Mon, 5 Apr 2010 13:16:18 +0200 Received: by 10.213.49.212 with SMTP id w20mr2875991ebf.29.1270466178721; Mon, 05 Apr 2010 04:16:18 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Richard Shockey Content-Type: multipart/alternative; boundary=001485318d09482f8204837b7570 Cc: Bernard Aboba , martini@ietf.org Subject: Re: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 11:16:31 -0000 --001485318d09482f8204837b7570 Content-Type: text/plain; charset=ISO-8859-1 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 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. > > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf > Of Dean Willis > Sent: Sunday, April 04, 2010 1:04 PM > To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org > Subject: Re: [martini] The IETF versus reality (was: problems with existing > SIP trunking solutions) > > Are you saying that the IMS solution is what the service providers need? > > > > "DOLLY, MARTIN C (ATTLABS)" 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 > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > --001485318d09482f8204837b7570 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is low cost IMS deployments to... this is a non-argument. There is ev= en open source IMS implementations available and some companies are buildin= g solutions based on that just for the kind of parties that you was referri= ng 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

O= n Sun, Apr 4, 2010 at 7:32 PM, Richard Shockey <richard@shockey.us> wrote:
The IMS solution could certainly work for large scale enterprise deployment= s served by ATT and massive PTT's but is ineffectual and cost prohibiti= ve for small and medium business served typically by CLEC's. That's= the whole business and technical model behind implicit registration SMB= 9;s and competition.


-----Original Message-----
From: martini-bounces@ietf.org<= /a> [mailto:martini-bounces@iet= f.org] On Behalf Of Dean Willis
Sent: Sunday, April 04, 2010 1:04 PM
To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org
Subject: Re: [martini] The IETF versus reality (was: problems with existing= SIP trunking solutions)

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


"DOLLY, MARTIN C (ATTLABS)" <md3135@att.com> wrote:

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

--
Dean Willis

_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini

--001485318d09482f8204837b7570-- From JSBURTON@cablevision.com Mon Apr 5 06:04:20 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4413D3A6992 for ; Mon, 5 Apr 2010 06:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.397 X-Spam-Level: * X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTNxLWEXmlj5 for ; Mon, 5 Apr 2010 06:04:19 -0700 (PDT) Received: from cscpsmout01.cablevision.com (cscpsmout01.cablevision.com [167.206.119.144]) by core3.amsl.com (Postfix) with ESMTP id F32793A698A for ; Mon, 5 Apr 2010 06:04:18 -0700 (PDT) Received: from c3gwiaoutvs.cablevision.com (c3gwiaoutvs.cablevision.com [10.128.36.189]) by cscpsmout01.cablevision.com (Sentrion-MTA-4.0.2/Sentrion-MTA-4.0.2) with ESMTP id o35D4Fn6025611 for ; Mon, 5 Apr 2010 09:04:15 -0400 X-DKIM: Sendmail DKIM Filter v2.5.6 cscpsmout01.cablevision.com o35D4Fn6025611 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cablevision.com; s=cscprod; t=1270472655; bh=hSmLf8SziO9uyuQcZOYki4AsICDy9dhd0vaEXp0 1I1A=; h=Message-Id:Date:From:To:Subject:References:In-Reply-To: Mime-Version:Content-Type; b=aD8Kru9SNENQWYB9rN2JVUjGxzMoqApf5rHNw Hcndg+VXovJ4ZwJQyHRPt8+aBdmnPVmUdwrU/28AP3ZHiNwW+PTDcz4S0Cl84rWVqzC tYr8wv8SZQvIFC0S1lOmtDJdmfOr6DeD8LS+fraS4ekQjJ2s4XbSMN8tIoKW5YcxSZA = Received: from C3GWIAOUTDOM-MTA by c3gwiaoutvs.cablevision.com with Novell_GroupWise; Mon, 05 Apr 2010 09:04:15 -0400 Message-Id: <4BB9A78A.38CD.00CB.0@cablevision.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Mon, 05 Apr 2010 09:04:10 -0400 From: "Jack Burton" To: References: <005701cad41c$bf4e1a20$3dea4e60$@us> In-Reply-To: <005701cad41c$bf4e1a20$3dea4e60$@us> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part9FB560DA.0__=" X-Auth-Type: Internal IP Subject: Re: [martini] The IETF versus reality (was: problemswith existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 13:04:20 -0000 --=__Part9FB560DA.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Speaking as another service provider, I agree with Richard. -Jack >>> "Richard Shockey" 4/4/2010 13:32 >>> 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: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis Sent: Sunday, April 04, 2010 1:04 PM To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org Subject: Re: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions) Are you saying that the IMS solution is what the service providers need? "DOLLY, MARTIN C (ATTLABS)" 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 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini -------------------------------------------------------- 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. -------------------------------------------------------- --=__Part9FB560DA.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML
Speaking as another service provider, I agree with Richard.
 
-Jack

>>> "Richard Shockey" <richard@shockey.us>= 4/4/2010 13:32 >>>
The IMS solution could certainly work for l= arge scale enterprise deployments served by ATT and massive PTT's but is in= effectual and cost prohibitive for small and medium business served typical= ly by CLEC's. That's the whole business and technical model behind implicit= registration SMB's and competition.


-----Original Message-----<= BR>From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Beha= lf Of Dean Willis
Sent: Sunday, April 04, 2010 1:04 PM
To: DOLLY, MAR= TIN C (ATTLABS); Bernard Aboba; martini@ietf.org
Subject: Re: [martini] = The IETF versus reality (was: problems with existing SIP trunking solutions= )

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



"DOLLY, MARTIN C (ATTLABS)" <md3135@att.com> wr= ote:

>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 hau= l .

--
Dean Willis

_______________________________________= ________
martini mailing list
martini@ietf.org
https://www.ietf.org/mailman/listinf= o/martini

--------------------------------------------------------
The information transmitted in this email and any of its attachments is int= ended only for the person or entity to which it is addressed and may contai= n 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 r= eceived 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.
-------------------------------------------------------- --=__Part9FB560DA.0__=-- From md3135@att.com Mon Apr 5 06:29:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CB5B3A69BD for ; Mon, 5 Apr 2010 06:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.748 X-Spam-Level: X-Spam-Status: No, score=-103.748 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP7vjgunhy43 for ; Mon, 5 Apr 2010 06:29:29 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 186103A699C for ; Mon, 5 Apr 2010 06:29:27 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-12.tower-129.messagelabs.com!1270474163!9236137!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 24620 invoked from network); 5 Apr 2010 13:29:24 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Apr 2010 13:29:24 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o35DTAha003378 for ; Mon, 5 Apr 2010 09:29:10 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o35DT6uZ003287 for ; Mon, 5 Apr 2010 09:29:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD4C3.FE8106AC" Date: Mon, 5 Apr 2010 09:29:18 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E5D@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) Thread-Index: AcrUwL+uv//Y4u0VTfKOK7kQtWPfiAAAz7xb From: "DOLLY, MARTIN C (ATTLABS)" To: , Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 13:29:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD4C3.FE8106AC Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gSUVURiBpcyB0aGUgdGhlcmUgZm9yIGNhYmxlLCBjb29sLiBUaGlzIHdpbGwgcGxheSB3ZWxs IGluIHJlZ3VsYXRvcnksIGR1ZGUsIHRoYW5rcw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpGcm9tOiBtYXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmcgPG1hcnRpbmktYm91bmNl c0BpZXRmLm9yZz4gDQpUbzogbWFydGluaUBpZXRmLm9yZyA8bWFydGluaUBpZXRmLm9yZz4gDQpT ZW50OiBNb24gQXByIDA1IDA5OjA0OjEwIDIwMTANClN1YmplY3Q6IFJlOiBbbWFydGluaV0gVGhl IElFVEYgdmVyc3VzIHJlYWxpdHkod2FzOiBwcm9ibGVtc3dpdGggZXhpc3RpbmcgU0lQIHRydW5r aW5nIHNvbHV0aW9ucykgDQoNCg0KU3BlYWtpbmcgYXMgYW5vdGhlciBzZXJ2aWNlIHByb3ZpZGVy LCBJIGFncmVlIHdpdGggUmljaGFyZC4NCiANCi1KYWNrDQoNCj4+PiAiUmljaGFyZCBTaG9ja2V5 IiA8cmljaGFyZEBzaG9ja2V5LnVzPiA0LzQvMjAxMCAxMzozMiA+Pj4NClRoZSBJTVMgc29sdXRp b24gY291bGQgY2VydGFpbmx5IHdvcmsgZm9yIGxhcmdlIHNjYWxlIGVudGVycHJpc2UgZGVwbG95 bWVudHMgc2VydmVkIGJ5IEFUVCBhbmQgbWFzc2l2ZSBQVFQncyBidXQgaXMgaW5lZmZlY3R1YWwg YW5kIGNvc3QgcHJvaGliaXRpdmUgZm9yIHNtYWxsIGFuZCBtZWRpdW0gYnVzaW5lc3Mgc2VydmVk IHR5cGljYWxseSBieSBDTEVDJ3MuIFRoYXQncyB0aGUgd2hvbGUgYnVzaW5lc3MgYW5kIHRlY2hu aWNhbCBtb2RlbCBiZWhpbmQgaW1wbGljaXQgcmVnaXN0cmF0aW9uIFNNQidzIGFuZCBjb21wZXRp dGlvbi4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbWFydGluaS1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bWFydGluaS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgRGVhbiBXaWxsaXMNClNlbnQ6IFN1bmRheSwgQXByaWwgMDQsIDIwMTAgMTowNCBQTQ0KVG86 IERPTExZLCBNQVJUSU4gQyAoQVRUTEFCUyk7IEJlcm5hcmQgQWJvYmE7IG1hcnRpbmlAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbbWFydGluaV0gVGhlIElFVEYgdmVyc3VzIHJlYWxpdHkgKHdhczog cHJvYmxlbXMgd2l0aCBleGlzdGluZyBTSVAgdHJ1bmtpbmcgc29sdXRpb25zKQ0KDQpBcmUgeW91 IHNheWluZyB0aGF0IHRoZSBJTVMgc29sdXRpb24gaXMgd2hhdCB0aGUgc2VydmljZSBwcm92aWRl cnMgbmVlZD8NCg0KDQoNCiJET0xMWSwgTUFSVElOIEMgKEFUVExBQlMpIiA8bWQzMTM1QGF0dC5j b20+IHdyb3RlOg0KDQo+U3BlYWtpbmcgYXMgYSBTZXJ2aWNlIFByb3ZpZGVyLCB0aGUgc29sdXRp b24gYmVpbmcgcHJvZHVjZWQgYnkgTWFydGluaSANCj5kb2VzIG5vdCBhZGRyZXNzIHdoYXQgaXMg bmVlZGVkIGZvciBjdXJyZW50IHRvIG1pZC10ZXJtIGRlcGxveW1lbnRzLCANCj5hbmQgY3JlYXRl cyBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zIGluIHRoZSBsb25nIGhhdWwgLg0KDQotLQ0KRGVh biBXaWxsaXMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCm1hcnRpbmkgbWFpbGluZyBsaXN0DQptYXJ0aW5pQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hcnRpbmkNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANClRoZSBpbmZvcm1hdGlvbiB0 cmFuc21pdHRlZCBpbiB0aGlzIGVtYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIGlzIGlu dGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJl c3NlZCBhbmQgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gY29uY2VybmluZyBDYWJsZXZpc2lvbiBh bmQvb3IgaXRzIGFmZmlsaWF0ZXMgYW5kIHN1YnNpZGlhcmllcyB0aGF0IGlzIHByb3ByaWV0YXJ5 LCBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwgYW5kL29yIHN1YmplY3QgdG8gY29weXJpZ2h0LiBB bnkgcmV2aWV3LCByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBvciBvdGhlciB1c2Ugb2Ys IG9yIHRha2luZyBvZiBhbnkgYWN0aW9uIGluIHJlbGlhbmNlIHVwb24sIHRoaXMgaW5mb3JtYXRp b24gYnkgcGVyc29ucyBvciBlbnRpdGllcyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGll bnQocykgaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgcmVjZWl2ZWQg dGhpcyBpbiBlcnJvciwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQg ZGVsZXRlIGFuZCBkZXN0cm95IHRoZSBjb21tdW5pY2F0aW9uIGFuZCBhbGwgb2YgdGhlIGF0dGFj aG1lbnRzIHlvdSBoYXZlIHJlY2VpdmVkIGFuZCBhbGwgY29waWVzIHRoZXJlb2YuDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K ------_=_NextPart_001_01CAD4C3.FE8106AC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PEhUTUw+PEhFQUQ+DQoNCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNvbnRlbnQ9Ik1TSFRNTCA4LjAw LjYwMDEuMTg5MDQiPjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJNQVJHSU46IDRweCA0cHggMXB4OyBG T05UOiAxMHB0IFRhaG9tYSI+PGRpdj48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFs Pg0KU28gSUVURiBpcyB0aGUgdGhlcmUgZm9yIGNhYmxlLCBjb29sLiBUaGlzIHdpbGwgcGxheSB3 ZWxsIGluIHJlZ3VsYXRvcnksIGR1ZGUsIHRoYW5rczwvZm9udD48L2Rpdj4NCjxicj48ZGl2Pjxo ciBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0YWJpbmRleD0tMT4NCjxmb250IGZh Y2U9VGFob21hIHNpemU9Mj4NCjxiPkZyb208L2I+OiBtYXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmcg Jmx0O21hcnRpbmktYm91bmNlc0BpZXRmLm9yZyZndDsNPGJyPjxiPlRvPC9iPjogbWFydGluaUBp ZXRmLm9yZyAmbHQ7bWFydGluaUBpZXRmLm9yZyZndDsNPGJyPjxiPlNlbnQ8L2I+OiBNb24gQXBy IDA1IDA5OjA0OjEwIDIwMTA8YnI+PGI+U3ViamVjdDwvYj46IFJlOiBbbWFydGluaV0gVGhlIElF VEYgdmVyc3VzIHJlYWxpdHkod2FzOglwcm9ibGVtc3dpdGgJZXhpc3RpbmcJU0lQIHRydW5raW5n IHNvbHV0aW9ucykNPGJyPjwvZm9udD48YnI+PC9kaXY+DQoNCjxESVY+U3BlYWtpbmcgYXMgYW5v dGhlciBzZXJ2aWNlIHByb3ZpZGVyLCBJIGFncmVlIHdpdGggUmljaGFyZC48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPi1KYWNrPEJSPjxCUj4mZ3Q7Jmd0OyZndDsgIlJpY2hhcmQgU2hv Y2tleSIgJmx0O3JpY2hhcmRAc2hvY2tleS51cyZndDsgNC80LzIwMTAgMTM6MzIgJmd0OyZndDsm Z3Q7PEJSPlRoZSBJTVMgc29sdXRpb24gY291bGQgY2VydGFpbmx5IHdvcmsgZm9yIGxhcmdlIHNj YWxlIGVudGVycHJpc2UgZGVwbG95bWVudHMgc2VydmVkIGJ5IEFUVCBhbmQgbWFzc2l2ZSBQVFQn cyBidXQgaXMgaW5lZmZlY3R1YWwgYW5kIGNvc3QgcHJvaGliaXRpdmUgZm9yIHNtYWxsIGFuZCBt ZWRpdW0gYnVzaW5lc3Mgc2VydmVkIHR5cGljYWxseSBieSBDTEVDJ3MuIFRoYXQncyB0aGUgd2hv bGUgYnVzaW5lc3MgYW5kIHRlY2huaWNhbCBtb2RlbCBiZWhpbmQgaW1wbGljaXQgcmVnaXN0cmF0 aW9uIFNNQidzIGFuZCBjb21wZXRpdGlvbi48QlI+PEJSPjxCUj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxCUj5Gcm9tOiBtYXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptYXJ0aW5p LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEZWFuIFdpbGxpczxCUj5TZW50OiBTdW5k YXksIEFwcmlsIDA0LCAyMDEwIDE6MDQgUE08QlI+VG86IERPTExZLCBNQVJUSU4gQyAoQVRUTEFC Uyk7IEJlcm5hcmQgQWJvYmE7IG1hcnRpbmlAaWV0Zi5vcmc8QlI+U3ViamVjdDogUmU6IFttYXJ0 aW5pXSBUaGUgSUVURiB2ZXJzdXMgcmVhbGl0eSAod2FzOiBwcm9ibGVtcyB3aXRoIGV4aXN0aW5n IFNJUCB0cnVua2luZyBzb2x1dGlvbnMpPEJSPjxCUj5BcmUgeW91IHNheWluZyB0aGF0IHRoZSBJ TVMgc29sdXRpb24gaXMgd2hhdCB0aGUgc2VydmljZSBwcm92aWRlcnMgbmVlZD88QlI+PEJSPjxC Uj48QlI+IkRPTExZLCBNQVJUSU4gQyAoQVRUTEFCUykiICZsdDttZDMxMzVAYXR0LmNvbSZndDsg d3JvdGU6PEJSPjxCUj4mZ3Q7U3BlYWtpbmcgYXMgYSBTZXJ2aWNlIFByb3ZpZGVyLCB0aGUgc29s dXRpb24gYmVpbmcgcHJvZHVjZWQgYnkgTWFydGluaSA8QlI+Jmd0O2RvZXMgbm90IGFkZHJlc3Mg d2hhdCBpcyBuZWVkZWQgZm9yIGN1cnJlbnQgdG8gbWlkLXRlcm0gZGVwbG95bWVudHMsIDxCUj4m Z3Q7YW5kIGNyZWF0ZXMgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcyBpbiB0aGUgbG9uZyBoYXVs IC48QlI+PEJSPi0tPEJSPkRlYW4gV2lsbGlzPEJSPjxCUj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5tYXJ0aW5pIG1haWxpbmcgbGlzdDxCUj5tYXJ0 aW5pQGlldGYub3JnPEJSPjxBIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWFydGluaSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYXJ0 aW5pPC9BPjxCUj48L0RJVj48L0JPRFk+PC9IVE1MPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KVGhlIGluZm9ybWF0 aW9uIHRyYW5zbWl0dGVkIGluIHRoaXMgZW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMg aXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMg YWRkcmVzc2VkIGFuZCBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiBjb25jZXJuaW5nIENhYmxldmlz aW9uIGFuZC9vciBpdHMgYWZmaWxpYXRlcyBhbmQgc3Vic2lkaWFyaWVzIHRoYXQgaXMgcHJvcHJp ZXRhcnksIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCBhbmQvb3Igc3ViamVjdCB0byBjb3B5cmln aHQuICAgQW55IHJldmlldywgcmV0cmFuc21pc3Npb24sIGRpc3NlbWluYXRpb24gb3Igb3RoZXIg dXNlIG9mLCBvciB0YWtpbmcgb2YgYW55IGFjdGlvbiBpbiByZWxpYW5jZSB1cG9uLCB0aGlzIGlu Zm9ybWF0aW9uIGJ5IHBlcnNvbnMgb3IgZW50aXRpZXMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gIElmIHlvdSBy ZWNlaXZlZCB0aGlzIGluIGVycm9yLCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBkZWxldGUgYW5kIGRlc3Ryb3kgdGhlIGNvbW11bmljYXRpb24gYW5kIGFsbCBvZiB0 aGUgYXR0YWNobWVudHMgeW91IGhhdmUgcmVjZWl2ZWQgYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi48 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ== ------_=_NextPart_001_01CAD4C3.FE8106AC-- From richard@shockey.us Mon Apr 5 08:50:22 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25C2628C184 for ; Mon, 5 Apr 2010 08:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.585 X-Spam-Level: X-Spam-Status: No, score=0.585 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpIRO3wvbIjP for ; Mon, 5 Apr 2010 08:50:20 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (oproxy2-pub.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 8343728C185 for ; Mon, 5 Apr 2010 08:50:20 -0700 (PDT) Received: (qmail 20855 invoked by uid 0); 5 Apr 2010 15:50:19 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 5 Apr 2010 15:50:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=pYDJr2EiBpkiYICTZ+ljPz4pRdxcjsqKi/+DbiUYqpQ040NjQMyOGmw6c18zLti0IHdsOri3edjtm4P41X7zvjK6RVJWZ6G3hZ1qnwHN++ZK/SvEEC0tBb2zDFeIUv82; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NyoZ8-0000JZ-DD; Mon, 05 Apr 2010 09:50:18 -0600 From: "Richard Shockey" To: "'DOLLY, MARTIN C \(ATTLABS\)'" , , References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E5D@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E5D@gaalpa1msgusr7e.ugd.att.com> Date: Mon, 5 Apr 2010 11:50:13 -0400 Message-ID: <000e01cad4d7$aecf5180$0c6df480$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CAD4B6.27BDB180" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrUwL+uv//Y4u0VTfKOK7kQtWPfiAAAz7xbAASG+3A= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 15:50:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01CAD4B6.27BDB180 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Marty =E2=80=A6I=E2=80=99m just doing my little bit to end POTS and the = PSTN by making it easier to kill off all of those nasty PRI=E2=80=99s = and TCAP. J=20 I do have a NO PRI hat for you BTW. Isn=E2=80=99t that what ATT wants? Certainly the filings at the FCC = says that what you guys want. J=20 You know I=E2=80=99d do anything I can to help ATT kill off analog POTS = and keep those dividends flowing to all those widows and orphans.=20 http://fjallfoss.fcc.gov/ecfs/document/view?id=3D7020354032 From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of DOLLY, MARTIN C (ATTLABS) Sent: Monday, April 05, 2010 9:29 AM To: JSBURTON@cablevision.com; martini@ietf.org Subject: Re: [martini] The IETF versus reality(was: problemswith = existing SIP trunking solutions) =20 So IETF is the there for cable, cool. This will play well in regulatory, = dude, thanks =20 _____ =20 From: martini-bounces@ietf.org =20 To: martini@ietf.org =20 Sent: Mon Apr 05 09:04:10 2010 Subject: Re: [martini] The IETF versus reality(was: problemswith = existing SIP trunking solutions)=20 Speaking as another service provider, I agree with Richard. =20 -Jack >>> "Richard Shockey" 4/4/2010 13:32 >>> 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: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of Dean Willis Sent: Sunday, April 04, 2010 1:04 PM To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org Subject: Re: [martini] The IETF versus reality (was: problems with = existing SIP trunking solutions) Are you saying that the IMS solution is what the service providers need? "DOLLY, MARTIN C (ATTLABS)" wrote: >Speaking as a Service Provider, the solution being produced by Martini=20 >does not address what is needed for current to mid-term deployments,=20 >and creates interoperability problems in the long haul . -- Dean Willis _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini --------------------------------------------------------=20 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. -------------------------------------------------------- ------=_NextPart_000_000F_01CAD4B6.27BDB180 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Marty =E2=80=A6I=E2=80=99m just doing my little bit to = end POTS and the PSTN by making it easier to kill off all of those nasty PRI=E2=80=99s and TCAP. = J

I do have a NO PRI hat for you BTW.

Isn=E2=80=99t that what ATT wants? =C2=A0Certainly the = filings at the FCC says that what you guys want. J

You know I=E2=80=99d do anything I can to help ATT kill = off analog POTS and keep those dividends flowing to all those widows and orphans. =

http://fjallfoss.fcc.gov/ecfs/document/view?id=3D702035403= 2

From:= martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of DOLLY, MARTIN C (ATTLABS)
Sent: Monday, April 05, 2010 9:29 AM
To: JSBURTON@cablevision.com; martini@ietf.org
Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions)

 

So= IETF is the there for cable, cool. This will play well in regulatory, dude, = thanks<= /span>

 <= /o:p>

From<= /b>: martini-bounces@ietf.org <martini-bounces@ietf.org>
To: martini@ietf.org <martini@ietf.org>
Sent: Mon Apr 05 09:04:10 2010
Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions)

Speaking as = another service provider, I agree with Richard.

 <= /o:p>

-Jack

>>> "Richard Shockey" <richard@shockey.us> = 4/4/2010 13:32 >>>
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: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of Dean Willis
Sent: Sunday, April 04, 2010 1:04 PM
To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org
Subject: Re: [martini] The IETF versus reality (was: problems with = existing SIP trunking solutions)

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



"DOLLY, MARTIN C (ATTLABS)" <md3135@att.com> 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

_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.o= rg/mailman/listinfo/martini


--------------------------------------------------------
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.
--------------------------------------------------------

------=_NextPart_000_000F_01CAD4B6.27BDB180-- From md3135@att.com Mon Apr 5 09:14:35 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 142243A6846 for ; Mon, 5 Apr 2010 09:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.923 X-Spam-Level: X-Spam-Status: No, score=-104.923 tagged_above=-999 required=5 tests=[AWL=1.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMMVJ+SBWT65 for ; Mon, 5 Apr 2010 09:14:32 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 54D853A69A4 for ; Mon, 5 Apr 2010 09:14:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-6.tower-129.messagelabs.com!1270484068!41139730!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 25132 invoked from network); 5 Apr 2010 16:14:29 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-6.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Apr 2010 16:14:29 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o35GEFnS031173; Mon, 5 Apr 2010 12:14:15 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o35GE8E9031086; Mon, 5 Apr 2010 12:14:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD4DB.0CBD605A" Date: Mon, 5 Apr 2010 12:14:20 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E5F@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) Thread-Index: AcrUwL+uv//Y4u0VTfKOK7kQtWPfiAAAz7xbAASG+3AAATyHOg== From: "DOLLY, MARTIN C (ATTLABS)" To: , , Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 16:14:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD4DB.0CBD605A Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R0lOIGRvZXMgbm90IGN1dCBpdC4gUHVyZSBCUw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpGcm9tOiBSaWNoYXJkIFNob2NrZXkgPHJpY2hhcmRAc2hvY2tleS51cz4gDQpU bzogRE9MTFksIE1BUlRJTiBDIChBVFRMQUJTKTsgSlNCVVJUT05AY2FibGV2aXNpb24uY29tIDxK U0JVUlRPTkBjYWJsZXZpc2lvbi5jb20+OyBtYXJ0aW5pQGlldGYub3JnIDxtYXJ0aW5pQGlldGYu b3JnPiANClNlbnQ6IE1vbiBBcHIgMDUgMTE6NTA6MTMgMjAxMA0KU3ViamVjdDogUkU6IFttYXJ0 aW5pXSBUaGUgSUVURiB2ZXJzdXMgcmVhbGl0eSh3YXM6IHByb2JsZW1zd2l0aCBleGlzdGluZyBT SVAgdHJ1bmtpbmcgc29sdXRpb25zKSANCg0KDQoNCk1hcnR5IOKApknigJltIGp1c3QgZG9pbmcg bXkgbGl0dGxlIGJpdCB0byBlbmQgUE9UUyBhbmQgdGhlIFBTVE4gYnkgbWFraW5nIGl0IGVhc2ll ciB0byBraWxsIG9mZiBhbGwgb2YgdGhvc2UgbmFzdHkgUFJJ4oCZcyBhbmQgVENBUC4gSiANCg0K SSBkbyBoYXZlIGEgTk8gUFJJIGhhdCBmb3IgeW91IEJUVy4NCg0KSXNu4oCZdCB0aGF0IHdoYXQg QVRUIHdhbnRzPyAgQ2VydGFpbmx5IHRoZSBmaWxpbmdzIGF0IHRoZSBGQ0Mgc2F5cyB0aGF0IHdo YXQgeW91IGd1eXMgd2FudC4gSiANCg0KWW91IGtub3cgSeKAmWQgZG8gYW55dGhpbmcgSSBjYW4g dG8gaGVscCBBVFQga2lsbCBvZmYgYW5hbG9nIFBPVFMgYW5kIGtlZXAgdGhvc2UgZGl2aWRlbmRz IGZsb3dpbmcgdG8gYWxsIHRob3NlIHdpZG93cyBhbmQgb3JwaGFucy4gDQoNCmh0dHA6Ly9mamFs bGZvc3MuZmNjLmdvdi9lY2ZzL2RvY3VtZW50L3ZpZXc/aWQ9NzAyMDM1NDAzMg0KDQpGcm9tOiBt YXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptYXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBET0xMWSwgTUFSVElOIEMgKEFUVExBQlMpDQpTZW50OiBNb25kYXksIEFw cmlsIDA1LCAyMDEwIDk6MjkgQU0NClRvOiBKU0JVUlRPTkBjYWJsZXZpc2lvbi5jb207IG1hcnRp bmlAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFydGluaV0gVGhlIElFVEYgdmVyc3VzIHJlYWxp dHkod2FzOiBwcm9ibGVtc3dpdGggZXhpc3RpbmcgU0lQIHRydW5raW5nIHNvbHV0aW9ucykNCg0K IA0KDQpTbyBJRVRGIGlzIHRoZSB0aGVyZSBmb3IgY2FibGUsIGNvb2wuIFRoaXMgd2lsbCBwbGF5 IHdlbGwgaW4gcmVndWxhdG9yeSwgZHVkZSwgdGhhbmtzDQoNCiANCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KRnJvbTogbWFydGluaS1ib3VuY2VzQGlldGYub3JnIDxtYXJ0 aW5pLWJvdW5jZXNAaWV0Zi5vcmc+IA0KVG86IG1hcnRpbmlAaWV0Zi5vcmcgPG1hcnRpbmlAaWV0 Zi5vcmc+IA0KU2VudDogTW9uIEFwciAwNSAwOTowNDoxMCAyMDEwDQpTdWJqZWN0OiBSZTogW21h cnRpbmldIFRoZSBJRVRGIHZlcnN1cyByZWFsaXR5KHdhczogcHJvYmxlbXN3aXRoIGV4aXN0aW5n IFNJUCB0cnVua2luZyBzb2x1dGlvbnMpIA0KDQpTcGVha2luZyBhcyBhbm90aGVyIHNlcnZpY2Ug cHJvdmlkZXIsIEkgYWdyZWUgd2l0aCBSaWNoYXJkLg0KDQogDQoNCi1KYWNrDQoNCj4+PiAiUmlj aGFyZCBTaG9ja2V5IiA8cmljaGFyZEBzaG9ja2V5LnVzPiA0LzQvMjAxMCAxMzozMiA+Pj4NClRo ZSBJTVMgc29sdXRpb24gY291bGQgY2VydGFpbmx5IHdvcmsgZm9yIGxhcmdlIHNjYWxlIGVudGVy cHJpc2UgZGVwbG95bWVudHMgc2VydmVkIGJ5IEFUVCBhbmQgbWFzc2l2ZSBQVFQncyBidXQgaXMg aW5lZmZlY3R1YWwgYW5kIGNvc3QgcHJvaGliaXRpdmUgZm9yIHNtYWxsIGFuZCBtZWRpdW0gYnVz aW5lc3Mgc2VydmVkIHR5cGljYWxseSBieSBDTEVDJ3MuIFRoYXQncyB0aGUgd2hvbGUgYnVzaW5l c3MgYW5kIHRlY2huaWNhbCBtb2RlbCBiZWhpbmQgaW1wbGljaXQgcmVnaXN0cmF0aW9uIFNNQidz IGFuZCBjb21wZXRpdGlvbi4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog bWFydGluaS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bWFydGluaS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRGVhbiBXaWxsaXMNClNlbnQ6IFN1bmRheSwgQXByaWwgMDQsIDIwMTAg MTowNCBQTQ0KVG86IERPTExZLCBNQVJUSU4gQyAoQVRUTEFCUyk7IEJlcm5hcmQgQWJvYmE7IG1h cnRpbmlAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFydGluaV0gVGhlIElFVEYgdmVyc3VzIHJl YWxpdHkgKHdhczogcHJvYmxlbXMgd2l0aCBleGlzdGluZyBTSVAgdHJ1bmtpbmcgc29sdXRpb25z KQ0KDQpBcmUgeW91IHNheWluZyB0aGF0IHRoZSBJTVMgc29sdXRpb24gaXMgd2hhdCB0aGUgc2Vy dmljZSBwcm92aWRlcnMgbmVlZD8NCg0KDQoNCiJET0xMWSwgTUFSVElOIEMgKEFUVExBQlMpIiA8 bWQzMTM1QGF0dC5jb20+IHdyb3RlOg0KDQo+U3BlYWtpbmcgYXMgYSBTZXJ2aWNlIFByb3ZpZGVy LCB0aGUgc29sdXRpb24gYmVpbmcgcHJvZHVjZWQgYnkgTWFydGluaSANCj5kb2VzIG5vdCBhZGRy ZXNzIHdoYXQgaXMgbmVlZGVkIGZvciBjdXJyZW50IHRvIG1pZC10ZXJtIGRlcGxveW1lbnRzLCAN Cj5hbmQgY3JlYXRlcyBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zIGluIHRoZSBsb25nIGhhdWwg Lg0KDQotLQ0KRGVhbiBXaWxsaXMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCm1hcnRpbmkgbWFpbGluZyBsaXN0DQptYXJ0aW5pQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hcnRpbmkNCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANClRoZSBp bmZvcm1hdGlvbiB0cmFuc21pdHRlZCBpbiB0aGlzIGVtYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFj aG1lbnRzIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHRvIHdoaWNo IGl0IGlzIGFkZHJlc3NlZCBhbmQgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gY29uY2VybmluZyBD YWJsZXZpc2lvbiBhbmQvb3IgaXRzIGFmZmlsaWF0ZXMgYW5kIHN1YnNpZGlhcmllcyB0aGF0IGlz IHByb3ByaWV0YXJ5LCBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwgYW5kL29yIHN1YmplY3QgdG8g Y29weXJpZ2h0LiBBbnkgcmV2aWV3LCByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBvciBv dGhlciB1c2Ugb2YsIG9yIHRha2luZyBvZiBhbnkgYWN0aW9uIGluIHJlbGlhbmNlIHVwb24sIHRo aXMgaW5mb3JtYXRpb24gYnkgcGVyc29ucyBvciBlbnRpdGllcyBvdGhlciB0aGFuIHRoZSBpbnRl bmRlZCByZWNpcGllbnQocykgaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5 b3UgcmVjZWl2ZWQgdGhpcyBpbiBlcnJvciwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgZGVsZXRlIGFuZCBkZXN0cm95IHRoZSBjb21tdW5pY2F0aW9uIGFuZCBhbGwg b2YgdGhlIGF0dGFjaG1lbnRzIHlvdSBoYXZlIHJlY2VpdmVkIGFuZCBhbGwgY29waWVzIHRoZXJl b2YuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQo= ------_=_NextPart_001_01CAD4DB.0CBD605A Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KDQo8bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPg0K PHN0eWxlPg0Kdlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZp b3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7 fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPg0KPCFbZW5k aWZdLS0+DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAw IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQogLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgltc28tYmVs aWV2ZS1ub3JtYWwtbGVmdDp5ZXM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30N Ci0tPg0KPC9zdHlsZT4NCjwhW2lmIG1zbyA5XT4NCjxzdHlsZT4NCnAuTXNvTm9ybWFsDQoJe21h cmdpbi1sZWZ0OjIuNHB0O30NCjwvc3R5bGU+DQo8IVtlbmRpZl0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQog PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5n PUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGUgc3R5bGU9J21hcmdpbi1sZWZ0OjIuNHB0O21h cmdpbi10b3A6DQoyLjRwdDttYXJnaW4tcmlnaHQ6Mi40cHQ7bWFyZ2luLWJvdHRvbTouNnB0Jz48 ZGl2Pjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+DQpHSU4gZG9lcyBub3QgY3V0 IGl0LiBQdXJlIEJTPC9mb250PjwvZGl2Pg0KPGJyPjxkaXY+PGhyIHNpemU9MiB3aWR0aD0iMTAw JSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0KPGZvbnQgZmFjZT1UYWhvbWEgc2l6ZT0yPg0K PGI+RnJvbTwvYj46IFJpY2hhcmQgU2hvY2tleSAmbHQ7cmljaGFyZEBzaG9ja2V5LnVzJmd0Ow08 YnI+PGI+VG88L2I+OiBET0xMWSwgTUFSVElOIEMgKEFUVExBQlMpOyBKU0JVUlRPTkBjYWJsZXZp c2lvbi5jb20gJmx0O0pTQlVSVE9OQGNhYmxldmlzaW9uLmNvbSZndDs7IG1hcnRpbmlAaWV0Zi5v cmcgJmx0O21hcnRpbmlAaWV0Zi5vcmcmZ3Q7DTxicj48Yj5TZW50PC9iPjogTW9uIEFwciAwNSAx MTo1MDoxMyAyMDEwPGJyPjxiPlN1YmplY3Q8L2I+OiBSRTogW21hcnRpbmldIFRoZSBJRVRGIHZl cnN1cwlyZWFsaXR5KHdhczoJcHJvYmxlbXN3aXRoCWV4aXN0aW5nCVNJUCB0cnVua2luZyBzb2x1 dGlvbnMpDTxicj48L2ZvbnQ+PGJyPjwvZGl2Pg0KDQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+TWFydHkg4oCmSeKA mW0ganVzdCBkb2luZyBteSBsaXR0bGUgYml0IHRvIGVuZCBQT1RTIGFuZCB0aGUgUFNUTiBieSBt YWtpbmcNCml0IGVhc2llciB0byBraWxsIG9mZiBhbGwgb2YgdGhvc2UgbmFzdHkgUFJJ4oCZcyBh bmQgVENBUC4gPC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCc+Sjwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz4gPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN CmNvbG9yOiMxRjQ5N0QnPkkgZG8gaGF2ZSBhIE5PIFBSSSBoYXQgZm9yIHlvdSBCVFcuPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMx RjQ5N0QnPklzbuKAmXQgdGhhdCB3aGF0IEFUVCB3YW50cz8gwqBDZXJ0YWlubHkgdGhlIGZpbGlu Z3MgYXQgdGhlIEZDQw0Kc2F5cyB0aGF0IHdoYXQgeW91IGd1eXMgd2FudC4gPC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Og0KV2luZ2RpbmdzO2NvbG9yOiMx RjQ5N0QnPko8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 DQoiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+WW91 IGtub3cgSeKAmWQgZG8gYW55dGhpbmcgSSBjYW4gdG8gaGVscCBBVFQga2lsbCBvZmYgYW5hbG9n IFBPVFMNCmFuZCBrZWVwIHRob3NlIGRpdmlkZW5kcyBmbG93aW5nIHRvIGFsbCB0aG9zZSB3aWRv d3MgYW5kIG9ycGhhbnMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5odHRwOi8vZmphbGxmb3NzLmZjYy5nb3YvZWNm cy9kb2N1bWVudC92aWV3P2lkPTcwMjAzNTQwMzI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxk aXY+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PGI+PHNwYW4NCnN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiInPg0KbWFydGluaS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bWFy dGluaS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkRPTExZLA0KTUFSVElO IEMgKEFUVExBQlMpPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwgMDUsIDIwMTAgOToy OSBBTTxicj4NCjxiPlRvOjwvYj4gSlNCVVJUT05AY2FibGV2aXNpb24uY29tOyBtYXJ0aW5pQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbWFydGluaV0gVGhlIElFVEYgdmVyc3Vz IHJlYWxpdHkod2FzOiBwcm9ibGVtc3dpdGgNCmV4aXN0aW5nIFNJUCB0cnVua2luZyBzb2x1dGlv bnMpPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4NCnN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOm5hdnknPlNvIElFVEYgaXMNCnRoZSB0aGVyZSBmb3IgY2FibGUsIGNvb2wuIFRoaXMgd2ls bCBwbGF5IHdlbGwgaW4gcmVndWxhdG9yeSwgZHVkZSwgdGhhbmtzPC9zcGFuPjxzcGFuDQpzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuDQpzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdj4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249 Y2VudGVyIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdDsNCnRleHQtYWxp Z246Y2VudGVyJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiInPg0KDQo8aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50 ZXI+DQoNCjwvc3Bhbj48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToNCjEyLjBwdDtt YXJnaW4tbGVmdDowaW4nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTwvc3Bhbj48L2I+PHNwYW4NCnN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+Og0KbWFy dGluaS1ib3VuY2VzQGlldGYub3JnICZsdDttYXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxi cj4NCjxiPlRvPC9iPjogbWFydGluaUBpZXRmLm9yZyAmbHQ7bWFydGluaUBpZXRmLm9yZyZndDsg PGJyPg0KPGI+U2VudDwvYj46IE1vbiBBcHIgMDUgMDk6MDQ6MTAgMjAxMDxicj4NCjxiPlN1Ympl Y3Q8L2I+OiBSZTogW21hcnRpbmldIFRoZSBJRVRGIHZlcnN1cyByZWFsaXR5KHdhczogcHJvYmxl bXN3aXRoDQpleGlzdGluZyBTSVAgdHJ1bmtpbmcgc29sdXRpb25zKSA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5TcGVha2luZyBhcyBhbm90 aGVyDQpzZXJ2aWNlIHByb3ZpZGVyLCBJIGFncmVlIHdpdGggUmljaGFyZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3Bhbg0Kc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4tSmFjazxi cj4NCjxicj4NCiZndDsmZ3Q7Jmd0OyAmcXVvdDtSaWNoYXJkIFNob2NrZXkmcXVvdDsgJmx0O3Jp Y2hhcmRAc2hvY2tleS51cyZndDsgNC80LzIwMTANCjEzOjMyICZndDsmZ3Q7Jmd0Ozxicj4NClRo ZSBJTVMgc29sdXRpb24gY291bGQgY2VydGFpbmx5IHdvcmsgZm9yIGxhcmdlIHNjYWxlIGVudGVy cHJpc2UgZGVwbG95bWVudHMNCnNlcnZlZCBieSBBVFQgYW5kIG1hc3NpdmUgUFRUJ3MgYnV0IGlz IGluZWZmZWN0dWFsIGFuZCBjb3N0IHByb2hpYml0aXZlIGZvcg0Kc21hbGwgYW5kIG1lZGl1bSBi dXNpbmVzcyBzZXJ2ZWQgdHlwaWNhbGx5IGJ5IENMRUMncy4gVGhhdCdzIHRoZSB3aG9sZSBidXNp bmVzcw0KYW5kIHRlY2huaWNhbCBtb2RlbCBiZWhpbmQgaW1wbGljaXQgcmVnaXN0cmF0aW9uIFNN QidzIGFuZCBjb21wZXRpdGlvbi48YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCkZyb206IG1hcnRpbmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1hcnRp bmktYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQpEZWFuIFdpbGxpczxicj4NClNlbnQ6 IFN1bmRheSwgQXByaWwgMDQsIDIwMTAgMTowNCBQTTxicj4NClRvOiBET0xMWSwgTUFSVElOIEMg KEFUVExBQlMpOyBCZXJuYXJkIEFib2JhOyBtYXJ0aW5pQGlldGYub3JnPGJyPg0KU3ViamVjdDog UmU6IFttYXJ0aW5pXSBUaGUgSUVURiB2ZXJzdXMgcmVhbGl0eSAod2FzOiBwcm9ibGVtcyB3aXRo IGV4aXN0aW5nIFNJUA0KdHJ1bmtpbmcgc29sdXRpb25zKTxicj4NCjxicj4NCkFyZSB5b3Ugc2F5 aW5nIHRoYXQgdGhlIElNUyBzb2x1dGlvbiBpcyB3aGF0IHRoZSBzZXJ2aWNlIHByb3ZpZGVycyBu ZWVkPzxicj4NCjxicj4NCjxicj4NCjxicj4NCiZxdW90O0RPTExZLCBNQVJUSU4gQyAoQVRUTEFC UykmcXVvdDsgJmx0O21kMzEzNUBhdHQuY29tJmd0OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7U3Bl YWtpbmcgYXMgYSBTZXJ2aWNlIFByb3ZpZGVyLCB0aGUgc29sdXRpb24gYmVpbmcgcHJvZHVjZWQg YnkgTWFydGluaSA8YnI+DQomZ3Q7ZG9lcyBub3QgYWRkcmVzcyB3aGF0IGlzIG5lZWRlZCBmb3Ig Y3VycmVudCB0byBtaWQtdGVybSBkZXBsb3ltZW50cywgPGJyPg0KJmd0O2FuZCBjcmVhdGVzIGlu dGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMgaW4gdGhlIGxvbmcgaGF1bCAuPGJyPg0KPGJyPg0KLS08 YnI+DQpEZWFuIFdpbGxpczxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KbWFydGluaSBtYWlsaW5nIGxpc3Q8YnI+DQptYXJ0aW5p QGlldGYub3JnPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tYXJ0aW5pIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hcnRp bmk8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCc+PGJyPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0K VGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGluIHRoaXMgZW1haWwgYW5kIGFueSBvZiBpdHMg YXR0YWNobWVudHMgaXMNCmludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHRv IHdoaWNoIGl0IGlzIGFkZHJlc3NlZCBhbmQgbWF5IGNvbnRhaW4NCmluZm9ybWF0aW9uIGNvbmNl cm5pbmcgQ2FibGV2aXNpb24gYW5kL29yIGl0cyBhZmZpbGlhdGVzIGFuZCBzdWJzaWRpYXJpZXMg dGhhdA0KaXMgcHJvcHJpZXRhcnksIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCBhbmQvb3Igc3Vi amVjdCB0byBjb3B5cmlnaHQuIEFueQ0KcmV2aWV3LCByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5h dGlvbiBvciBvdGhlciB1c2Ugb2YsIG9yIHRha2luZyBvZiBhbnkgYWN0aW9uDQppbiByZWxpYW5j ZSB1cG9uLCB0aGlzIGluZm9ybWF0aW9uIGJ5IHBlcnNvbnMgb3IgZW50aXRpZXMgb3RoZXIgdGhh biB0aGUNCmludGVuZGVkIHJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5s YXdmdWwuIElmIHlvdSByZWNlaXZlZCB0aGlzDQppbiBlcnJvciwgcGxlYXNlIGNvbnRhY3QgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGFuZCBkZXN0cm95IHRoZQ0KY29tbXVuaWNh dGlvbiBhbmQgYWxsIG9mIHRoZSBhdHRhY2htZW50cyB5b3UgaGF2ZSByZWNlaXZlZCBhbmQgYWxs IGNvcGllcw0KdGhlcmVvZi48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9ib2R5 Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_001_01CAD4DB.0CBD605A-- From pkyzivat@cisco.com Mon Apr 5 09:51:16 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532BB3A68DD for ; Mon, 5 Apr 2010 09:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.794 X-Spam-Level: X-Spam-Status: No, score=-9.794 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ69L25pfwdf for ; Mon, 5 Apr 2010 09:51:15 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C40913A68A4 for ; Mon, 5 Apr 2010 09:51:13 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFuxuUtAZnwN/2dsb2JhbACDEpg4cZ4FiEWPRYErgm5uBA X-IronPort-AV: E=Sophos;i="4.51,366,1267401600"; d="scan'208";a="98892257" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2010 16:51:07 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o35Gp78l012362; Mon, 5 Apr 2010 16:51:07 GMT Message-ID: <4BBA14F9.30202@cisco.com> Date: Mon, 05 Apr 2010 12:51:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "DOLLY, MARTIN C (ATTLABS)" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E5F@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E5F@gaalpa1msgusr7e.ugd.att.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: JSBURTON@cablevision.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 16:51:16 -0000 [as chair] DOLLY, MARTIN C (ATTLABS) wrote: > GIN does not cut it. Pure BS Martin - Such comments do not contribute to arriving at a consensus. If you have technical and/or editorial comments to make, they are welcome. Or feel free to submit an individual draft as an alternative to be considered. Thanks, Paul > ------------------------------------------------------------------------ > *From*: Richard Shockey > *To*: DOLLY, MARTIN C (ATTLABS); JSBURTON@cablevision.com > ; martini@ietf.org > *Sent*: Mon Apr 05 11:50:13 2010 > *Subject*: RE: [martini] The IETF versus reality(was: problemswith > existing SIP trunking solutions) > > Marty …I’m just doing my little bit to end POTS and the PSTN by making > it easier to kill off all of those nasty PRI’s and TCAP. J > > I do have a NO PRI hat for you BTW. > > Isn’t that what ATT wants? Certainly the filings at the FCC says that > what you guys want. J > > You know I’d do anything I can to help ATT kill off analog POTS and keep > those dividends flowing to all those widows and orphans. > > http://fjallfoss.fcc.gov/ecfs/document/view?id=7020354032 > > *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] *On > Behalf Of *DOLLY, MARTIN C (ATTLABS) > *Sent:* Monday, April 05, 2010 9:29 AM > *To:* JSBURTON@cablevision.com; martini@ietf.org > *Subject:* Re: [martini] The IETF versus reality(was: problemswith > existing SIP trunking solutions) > > > > So IETF is the there for cable, cool. This will play well in regulatory, > dude, thanks > > > > ------------------------------------------------------------------------ > > *From*: martini-bounces@ietf.org > *To*: martini@ietf.org > *Sent*: Mon Apr 05 09:04:10 2010 > *Subject*: Re: [martini] The IETF versus reality(was: problemswith > existing SIP trunking solutions) > > Speaking as another service provider, I agree with Richard. > > > > -Jack > >> >> "Richard Shockey" 4/4/2010 13:32 >>> > 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: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Dean Willis > Sent: Sunday, April 04, 2010 1:04 PM > To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org > Subject: Re: [martini] The IETF versus reality (was: problems with > existing SIP trunking solutions) > > Are you saying that the IMS solution is what the service providers need? > > > > "DOLLY, MARTIN C (ATTLABS)" 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 > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > > > -------------------------------------------------------- > 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. > -------------------------------------------------------- > > > ------------------------------------------------------------------------ > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From md3135@att.com Mon Apr 5 09:52:56 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06043A68DD for ; Mon, 5 Apr 2010 09:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.565 X-Spam-Level: X-Spam-Status: No, score=-105.565 tagged_above=-999 required=5 tests=[AWL=1.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZeIa7V5TyPg for ; Mon, 5 Apr 2010 09:52:55 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 8CFDA3A68A4 for ; Mon, 5 Apr 2010 09:52:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-5.tower-167.messagelabs.com!1270486372!16470785!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 23759 invoked from network); 5 Apr 2010 16:52:53 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Apr 2010 16:52:53 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o35Gqdji015154; Mon, 5 Apr 2010 12:52:39 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o35GqY4t015089; Mon, 5 Apr 2010 12:52:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 5 Apr 2010 12:52:45 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA061F5349@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <4BBA14F9.30202@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) Thread-Index: AcrU4DbtQ5FgmR0fSZ6/NherIZikBQAAA3xQ References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E5F@gaalpa1msgusr7e.ugd.att.com> <4BBA14F9.30202@cisco.com> From: "DOLLY, MARTIN C (ATTLABS)" To: "Paul Kyzivat" Cc: JSBURTON@cablevision.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 16:52:56 -0000 UGF1bCwNCg0KV2hhdCBpcyBjb25zZW5zdXMsIEkga25vdyBJIGRvIG5vdCBoYXZlIGEgdm90ZSBp biB0aGF0IGFzIEFUJlQuLi5zbyB3aGF0IGlzIHlvdXIgcG9pbnQNCg0KTWFydGluDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZh dEBjaXNjby5jb21dIA0KU2VudDogTW9uZGF5LCBBcHJpbCAwNSwgMjAxMCAxMjo1MSBQTQ0KVG86 IERPTExZLCBNQVJUSU4gQyAoQVRUTEFCUykNCkNjOiByaWNoYXJkQHNob2NrZXkudXM7IEpTQlVS VE9OQGNhYmxldmlzaW9uLmNvbTsgbWFydGluaUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttYXJ0 aW5pXSBUaGUgSUVURiB2ZXJzdXMgcmVhbGl0eSh3YXM6IHByb2JsZW1zd2l0aCBleGlzdGluZyBT SVAgdHJ1bmtpbmcgc29sdXRpb25zKQ0KDQpbYXMgY2hhaXJdDQoNCkRPTExZLCBNQVJUSU4gQyAo QVRUTEFCUykgd3JvdGU6DQo+IEdJTiBkb2VzIG5vdCBjdXQgaXQuIFB1cmUgQlMNCg0KTWFydGlu IC0gU3VjaCBjb21tZW50cyBkbyBub3QgY29udHJpYnV0ZSB0byBhcnJpdmluZyBhdCBhIGNvbnNl bnN1cy4NCg0KSWYgeW91IGhhdmUgdGVjaG5pY2FsIGFuZC9vciBlZGl0b3JpYWwgY29tbWVudHMg dG8gbWFrZSwgdGhleSBhcmUgDQp3ZWxjb21lLiBPciBmZWVsIGZyZWUgdG8gc3VibWl0IGFuIGlu ZGl2aWR1YWwgZHJhZnQgYXMgYW4gYWx0ZXJuYXRpdmUgdG8gDQpiZSBjb25zaWRlcmVkLg0KDQoJ VGhhbmtzLA0KCVBhdWwNCg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gKkZyb20qOiBSaWNoYXJkIFNo b2NrZXkgPHJpY2hhcmRAc2hvY2tleS51cz4NCj4gKlRvKjogRE9MTFksIE1BUlRJTiBDIChBVFRM QUJTKTsgSlNCVVJUT05AY2FibGV2aXNpb24uY29tIA0KPiA8SlNCVVJUT05AY2FibGV2aXNpb24u Y29tPjsgbWFydGluaUBpZXRmLm9yZyA8bWFydGluaUBpZXRmLm9yZz4NCj4gKlNlbnQqOiBNb24g QXByIDA1IDExOjUwOjEzIDIwMTANCj4gKlN1YmplY3QqOiBSRTogW21hcnRpbmldIFRoZSBJRVRG IHZlcnN1cyByZWFsaXR5KHdhczogcHJvYmxlbXN3aXRoIA0KPiBleGlzdGluZyBTSVAgdHJ1bmtp bmcgc29sdXRpb25zKQ0KPiANCj4gTWFydHkg4oCmSeKAmW0ganVzdCBkb2luZyBteSBsaXR0bGUg Yml0IHRvIGVuZCBQT1RTIGFuZCB0aGUgUFNUTiBieSBtYWtpbmcgDQo+IGl0IGVhc2llciB0byBr aWxsIG9mZiBhbGwgb2YgdGhvc2UgbmFzdHkgUFJJ4oCZcyBhbmQgVENBUC4gSg0KPiANCj4gSSBk byBoYXZlIGEgTk8gUFJJIGhhdCBmb3IgeW91IEJUVy4NCj4gDQo+IElzbuKAmXQgdGhhdCB3aGF0 IEFUVCB3YW50cz8gIENlcnRhaW5seSB0aGUgZmlsaW5ncyBhdCB0aGUgRkNDIHNheXMgdGhhdCAN Cj4gd2hhdCB5b3UgZ3V5cyB3YW50LiBKDQo+IA0KPiBZb3Uga25vdyBJ4oCZZCBkbyBhbnl0aGlu ZyBJIGNhbiB0byBoZWxwIEFUVCBraWxsIG9mZiBhbmFsb2cgUE9UUyBhbmQga2VlcCANCj4gdGhv c2UgZGl2aWRlbmRzIGZsb3dpbmcgdG8gYWxsIHRob3NlIHdpZG93cyBhbmQgb3JwaGFucy4NCj4g DQo+IGh0dHA6Ly9mamFsbGZvc3MuZmNjLmdvdi9lY2ZzL2RvY3VtZW50L3ZpZXc/aWQ9NzAyMDM1 NDAzMg0KPiANCj4gKkZyb206KiBtYXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptYXJ0 aW5pLWJvdW5jZXNAaWV0Zi5vcmddICpPbiANCj4gQmVoYWxmIE9mICpET0xMWSwgTUFSVElOIEMg KEFUVExBQlMpDQo+ICpTZW50OiogTW9uZGF5LCBBcHJpbCAwNSwgMjAxMCA5OjI5IEFNDQo+ICpU bzoqIEpTQlVSVE9OQGNhYmxldmlzaW9uLmNvbTsgbWFydGluaUBpZXRmLm9yZw0KPiAqU3ViamVj dDoqIFJlOiBbbWFydGluaV0gVGhlIElFVEYgdmVyc3VzIHJlYWxpdHkod2FzOiBwcm9ibGVtc3dp dGggDQo+IGV4aXN0aW5nIFNJUCB0cnVua2luZyBzb2x1dGlvbnMpDQo+IA0KPiAgDQo+IA0KPiBT byBJRVRGIGlzIHRoZSB0aGVyZSBmb3IgY2FibGUsIGNvb2wuIFRoaXMgd2lsbCBwbGF5IHdlbGwg aW4gcmVndWxhdG9yeSwgDQo+IGR1ZGUsIHRoYW5rcw0KPiANCj4gIA0KPiANCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IA0KPiAqRnJvbSo6IG1hcnRpbmktYm91bmNlc0BpZXRmLm9yZyA8bWFydGluaS1i b3VuY2VzQGlldGYub3JnPg0KPiAqVG8qOiBtYXJ0aW5pQGlldGYub3JnIDxtYXJ0aW5pQGlldGYu b3JnPg0KPiAqU2VudCo6IE1vbiBBcHIgMDUgMDk6MDQ6MTAgMjAxMA0KPiAqU3ViamVjdCo6IFJl OiBbbWFydGluaV0gVGhlIElFVEYgdmVyc3VzIHJlYWxpdHkod2FzOiBwcm9ibGVtc3dpdGggDQo+ IGV4aXN0aW5nIFNJUCB0cnVua2luZyBzb2x1dGlvbnMpDQo+IA0KPiBTcGVha2luZyBhcyBhbm90 aGVyIHNlcnZpY2UgcHJvdmlkZXIsIEkgYWdyZWUgd2l0aCBSaWNoYXJkLg0KPiANCj4gIA0KPiAN Cj4gLUphY2sNCj4gDQo+PiA+PiAiUmljaGFyZCBTaG9ja2V5IiA8cmljaGFyZEBzaG9ja2V5LnVz PiA0LzQvMjAxMCAxMzozMiA+Pj4NCj4gVGhlIElNUyBzb2x1dGlvbiBjb3VsZCBjZXJ0YWlubHkg d29yayBmb3IgbGFyZ2Ugc2NhbGUgZW50ZXJwcmlzZSANCj4gZGVwbG95bWVudHMgc2VydmVkIGJ5 IEFUVCBhbmQgbWFzc2l2ZSBQVFQncyBidXQgaXMgaW5lZmZlY3R1YWwgYW5kIGNvc3QgDQo+IHBy b2hpYml0aXZlIGZvciBzbWFsbCBhbmQgbWVkaXVtIGJ1c2luZXNzIHNlcnZlZCB0eXBpY2FsbHkg YnkgQ0xFQydzLiANCj4gVGhhdCdzIHRoZSB3aG9sZSBidXNpbmVzcyBhbmQgdGVjaG5pY2FsIG1v ZGVsIGJlaGluZCBpbXBsaWNpdCANCj4gcmVnaXN0cmF0aW9uIFNNQidzIGFuZCBjb21wZXRpdGlv bi4NCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtYXJ0aW5p LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptYXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0K PiBCZWhhbGYgT2YgRGVhbiBXaWxsaXMNCj4gU2VudDogU3VuZGF5LCBBcHJpbCAwNCwgMjAxMCAx OjA0IFBNDQo+IFRvOiBET0xMWSwgTUFSVElOIEMgKEFUVExBQlMpOyBCZXJuYXJkIEFib2JhOyBt YXJ0aW5pQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbWFydGluaV0gVGhlIElFVEYgdmVyc3Vz IHJlYWxpdHkgKHdhczogcHJvYmxlbXMgd2l0aCANCj4gZXhpc3RpbmcgU0lQIHRydW5raW5nIHNv bHV0aW9ucykNCj4gDQo+IEFyZSB5b3Ugc2F5aW5nIHRoYXQgdGhlIElNUyBzb2x1dGlvbiBpcyB3 aGF0IHRoZSBzZXJ2aWNlIHByb3ZpZGVycyBuZWVkPw0KPiANCj4gDQo+IA0KPiAiRE9MTFksIE1B UlRJTiBDIChBVFRMQUJTKSIgPG1kMzEzNUBhdHQuY29tPiB3cm90ZToNCj4gDQo+PlNwZWFraW5n IGFzIGEgU2VydmljZSBQcm92aWRlciwgdGhlIHNvbHV0aW9uIGJlaW5nIHByb2R1Y2VkIGJ5IE1h cnRpbmkNCj4+ZG9lcyBub3QgYWRkcmVzcyB3aGF0IGlzIG5lZWRlZCBmb3IgY3VycmVudCB0byBt aWQtdGVybSBkZXBsb3ltZW50cywNCj4+YW5kIGNyZWF0ZXMgaW50ZXJvcGVyYWJpbGl0eSBwcm9i bGVtcyBpbiB0aGUgbG9uZyBoYXVsIC4NCj4gDQo+IC0tDQo+IERlYW4gV2lsbGlzDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtYXJ0aW5p IG1haWxpbmcgbGlzdA0KPiBtYXJ0aW5pQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbWFydGluaQ0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFRoZSBpbmZvcm1hdGlvbiB0 cmFuc21pdHRlZCBpbiB0aGlzIGVtYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIGlzIA0K PiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBh ZGRyZXNzZWQgYW5kIG1heSANCj4gY29udGFpbiBpbmZvcm1hdGlvbiBjb25jZXJuaW5nIENhYmxl dmlzaW9uIGFuZC9vciBpdHMgYWZmaWxpYXRlcyBhbmQgDQo+IHN1YnNpZGlhcmllcyB0aGF0IGlz IHByb3ByaWV0YXJ5LCBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwgYW5kL29yIA0KPiBzdWJqZWN0 IHRvIGNvcHlyaWdodC4gQW55IHJldmlldywgcmV0cmFuc21pc3Npb24sIGRpc3NlbWluYXRpb24g b3Igb3RoZXIgDQo+IHVzZSBvZiwgb3IgdGFraW5nIG9mIGFueSBhY3Rpb24gaW4gcmVsaWFuY2Ug dXBvbiwgdGhpcyBpbmZvcm1hdGlvbiBieSANCj4gcGVyc29ucyBvciBlbnRpdGllcyBvdGhlciB0 aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykgaXMgcHJvaGliaXRlZCANCj4gYW5kIG1heSBi ZSB1bmxhd2Z1bC4gSWYgeW91IHJlY2VpdmVkIHRoaXMgaW4gZXJyb3IsIHBsZWFzZSBjb250YWN0 IHRoZSANCj4gc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgYW5kIGRlc3Ryb3kgdGhlIGNv bW11bmljYXRpb24gYW5kIGFsbCBvZiANCj4gdGhlIGF0dGFjaG1lbnRzIHlvdSBoYXZlIHJlY2Vp dmVkIGFuZCBhbGwgY29waWVzIHRoZXJlb2YuDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBtYXJ0aW5pIG1haWxpbmcgbGlzdA0KPiBtYXJ0aW5pQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFydGluaQ0K From pkyzivat@cisco.com Mon Apr 5 10:24:48 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D68F3A67C2 for ; Mon, 5 Apr 2010 10:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.995 X-Spam-Level: X-Spam-Status: No, score=-9.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8deJBkYpYYY3 for ; Mon, 5 Apr 2010 10:24:42 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 614EF3A679C for ; Mon, 5 Apr 2010 10:24:41 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAI65uUtAZnwN/2dsb2JhbACDEpg4cZ1+iEWPTIErgm5uBA X-IronPort-AV: E=Sophos;i="4.51,366,1267401600"; d="scan'208";a="98900303" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2010 17:24:38 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o35HOc3E021455; Mon, 5 Apr 2010 17:24:38 GMT Message-ID: <4BBA1CD9.2060909@cisco.com> Date: Mon, 05 Apr 2010 13:24:41 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "DOLLY, MARTIN C (ATTLABS)" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E5F@gaalpa1msgusr7e.ugd.att.com> <4BBA14F9.30202@cisco.com> <14C85D6CCBE92743AF33663BF5D24EBA061F5349@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA061F5349@gaalpa1msgusr7e.ugd.att.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: JSBURTON@cablevision.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 17:24:48 -0000 DOLLY, MARTIN C (ATTLABS) wrote: > Paul, > > What is consensus, I know I do not have a vote in that as AT&T...so what is your point Take a look at http://tools.ietf.org/html/rfc2418 http://www.ietf.org/tao.html http://en.wikipedia.org/wiki/Rough_consensus You have a "vote" as an *individual*, not as a representative of AT&T. My point is that if you don't like the direction things are going, and would like to see that direction change, then you could consider proposing another direction and advancing arguments that will persuade others to support you. Thanks, Paul > Martin > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, April 05, 2010 12:51 PM > To: DOLLY, MARTIN C (ATTLABS) > Cc: richard@shockey.us; JSBURTON@cablevision.com; martini@ietf.org > Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) > > [as chair] > > DOLLY, MARTIN C (ATTLABS) wrote: >> GIN does not cut it. Pure BS > > Martin - Such comments do not contribute to arriving at a consensus. > > If you have technical and/or editorial comments to make, they are > welcome. Or feel free to submit an individual draft as an alternative to > be considered. > > Thanks, > Paul > >> ------------------------------------------------------------------------ >> *From*: Richard Shockey >> *To*: DOLLY, MARTIN C (ATTLABS); JSBURTON@cablevision.com >> ; martini@ietf.org >> *Sent*: Mon Apr 05 11:50:13 2010 >> *Subject*: RE: [martini] The IETF versus reality(was: problemswith >> existing SIP trunking solutions) >> >> Marty …I’m just doing my little bit to end POTS and the PSTN by making >> it easier to kill off all of those nasty PRI’s and TCAP. J >> >> I do have a NO PRI hat for you BTW. >> >> Isn’t that what ATT wants? Certainly the filings at the FCC says that >> what you guys want. J >> >> You know I’d do anything I can to help ATT kill off analog POTS and keep >> those dividends flowing to all those widows and orphans. >> >> http://fjallfoss.fcc.gov/ecfs/document/view?id=7020354032 >> >> *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] *On >> Behalf Of *DOLLY, MARTIN C (ATTLABS) >> *Sent:* Monday, April 05, 2010 9:29 AM >> *To:* JSBURTON@cablevision.com; martini@ietf.org >> *Subject:* Re: [martini] The IETF versus reality(was: problemswith >> existing SIP trunking solutions) >> >> >> >> So IETF is the there for cable, cool. This will play well in regulatory, >> dude, thanks >> >> >> >> ------------------------------------------------------------------------ >> >> *From*: martini-bounces@ietf.org >> *To*: martini@ietf.org >> *Sent*: Mon Apr 05 09:04:10 2010 >> *Subject*: Re: [martini] The IETF versus reality(was: problemswith >> existing SIP trunking solutions) >> >> Speaking as another service provider, I agree with Richard. >> >> >> >> -Jack >> >>>>> "Richard Shockey" 4/4/2010 13:32 >>> >> 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: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >> Behalf Of Dean Willis >> Sent: Sunday, April 04, 2010 1:04 PM >> To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org >> Subject: Re: [martini] The IETF versus reality (was: problems with >> existing SIP trunking solutions) >> >> Are you saying that the IMS solution is what the service providers need? >> >> >> >> "DOLLY, MARTIN C (ATTLABS)" 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 >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> >> >> -------------------------------------------------------- >> 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. >> -------------------------------------------------------- >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini From pkyzivat@cisco.com Mon Apr 5 10:26:04 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0417A3A67C2 for ; Mon, 5 Apr 2010 10:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.116 X-Spam-Level: X-Spam-Status: No, score=-10.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR78HcJrvHW8 for ; Mon, 5 Apr 2010 10:26:02 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 615033A679C for ; Mon, 5 Apr 2010 10:26:00 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFO5uUtAZnwN/2dsb2JhbACDEpg4cZ4PiEWPTIErgm5uBA X-IronPort-AV: E=Sophos;i="4.51,366,1267401600"; d="scan'208";a="99037248" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 05 Apr 2010 17:25:58 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o35HPwYS021775; Mon, 5 Apr 2010 17:25:58 GMT Message-ID: <4BBA1D29.9020000@cisco.com> Date: Mon, 05 Apr 2010 13:26:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "DOLLY, MARTIN C (ATTLABS)" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E5F@gaalpa1msgusr7e.ugd.att.com> <4BBA14F9.30202@cisco.com> In-Reply-To: <4BBA14F9.30202@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: JSBURTON@cablevision.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 17:26:04 -0000 Sorry - I should not have said "as chair", since this is martini, not sipcore. Thanks, Paul Paul Kyzivat wrote: > [as chair] > > DOLLY, MARTIN C (ATTLABS) wrote: >> GIN does not cut it. Pure BS > > Martin - Such comments do not contribute to arriving at a consensus. > > If you have technical and/or editorial comments to make, they are > welcome. Or feel free to submit an individual draft as an alternative to > be considered. > > Thanks, > Paul > >> ------------------------------------------------------------------------ >> *From*: Richard Shockey >> *To*: DOLLY, MARTIN C (ATTLABS); JSBURTON@cablevision.com >> ; martini@ietf.org >> *Sent*: Mon Apr 05 11:50:13 2010 >> *Subject*: RE: [martini] The IETF versus reality(was: problemswith >> existing SIP trunking solutions) >> >> Marty …I’m just doing my little bit to end POTS and the PSTN by making >> it easier to kill off all of those nasty PRI’s and TCAP. J >> >> I do have a NO PRI hat for you BTW. >> >> Isn’t that what ATT wants? Certainly the filings at the FCC says that >> what you guys want. J >> >> You know I’d do anything I can to help ATT kill off analog POTS and >> keep those dividends flowing to all those widows and orphans. >> >> http://fjallfoss.fcc.gov/ecfs/document/view?id=7020354032 >> >> *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] *On >> Behalf Of *DOLLY, MARTIN C (ATTLABS) >> *Sent:* Monday, April 05, 2010 9:29 AM >> *To:* JSBURTON@cablevision.com; martini@ietf.org >> *Subject:* Re: [martini] The IETF versus reality(was: problemswith >> existing SIP trunking solutions) >> >> >> >> So IETF is the there for cable, cool. This will play well in >> regulatory, dude, thanks >> >> >> >> ------------------------------------------------------------------------ >> >> *From*: martini-bounces@ietf.org >> *To*: martini@ietf.org >> *Sent*: Mon Apr 05 09:04:10 2010 >> *Subject*: Re: [martini] The IETF versus reality(was: problemswith >> existing SIP trunking solutions) >> >> Speaking as another service provider, I agree with Richard. >> >> >> >> -Jack >> >>> >> "Richard Shockey" 4/4/2010 13:32 >>> >> 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: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >> Behalf Of Dean Willis >> Sent: Sunday, April 04, 2010 1:04 PM >> To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org >> Subject: Re: [martini] The IETF versus reality (was: problems with >> existing SIP trunking solutions) >> >> Are you saying that the IMS solution is what the service providers need? >> >> >> >> "DOLLY, MARTIN C (ATTLABS)" 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 >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> >> >> -------------------------------------------------------- >> 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. >> -------------------------------------------------------- >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From md3135@att.com Mon Apr 5 10:28:09 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3593A679C for ; Mon, 5 Apr 2010 10:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.824 X-Spam-Level: X-Spam-Status: No, score=-105.824 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1OIrHLpuNHa for ; Mon, 5 Apr 2010 10:28:04 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 893CE3A6847 for ; Mon, 5 Apr 2010 10:28:03 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-13.tower-129.messagelabs.com!1270488480!7595277!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 2687 invoked from network); 5 Apr 2010 17:28:01 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Apr 2010 17:28:01 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o35HRkmo004066; Mon, 5 Apr 2010 13:27:47 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o35HRhMW004030; Mon, 5 Apr 2010 13:27:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 5 Apr 2010 13:27:53 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA061F5391@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <4BBA1CD9.2060909@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) Thread-Index: AcrU5OR1RdKAgCDtTTOj68JP/6BLAAAAGM2g References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E5F@gaalpa1msgusr7e.ugd.att.com> <4BBA14F9.30202@cisco.com> <14C85D6CCBE92743AF33663BF5D24EBA061F5349@gaalpa1msgusr7e.ugd.att.com> <4BBA1CD9.2060909@cisco.com> From: "DOLLY, MARTIN C (ATTLABS)" To: "Paul Kyzivat" Cc: JSBURTON@cablevision.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 17:28:09 -0000 WWVhLCByaWdodC4gQlMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBhdWwg S3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGNpc2NvLmNvbV0gDQpTZW50OiBNb25kYXksIEFwcmls IDA1LCAyMDEwIDE6MjUgUE0NClRvOiBET0xMWSwgTUFSVElOIEMgKEFUVExBQlMpDQpDYzogcmlj aGFyZEBzaG9ja2V5LnVzOyBKU0JVUlRPTkBjYWJsZXZpc2lvbi5jb207IG1hcnRpbmlAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbbWFydGluaV0gVGhlIElFVEYgdmVyc3VzIHJlYWxpdHkod2FzOiBw cm9ibGVtc3dpdGggZXhpc3RpbmcgU0lQIHRydW5raW5nIHNvbHV0aW9ucykNCg0KRE9MTFksIE1B UlRJTiBDIChBVFRMQUJTKSB3cm90ZToNCj4gUGF1bCwNCj4gDQo+IFdoYXQgaXMgY29uc2Vuc3Vz LCBJIGtub3cgSSBkbyBub3QgaGF2ZSBhIHZvdGUgaW4gdGhhdCBhcyBBVCZULi4uc28gd2hhdCBp cyB5b3VyIHBvaW50DQoNClRha2UgYSBsb29rIGF0DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzI0MTgNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvdGFvLmh0bWwNCmh0dHA6Ly9lbi53aWtp cGVkaWEub3JnL3dpa2kvUm91Z2hfY29uc2Vuc3VzDQoNCllvdSBoYXZlIGEgInZvdGUiIGFzIGFu ICppbmRpdmlkdWFsKiwgbm90IGFzIGEgcmVwcmVzZW50YXRpdmUgb2YgQVQmVC4NCg0KTXkgcG9p bnQgaXMgdGhhdCBpZiB5b3UgZG9uJ3QgbGlrZSB0aGUgZGlyZWN0aW9uIHRoaW5ncyBhcmUgZ29p bmcsIGFuZCANCndvdWxkIGxpa2UgdG8gc2VlIHRoYXQgZGlyZWN0aW9uIGNoYW5nZSwgdGhlbiB5 b3UgY291bGQgY29uc2lkZXIgDQpwcm9wb3NpbmcgYW5vdGhlciBkaXJlY3Rpb24gYW5kIGFkdmFu Y2luZyBhcmd1bWVudHMgdGhhdCB3aWxsIHBlcnN1YWRlIA0Kb3RoZXJzIHRvIHN1cHBvcnQgeW91 Lg0KDQoJVGhhbmtzLA0KCVBhdWwNCg0KPiBNYXJ0aW4NCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGNpc2NvLmNv bV0gDQo+IFNlbnQ6IE1vbmRheSwgQXByaWwgMDUsIDIwMTAgMTI6NTEgUE0NCj4gVG86IERPTExZ LCBNQVJUSU4gQyAoQVRUTEFCUykNCj4gQ2M6IHJpY2hhcmRAc2hvY2tleS51czsgSlNCVVJUT05A Y2FibGV2aXNpb24uY29tOyBtYXJ0aW5pQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbWFydGlu aV0gVGhlIElFVEYgdmVyc3VzIHJlYWxpdHkod2FzOiBwcm9ibGVtc3dpdGggZXhpc3RpbmcgU0lQ IHRydW5raW5nIHNvbHV0aW9ucykNCj4gDQo+IFthcyBjaGFpcl0NCj4gDQo+IERPTExZLCBNQVJU SU4gQyAoQVRUTEFCUykgd3JvdGU6DQo+PiBHSU4gZG9lcyBub3QgY3V0IGl0LiBQdXJlIEJTDQo+ IA0KPiBNYXJ0aW4gLSBTdWNoIGNvbW1lbnRzIGRvIG5vdCBjb250cmlidXRlIHRvIGFycml2aW5n IGF0IGEgY29uc2Vuc3VzLg0KPiANCj4gSWYgeW91IGhhdmUgdGVjaG5pY2FsIGFuZC9vciBlZGl0 b3JpYWwgY29tbWVudHMgdG8gbWFrZSwgdGhleSBhcmUgDQo+IHdlbGNvbWUuIE9yIGZlZWwgZnJl ZSB0byBzdWJtaXQgYW4gaW5kaXZpZHVhbCBkcmFmdCBhcyBhbiBhbHRlcm5hdGl2ZSB0byANCj4g YmUgY29uc2lkZXJlZC4NCj4gDQo+IAlUaGFua3MsDQo+IAlQYXVsDQo+IA0KPj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+PiAqRnJvbSo6IFJpY2hhcmQgU2hvY2tleSA8cmljaGFyZEBzaG9ja2V5LnVzPg0K Pj4gKlRvKjogRE9MTFksIE1BUlRJTiBDIChBVFRMQUJTKTsgSlNCVVJUT05AY2FibGV2aXNpb24u Y29tIA0KPj4gPEpTQlVSVE9OQGNhYmxldmlzaW9uLmNvbT47IG1hcnRpbmlAaWV0Zi5vcmcgPG1h cnRpbmlAaWV0Zi5vcmc+DQo+PiAqU2VudCo6IE1vbiBBcHIgMDUgMTE6NTA6MTMgMjAxMA0KPj4g KlN1YmplY3QqOiBSRTogW21hcnRpbmldIFRoZSBJRVRGIHZlcnN1cyByZWFsaXR5KHdhczogcHJv YmxlbXN3aXRoIA0KPj4gZXhpc3RpbmcgU0lQIHRydW5raW5nIHNvbHV0aW9ucykNCj4+DQo+PiBN YXJ0eSDigKZJ4oCZbSBqdXN0IGRvaW5nIG15IGxpdHRsZSBiaXQgdG8gZW5kIFBPVFMgYW5kIHRo ZSBQU1ROIGJ5IG1ha2luZyANCj4+IGl0IGVhc2llciB0byBraWxsIG9mZiBhbGwgb2YgdGhvc2Ug bmFzdHkgUFJJ4oCZcyBhbmQgVENBUC4gSg0KPj4NCj4+IEkgZG8gaGF2ZSBhIE5PIFBSSSBoYXQg Zm9yIHlvdSBCVFcuDQo+Pg0KPj4gSXNu4oCZdCB0aGF0IHdoYXQgQVRUIHdhbnRzPyAgQ2VydGFp bmx5IHRoZSBmaWxpbmdzIGF0IHRoZSBGQ0Mgc2F5cyB0aGF0IA0KPj4gd2hhdCB5b3UgZ3V5cyB3 YW50LiBKDQo+Pg0KPj4gWW91IGtub3cgSeKAmWQgZG8gYW55dGhpbmcgSSBjYW4gdG8gaGVscCBB VFQga2lsbCBvZmYgYW5hbG9nIFBPVFMgYW5kIGtlZXAgDQo+PiB0aG9zZSBkaXZpZGVuZHMgZmxv d2luZyB0byBhbGwgdGhvc2Ugd2lkb3dzIGFuZCBvcnBoYW5zLg0KPj4NCj4+IGh0dHA6Ly9mamFs bGZvc3MuZmNjLmdvdi9lY2ZzL2RvY3VtZW50L3ZpZXc/aWQ9NzAyMDM1NDAzMg0KPj4NCj4+ICpG cm9tOiogbWFydGluaS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bWFydGluaS1ib3VuY2VzQGll dGYub3JnXSAqT24gDQo+PiBCZWhhbGYgT2YgKkRPTExZLCBNQVJUSU4gQyAoQVRUTEFCUykNCj4+ ICpTZW50OiogTW9uZGF5LCBBcHJpbCAwNSwgMjAxMCA5OjI5IEFNDQo+PiAqVG86KiBKU0JVUlRP TkBjYWJsZXZpc2lvbi5jb207IG1hcnRpbmlAaWV0Zi5vcmcNCj4+ICpTdWJqZWN0OiogUmU6IFtt YXJ0aW5pXSBUaGUgSUVURiB2ZXJzdXMgcmVhbGl0eSh3YXM6IHByb2JsZW1zd2l0aCANCj4+IGV4 aXN0aW5nIFNJUCB0cnVua2luZyBzb2x1dGlvbnMpDQo+Pg0KPj4gIA0KPj4NCj4+IFNvIElFVEYg aXMgdGhlIHRoZXJlIGZvciBjYWJsZSwgY29vbC4gVGhpcyB3aWxsIHBsYXkgd2VsbCBpbiByZWd1 bGF0b3J5LCANCj4+IGR1ZGUsIHRoYW5rcw0KPj4NCj4+ICANCj4+DQo+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4+DQo+PiAqRnJvbSo6IG1hcnRpbmktYm91bmNlc0BpZXRmLm9yZyA8bWFydGluaS1ib3Vu Y2VzQGlldGYub3JnPg0KPj4gKlRvKjogbWFydGluaUBpZXRmLm9yZyA8bWFydGluaUBpZXRmLm9y Zz4NCj4+ICpTZW50KjogTW9uIEFwciAwNSAwOTowNDoxMCAyMDEwDQo+PiAqU3ViamVjdCo6IFJl OiBbbWFydGluaV0gVGhlIElFVEYgdmVyc3VzIHJlYWxpdHkod2FzOiBwcm9ibGVtc3dpdGggDQo+ PiBleGlzdGluZyBTSVAgdHJ1bmtpbmcgc29sdXRpb25zKQ0KPj4NCj4+IFNwZWFraW5nIGFzIGFu b3RoZXIgc2VydmljZSBwcm92aWRlciwgSSBhZ3JlZSB3aXRoIFJpY2hhcmQuDQo+Pg0KPj4gIA0K Pj4NCj4+IC1KYWNrDQo+Pg0KPj4+Pj4gIlJpY2hhcmQgU2hvY2tleSIgPHJpY2hhcmRAc2hvY2tl eS51cz4gNC80LzIwMTAgMTM6MzIgPj4+DQo+PiBUaGUgSU1TIHNvbHV0aW9uIGNvdWxkIGNlcnRh aW5seSB3b3JrIGZvciBsYXJnZSBzY2FsZSBlbnRlcnByaXNlIA0KPj4gZGVwbG95bWVudHMgc2Vy dmVkIGJ5IEFUVCBhbmQgbWFzc2l2ZSBQVFQncyBidXQgaXMgaW5lZmZlY3R1YWwgYW5kIGNvc3Qg DQo+PiBwcm9oaWJpdGl2ZSBmb3Igc21hbGwgYW5kIG1lZGl1bSBidXNpbmVzcyBzZXJ2ZWQgdHlw aWNhbGx5IGJ5IENMRUMncy4gDQo+PiBUaGF0J3MgdGhlIHdob2xlIGJ1c2luZXNzIGFuZCB0ZWNo bmljYWwgbW9kZWwgYmVoaW5kIGltcGxpY2l0IA0KPj4gcmVnaXN0cmF0aW9uIFNNQidzIGFuZCBj b21wZXRpdGlvbi4NCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZy b206IG1hcnRpbmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1hcnRpbmktYm91bmNlc0BpZXRm Lm9yZ10gT24gDQo+PiBCZWhhbGYgT2YgRGVhbiBXaWxsaXMNCj4+IFNlbnQ6IFN1bmRheSwgQXBy aWwgMDQsIDIwMTAgMTowNCBQTQ0KPj4gVG86IERPTExZLCBNQVJUSU4gQyAoQVRUTEFCUyk7IEJl cm5hcmQgQWJvYmE7IG1hcnRpbmlAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbbWFydGluaV0g VGhlIElFVEYgdmVyc3VzIHJlYWxpdHkgKHdhczogcHJvYmxlbXMgd2l0aCANCj4+IGV4aXN0aW5n IFNJUCB0cnVua2luZyBzb2x1dGlvbnMpDQo+Pg0KPj4gQXJlIHlvdSBzYXlpbmcgdGhhdCB0aGUg SU1TIHNvbHV0aW9uIGlzIHdoYXQgdGhlIHNlcnZpY2UgcHJvdmlkZXJzIG5lZWQ/DQo+Pg0KPj4N Cj4+DQo+PiAiRE9MTFksIE1BUlRJTiBDIChBVFRMQUJTKSIgPG1kMzEzNUBhdHQuY29tPiB3cm90 ZToNCj4+DQo+Pj4gU3BlYWtpbmcgYXMgYSBTZXJ2aWNlIFByb3ZpZGVyLCB0aGUgc29sdXRpb24g YmVpbmcgcHJvZHVjZWQgYnkgTWFydGluaQ0KPj4+IGRvZXMgbm90IGFkZHJlc3Mgd2hhdCBpcyBu ZWVkZWQgZm9yIGN1cnJlbnQgdG8gbWlkLXRlcm0gZGVwbG95bWVudHMsDQo+Pj4gYW5kIGNyZWF0 ZXMgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcyBpbiB0aGUgbG9uZyBoYXVsIC4NCj4+IC0tDQo+ PiBEZWFuIFdpbGxpcw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBtYXJ0aW5pIG1haWxpbmcgbGlzdA0KPj4gbWFydGluaUBpZXRmLm9y Zw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYXJ0aW5pDQo+Pg0K Pj4NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+PiBUaGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgaW4gdGhpcyBlbWFpbCBhbmQg YW55IG9mIGl0cyBhdHRhY2htZW50cyBpcyANCj4+IGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJz b24gb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZCBhbmQgbWF5IA0KPj4gY29udGFp biBpbmZvcm1hdGlvbiBjb25jZXJuaW5nIENhYmxldmlzaW9uIGFuZC9vciBpdHMgYWZmaWxpYXRl cyBhbmQgDQo+PiBzdWJzaWRpYXJpZXMgdGhhdCBpcyBwcm9wcmlldGFyeSwgcHJpdmlsZWdlZCwg Y29uZmlkZW50aWFsIGFuZC9vciANCj4+IHN1YmplY3QgdG8gY29weXJpZ2h0LiBBbnkgcmV2aWV3 LCByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBvciBvdGhlciANCj4+IHVzZSBvZiwgb3Ig dGFraW5nIG9mIGFueSBhY3Rpb24gaW4gcmVsaWFuY2UgdXBvbiwgdGhpcyBpbmZvcm1hdGlvbiBi eSANCj4+IHBlcnNvbnMgb3IgZW50aXRpZXMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50KHMpIGlzIHByb2hpYml0ZWQgDQo+PiBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgcmVj ZWl2ZWQgdGhpcyBpbiBlcnJvciwgcGxlYXNlIGNvbnRhY3QgdGhlIA0KPj4gc2VuZGVyIGltbWVk aWF0ZWx5IGFuZCBkZWxldGUgYW5kIGRlc3Ryb3kgdGhlIGNvbW11bmljYXRpb24gYW5kIGFsbCBv ZiANCj4+IHRoZSBhdHRhY2htZW50cyB5b3UgaGF2ZSByZWNlaXZlZCBhbmQgYWxsIGNvcGllcyB0 aGVyZW9mLg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+DQo+Pg0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG1hcnRpbmkgbWFpbGlu ZyBsaXN0DQo+PiBtYXJ0aW5pQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21hcnRpbmkNCg== From md3135@att.com Mon Apr 5 10:32:24 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CD443A69DE for ; Mon, 5 Apr 2010 10:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.979 X-Spam-Level: X-Spam-Status: No, score=-105.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBgL00SS+UoF for ; Mon, 5 Apr 2010 10:32:23 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 9764B3A699D for ; Mon, 5 Apr 2010 10:32:22 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-8.tower-161.messagelabs.com!1270488739!30952135!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 29370 invoked from network); 5 Apr 2010 17:32:20 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Apr 2010 17:32:20 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o35HW61Z009853 for ; Mon, 5 Apr 2010 13:32:06 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o35HW3L2009807 for ; Mon, 5 Apr 2010 13:32:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 5 Apr 2010 13:32:14 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA061F53A1@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <4BBA1D29.9020000@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) Thread-Index: AcrU5RNMSorAz24bSWifwZ5PGZenmAAAM38w References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E5F@gaalpa1msgusr7e.ugd.att.com> <4BBA14F9.30202@cisco.com> <4BBA1D29.9020000@cisco.com> From: "DOLLY, MARTIN C (ATTLABS)" To: "Paul Kyzivat" Cc: JSBURTON@cablevision.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 17:32:24 -0000 WW91ciBDaXNjbywgd2hhdCBkaWZmZXJlbmNlIGRvZXMgaXQgbWFrZS4NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGNpc2Nv LmNvbV0gDQpTZW50OiBNb25kYXksIEFwcmlsIDA1LCAyMDEwIDE6MjYgUE0NClRvOiBET0xMWSwg TUFSVElOIEMgKEFUVExBQlMpDQpDYzogSlNCVVJUT05AY2FibGV2aXNpb24uY29tOyBtYXJ0aW5p QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hcnRpbmldIFRoZSBJRVRGIHZlcnN1cyByZWFsaXR5 KHdhczogcHJvYmxlbXN3aXRoIGV4aXN0aW5nIFNJUCB0cnVua2luZyBzb2x1dGlvbnMpDQoNClNv cnJ5IC0gSSBzaG91bGQgbm90IGhhdmUgc2FpZCAiYXMgY2hhaXIiLCBzaW5jZSB0aGlzIGlzIG1h cnRpbmksIG5vdCANCnNpcGNvcmUuDQoNCglUaGFua3MsDQoJUGF1bA0KDQpQYXVsIEt5eml2YXQg d3JvdGU6DQo+IFthcyBjaGFpcl0NCj4gDQo+IERPTExZLCBNQVJUSU4gQyAoQVRUTEFCUykgd3Jv dGU6DQo+PiBHSU4gZG9lcyBub3QgY3V0IGl0LiBQdXJlIEJTDQo+IA0KPiBNYXJ0aW4gLSBTdWNo IGNvbW1lbnRzIGRvIG5vdCBjb250cmlidXRlIHRvIGFycml2aW5nIGF0IGEgY29uc2Vuc3VzLg0K PiANCj4gSWYgeW91IGhhdmUgdGVjaG5pY2FsIGFuZC9vciBlZGl0b3JpYWwgY29tbWVudHMgdG8g bWFrZSwgdGhleSBhcmUgDQo+IHdlbGNvbWUuIE9yIGZlZWwgZnJlZSB0byBzdWJtaXQgYW4gaW5k aXZpZHVhbCBkcmFmdCBhcyBhbiBhbHRlcm5hdGl2ZSB0byANCj4gYmUgY29uc2lkZXJlZC4NCj4g DQo+ICAgICBUaGFua3MsDQo+ICAgICBQYXVsDQo+IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiAq RnJvbSo6IFJpY2hhcmQgU2hvY2tleSA8cmljaGFyZEBzaG9ja2V5LnVzPg0KPj4gKlRvKjogRE9M TFksIE1BUlRJTiBDIChBVFRMQUJTKTsgSlNCVVJUT05AY2FibGV2aXNpb24uY29tIA0KPj4gPEpT QlVSVE9OQGNhYmxldmlzaW9uLmNvbT47IG1hcnRpbmlAaWV0Zi5vcmcgPG1hcnRpbmlAaWV0Zi5v cmc+DQo+PiAqU2VudCo6IE1vbiBBcHIgMDUgMTE6NTA6MTMgMjAxMA0KPj4gKlN1YmplY3QqOiBS RTogW21hcnRpbmldIFRoZSBJRVRGIHZlcnN1cyByZWFsaXR5KHdhczogcHJvYmxlbXN3aXRoIA0K Pj4gZXhpc3RpbmcgU0lQIHRydW5raW5nIHNvbHV0aW9ucykNCj4+DQo+PiBNYXJ0eSDigKZJ4oCZ bSBqdXN0IGRvaW5nIG15IGxpdHRsZSBiaXQgdG8gZW5kIFBPVFMgYW5kIHRoZSBQU1ROIGJ5IG1h a2luZyANCj4+IGl0IGVhc2llciB0byBraWxsIG9mZiBhbGwgb2YgdGhvc2UgbmFzdHkgUFJJ4oCZ cyBhbmQgVENBUC4gSg0KPj4NCj4+IEkgZG8gaGF2ZSBhIE5PIFBSSSBoYXQgZm9yIHlvdSBCVFcu DQo+Pg0KPj4gSXNu4oCZdCB0aGF0IHdoYXQgQVRUIHdhbnRzPyAgQ2VydGFpbmx5IHRoZSBmaWxp bmdzIGF0IHRoZSBGQ0Mgc2F5cyB0aGF0IA0KPj4gd2hhdCB5b3UgZ3V5cyB3YW50LiBKDQo+Pg0K Pj4gWW91IGtub3cgSeKAmWQgZG8gYW55dGhpbmcgSSBjYW4gdG8gaGVscCBBVFQga2lsbCBvZmYg YW5hbG9nIFBPVFMgYW5kIA0KPj4ga2VlcCB0aG9zZSBkaXZpZGVuZHMgZmxvd2luZyB0byBhbGwg dGhvc2Ugd2lkb3dzIGFuZCBvcnBoYW5zLg0KPj4NCj4+IGh0dHA6Ly9mamFsbGZvc3MuZmNjLmdv di9lY2ZzL2RvY3VtZW50L3ZpZXc/aWQ9NzAyMDM1NDAzMg0KPj4NCj4+ICpGcm9tOiogbWFydGlu aS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bWFydGluaS1ib3VuY2VzQGlldGYub3JnXSAqT24g DQo+PiBCZWhhbGYgT2YgKkRPTExZLCBNQVJUSU4gQyAoQVRUTEFCUykNCj4+ICpTZW50OiogTW9u ZGF5LCBBcHJpbCAwNSwgMjAxMCA5OjI5IEFNDQo+PiAqVG86KiBKU0JVUlRPTkBjYWJsZXZpc2lv bi5jb207IG1hcnRpbmlAaWV0Zi5vcmcNCj4+ICpTdWJqZWN0OiogUmU6IFttYXJ0aW5pXSBUaGUg SUVURiB2ZXJzdXMgcmVhbGl0eSh3YXM6IHByb2JsZW1zd2l0aCANCj4+IGV4aXN0aW5nIFNJUCB0 cnVua2luZyBzb2x1dGlvbnMpDQo+Pg0KPj4gIA0KPj4NCj4+IFNvIElFVEYgaXMgdGhlIHRoZXJl IGZvciBjYWJsZSwgY29vbC4gVGhpcyB3aWxsIHBsYXkgd2VsbCBpbiANCj4+IHJlZ3VsYXRvcnks IGR1ZGUsIHRoYW5rcw0KPj4NCj4+ICANCj4+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+PiAq RnJvbSo6IG1hcnRpbmktYm91bmNlc0BpZXRmLm9yZyA8bWFydGluaS1ib3VuY2VzQGlldGYub3Jn Pg0KPj4gKlRvKjogbWFydGluaUBpZXRmLm9yZyA8bWFydGluaUBpZXRmLm9yZz4NCj4+ICpTZW50 KjogTW9uIEFwciAwNSAwOTowNDoxMCAyMDEwDQo+PiAqU3ViamVjdCo6IFJlOiBbbWFydGluaV0g VGhlIElFVEYgdmVyc3VzIHJlYWxpdHkod2FzOiBwcm9ibGVtc3dpdGggDQo+PiBleGlzdGluZyBT SVAgdHJ1bmtpbmcgc29sdXRpb25zKQ0KPj4NCj4+IFNwZWFraW5nIGFzIGFub3RoZXIgc2Vydmlj ZSBwcm92aWRlciwgSSBhZ3JlZSB3aXRoIFJpY2hhcmQuDQo+Pg0KPj4gIA0KPj4NCj4+IC1KYWNr DQo+Pg0KPj4+ID4+ICJSaWNoYXJkIFNob2NrZXkiIDxyaWNoYXJkQHNob2NrZXkudXM+IDQvNC8y MDEwIDEzOjMyID4+Pg0KPj4gVGhlIElNUyBzb2x1dGlvbiBjb3VsZCBjZXJ0YWlubHkgd29yayBm b3IgbGFyZ2Ugc2NhbGUgZW50ZXJwcmlzZSANCj4+IGRlcGxveW1lbnRzIHNlcnZlZCBieSBBVFQg YW5kIG1hc3NpdmUgUFRUJ3MgYnV0IGlzIGluZWZmZWN0dWFsIGFuZCANCj4+IGNvc3QgcHJvaGli aXRpdmUgZm9yIHNtYWxsIGFuZCBtZWRpdW0gYnVzaW5lc3Mgc2VydmVkIHR5cGljYWxseSBieSAN Cj4+IENMRUMncy4gVGhhdCdzIHRoZSB3aG9sZSBidXNpbmVzcyBhbmQgdGVjaG5pY2FsIG1vZGVs IGJlaGluZCBpbXBsaWNpdCANCj4+IHJlZ2lzdHJhdGlvbiBTTUIncyBhbmQgY29tcGV0aXRpb24u DQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBtYXJ0aW5p LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptYXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0K Pj4gQmVoYWxmIE9mIERlYW4gV2lsbGlzDQo+PiBTZW50OiBTdW5kYXksIEFwcmlsIDA0LCAyMDEw IDE6MDQgUE0NCj4+IFRvOiBET0xMWSwgTUFSVElOIEMgKEFUVExBQlMpOyBCZXJuYXJkIEFib2Jh OyBtYXJ0aW5pQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW21hcnRpbmldIFRoZSBJRVRGIHZl cnN1cyByZWFsaXR5ICh3YXM6IHByb2JsZW1zIHdpdGggDQo+PiBleGlzdGluZyBTSVAgdHJ1bmtp bmcgc29sdXRpb25zKQ0KPj4NCj4+IEFyZSB5b3Ugc2F5aW5nIHRoYXQgdGhlIElNUyBzb2x1dGlv biBpcyB3aGF0IHRoZSBzZXJ2aWNlIHByb3ZpZGVycyBuZWVkPw0KPj4NCj4+DQo+Pg0KPj4gIkRP TExZLCBNQVJUSU4gQyAoQVRUTEFCUykiIDxtZDMxMzVAYXR0LmNvbT4gd3JvdGU6DQo+Pg0KPj4+ IFNwZWFraW5nIGFzIGEgU2VydmljZSBQcm92aWRlciwgdGhlIHNvbHV0aW9uIGJlaW5nIHByb2R1 Y2VkIGJ5IE1hcnRpbmkNCj4+PiBkb2VzIG5vdCBhZGRyZXNzIHdoYXQgaXMgbmVlZGVkIGZvciBj dXJyZW50IHRvIG1pZC10ZXJtIGRlcGxveW1lbnRzLA0KPj4+IGFuZCBjcmVhdGVzIGludGVyb3Bl cmFiaWxpdHkgcHJvYmxlbXMgaW4gdGhlIGxvbmcgaGF1bCAuDQo+Pg0KPj4gLS0gDQo+PiBEZWFu IFdpbGxpcw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiBtYXJ0aW5pIG1haWxpbmcgbGlzdA0KPj4gbWFydGluaUBpZXRmLm9yZw0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYXJ0aW5pDQo+Pg0KPj4NCj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+PiBUaGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgaW4gdGhpcyBlbWFpbCBhbmQgYW55IG9m IGl0cyBhdHRhY2htZW50cyANCj4+IGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3Ig ZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZCBhbmQgDQo+PiBtYXkgY29udGFpbiBpbmZv cm1hdGlvbiBjb25jZXJuaW5nIENhYmxldmlzaW9uIGFuZC9vciBpdHMgYWZmaWxpYXRlcyANCj4+ IGFuZCBzdWJzaWRpYXJpZXMgdGhhdCBpcyBwcm9wcmlldGFyeSwgcHJpdmlsZWdlZCwgY29uZmlk ZW50aWFsIGFuZC9vciANCj4+IHN1YmplY3QgdG8gY29weXJpZ2h0LiBBbnkgcmV2aWV3LCByZXRy YW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBvciANCj4+IG90aGVyIHVzZSBvZiwgb3IgdGFraW5n IG9mIGFueSBhY3Rpb24gaW4gcmVsaWFuY2UgdXBvbiwgdGhpcyANCj4+IGluZm9ybWF0aW9uIGJ5 IHBlcnNvbnMgb3IgZW50aXRpZXMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgDQo+PiByZWNpcGll bnQocykgaXMgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgcmVjZWl2ZWQg dGhpcyANCj4+IGluIGVycm9yLCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGFuZCBkZWxldGUgYW5kIGRlc3Ryb3kgDQo+PiB0aGUgY29tbXVuaWNhdGlvbiBhbmQgYWxsIG9m IHRoZSBhdHRhY2htZW50cyB5b3UgaGF2ZSByZWNlaXZlZCBhbmQgYWxsIA0KPj4gY29waWVzIHRo ZXJlb2YuDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPj4NCj4+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbWFydGluaSBtYWlsaW5n IGxpc3QNCj4+IG1hcnRpbmlAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWFydGluaQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBtYXJ0aW5pIG1haWxpbmcgbGlzdA0KPiBtYXJ0aW5pQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFydGluaQ0K From adam@nostrum.com Mon Apr 5 10:42:34 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695833A67C2 for ; Mon, 5 Apr 2010 10:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiqJEaJzjHqe for ; Mon, 5 Apr 2010 10:42:32 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 31E433A679C for ; Mon, 5 Apr 2010 10:42:31 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o35HgQLs047645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Apr 2010 12:42:26 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBA2102.4010308@nostrum.com> Date: Mon, 05 Apr 2010 12:42:26 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "DOLLY, MARTIN C (ATTLABS)" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E5F@gaalpa1msgusr7e.ugd.att.com> <4BBA14F9.30202@cisco.com> <14C85D6CCBE92743AF33663BF5D24EBA061F5349@gaalpa1msgusr7e.ugd.att.com> <4BBA1CD9.2060909@cisco.com> <14C85D6CCBE92743AF33663BF5D24EBA061F5391@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA061F5391@gaalpa1msgusr7e.ugd.att.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: martini@ietf.org, martini-chairs@tools.ietf.org Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 17:42:34 -0000 Actually, we are quickly coming up on a point where RFC 3683 may be more relevant than the documents Paul cites. http://tools.ietf.org/html/rfc3683 /a On 4/5/10 12:27 PM, DOLLY, MARTIN C (ATTLABS) wrote: > Yea, right. BS > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, April 05, 2010 1:25 PM > To: DOLLY, MARTIN C (ATTLABS) > Cc: richard@shockey.us; JSBURTON@cablevision.com; martini@ietf.org > Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) > > DOLLY, MARTIN C (ATTLABS) wrote: > >> Paul, >> >> What is consensus, I know I do not have a vote in that as AT&T...so what is your point >> > Take a look at > > http://tools.ietf.org/html/rfc2418 > http://www.ietf.org/tao.html > http://en.wikipedia.org/wiki/Rough_consensus > > You have a "vote" as an *individual*, not as a representative of AT&T. > > My point is that if you don't like the direction things are going, and > would like to see that direction change, then you could consider > proposing another direction and advancing arguments that will persuade > others to support you. > > Thanks, > Paul > > >> Martin >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, April 05, 2010 12:51 PM >> To: DOLLY, MARTIN C (ATTLABS) >> Cc: richard@shockey.us; JSBURTON@cablevision.com; martini@ietf.org >> Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) >> >> [as chair] >> >> DOLLY, MARTIN C (ATTLABS) wrote: >> >>> GIN does not cut it. Pure BS >>> >> Martin - Such comments do not contribute to arriving at a consensus. >> >> If you have technical and/or editorial comments to make, they are >> welcome. Or feel free to submit an individual draft as an alternative to >> be considered. >> >> Thanks, >> Paul >> >> >>> ------------------------------------------------------------------------ >>> *From*: Richard Shockey >>> *To*: DOLLY, MARTIN C (ATTLABS); JSBURTON@cablevision.com >>> ; martini@ietf.org >>> *Sent*: Mon Apr 05 11:50:13 2010 >>> *Subject*: RE: [martini] The IETF versus reality(was: problemswith >>> existing SIP trunking solutions) >>> >>> Marty …I’m just doing my little bit to end POTS and the PSTN by making >>> it easier to kill off all of those nasty PRI’s and TCAP. J >>> >>> I do have a NO PRI hat for you BTW. >>> >>> Isn’t that what ATT wants? Certainly the filings at the FCC says that >>> what you guys want. J >>> >>> You know I’d do anything I can to help ATT kill off analog POTS and keep >>> those dividends flowing to all those widows and orphans. >>> >>> http://fjallfoss.fcc.gov/ecfs/document/view?id=7020354032 >>> >>> *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] *On >>> Behalf Of *DOLLY, MARTIN C (ATTLABS) >>> *Sent:* Monday, April 05, 2010 9:29 AM >>> *To:* JSBURTON@cablevision.com; martini@ietf.org >>> *Subject:* Re: [martini] The IETF versus reality(was: problemswith >>> existing SIP trunking solutions) >>> >>> >>> >>> So IETF is the there for cable, cool. This will play well in regulatory, >>> dude, thanks >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> *From*: martini-bounces@ietf.org >>> *To*: martini@ietf.org >>> *Sent*: Mon Apr 05 09:04:10 2010 >>> *Subject*: Re: [martini] The IETF versus reality(was: problemswith >>> existing SIP trunking solutions) >>> >>> Speaking as another service provider, I agree with Richard. >>> >>> >>> >>> -Jack >>> >>> >>>>>> "Richard Shockey" 4/4/2010 13:32>>> >>>>>> >>> 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: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >>> Behalf Of Dean Willis >>> Sent: Sunday, April 04, 2010 1:04 PM >>> To: DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org >>> Subject: Re: [martini] The IETF versus reality (was: problems with >>> existing SIP trunking solutions) >>> >>> Are you saying that the IMS solution is what the service providers need? >>> >>> >>> >>> "DOLLY, MARTIN C (ATTLABS)" 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 >>> >>> _______________________________________________ >>> martini mailing list >>> martini@ietf.org >>> https://www.ietf.org/mailman/listinfo/martini >>> >>> >>> -------------------------------------------------------- >>> 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. >>> -------------------------------------------------------- >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> martini mailing list >>> martini@ietf.org >>> https://www.ietf.org/mailman/listinfo/martini >>> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From spencer@wonderhamster.org Mon Apr 5 11:04:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6A63A692E for ; Mon, 5 Apr 2010 11:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vDAJ7lX63WX for ; Mon, 5 Apr 2010 11:04:22 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 4A6893A6853 for ; Mon, 5 Apr 2010 11:04:21 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LjIrH-1NOPuI0Vrz-00dPqV; Mon, 05 Apr 2010 14:04:10 -0400 Message-ID: From: "Spencer Dawkins" To: Date: Mon, 5 Apr 2010 13:04:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX18ydVaeYwJ5ChLauWVONFZqXdUit50aBvlkM3G bDIeWJBCeDqWVsEYVnwSeFiV0mgetWcGoEIWiQoWyJZrz7jqPh 069AOs8Nyu0dXOEtI7XmFd8D0HQcwDPG2U+A4DpPRY= Subject: [martini] Revectoring back to technical discussion X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 18:04:25 -0000 Speaking as co-chair... Here's where Bernard and I think we are in MARTINI. We were chartered as a DISPATCHed working group with very tight milestone dates. We have a problem statement/requirements working group draft, at http://tools.ietf.org/html/draft-ietf-martini-reqs-03. We think we're close to consenus on that draft - we're not declaring consensus now, but anyone who thinks that the problems in that draft aren't real problems today, needs to be focused on convincing the working group, in a very short timeframe. We adopted the GIN draft as our solution draft, based on those requirements. The current version is at http://tools.ietf.org/html/draft-ietf-martini-gin-00, which includes a detailed analysis against those requirements (see section 9). We're now at the point at which the working group actually starts to work on the draft. Anyone who thinks that GIN is the wrong answer is welcome to submit a counterproposal, bue we really can't just stop dead in the water - we need to keep moving. We have been telling working group chairs for more than ten years, as part of their training, that technical concerns are always in order, and I believe this to be true, so I'm not willing to shut down technical concerns, even if we've adopted GIN as a working group draft. But we're not quite having a technical discussion onlist. In the absence of technical concerns, Bernard and I have a job to do, and that's to produce consensus-backed specifications. Thanks, Spencer, as co-chair From md3135@att.com Mon Apr 5 11:10:06 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151333A69F8 for ; Mon, 5 Apr 2010 11:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.082 X-Spam-Level: X-Spam-Status: No, score=-106.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKCUxlYAPzTC for ; Mon, 5 Apr 2010 11:10:02 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id A0F753A6943 for ; Mon, 5 Apr 2010 11:10:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-7.tower-121.messagelabs.com!1270490998!35028682!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 20013 invoked from network); 5 Apr 2010 18:09:58 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Apr 2010 18:09:58 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o35I9icY027471; Mon, 5 Apr 2010 14:09:45 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o35I9gPJ027422; Mon, 5 Apr 2010 14:09:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 5 Apr 2010 14:09:54 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E60@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Revectoring back to technical discussion Thread-Index: AcrU6nVnf+Dcn1ZyRdegviJXRi8XPgAALwmz From: "DOLLY, MARTIN C (ATTLABS)" To: , Subject: Re: [martini] Revectoring back to technical discussion X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 18:10:06 -0000 Q29uc2Vuc3VzPw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBtYXJ0aW5p LWJvdW5jZXNAaWV0Zi5vcmcgPG1hcnRpbmktYm91bmNlc0BpZXRmLm9yZz4NClRvOiBtYXJ0aW5p QGlldGYub3JnIDxtYXJ0aW5pQGlldGYub3JnPg0KU2VudDogTW9uIEFwciAwNSAxNDowNDowMCAy MDEwDQpTdWJqZWN0OiBbbWFydGluaV0gUmV2ZWN0b3JpbmcgYmFjayB0byB0ZWNobmljYWwgZGlz Y3Vzc2lvbg0KDQpTcGVha2luZyBhcyBjby1jaGFpci4uLg0KDQpIZXJlJ3Mgd2hlcmUgQmVybmFy ZCBhbmQgSSB0aGluayB3ZSBhcmUgaW4gTUFSVElOSS4NCg0KV2Ugd2VyZSBjaGFydGVyZWQgYXMg YSBESVNQQVRDSGVkIHdvcmtpbmcgZ3JvdXAgd2l0aCB2ZXJ5IHRpZ2h0IG1pbGVzdG9uZSANCmRh dGVzLg0KDQpXZSBoYXZlIGEgcHJvYmxlbSBzdGF0ZW1lbnQvcmVxdWlyZW1lbnRzIHdvcmtpbmcg Z3JvdXAgZHJhZnQsIGF0IA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1t YXJ0aW5pLXJlcXMtMDMuDQoNCldlIHRoaW5rIHdlJ3JlIGNsb3NlIHRvIGNvbnNlbnVzIG9uIHRo YXQgZHJhZnQgLSB3ZSdyZSBub3QgZGVjbGFyaW5nIA0KY29uc2Vuc3VzIG5vdywgYnV0IGFueW9u ZSB3aG8gdGhpbmtzIHRoYXQgdGhlIHByb2JsZW1zIGluIHRoYXQgZHJhZnQgYXJlbid0IA0KcmVh bCBwcm9ibGVtcyB0b2RheSwgbmVlZHMgdG8gYmUgZm9jdXNlZCBvbiBjb252aW5jaW5nIHRoZSB3 b3JraW5nIGdyb3VwLCBpbiANCmEgdmVyeSBzaG9ydCB0aW1lZnJhbWUuDQoNCldlIGFkb3B0ZWQg dGhlIEdJTiBkcmFmdCBhcyBvdXIgc29sdXRpb24gZHJhZnQsIGJhc2VkIG9uIHRob3NlIHJlcXVp cmVtZW50cy4gDQpUaGUgY3VycmVudCB2ZXJzaW9uIGlzIGF0IA0KaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1tYXJ0aW5pLWdpbi0wMCwgd2hpY2ggaW5jbHVkZXMgYSANCmRl dGFpbGVkIGFuYWx5c2lzIGFnYWluc3QgdGhvc2UgcmVxdWlyZW1lbnRzIChzZWUgc2VjdGlvbiA5 KS4gV2UncmUgbm93IGF0IA0KdGhlIHBvaW50IGF0IHdoaWNoIHRoZSB3b3JraW5nIGdyb3VwIGFj dHVhbGx5IHN0YXJ0cyB0byB3b3JrIG9uIHRoZSBkcmFmdC4NCg0KQW55b25lIHdobyB0aGlua3Mg dGhhdCBHSU4gaXMgdGhlIHdyb25nIGFuc3dlciBpcyB3ZWxjb21lIHRvIHN1Ym1pdCBhIA0KY291 bnRlcnByb3Bvc2FsLCBidWUgd2UgcmVhbGx5IGNhbid0IGp1c3Qgc3RvcCBkZWFkIGluIHRoZSB3 YXRlciAtIHdlIG5lZWQgDQp0byBrZWVwIG1vdmluZy4NCg0KV2UgaGF2ZSBiZWVuIHRlbGxpbmcg d29ya2luZyBncm91cCBjaGFpcnMgZm9yIG1vcmUgdGhhbiB0ZW4geWVhcnMsIGFzIHBhcnQgDQpv ZiB0aGVpciB0cmFpbmluZywgdGhhdCB0ZWNobmljYWwgY29uY2VybnMgYXJlIGFsd2F5cyBpbiBv cmRlciwgYW5kIEkgDQpiZWxpZXZlIHRoaXMgdG8gYmUgdHJ1ZSwgc28gSSdtIG5vdCB3aWxsaW5n IHRvIHNodXQgZG93biB0ZWNobmljYWwgY29uY2VybnMsIA0KZXZlbiBpZiB3ZSd2ZSBhZG9wdGVk IEdJTiBhcyBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQuDQoNCkJ1dCB3ZSdyZSBub3QgcXVpdGUgaGF2 aW5nIGEgdGVjaG5pY2FsIGRpc2N1c3Npb24gb25saXN0LiBJbiB0aGUgYWJzZW5jZSBvZiANCnRl Y2huaWNhbCBjb25jZXJucywgQmVybmFyZCBhbmQgSSBoYXZlIGEgam9iIHRvIGRvLCBhbmQgdGhh dCdzIHRvIHByb2R1Y2UgDQpjb25zZW5zdXMtYmFja2VkIHNwZWNpZmljYXRpb25zLg0KDQpUaGFu a3MsDQoNClNwZW5jZXIsIGFzIGNvLWNoYWlyIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbWFydGluaSBtYWlsaW5nIGxpc3QNCm1hcnRpbmlAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFydGluaQ0K From christer.holmberg@ericsson.com Mon Apr 5 12:59:32 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2A4A3A69DA for ; Mon, 5 Apr 2010 12:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3xoJVOnJOWG for ; Mon, 5 Apr 2010 12:59:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C5CD93A69B0 for ; Mon, 5 Apr 2010 12:59:30 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-12-4bba411fe57b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id F5.2B.23740.F114ABB4; Mon, 5 Apr 2010 21:59:27 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 5 Apr 2010 21:59:27 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Mon, 5 Apr 2010 21:59:27 +0200 From: Christer Holmberg To: Spencer Dawkins , "martini@ietf.org" Date: Mon, 5 Apr 2010 21:56:26 +0200 Thread-Topic: [martini] Revectoring back to technical discussion Thread-Index: AcrU6nRMAnPoQzlYTmCDEhEIZ7MO3gAD580F Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] Revectoring back to technical discussion X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 19:59:33 -0000 Hi, In order to clarify things, especially for those who did not attend the mee= ting, my understand was that the question was whether to adopt the GIN draf= t as the place were we will describe the solution - whatever that solution = is. Ie there was no talk about adopting the currently described solution in= the draft. Am I correct? Regards, Christer ________________________________________ From: martini-bounces@ietf.org [martini-bounces@ietf.org] On Behalf Of Spen= cer Dawkins [spencer@wonderhamster.org] Sent: Monday, April 05, 2010 9:04 PM To: martini@ietf.org Subject: [martini] Revectoring back to technical discussion Speaking as co-chair... Here's where Bernard and I think we are in MARTINI. We were chartered as a DISPATCHed working group with very tight milestone dates. We have a problem statement/requirements working group draft, at http://tools.ietf.org/html/draft-ietf-martini-reqs-03. We think we're close to consenus on that draft - we're not declaring consensus now, but anyone who thinks that the problems in that draft aren't real problems today, needs to be focused on convincing the working group, i= n a very short timeframe. We adopted the GIN draft as our solution draft, based on those requirements= . The current version is at http://tools.ietf.org/html/draft-ietf-martini-gin-00, which includes a detailed analysis against those requirements (see section 9). We're now at the point at which the working group actually starts to work on the draft. Anyone who thinks that GIN is the wrong answer is welcome to submit a counterproposal, bue we really can't just stop dead in the water - we need to keep moving. We have been telling working group chairs for more than ten years, as part of their training, that technical concerns are always in order, and I believe this to be true, so I'm not willing to shut down technical concerns= , even if we've adopted GIN as a working group draft. But we're not quite having a technical discussion onlist. In the absence of technical concerns, Bernard and I have a job to do, and that's to produce consensus-backed specifications. Thanks, Spencer, as co-chair _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini= From christer.holmberg@ericsson.com Mon Apr 5 13:04:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A89A3A688D for ; Mon, 5 Apr 2010 13:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSDxMr+56s0A for ; Mon, 5 Apr 2010 13:04:45 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 07B533A6A7D for ; Mon, 5 Apr 2010 13:04:41 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-ed-4bba4256f2b0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 85.6B.23740.6524ABB4; Mon, 5 Apr 2010 22:04:38 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 5 Apr 2010 22:04:39 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Mon, 5 Apr 2010 22:04:38 +0200 From: Christer Holmberg To: Spencer Dawkins , "martini@ietf.org" Date: Mon, 5 Apr 2010 22:01:43 +0200 Thread-Topic: [martini] Revectoring back to technical discussion Thread-Index: AcrU6nRMAnPoQzlYTmCDEhEIZ7MO3gAEFuon Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] Revectoring back to technical discussion X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 20:04:46 -0000 Hi, >Anyone who thinks that GIN is the wrong answer is welcome to submit a >counterproposal, bue we really can't just stop dead in the water - we need >to keep moving. If you talk about the SOLUTION in the GIN draft, I think is what we are dis= cussing most of the time, and have been discussing for a while :) Regards, Christer= From spencer@wonderhamster.org Mon Apr 5 13:31:05 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2522D28C18A for ; Mon, 5 Apr 2010 13:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_20=-0.74, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fd8uJND0TuI for ; Mon, 5 Apr 2010 13:31:03 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id B2F4D28C1E4 for ; Mon, 5 Apr 2010 13:27:21 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Lxh59-1NRjkE18ix-017DJy; Mon, 05 Apr 2010 16:27:19 -0400 Message-ID: <0AE609CB78324AA9B969818255CC6EC1@china.huawei.com> From: "Spencer Dawkins" To: "Christer Holmberg" , References: Date: Mon, 5 Apr 2010 15:27:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19tYlyV7bHIdtUrRIFAhrTPe8I+0YAD9qXL16F VXPptVNWg+UGVB4gLlXZflllbT6Q7xIPzQr4qa5zrb6WIpkj4h MB3rnpgccoh3S6uGwcm9xD3pmatIjq4jHfQvRg4SxI= Subject: Re: [martini] Revectoring back to technical discussion X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 20:31:05 -0000 following up to christer's post, but not just to christer... "... looking for a counterproposal ..." at the DREGS DISPATCH ad hoc at IETF 76, there was a fairly widespread assumption that the proposed work was a request to rubber-stamp a SIP Forum proposal in the IETF. That wasn't actually true - the thinking from SIP Forum had morphed pretty seriously in the IETF before IETF 76, and morphed again when Hadriel submitted two individual drafts, -shaken and -stirred, and morphed again when Adam submitted the -gin draft prior to one of our virtual interims. it's not like nobody has had an open mind throughout this process. but we need proposals to consider, and those proposals need to come in the form of internet drafts, because that's what we know how to work on. spencer ----- Original Message ----- From: "Christer Holmberg" To: "Spencer Dawkins" ; Sent: Monday, April 05, 2010 3:01 PM Subject: RE: [martini] Revectoring back to technical discussion Hi, >Anyone who thinks that GIN is the wrong answer is welcome to submit a >counterproposal, bue we really can't just stop dead in the water - we need >to keep moving. If you talk about the SOLUTION in the GIN draft, I think is what we are discussing most of the time, and have been discussing for a while :) Regards, Christer= From md3135@att.com Mon Apr 5 14:00:38 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A9803A6A81 for ; Mon, 5 Apr 2010 14:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.156 X-Spam-Level: X-Spam-Status: No, score=-106.156 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxb-bXAXohl5 for ; Mon, 5 Apr 2010 14:00:37 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 8C0353A6A79 for ; Mon, 5 Apr 2010 14:00:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-7.tower-161.messagelabs.com!1270501234!29237265!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 30923 invoked from network); 5 Apr 2010 21:00:35 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Apr 2010 21:00:35 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o35L0KrV028847; Mon, 5 Apr 2010 17:00:21 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o35L0FE5028724; Mon, 5 Apr 2010 17:00:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 5 Apr 2010 17:00:26 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E62@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Revectoring back to technical discussion Thread-Index: AcrU/vGKjAzTB/tKTEezSdnn+QWb/wABBL2S From: "DOLLY, MARTIN C (ATTLABS)" To: , , Subject: Re: [martini] Revectoring back to technical discussion X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 21:00:38 -0000 R0lOIGlzIERPQS4gVGFrZSBvZmYgeW91ciBJRVRGIGhhdHMgYW5kIGRlYWwgd2l0aCB0aGUgcmVh bCB3b3JsZA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBtYXJ0aW5pLWJv dW5jZXNAaWV0Zi5vcmcgPG1hcnRpbmktYm91bmNlc0BpZXRmLm9yZz4NClRvOiBDaHJpc3RlciBI b2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgbWFydGluaUBpZXRmLm9y ZyA8bWFydGluaUBpZXRmLm9yZz4NClNlbnQ6IE1vbiBBcHIgMDUgMTY6Mjc6MDggMjAxMA0KU3Vi amVjdDogUmU6IFttYXJ0aW5pXSBSZXZlY3RvcmluZyBiYWNrIHRvIHRlY2huaWNhbCBkaXNjdXNz aW9uDQoNCmZvbGxvd2luZyB1cCB0byBjaHJpc3RlcidzIHBvc3QsIGJ1dCBub3QganVzdCB0byBj aHJpc3Rlci4uLg0KDQoiLi4uIGxvb2tpbmcgZm9yIGEgY291bnRlcnByb3Bvc2FsIC4uLiINCg0K YXQgdGhlIERSRUdTIERJU1BBVENIIGFkIGhvYyBhdCBJRVRGIDc2LCB0aGVyZSB3YXMgYSBmYWly bHkgd2lkZXNwcmVhZCANCmFzc3VtcHRpb24gdGhhdCB0aGUgcHJvcG9zZWQgd29yayB3YXMgYSBy ZXF1ZXN0IHRvIHJ1YmJlci1zdGFtcCBhIFNJUCBGb3J1bSANCnByb3Bvc2FsIGluIHRoZSBJRVRG LiBUaGF0IHdhc24ndCBhY3R1YWxseSB0cnVlIC0gdGhlIHRoaW5raW5nIGZyb20gU0lQIA0KRm9y dW0gaGFkIG1vcnBoZWQgcHJldHR5IHNlcmlvdXNseSBpbiB0aGUgSUVURiBiZWZvcmUgSUVURiA3 NiwgYW5kIG1vcnBoZWQgDQphZ2FpbiB3aGVuIEhhZHJpZWwgc3VibWl0dGVkIHR3byBpbmRpdmlk dWFsIGRyYWZ0cywgLXNoYWtlbiBhbmQgLXN0aXJyZWQsIA0KYW5kIG1vcnBoZWQgYWdhaW4gd2hl biBBZGFtIHN1Ym1pdHRlZCB0aGUgLWdpbiBkcmFmdCBwcmlvciB0byBvbmUgb2Ygb3VyIA0Kdmly dHVhbCBpbnRlcmltcy4NCg0KaXQncyBub3QgbGlrZSBub2JvZHkgaGFzIGhhZCBhbiBvcGVuIG1p bmQgdGhyb3VnaG91dCB0aGlzIHByb2Nlc3MuDQoNCmJ1dCB3ZSBuZWVkIHByb3Bvc2FscyB0byBj b25zaWRlciwgYW5kIHRob3NlIHByb3Bvc2FscyBuZWVkIHRvIGNvbWUgaW4gdGhlIA0KZm9ybSBv ZiBpbnRlcm5ldCBkcmFmdHMsIGJlY2F1c2UgdGhhdCdzIHdoYXQgd2Uga25vdyBob3cgdG8gd29y ayBvbi4NCg0Kc3BlbmNlcg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTog IkNocmlzdGVyIEhvbG1iZXJnIiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KVG86 ICJTcGVuY2VyIERhd2tpbnMiIDxzcGVuY2VyQHdvbmRlcmhhbXN0ZXIub3JnPjsgPG1hcnRpbmlA aWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIEFwcmlsIDA1LCAyMDEwIDM6MDEgUE0NClN1YmplY3Q6 IFJFOiBbbWFydGluaV0gUmV2ZWN0b3JpbmcgYmFjayB0byB0ZWNobmljYWwgZGlzY3Vzc2lvbg0K DQoNCkhpLA0KDQo+QW55b25lIHdobyB0aGlua3MgdGhhdCBHSU4gaXMgdGhlIHdyb25nIGFuc3dl ciBpcyB3ZWxjb21lIHRvIHN1Ym1pdCBhDQo+Y291bnRlcnByb3Bvc2FsLCBidWUgd2UgcmVhbGx5 IGNhbid0IGp1c3Qgc3RvcCBkZWFkIGluIHRoZSB3YXRlciAtIHdlIG5lZWQNCj50byBrZWVwIG1v dmluZy4NCg0KSWYgeW91IHRhbGsgYWJvdXQgdGhlIFNPTFVUSU9OIGluIHRoZSBHSU4gZHJhZnQs IEkgdGhpbmsgaXMgd2hhdCB3ZSBhcmUgDQpkaXNjdXNzaW5nIG1vc3Qgb2YgdGhlIHRpbWUsIGFu ZCBoYXZlIGJlZW4gZGlzY3Vzc2luZyBmb3IgYSB3aGlsZSA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJp c3Rlcj0gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQptYXJ0aW5pIG1haWxpbmcgbGlzdA0KbWFydGluaUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYXJ0aW5pDQo= From adam@nostrum.com Mon Apr 5 14:06:48 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079E63A6A85 for ; Mon, 5 Apr 2010 14:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaFVIqZhXr-x for ; Mon, 5 Apr 2010 14:06:47 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A7AB73A6A56 for ; Mon, 5 Apr 2010 14:06:45 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o35L6Xnq062959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Apr 2010 16:06:35 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBA50D9.7030507@nostrum.com> Date: Mon, 05 Apr 2010 16:06:33 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "DOLLY, MARTIN C (ATTLABS)" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E62@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E62@gaalpa1msgusr7e.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: martini@ietf.org Subject: Re: [martini] Revectoring back to technical discussion X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 21:06:48 -0000 Martin: I appreciate your constructive input, and look forward to your internet-draft describing an alternate approach that satisfies the requirements document. Thanks. /a On 4/5/10 4:00 PM, DOLLY, MARTIN C (ATTLABS) wrote: > GIN is DOA. Take off your IETF hats and deal with the real world > > ----- Original Message ----- > From: martini-bounces@ietf.org > To: Christer Holmberg; martini@ietf.org > Sent: Mon Apr 05 16:27:08 2010 > Subject: Re: [martini] Revectoring back to technical discussion > > following up to christer's post, but not just to christer... > > "... looking for a counterproposal ..." > > at the DREGS DISPATCH ad hoc at IETF 76, there was a fairly widespread > assumption that the proposed work was a request to rubber-stamp a SIP Forum > proposal in the IETF. That wasn't actually true - the thinking from SIP > Forum had morphed pretty seriously in the IETF before IETF 76, and morphed > again when Hadriel submitted two individual drafts, -shaken and -stirred, > and morphed again when Adam submitted the -gin draft prior to one of our > virtual interims. > > it's not like nobody has had an open mind throughout this process. > > but we need proposals to consider, and those proposals need to come in the > form of internet drafts, because that's what we know how to work on. > > spencer > > ----- Original Message ----- > From: "Christer Holmberg" > To: "Spencer Dawkins"; > Sent: Monday, April 05, 2010 3:01 PM > Subject: RE: [martini] Revectoring back to technical discussion > > > Hi, > > >> Anyone who thinks that GIN is the wrong answer is welcome to submit a >> counterproposal, bue we really can't just stop dead in the water - we need >> to keep moving. >> > If you talk about the SOLUTION in the GIN draft, I think is what we are > discussing most of the time, and have been discussing for a while :) > > Regards, > > Christer= > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From bernard_aboba@hotmail.com Mon Apr 5 14:48:58 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12AD3A6A79 for ; Mon, 5 Apr 2010 14:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.752 X-Spam-Level: X-Spam-Status: No, score=0.752 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30o2ba+SsDU9 for ; Mon, 5 Apr 2010 14:48:57 -0700 (PDT) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by core3.amsl.com (Postfix) with ESMTP id 5303D3A67E1 for ; Mon, 5 Apr 2010 14:48:53 -0700 (PDT) Received: from BLU137-W21 ([65.55.111.73]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 14:48:51 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_dbbc99c4-411e-4691-a1b9-b514b53603c4_" X-Originating-IP: [72.11.66.126] From: Bernard Aboba To: Date: Mon, 5 Apr 2010 14:48:51 -0700 Importance: Normal In-Reply-To: <258621872.453212.1270503776767.JavaMail.doodle@worker1> References: <258621872.453212.1270503776767.JavaMail.doodle@worker1> MIME-Version: 1.0 X-OriginalArrivalTime: 05 Apr 2010 21:48:51.0445 (UTC) FILETIME=[C7A60A50:01CAD509] Subject: [martini] MARTINI Virtual Interim Doodle Poll X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 21:48:58 -0000 --_dbbc99c4-411e-4691-a1b9-b514b53603c4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In order to investigate potential dates/times for a MARTINI Virtual Interim= during the last week of April=2C we are starting a Doodle poll:=20 http://www.doodle.com/whns4fd75dcerxnz Please fill in your availability ASAP. We will make a decision on Monday= =2C April 12.=20 = --_dbbc99c4-411e-4691-a1b9-b514b53603c4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In order to investigate potential dates/times for a MARTINI Virtual Interim= during the last week of April=2C we are starting a Doodle poll:

ht= tp://www.doodle.com/whns4fd75dcerxnz

Please fill in your availabilit= y ASAP. =3B We will make a decision on Monday=2C April 12.

= = --_dbbc99c4-411e-4691-a1b9-b514b53603c4_-- From bernard_aboba@hotmail.com Mon Apr 5 14:49:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2254F3A68E9 for ; Mon, 5 Apr 2010 14:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.471 X-Spam-Level: X-Spam-Status: No, score=0.471 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDTo-NFdjXqy for ; Mon, 5 Apr 2010 14:49:24 -0700 (PDT) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by core3.amsl.com (Postfix) with ESMTP id 501BC3A67E1 for ; Mon, 5 Apr 2010 14:49:24 -0700 (PDT) Received: from BLU137-W13 ([65.55.111.72]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 14:49:22 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_e3154f14-1c15-48ec-8910-4c8994d3ed51_" X-Originating-IP: [72.11.66.126] From: Bernard Aboba To: Date: Mon, 5 Apr 2010 14:49:22 -0700 Importance: Normal In-Reply-To: <258621872.453212.1270503776767.JavaMail.doodle@worker1> References: <258621872.453212.1270503776767.JavaMail.doodle@worker1> MIME-Version: 1.0 X-OriginalArrivalTime: 05 Apr 2010 21:49:22.0650 (UTC) FILETIME=[DA3F8BA0:01CAD509] Subject: Re: [martini] MARTINI Virtual Interim Doodle Poll X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 21:49:25 -0000 --_e3154f14-1c15-48ec-8910-4c8994d3ed51_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And BTW=2C all times are Pacific Time Zone.=20 From: bernard_aboba@hotmail.com To: martini@ietf.org Subject: MARTINI Virtual Interim Doodle Poll Date: Mon=2C 5 Apr 2010 14:48:51 -0700 In order to investigate potential dates/times for a MARTINI Virtual Interim= during the last week of April=2C we are starting a Doodle poll:=20 http://www.doodle.com/whns4fd75dcerxnz Please fill in your availability ASAP. We will make a decision on Monday= =2C April 12.=20 = --_e3154f14-1c15-48ec-8910-4c8994d3ed51_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And BTW=2C all times are Pacific Time Zone.

From: bernard_aboba@hotmail.com
To: martini@ietf.org
Subject: MARTIN= I Virtual Interim Doodle Poll
Date: Mon=2C 5 Apr 2010 14:48:51 -0700
=
In order to investigate potential dates/times for a MARTINI Virtual Interim= during the last week of April=2C we are starting a Doodle poll:

ht= tp://www.doodle.com/whns4fd75dcerxnz

Please fill in your availabilit= y ASAP. =3B We will make a decision on Monday=2C April 12.

= = --_e3154f14-1c15-48ec-8910-4c8994d3ed51_-- From dean.willis@softarmor.com Mon Apr 5 16:53:35 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76CB73A659C for ; Mon, 5 Apr 2010 16:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EeUqEBI0Osk for ; Mon, 5 Apr 2010 16:53:34 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id BD0283A63D3 for ; Mon, 5 Apr 2010 16:53:34 -0700 (PDT) Received: from [192.168.2.109] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o35NrV0R017903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 5 Apr 2010 18:53:32 -0500 Message-Id: <1ADB0F54-EA2C-45A2-BDB4-B1A4B1C11E62@softarmor.com> From: Dean Willis To: Bernard Aboba In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Apr 2010 18:53:25 -0500 References: <258621872.453212.1270503776767.JavaMail.doodle@worker1> X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] MARTINI Virtual Interim Doodle Poll X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 23:53:35 -0000 On Apr 5, 2010, at 4:49 PM, Bernard Aboba wrote: > And BTW, all times are Pacific Time Zone. which, AFAIK, is GMT/UTC-7 at the moment. I'm beginning to develop a preference for the idea that all clocks should be set to UTC, and the locals should just learn to deal with it. -- Dean From bruno.chatras@orange-ftgroup.com Tue Apr 6 01:23:08 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6AF3A6835 for ; Tue, 6 Apr 2010 01:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVCb5dA0JZ6R for ; Tue, 6 Apr 2010 01:23:05 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 319553A6839 for ; Tue, 6 Apr 2010 01:23:05 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 844566C0029; Tue, 6 Apr 2010 10:22:50 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 771256C0027; Tue, 6 Apr 2010 10:22:50 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 10:22:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Apr 2010 10:22:46 +0200 Message-ID: <9ECCF01B52E7AB408A7EB85352642141014C2338@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E93278@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX Thread-Index: AcrQ23D3EqrCTe1bR2izj67MexoX3wAO4MiAACVdHdAAVrMb0AARaLKAAIPfbnA= References: <430FC6BDED356B4C8498F634416644A91A79E92C83@mail><000401cad1ac$f5111d00$df335700$@us> <430FC6BDED356B4C8498F634416644A91A79E93278@mail> From: To: , , , X-OriginalArrivalTime: 06 Apr 2010 08:22:47.0664 (UTC) FILETIME=[57007700:01CAD562] Cc: martini@ietf.org Subject: Re: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 08:23:08 -0000 =20 > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Hadriel Kaplan > Envoy=E9 : samedi 3 avril 2010 19:09 > =C0 : Christer Holmberg; 'Richard Shockey'; 'Hans Erik van Elburg' > Cc : martini@ietf.org > Objet : Re: [martini] Issue with existing SIP trunking=20 > solutions, was Re: #21: 3.2.2 describes an issue with some PBX >=20 >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Saturday, April 03, 2010 4:31 AM > > To: 'Richard Shockey'; 'Hans Erik van Elburg'; Hadriel Kaplan > >=20 > >=20 > > >No thank you. Some of us want to get this done before the next US > > presidential election. > >=20 > > Also, I guess it is then ok for other SDOs (e.g. 3GPP) to start=20 > > defining their own protocol extensions etc, instead of=20 > bringing them=20 > > to IETF - simply based on the argument (whether it's true=20 > or not) that=20 > > it will take too long to do it in IETF... >=20 > Umm... you do realize that is what some folks believe=20 > happened in this case, right? > Some folks view ETSI's usage of a loose-route model for=20 > Registered contacts as conflicting with the current 3261=20 > model. (i.e., extending it) Personally I think a good lawyer=20 > could make the case it isn't, but we couldn't get consensus=20 > to go that way. > =20 >=20 > > Also, based on what argument do you think it would take a=20 > long time to=20 > > do this with 3GPP/ETSI? >=20 > I think he meant in the context of your suggested=20 > "communicating changes with 3gpp". I too have been told that=20 > trying to coordinate changes/updates to specs with both IETF=20 > and 3GPP at the same time through liaisons takes a long time. >=20 > And it _would_ still require something to be published in the=20 > IETF. There are plenty of SIP networks in existence which=20 > are not IMS, and won't be IMS. >=20 > -hadriel > p.s. And I'm not disparaging IMS (most of my revenue comes=20 > from IMS!) - but it's not the only game in town. IP-PBX SIP=20 > trunks need to work with any SSP network architecture. BC: The solution documented in 3GPP/ETSI specifications would work with = a different architecture than the IMS. We should actually refrain from = calling it "IMS solution" as this sows confusion is people's mind. > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 From bruno.chatras@orange-ftgroup.com Tue Apr 6 01:25:29 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D1E53A6835 for ; Tue, 6 Apr 2010 01:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4xTP5L2FmV3 for ; Tue, 6 Apr 2010 01:25:28 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 48DDB3A67C0 for ; Tue, 6 Apr 2010 01:25:28 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5A1C4A00651; Tue, 6 Apr 2010 10:24:23 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id C38A3A00659; Tue, 6 Apr 2010 10:22:50 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 10:22:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Apr 2010 10:22:45 +0200 Message-ID: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) Thread-Index: AcrUGPUllJsWtr48TgKAWCE3kZno2wBQViXg References: From: To: , , , X-OriginalArrivalTime: 06 Apr 2010 08:22:47.0399 (UTC) FILETIME=[56D80770:01CAD562] Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 08:25:29 -0000 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 : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Dean Willis > Envoy=E9 : dimanche 4 avril 2010 19:04 > =C0 : DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org > Objet : Re: [martini] The IETF versus reality (was: problems=20 > withexisting SIP trunking solutions) >=20 > Are you saying that the IMS solution is what the service=20 > providers need? > =20 >=20 >=20 > "DOLLY, MARTIN C (ATTLABS)" wrote: >=20 > >Speaking as a Service Provider, the solution being produced=20 > by Martini=20 > >does not address what is needed for current to mid-term deployments,=20 > >and creates interoperability problems in the long haul . >=20 > -- > Dean Willis >=20 From bruno.chatras@orange-ftgroup.com Tue Apr 6 05:15:28 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9EF03A6897 for ; Tue, 6 Apr 2010 05:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilCJaIJAd-jZ for ; Tue, 6 Apr 2010 05:15:28 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id C885C3A6358 for ; Tue, 6 Apr 2010 05:15:27 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3FDE6A0065F; Tue, 6 Apr 2010 11:11:57 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 35D96A00655; Tue, 6 Apr 2010 11:11:57 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 11:11:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Apr 2010 11:11:41 +0200 Message-ID: <9ECCF01B52E7AB408A7EB85352642141014C2444@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Revectoring back to technical discussion Thread-Index: AcrU6nQIQzn5uQy8SWufhzu0tCzfiAAfj90A References: From: To: , X-OriginalArrivalTime: 06 Apr 2010 09:11:41.0396 (UTC) FILETIME=[2BA47140:01CAD569] Subject: Re: [martini] Revectoring back to technical discussion X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 12:15:28 -0000 =20 > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Spencer Dawkins > Envoy=E9 : lundi 5 avril 2010 20:04 > =C0 : martini@ietf.org > Objet : [martini] Revectoring back to technical discussion >=20 > Speaking as co-chair... >=20 > Here's where Bernard and I think we are in MARTINI. >=20 > We were chartered as a DISPATCHed working group with very=20 > tight milestone dates. >=20 > We have a problem statement/requirements working group draft,=20 > at http://tools.ietf.org/html/draft-ietf-martini-reqs-03. >=20 > We think we're close to consenus on that draft - we're not=20 > declaring consensus now, but anyone who thinks that the=20 > problems in that draft aren't real problems today, needs to=20 > be focused on convincing the working group, in a very short timeframe. >=20 > We adopted the GIN draft as our solution draft, based on=20 > those requirements.=20 > The current version is at > http://tools.ietf.org/html/draft-ietf-martini-gin-00, which=20 > includes a detailed analysis against those requirements (see=20 > section 9). We're now at the point at which the working group=20 > actually starts to work on the draft. >=20 > Anyone who thinks that GIN is the wrong answer is welcome to=20 > submit a counterproposal, bue we really can't just stop dead=20 > in the water - we need to keep moving. =3D=3D>BC: I do think this is the wrong answer. A better basis for a = good answer was documented in the shaken draft. >=20 > We have been telling working group chairs for more than ten=20 > years, as part of their training, that technical concerns are=20 > always in order, and I believe this to be true, so I'm not=20 > willing to shut down technical concerns, even if we've=20 > adopted GIN as a working group draft. >=20 > But we're not quite having a technical discussion onlist. In=20 > the absence of technical concerns, Bernard and I have a job=20 > to do, and that's to produce consensus-backed specifications. >=20 > Thanks, >=20 > Spencer, as co-chair=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 From keith.drage@alcatel-lucent.com Tue Apr 6 05:56:39 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 578803A67A7 for ; Tue, 6 Apr 2010 05:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUTQ1nXTLTgy for ; Tue, 6 Apr 2010 05:56:38 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 285693A68E8 for ; Tue, 6 Apr 2010 05:56:38 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o36Cu8dW015700 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Apr 2010 14:56:31 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 6 Apr 2010 14:56:28 +0200 From: "DRAGE, Keith (Keith)" To: Bernard Aboba , "martini@ietf.org" Date: Tue, 6 Apr 2010 14:56:26 +0200 Thread-Topic: [martini] MARTINI Virtual Interim Doodle Poll Thread-Index: AcrVCd1TiRU9SIaUSpmbKSCL3ifXpQAfoqXA Message-ID: References: <258621872.453212.1270503776767.JavaMail.doodle@worker1> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE211CCD4CCFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [martini] MARTINI Virtual Interim Doodle Poll X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 12:56:39 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE211CCD4CCFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Wrong, because for once you have remembered to configure in the time zone c= hange bit of doodle. Keith ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Bernard Aboba Sent: Monday, April 05, 2010 10:49 PM To: martini@ietf.org Subject: Re: [martini] MARTINI Virtual Interim Doodle Poll And BTW, all times are Pacific Time Zone. ________________________________ From: bernard_aboba@hotmail.com To: martini@ietf.org Subject: MARTINI Virtual Interim Doodle Poll Date: Mon, 5 Apr 2010 14:48:51 -0700 In order to investigate potential dates/times for a MARTINI Virtual Interim= during the last week of April, we are starting a Doodle poll: http://www.doodle.com/whns4fd75dcerxnz Please fill in your availability ASAP. We will make a decision on Monday, = April 12. --_000_EDC0A1AE77C57744B664A310A0B23AE211CCD4CCFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Wrong, because for once you have remembered to configure in= the=20 time zone change bit of doodle.
 
Keith

From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Monday, April 05, 2010 10:49 PM
To:=20 martini@ietf.org
Subject: Re: [martini] MARTINI Virtual Interim= =20 Doodle Poll

And BTW, all times are Pacific Time Zone.

From: bernard_aboba@hotmail.com
To: martini@ietf.org
Subject: MARTI= NI=20 Virtual Interim Doodle Poll
Date: Mon, 5 Apr 2010 14:48:51 -0700
In order to investigate potential dates/times for a MARTINI Virtual Inter= im=20 during the last week of April, we are starting a Doodle poll:=20

http://www.doodle.com/whns4fd75dcerxnz

Please fill in your= =20 availability ASAP.  We will make a decision on Monday, April 12.=20

--_000_EDC0A1AE77C57744B664A310A0B23AE211CCD4CCFRMRSSXCHMBSC3d_-- From pkyzivat@cisco.com Tue Apr 6 06:05:34 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74A8C3A6897 for ; Tue, 6 Apr 2010 06:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.153 X-Spam-Level: X-Spam-Status: No, score=-10.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc+qQKcoPxd1 for ; Tue, 6 Apr 2010 06:05:33 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0351D3A67A7 for ; Tue, 6 Apr 2010 06:05:32 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIFAB/OuktAZnwM/2dsb2JhbACPUot4cZ94mH2FCQQ X-IronPort-AV: E=Sophos;i="4.51,372,1267401600"; d="scan'208";a="99144029" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 06 Apr 2010 13:05:30 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o36D5UGc027710; Tue, 6 Apr 2010 13:05:30 GMT Message-ID: <4BBB319A.1070107@cisco.com> Date: Tue, 06 Apr 2010 09:05:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: bruno.chatras@orange-ftgroup.com References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 13:05:34 -0000 bruno.chatras@orange-ftgroup.com wrote: > 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. 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 >> -----Message d'origine----- >> De : martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] De la part de Dean Willis >> Envoyé : dimanche 4 avril 2010 19:04 >> À : DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org >> Objet : Re: [martini] The IETF versus reality (was: problems >> withexisting SIP trunking solutions) >> >> Are you saying that the IMS solution is what the service >> providers need? >> >> >> >> "DOLLY, MARTIN C (ATTLABS)" 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 >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From richard@shockey.us Tue Apr 6 06:47:38 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FCB73A692D for ; Tue, 6 Apr 2010 06:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.861 X-Spam-Level: X-Spam-Status: No, score=-0.861 tagged_above=-999 required=5 tests=[AWL=1.738, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejXO0JlLXJ9w for ; Tue, 6 Apr 2010 06:47:37 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id D5AE93A6903 for ; Tue, 6 Apr 2010 06:47:23 -0700 (PDT) Received: (qmail 1440 invoked by uid 0); 6 Apr 2010 13:47:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 6 Apr 2010 13:47:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=DZlbhKaKYC6jdjYeQMHeeTKV2eugd8xJ3WBGq5n2gsZpXgxVA40PFyDzua3EEL2OBZsm45NHBndzWp5P/SZldu8QThGrrKSISpPQDc62f3r4cUZczwlPM0si8DYuW7EK; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nz97e-0002YA-Ud; Tue, 06 Apr 2010 07:47:19 -0600 From: "Richard Shockey" To: , , , , References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> Date: Tue, 6 Apr 2010 09:47:14 -0400 Message-ID: <007b01cad58f$aaff0600$00fd1200$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrUGPUllJsWtr48TgKAWCE3kZno2wBQViXgAA0tRXA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 13:47:38 -0000 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: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of bruno.chatras@orange-ftgroup.com Sent: Tuesday, April 06, 2010 4:23 AM To: dean.willis@softarmor.com; md3135@att.com; = bernard_aboba@hotmail.com; martini@ietf.org 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. > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Dean Willis > Envoy=E9 : dimanche 4 avril 2010 19:04 > =C0 : DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org > Objet : Re: [martini] The IETF versus reality (was: problems=20 > withexisting SIP trunking solutions) >=20 > Are you saying that the IMS solution is what the service=20 > providers need? > =20 >=20 >=20 > "DOLLY, MARTIN C (ATTLABS)" wrote: >=20 > >Speaking as a Service Provider, the solution being produced=20 > by Martini=20 > >does not address what is needed for current to mid-term deployments,=20 > >and creates interoperability problems in the long haul . >=20 > -- > Dean Willis >=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From richard@shockey.us Tue Apr 6 07:03:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28B83A67F3 for ; Tue, 6 Apr 2010 07:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.589 X-Spam-Level: X-Spam-Status: No, score=-0.589 tagged_above=-999 required=5 tests=[AWL=0.770, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCSmxOURbcyy for ; Tue, 6 Apr 2010 07:03:17 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id AA12E3A67F4 for ; Tue, 6 Apr 2010 07:03:17 -0700 (PDT) Received: (qmail 19900 invoked by uid 0); 6 Apr 2010 14:03:16 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 6 Apr 2010 14:03:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=GJxuPXzxWX+/NRRGPk+ejiXUCwm+UKpUvgvZ/BTxuoojhne8un4OotuNii3YzKjd0bHs7dSbIJE+wTl4Ktdv6+ogpKbaKhcT2bofNTThf1yb3JsMmdPBFRuPcOteZh3u; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nz9N5-0003yq-DQ; Tue, 06 Apr 2010 08:03:15 -0600 From: "Richard Shockey" To: "'Paul Kyzivat'" , References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <4BBB319A.1070107@cisco.com> In-Reply-To: <4BBB319A.1070107@cisco.com> Date: Tue, 6 Apr 2010 10:03:11 -0400 Message-ID: <007c01cad591$e51fc840$af5f58c0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrVide5xazgrIcSRMuYRZL0j0aUNQABfUkg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:03:18 -0000 Well that is a thoughtful answer Paul. I personally don=92t 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=92t 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=92t 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: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of Paul Kyzivat Sent: Tuesday, April 06, 2010 9:05 AM To: bruno.chatras@orange-ftgroup.com Cc: bernard_aboba@hotmail.com; martini@ietf.org Subject: Re: [martini] The IETF versus reality bruno.chatras@orange-ftgroup.com wrote: > 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. That's a fine answer if what you have implemented is the "IMS solution". But others have already implemented something else, such as the=20 SIPConnect 1.0 solution. (Which, because it was underspecified, could=20 mean a variety of things.) The bottom line is that there a lot of different things implemented in=20 the wild. So either you take a vote, and adopt whatever has been=20 implemented "the most", or whatever has been implemented by "the most=20 influential", or whatever solution is "better", or you just go back to=20 requirements and sort it out again. No matter what you do, there will be interop problems. That is always=20 the case when we standardize something that has already been = implemented. Thanks, Paul >> -----Message d'origine----- >> De : martini-bounces@ietf.org=20 >> [mailto:martini-bounces@ietf.org] De la part de Dean Willis >> Envoy=E9 : dimanche 4 avril 2010 19:04 >> =C0 : DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org >> Objet : Re: [martini] The IETF versus reality (was: problems=20 >> withexisting SIP trunking solutions) >> >> Are you saying that the IMS solution is what the service=20 >> providers need? >> =20 >> >> >> "DOLLY, MARTIN C (ATTLABS)" wrote: >> >>> Speaking as a Service Provider, the solution being produced=20 >> by Martini=20 >>> does not address what is needed for current to mid-term deployments, = >>> and creates interoperability problems in the long haul . >> -- >> Dean Willis >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From ietf.hanserik@gmail.com Tue Apr 6 07:30:24 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E873A687F for ; Tue, 6 Apr 2010 07:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSz08yMBW69d for ; Tue, 6 Apr 2010 07:30:21 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 10FE13A67E3 for ; Tue, 6 Apr 2010 07:30:20 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so3411eyf.51 for ; Tue, 06 Apr 2010 07:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=iijmCCKlvADjoFFK6xtyA/rXnNFGJHdTb7snWksond4=; b=vc97umlxOSUMDPtk21GJwdkAiVpebIPUA4w34BCqZUMbyW5dGGm5oFDhuWzoW1xoXd OQUr1KWwS2e1wvp2WI/jmRYR6fvPtpo5Mja7nC1HWa7MeNqO/XhJ3qN+xyJ36PCgd0it XVnfr9kR6xfDTyglxg7vzg2PvI0xTMbZbMULA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nOTMnadtdjp2aRgnZwYX+Lw1yKawITD8Pr1o202jVmb4hR6b29xKgEg6EDYjHRYfZU MT+S1vibhKkgmH/M7ttbwqlV89OiluIDal+ppOTCeeLSXDV3h4TG+XjOurZY9puQcTYn uopDKHrr2FABZ9bVYgRpNmzq85CwKiyXEyEhI= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Tue, 6 Apr 2010 07:30:13 -0700 (PDT) In-Reply-To: <007b01cad58f$aaff0600$00fd1200$@us> References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> Date: Tue, 6 Apr 2010 16:30:13 +0200 Received: by 10.213.42.136 with SMTP id s8mr2512452ebe.16.1270564213755; Tue, 06 Apr 2010 07:30:13 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Richard Shockey Content-Type: multipart/alternative; boundary=001485326192a01d6004839248d7 Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:30:24 -0000 --001485326192a01d6004839248d7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 On Tue, Apr 6, 2010 at 3:47 PM, Richard Shockey wrote: > > Well actually the so called IMS solution has its own interoperability > problems caused by the same poor design the original implicit registratio= n > process had. The problem is the registration proxy does not have sufficie= nt > information on what the message is to often process correctly which is wh= y > after 16 months or so of looking at the problem it was clear to some of u= s > 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: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of bruno.chatras@orange-ftgroup.com > Sent: Tuesday, April 06, 2010 4:23 AM > To: dean.willis@softarmor.com; md3135@att.com; bernard_aboba@hotmail.com; > martini@ietf.org > Subject: Re: [martini] The IETF versus reality (was: problems withexistin= g > 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 targe= ts > in front of them: the IMS solution and the GIN solution. > > > -----Message d'origine----- > > De : martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] De la part de Dean Willis > > Envoy=E9 : dimanche 4 avril 2010 19:04 > > =C0 : DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org > > Objet : Re: [martini] The IETF versus reality (was: problems > > withexisting SIP trunking solutions) > > > > Are you saying that the IMS solution is what the service > > providers need? > > > > > > > > "DOLLY, MARTIN C (ATTLABS)" 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 > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > --001485326192a01d6004839248d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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.

/Han= s Erik van Elburg


On Tue, Apr 6, 2010 at 3:47 PM, Richard = Shockey <richard= @shockey.us> wrote:

Well actually the so called IMS solution has its own interoperability
problems caused by the same poor design the original implicit registration<= br> 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<= br> after 16 months or so of looking at the problem it was clear to some of us<= br> 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 i= n
favor of large scale enterprise deployments which, at least in North Americ= a
are not the majority of customers.

-----Original Message-----
From: martini-bounces@ietf.org<= /a> [mailto:martini-bounces@iet= f.org] On Behalf
Of bruno.chatras@orange= -ftgroup.com
Sent: Tuesday, April 06, 2010 4:23 AM
To: dean.willis@softarmor.com<= /a>; md3135@att.com; bernard_aboba@hotmail.com;
martini@ietf.org
Subject: Re: [martini] The IETF ver= sus 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.

> -----Message d'origine-----
> De : martini-bounces@ietf.= org
> [mailto:martini-bounces@ie= tf.org] De la part de Dean Willis
> Envoy=E9 : dimanche 4 avril 2010 19:04
> =C0 : DOLLY, MARTIN C (ATTLABS); Bernard Aboba; martini@ietf.org
> Objet : Re: [martini] The IETF versus reality (was: problems
> withexisting SIP trunking solutions)
>
> Are you saying that the IMS solution is what the service
> providers need?
>
>
>
> "DOLLY, MARTIN C (ATTLABS)" <md3135@att.com> wrote:
>
> >Speaking as a Service Provider, the solution being produced
> by Martini
> >does not address what is needed for current to mid-term deployment= s,
> >and creates interoperability problems in the long haul .
>
> --
> Dean Willis
>
_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini

_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini

--001485326192a01d6004839248d7-- From bruno.chatras@orange-ftgroup.com Tue Apr 6 07:51:43 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8763E3A6962 for ; Tue, 6 Apr 2010 07:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9lTAXd9XUHV for ; Tue, 6 Apr 2010 07:51:42 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 57F7E3A6961 for ; Tue, 6 Apr 2010 07:51:42 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7A415A00604; Tue, 6 Apr 2010 16:43:14 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 6E1D0A00610; Tue, 6 Apr 2010 16:43:14 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 16:43:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Apr 2010 16:40:10 +0200 Message-ID: <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <007b01cad58f$aaff0600$00fd1200$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) Thread-Index: AcrUGPUllJsWtr48TgKAWCE3kZno2wBQViXgAA0tRXAAALPbsA== References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> From: To: , , , , X-OriginalArrivalTime: 06 Apr 2010 14:43:10.0249 (UTC) FILETIME=[7A529190:01CAD597] Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:51:43 -0000 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 > -----Message d'origine----- > De : Richard Shockey [mailto:richard@shockey.us]=20 > Envoy=E9 : mardi 6 avril 2010 15:47 > =C0 : CHATRAS Bruno RD-CORE-ISS; dean.willis@softarmor.com;=20 > md3135@att.com; bernard_aboba@hotmail.com; martini@ietf.org > Objet : RE: [martini] The IETF versus reality (was: problems=20 > withexisting SIP trunking solutions) >=20 >=20 > Well actually the so called IMS solution has its own=20 > interoperability problems caused by the same poor design the=20 > original implicit registration process had. The problem is=20 > the registration proxy does not have sufficient information=20 > on what the message is to often process correctly which is=20 > why after 16 months or so of looking at the problem it was=20 > clear to some of us that some methodology that used a=20 > explicit indicator such as a option tag was the ultimate=20 > solution. I still hold that the ETSI solution has a bias in=20 > favor of large scale enterprise deployments which, at least=20 > in North America are not the majority of customers. >=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of=20 > bruno.chatras@orange-ftgroup.com > Sent: Tuesday, April 06, 2010 4:23 AM > To: dean.willis@softarmor.com; md3135@att.com;=20 > bernard_aboba@hotmail.com; martini@ietf.org > Subject: Re: [martini] The IETF versus reality (was: problems=20 > withexisting SIP trunking solutions) >=20 > I don't know what Martin was saying but I agree that the GIN=20 > solution creates additional interoperability problems, simply=20 > because this is yet another solution... Instead of having a=20 > single target (i.e. the so-called IMS solution) to converge=20 > to, PBX vendors will have two alternative targets in front of=20 > them: the IMS solution and the GIN solution. >=20 > > -----Message d'origine----- > > De : martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] De la part de Dean Willis=20 > Envoy=E9 :=20 > > dimanche 4 avril 2010 19:04 =C0 : DOLLY, MARTIN C (ATTLABS); Bernard = > > Aboba; martini@ietf.org Objet : Re: [martini] The IETF=20 > versus reality=20 > > (was: problems withexisting SIP trunking solutions) > >=20 > > Are you saying that the IMS solution is what the service providers=20 > > need? > > =20 > >=20 > >=20 > > "DOLLY, MARTIN C (ATTLABS)" wrote: > >=20 > > >Speaking as a Service Provider, the solution being produced > > by Martini > > >does not address what is needed for current to mid-term=20 > deployments,=20 > > >and creates interoperability problems in the long haul . > >=20 > > -- > > Dean Willis > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 >=20 From adam@nostrum.com Tue Apr 6 08:12:07 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1327A3A6996 for ; Tue, 6 Apr 2010 08:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWKMWccOymH4 for ; Tue, 6 Apr 2010 08:12:03 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E666E3A6990 for ; Tue, 6 Apr 2010 08:11:59 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o36FBqUG045924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2010 10:11:52 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBB4F38.7050208@nostrum.com> Date: Tue, 06 Apr 2010 10:11:52 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: bruno.chatras@orange-ftgroup.com References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 15:12:07 -0000 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, bruno.chatras@orange-ftgroup.com wrote: > 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 > > >> -----Message d'origine----- >> De : Richard Shockey [mailto:richard@shockey.us] >> Envoyé : mardi 6 avril 2010 15:47 >> À : CHATRAS Bruno RD-CORE-ISS; dean.willis@softarmor.com; >> md3135@att.com; bernard_aboba@hotmail.com; martini@ietf.org >> Objet : RE: [martini] The IETF versus reality (was: problems >> withexisting SIP trunking solutions) >> >> >> 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: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of >> bruno.chatras@orange-ftgroup.com >> Sent: Tuesday, April 06, 2010 4:23 AM >> To: dean.willis@softarmor.com; md3135@att.com; >> bernard_aboba@hotmail.com; martini@ietf.org >> 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. >> >> >>> -----Message d'origine----- >>> De : martini-bounces@ietf.org >>> [mailto:martini-bounces@ietf.org] De la part de Dean Willis >>> >> Envoyé : >> >>> dimanche 4 avril 2010 19:04 À : DOLLY, MARTIN C (ATTLABS); Bernard >>> Aboba; martini@ietf.org Objet : Re: [martini] The IETF >>> >> versus reality >> >>> (was: problems withexisting SIP trunking solutions) >>> >>> Are you saying that the IMS solution is what the service providers >>> need? >>> >>> >>> >>> "DOLLY, MARTIN C (ATTLABS)" 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 >>> >>> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> >> >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From tyler@foxfam.com Tue Apr 6 08:17:11 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40EAD3A695F for ; Tue, 6 Apr 2010 08:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aayEtCno88m2 for ; Tue, 6 Apr 2010 08:17:10 -0700 (PDT) Received: from smtp03.atlngahp.sys.nuvox.net (smtp-out3.atlngahp.sys.nuvox.net [70.43.63.20]) by core3.amsl.com (Postfix) with ESMTP id D546D3A694A for ; Tue, 6 Apr 2010 08:17:09 -0700 (PDT) Received: from LT6KW7CD1 (fw.newsouth.com [209.177.200.190]) by smtp03.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with SMTP id o36FH3jh029778 for ; Tue, 6 Apr 2010 11:17:03 -0400 Message-ID: <00cb01cad59c$36507f20$150510ac@CORPORATE.VOX.NET> From: "Tyler Parkin" To: Date: Tue, 6 Apr 2010 11:17:02 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C8_01CAD57A.AEC78C40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: [martini] Request for SSP perspective X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 15:17:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C8_01CAD57A.AEC78C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looking at the list, it seems there is a large (and vocal) group of PBX = representatives and a smaller (and nearly inaudible) list of SSP's. I = guess what I'd like to see as an SSP is for other SSP's to speak up and = constructively point out the issues they see with GIN, if not propose = solutions. =20 For a while it looked like there was one SSP saying "Looks good" and = another saying "wait a sec...," but it seems that now there are a couple = more voicing concerns about the proposal. As an example, as an SSP my concerns are the following (and I've = repeatedly argued these in the past): 1) Interoperability with PBX's that don't support implicit reg (I'm in = favor of the options tag) 2) Not defining the behavior of middle boxes's and proxy's along with = the registrars, even generically. I've got a half dozen major players = in my network; I don't care if your PBX supports implicit reg, if either = my SBC (or yours) or my registrar don't interop in the same fashion your = PBX will never be able to bulk reg with me. 3) Not indicating some sort of contact based registration status. If = you think you're implicitly registering 400 telnos and I think you're = registering 395, we've got a mismatch. I don't want a PBX sending me = notify's and subscribe's every 15 seconds for a number I don't have on = that account. Alternatively, if you think you're registering 395 and I = think you have 400, you don't want me sending you calls for numbers you = don't have configured (and I sure as heck don't want to lol). There's = been griping about provisioning, and how it's not included in MARTINI, = but I see provisioning and some agreement on registered contacts as = different items. Even if at minimum it's just an indicator of how MANY = different contacts you think you're registering, that's better than the = blind faith model. If I 404 your bulk reg request, you could fall back = to individual registrations. A couple points ~=20 I own (and lease in some cases) the last mile, and I own the IP address = space. Because of that, I don't see moving to a DNS/domain based = solution as a huge driver. So the locator stuff isn't a huge concern = for me. I know that pisses off some people on this list (SIP = purests/p2p fans =3D) ). =20 Also, I see IMS as a good idea and something to drive my network towards = as a future goal, but I don't have an imediate NEED for it because I = don't have mobile subscribers or internet based subs. If/when I get = internet based subs or start a lot of wholesale peering, I might work = towards it faster. I guess I mention that because I don't see IMS as a = scale/sizing issue (i.e ATT vs. the little CLEC), so much as I see it as = a services and priority issue. Thanks, Tyler Parkin ------=_NextPart_000_00C8_01CAD57A.AEC78C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Looking at the list, it seems there is = a large (and=20 vocal) group of PBX representatives and a smaller (and nearly inaudible) = list of=20 SSP's.  I guess what I'd like to see as an SSP is for other SSP's = to speak=20 up and constructively point out the issues they see with GIN, if not = propose=20 solutions. 
 
For a while it looked like there was = one SSP saying=20 "Looks good" and another saying "wait a sec...," but it seems that now = there are=20 a couple more voicing concerns about the proposal.
 
As an example, as an SSP my concerns = are the=20 following (and I've repeatedly argued these in the past):
 
1) Interoperability with PBX's that = don't support=20 implicit reg (I'm in favor of the options tag)
 
2) Not defining the behavior of middle = boxes's and=20 proxy's along with the registrars, even generically.  I've got a = half dozen=20 major players in my network; I don't care if your PBX supports implicit = reg, if=20 either my SBC (or yours) or my registrar don't interop in the same = fashion your=20 PBX will never be able to bulk reg with me.
 
3) Not indicating some sort of contact = based=20 registration status.  If you think you're implicitly registering = 400 telnos=20 and I think you're registering 395, we've got a mismatch.  I don't = want a=20 PBX sending me notify's and subscribe's every 15 seconds for a = number I=20 don't have on that account.  Alternatively, if you think you're = registering=20 395 and I think you have 400, you don't want me sending you calls for = numbers=20 you don't have configured (and I sure as heck don't want to lol).  = There's=20 been griping about provisioning, and how it's not included in MARTINI, = but I see=20 provisioning and some agreement on registered contacts as different = items. =20 Even if at minimum it's just an indicator of how MANY different contacts = you=20 think you're registering, that's better than the blind faith = model.  If I=20 404 your bulk reg request, you could fall back to individual=20 registrations.
 
 
A couple points ~
 
I own (and lease in some cases) the = last mile, and=20 I own the IP address space.  Because of that, I don't see moving to = a=20 DNS/domain based solution as a huge driver.  So the locator stuff = isn't a=20 huge concern for me.  I know that pisses off some people on this = list (SIP=20 purests/p2p fans =3D) ). 
 
Also, I see IMS as a good idea and = something to=20 drive my network towards as a future goal, but I don't have an imediate = NEED for=20 it because I don't have mobile subscribers or internet based subs.  = If/when=20 I get internet based subs or start a lot of wholesale peering, I might = work=20 towards it faster.  I guess I mention that because I don't see = IMS as=20 a scale/sizing issue (i.e ATT vs. the little CLEC), so much as I see it = as a=20 services and priority issue.
 
Thanks,
 
Tyler Parkin
 
 
------=_NextPart_000_00C8_01CAD57A.AEC78C40-- From md3135@att.com Tue Apr 6 08:18:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A83B3A6845 for ; Tue, 6 Apr 2010 08:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.211 X-Spam-Level: X-Spam-Status: No, score=-106.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FwFgWqoLgxu for ; Tue, 6 Apr 2010 08:18:50 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 31CC63A68AA for ; Tue, 6 Apr 2010 08:18:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-8.tower-167.messagelabs.com!1270567126!22968450!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 25705 invoked from network); 6 Apr 2010 15:18:47 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Apr 2010 15:18:47 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o36FIXvV010028; Tue, 6 Apr 2010 11:18:33 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o36FISU4009943; Tue, 6 Apr 2010 11:18:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Apr 2010 11:18:38 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <4BBB4F38.7050208@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) Thread-Index: AcrVm4PF0T6vobDfRlevhYeYUWDEswAAFZcg References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com> From: "DOLLY, MARTIN C (ATTLABS)" To: "Adam Roach" , Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 15:18:52 -0000 Adam, But GIN does not address the Internet at large either??=20 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:adam@nostrum.com]=20 Sent: Tuesday, April 06, 2010 11:12 AM To: bruno.chatras@orange-ftgroup.com Cc: richard@shockey.us; dean.willis@softarmor.com; DOLLY, MARTIN C = (ATTLABS); bernard_aboba@hotmail.com; martini@ietf.org Subject: Re: [martini] The IETF versus reality (was: problems = withexisting SIP trunking solutions) The changes proposed in GIN are not mere caprice, nor are they simply=20 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=20 anyone favoring the IMS solutions have come to "solving" these problems=20 is outright dismissal. The response has largely been of the form "it=20 works for my walled gardens, and I don't care whether it works on the=20 Internet at large." The problem is that the stuff we work on here in the Internet=20 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, bruno.chatras@orange-ftgroup.com wrote: > 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 > > =20 >> -----Message d'origine----- >> De : Richard Shockey [mailto:richard@shockey.us] >> Envoy=E9 : mardi 6 avril 2010 15:47 >> =C0 : CHATRAS Bruno RD-CORE-ISS; dean.willis@softarmor.com; >> md3135@att.com; bernard_aboba@hotmail.com; martini@ietf.org >> Objet : RE: [martini] The IETF versus reality (was: problems >> withexisting SIP trunking solutions) >> >> >> 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: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of >> bruno.chatras@orange-ftgroup.com >> Sent: Tuesday, April 06, 2010 4:23 AM >> To: dean.willis@softarmor.com; md3135@att.com; >> bernard_aboba@hotmail.com; martini@ietf.org >> 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. >> >> =20 >>> -----Message d'origine----- >>> De : martini-bounces@ietf.org >>> [mailto:martini-bounces@ietf.org] De la part de Dean Willis >>> =20 >> Envoy=E9 : >> =20 >>> dimanche 4 avril 2010 19:04 =C0 : DOLLY, MARTIN C (ATTLABS); Bernard >>> Aboba; martini@ietf.org Objet : Re: [martini] The IETF >>> =20 >> versus reality >> =20 >>> (was: problems withexisting SIP trunking solutions) >>> >>> Are you saying that the IMS solution is what the service providers >>> need? >>> >>> >>> >>> "DOLLY, MARTIN C (ATTLABS)" wrote: >>> >>> =20 >>>> Speaking as a Service Provider, the solution being produced >>>> =20 >>> by Martini >>> =20 >>>> does not address what is needed for current to mid-term >>>> =20 >> deployments, >> =20 >>>> and creates interoperability problems in the long haul . >>>> =20 >>> -- >>> Dean Willis >>> >>> =20 >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> >> >> =20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > =20 From bruno.chatras@orange-ftgroup.com Tue Apr 6 08:33:06 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49FD83A6954 for ; Tue, 6 Apr 2010 08:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYHVqpzqzSR7 for ; Tue, 6 Apr 2010 08:33:05 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id BCDE93A695A for ; Tue, 6 Apr 2010 08:33:04 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 33EFB8B8011; Tue, 6 Apr 2010 17:28:06 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 35FA58B8046; Tue, 6 Apr 2010 17:25:23 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 17:25:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD59D.57358AE0" Date: Tue, 6 Apr 2010 17:25:07 +0200 Message-ID: <9ECCF01B52E7AB408A7EB85352642141014F598E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <00cb01cad59c$36507f20$150510ac@CORPORATE.VOX.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Request for SSP perspective Thread-Index: AcrVnE9F11EJ7o/uSIWyOR7L0eFG6AAALUIw References: <00cb01cad59c$36507f20$150510ac@CORPORATE.VOX.NET> From: To: , X-OriginalArrivalTime: 06 Apr 2010 15:25:07.0381 (UTC) FILETIME=[56A66E50:01CAD59D] Subject: Re: [martini] Request for SSP perspective X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 15:33:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD59D.57358AE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 ________________________________ De : martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] De la = part de Tyler Parkin Envoy=E9 : mardi 6 avril 2010 17:17 =C0 : martini@ietf.org Objet : [martini] Request for SSP perspective =09 =09 Looking at the list, it seems there is a large (and vocal) group of PBX = representatives and a smaller (and nearly inaudible) list of SSP's. I = guess what I'd like to see as an SSP is for other SSP's to speak up and = constructively point out the issues they see with GIN, if not propose = solutions. =20 =20 For a while it looked like there was one SSP saying "Looks good" and = another saying "wait a sec...," but it seems that now there are a couple = more voicing concerns about the proposal. =20 As an example, as an SSP my concerns are the following (and I've = repeatedly argued these in the past): =20 1) Interoperability with PBX's that don't support implicit reg (I'm in = favor of the options tag) =20 2) Not defining the behavior of middle boxes's and proxy's along with = the registrars, even generically. I've got a half dozen major players = in my network; I don't care if your PBX supports implicit reg, if either = my SBC (or yours) or my registrar don't interop in the same fashion your = PBX will never be able to bulk reg with me. =20 3) Not indicating some sort of contact based registration status. If = you think you're implicitly registering 400 telnos and I think you're = registering 395, we've got a mismatch. I don't want a PBX sending me = notify's and subscribe's every 15 seconds for a number I don't have on = that account. Alternatively, if you think you're registering 395 and I = think you have 400, you don't want me sending you calls for numbers you = don't have configured (and I sure as heck don't want to lol). There's = been griping about provisioning, and how it's not included in MARTINI, = but I see provisioning and some agreement on registered contacts as = different items. Even if at minimum it's just an indicator of how MANY = different contacts you think you're registering, that's better than the = blind faith model. If I 404 your bulk reg request, you could fall back = to individual registrations. =20 =20 A couple points ~=20 =20 I own (and lease in some cases) the last mile, and I own the IP address = space. Because of that, I don't see moving to a DNS/domain based = solution as a huge driver. So the locator stuff isn't a huge concern = for me. I know that pisses off some people on this list (SIP = purests/p2p fans =3D) ). =20 =20 Also, I see IMS as a good idea and something to drive my network = towards as a future goal, but I don't have an imediate NEED for it = because I don't have mobile subscribers or internet based subs. If/when = I get internet based subs or start a lot of wholesale peering, I might = work towards it faster. I guess I mention that because I don't see IMS = as a scale/sizing issue (i.e ATT vs. the little CLEC), so much as I see = it as a services and priority issue. [=3D=3D>BC:] The so-called "IMS solution" documented in 3GPP/ETSI = specifications would work with a different architecture than the IMS, = all the more so if the option-tag was added on top of it (as initially = proposed in the 'shaken' draft). =20 =20 Thanks, =20 Tyler Parkin =20 =20 ------_=_NextPart_001_01CAD59D.57358AE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 

De : martini-bounces@ietf.org = [mailto:martini-bounces@ietf.org] De la part de Tyler=20 Parkin
Envoy=E9 : mardi 6 avril 2010 = 17:17
=C0 :=20 martini@ietf.org
Objet : [martini] Request for SSP=20 perspective

Looking at the list, it seems there = is a large=20 (and vocal) group of PBX representatives and a smaller (and nearly = inaudible)=20 list of SSP's.  I guess what I'd like to see as an SSP is for = other SSP's=20 to speak up and constructively point out the issues they see with GIN, = if not=20 propose solutions. 
 
For a while it looked like there was = one SSP=20 saying "Looks good" and another saying "wait a sec...," but it seems = that now=20 there are a couple more voicing concerns about the = proposal.
 
As an example, as an SSP my concerns = are the=20 following (and I've repeatedly argued these in the past):
 
1) Interoperability with PBX's that = don't support=20 implicit reg (I'm in favor of the options tag)
 
2) Not defining the behavior of = middle boxes's=20 and proxy's along with the registrars, even generically.  I've = got a half=20 dozen major players in my network; I don't care if your PBX supports = implicit=20 reg, if either my SBC (or yours) or my registrar don't interop in the = same=20 fashion your PBX will never be able to bulk reg with me.
 
3) Not indicating some sort of = contact based=20 registration status.  If you think you're implicitly registering = 400=20 telnos and I think you're registering 395, we've got a mismatch.  = I don't=20 want a PBX sending me notify's and subscribe's every 15 seconds for a=20 number I don't have on that account.  Alternatively, if you = think=20 you're registering 395 and I think you have 400, you don't want me = sending you=20 calls for numbers you don't have configured (and I sure as heck don't = want to=20 lol).  There's been griping about provisioning, and how it's not = included=20 in MARTINI, but I see provisioning and some agreement on registered = contacts=20 as different items.  Even if at minimum it's just an indicator of = how=20 MANY different contacts you think you're registering, that's better = than the=20 blind faith model.  If I 404 your bulk reg request, you could = fall back=20 to individual registrations.
 
 
A couple points ~
 
I own (and lease in some cases) the = last mile,=20 and I own the IP address space.  Because of that, I don't see = moving to a=20 DNS/domain based solution as a huge driver.  So the locator stuff = isn't a=20 huge concern for me.  I know that pisses off some people on this = list=20 (SIP purests/p2p fans =3D) ). 
 
Also, I see IMS as a good idea = and=20 something to drive my network towards as a future goal, but I don't = have an=20 imediate NEED for it because I don't have mobile subscribers or = internet based=20 subs.  If/when I get internet based subs or start a lot of = wholesale=20 peering, I might work towards it faster.  I guess I mention that = because=20 I don't see IMS as a scale/sizing issue (i.e ATT vs. the little = CLEC), so=20 much as I see it as a services and priority issue.
[=3D=3D>BC:] The so-called "IMS solution" documented in 3GPP/ETSI = specifications=20 would work with a different architecture than the IMS, all the more so = if the=20 option-tag was added on top of it (as = initially proposed in the=20 'shaken' draft).  
 
Thanks,
 
Tyler Parkin
 
 
------_=_NextPart_001_01CAD59D.57358AE0-- From keith.drage@alcatel-lucent.com Tue Apr 6 08:40:19 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9238E3A6811 for ; Tue, 6 Apr 2010 08:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.248 X-Spam-Level: X-Spam-Status: No, score=-4.248 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRXBelP99lBh for ; Tue, 6 Apr 2010 08:40:17 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 88AFE3A6808 for ; Tue, 6 Apr 2010 08:40:17 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o36FZU1k020347 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Apr 2010 17:40:09 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 6 Apr 2010 17:39:42 +0200 From: "DRAGE, Keith (Keith)" To: Adam Roach , "DOLLY, MARTIN C (ATTLABS)" Date: Tue, 6 Apr 2010 17:39:40 +0200 Thread-Topic: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) Thread-Index: AcrU53MJVh0FExmzQpSFpmDlsrxrWQAt9+wA Message-ID: References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E5F@gaalpa1msgusr7e.ugd.att.com> <4BBA14F9.30202@cisco.com> <14C85D6CCBE92743AF33663BF5D24EBA061F5349@gaalpa1msgusr7e.ugd.att.com> <4BBA1CD9.2060909@cisco.com> <14C85D6CCBE92743AF33663BF5D24EBA061F5391@gaalpa1msgusr7e.ugd.att.com> <4BBA2102.4010308@nostrum.com> In-Reply-To: <4BBA2102.4010308@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "martini@ietf.org" , "martini-chairs@tools.ietf.org" Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 15:40:19 -0000 V2VsbCBJIGd1ZXNzIHRoYXQgaXMgd2hhdCB5b3UgZ2V0IHdoZW4gY2hhaXJzIGRlY2xhcmUgY29u c2Vuc3VzIHdoZXJlIG5vbmUgYXBwYXJlbnRseSBleGlzdHMuDQoNCktlaXRoIA0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1hcnRpbmktYm91bmNlc0BpZXRmLm9yZyAN Cj4gW21haWx0bzptYXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZGFtIFJv YWNoDQo+IFNlbnQ6IE1vbmRheSwgQXByaWwgMDUsIDIwMTAgNjo0MiBQTQ0KPiBUbzogRE9MTFks IE1BUlRJTiBDIChBVFRMQUJTKQ0KPiBDYzogbWFydGluaUBpZXRmLm9yZzsgbWFydGluaS1jaGFp cnNAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttYXJ0aW5pXSBUaGUgSUVURiB2ZXJz dXMgcmVhbGl0eSh3YXM6IA0KPiBwcm9ibGVtc3dpdGggZXhpc3RpbmcgU0lQIHRydW5raW5nIHNv bHV0aW9ucykNCj4gDQo+IEFjdHVhbGx5LCB3ZSBhcmUgcXVpY2tseSBjb21pbmcgdXAgb24gYSBw b2ludCB3aGVyZSBSRkMgMzY4MyANCj4gbWF5IGJlIG1vcmUgcmVsZXZhbnQgdGhhbiB0aGUgZG9j dW1lbnRzIFBhdWwgY2l0ZXMuDQo+IA0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMz NjgzDQo+IA0KPiANCj4gL2ENCj4gDQo+IE9uIDQvNS8xMCAxMjoyNyBQTSwgRE9MTFksIE1BUlRJ TiBDIChBVFRMQUJTKSB3cm90ZToNCj4gPiBZZWEsIHJpZ2h0LiBCUw0KPiA+DQo+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6 aXZhdEBjaXNjby5jb21dDQo+ID4gU2VudDogTW9uZGF5LCBBcHJpbCAwNSwgMjAxMCAxOjI1IFBN DQo+ID4gVG86IERPTExZLCBNQVJUSU4gQyAoQVRUTEFCUykNCj4gPiBDYzogcmljaGFyZEBzaG9j a2V5LnVzOyBKU0JVUlRPTkBjYWJsZXZpc2lvbi5jb207IG1hcnRpbmlAaWV0Zi5vcmcNCj4gPiBT dWJqZWN0OiBSZTogW21hcnRpbmldIFRoZSBJRVRGIHZlcnN1cyByZWFsaXR5KHdhczogcHJvYmxl bXN3aXRoIA0KPiA+IGV4aXN0aW5nIFNJUCB0cnVua2luZyBzb2x1dGlvbnMpDQo+ID4NCj4gPiBE T0xMWSwgTUFSVElOIEMgKEFUVExBQlMpIHdyb3RlOg0KPiA+ICAgIA0KPiA+PiBQYXVsLA0KPiA+ Pg0KPiA+PiBXaGF0IGlzIGNvbnNlbnN1cywgSSBrbm93IEkgZG8gbm90IGhhdmUgYSB2b3RlIGlu IHRoYXQgYXMgDQo+IEFUJlQuLi5zbyANCj4gPj4gd2hhdCBpcyB5b3VyIHBvaW50DQo+ID4+ICAg ICAgDQo+ID4gVGFrZSBhIGxvb2sgYXQNCj4gPg0KPiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzI0MTgNCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL3Rhby5odG1sDQo+ID4gaHR0cDov L2VuLndpa2lwZWRpYS5vcmcvd2lraS9Sb3VnaF9jb25zZW5zdXMNCj4gPg0KPiA+IFlvdSBoYXZl IGEgInZvdGUiIGFzIGFuICppbmRpdmlkdWFsKiwgbm90IGFzIGEgDQo+IHJlcHJlc2VudGF0aXZl IG9mIEFUJlQuDQo+ID4NCj4gPiBNeSBwb2ludCBpcyB0aGF0IGlmIHlvdSBkb24ndCBsaWtlIHRo ZSBkaXJlY3Rpb24gdGhpbmdzIGFyZSANCj4gZ29pbmcsIGFuZCANCj4gPiB3b3VsZCBsaWtlIHRv IHNlZSB0aGF0IGRpcmVjdGlvbiBjaGFuZ2UsIHRoZW4geW91IGNvdWxkIGNvbnNpZGVyIA0KPiA+ IHByb3Bvc2luZyBhbm90aGVyIGRpcmVjdGlvbiBhbmQgYWR2YW5jaW5nIGFyZ3VtZW50cyB0aGF0 IA0KPiB3aWxsIHBlcnN1YWRlIA0KPiA+IG90aGVycyB0byBzdXBwb3J0IHlvdS4NCj4gPg0KPiA+ IAlUaGFua3MsDQo+ID4gCVBhdWwNCj4gPg0KPiA+ICAgIA0KPiA+PiBNYXJ0aW4NCj4gPj4NCj4g Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogUGF1bCBLeXppdmF0IFtt YWlsdG86cGt5eml2YXRAY2lzY28uY29tXQ0KPiA+PiBTZW50OiBNb25kYXksIEFwcmlsIDA1LCAy MDEwIDEyOjUxIFBNDQo+ID4+IFRvOiBET0xMWSwgTUFSVElOIEMgKEFUVExBQlMpDQo+ID4+IENj OiByaWNoYXJkQHNob2NrZXkudXM7IEpTQlVSVE9OQGNhYmxldmlzaW9uLmNvbTsgbWFydGluaUBp ZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW21hcnRpbmldIFRoZSBJRVRGIHZlcnN1cyByZWFs aXR5KHdhczogcHJvYmxlbXN3aXRoIA0KPiA+PiBleGlzdGluZyBTSVAgdHJ1bmtpbmcgc29sdXRp b25zKQ0KPiA+Pg0KPiA+PiBbYXMgY2hhaXJdDQo+ID4+DQo+ID4+IERPTExZLCBNQVJUSU4gQyAo QVRUTEFCUykgd3JvdGU6DQo+ID4+ICAgICAgDQo+ID4+PiBHSU4gZG9lcyBub3QgY3V0IGl0LiBQ dXJlIEJTDQo+ID4+PiAgICAgICAgDQo+ID4+IE1hcnRpbiAtIFN1Y2ggY29tbWVudHMgZG8gbm90 IGNvbnRyaWJ1dGUgdG8gYXJyaXZpbmcgYXQgYSANCj4gY29uc2Vuc3VzLg0KPiA+Pg0KPiA+PiBJ ZiB5b3UgaGF2ZSB0ZWNobmljYWwgYW5kL29yIGVkaXRvcmlhbCBjb21tZW50cyB0byBtYWtlLCB0 aGV5IGFyZSANCj4gPj4gd2VsY29tZS4gT3IgZmVlbCBmcmVlIHRvIHN1Ym1pdCBhbiBpbmRpdmlk dWFsIGRyYWZ0IGFzIGFuIA0KPiBhbHRlcm5hdGl2ZSANCj4gPj4gdG8gYmUgY29uc2lkZXJlZC4N Cj4gPj4NCj4gPj4gCVRoYW5rcywNCj4gPj4gCVBhdWwNCj4gPj4NCj4gPj4gICAgICANCj4gPj4+ IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4gLS0tLQ0KPiA+Pj4gKkZyb20qOiBSaWNoYXJkIFNob2Nr ZXk8cmljaGFyZEBzaG9ja2V5LnVzPg0KPiA+Pj4gKlRvKjogRE9MTFksIE1BUlRJTiBDIChBVFRM QUJTKTsgSlNCVVJUT05AY2FibGV2aXNpb24uY29tIA0KPiA+Pj4gPEpTQlVSVE9OQGNhYmxldmlz aW9uLmNvbT47IG1hcnRpbmlAaWV0Zi5vcmc8bWFydGluaUBpZXRmLm9yZz4NCj4gPj4+ICpTZW50 KjogTW9uIEFwciAwNSAxMTo1MDoxMyAyMDEwDQo+ID4+PiAqU3ViamVjdCo6IFJFOiBbbWFydGlu aV0gVGhlIElFVEYgdmVyc3VzIHJlYWxpdHkod2FzOiANCj4gcHJvYmxlbXN3aXRoIA0KPiA+Pj4g ZXhpc3RpbmcgU0lQIHRydW5raW5nIHNvbHV0aW9ucykNCj4gPj4+DQo+ID4+PiBNYXJ0eSDigKZJ 4oCZbSBqdXN0IGRvaW5nIG15IGxpdHRsZSBiaXQgdG8gZW5kIFBPVFMgYW5kIHRoZSBQU1ROIGJ5 IA0KPiA+Pj4gbWFraW5nIGl0IGVhc2llciB0byBraWxsIG9mZiBhbGwgb2YgdGhvc2UgbmFzdHkg UFJJ4oCZcyBhbmQgVENBUC4gSg0KPiA+Pj4NCj4gPj4+IEkgZG8gaGF2ZSBhIE5PIFBSSSBoYXQg Zm9yIHlvdSBCVFcuDQo+ID4+Pg0KPiA+Pj4gSXNu4oCZdCB0aGF0IHdoYXQgQVRUIHdhbnRzPyAg Q2VydGFpbmx5IHRoZSBmaWxpbmdzIGF0IHRoZSBGQ0Mgc2F5cyANCj4gPj4+IHRoYXQgd2hhdCB5 b3UgZ3V5cyB3YW50LiBKDQo+ID4+Pg0KPiA+Pj4gWW91IGtub3cgSeKAmWQgZG8gYW55dGhpbmcg SSBjYW4gdG8gaGVscCBBVFQga2lsbCBvZmYgDQo+IGFuYWxvZyBQT1RTIGFuZCANCj4gPj4+IGtl ZXAgdGhvc2UgZGl2aWRlbmRzIGZsb3dpbmcgdG8gYWxsIHRob3NlIHdpZG93cyBhbmQgb3JwaGFu cy4NCj4gPj4+DQo+ID4+PiBodHRwOi8vZmphbGxmb3NzLmZjYy5nb3YvZWNmcy9kb2N1bWVudC92 aWV3P2lkPTcwMjAzNTQwMzINCj4gPj4+DQo+ID4+PiAqRnJvbToqIG1hcnRpbmktYm91bmNlc0Bp ZXRmLm9yZyANCj4gW21haWx0bzptYXJ0aW5pLWJvdW5jZXNAaWV0Zi5vcmddIA0KPiA+Pj4gKk9u IEJlaGFsZiBPZiAqRE9MTFksIE1BUlRJTiBDIChBVFRMQUJTKQ0KPiA+Pj4gKlNlbnQ6KiBNb25k YXksIEFwcmlsIDA1LCAyMDEwIDk6MjkgQU0NCj4gPj4+ICpUbzoqIEpTQlVSVE9OQGNhYmxldmlz aW9uLmNvbTsgbWFydGluaUBpZXRmLm9yZw0KPiA+Pj4gKlN1YmplY3Q6KiBSZTogW21hcnRpbmld IFRoZSBJRVRGIHZlcnN1cyByZWFsaXR5KHdhczogDQo+IHByb2JsZW1zd2l0aCANCj4gPj4+IGV4 aXN0aW5nIFNJUCB0cnVua2luZyBzb2x1dGlvbnMpDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+ PiBTbyBJRVRGIGlzIHRoZSB0aGVyZSBmb3IgY2FibGUsIGNvb2wuIFRoaXMgd2lsbCBwbGF5IHdl bGwgaW4gDQo+ID4+PiByZWd1bGF0b3J5LCBkdWRlLCB0aGFua3MNCj4gPj4+DQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4gLS0tLQ0KPiA+Pj4NCj4gPj4+ICpGcm9t KjogbWFydGluaS1ib3VuY2VzQGlldGYub3JnPG1hcnRpbmktYm91bmNlc0BpZXRmLm9yZz4NCj4g Pj4+ICpUbyo6IG1hcnRpbmlAaWV0Zi5vcmc8bWFydGluaUBpZXRmLm9yZz4NCj4gPj4+ICpTZW50 KjogTW9uIEFwciAwNSAwOTowNDoxMCAyMDEwDQo+ID4+PiAqU3ViamVjdCo6IFJlOiBbbWFydGlu aV0gVGhlIElFVEYgdmVyc3VzIHJlYWxpdHkod2FzOiANCj4gcHJvYmxlbXN3aXRoIA0KPiA+Pj4g ZXhpc3RpbmcgU0lQIHRydW5raW5nIHNvbHV0aW9ucykNCj4gPj4+DQo+ID4+PiBTcGVha2luZyBh cyBhbm90aGVyIHNlcnZpY2UgcHJvdmlkZXIsIEkgYWdyZWUgd2l0aCBSaWNoYXJkLg0KPiA+Pj4N Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4gLUphY2sNCj4gPj4+DQo+ID4+PiAgICAgICAgDQo+ID4+Pj4+ PiAiUmljaGFyZCBTaG9ja2V5IjxyaWNoYXJkQHNob2NrZXkudXM+ICA0LzQvMjAxMCAxMzozMj4+ Pg0KPiA+Pj4+Pj4gICAgICAgICAgICAgIA0KPiA+Pj4gVGhlIElNUyBzb2x1dGlvbiBjb3VsZCBj ZXJ0YWlubHkgd29yayBmb3IgbGFyZ2Ugc2NhbGUgZW50ZXJwcmlzZSANCj4gPj4+IGRlcGxveW1l bnRzIHNlcnZlZCBieSBBVFQgYW5kIG1hc3NpdmUgUFRUJ3MgYnV0IGlzIA0KPiBpbmVmZmVjdHVh bCBhbmQgDQo+ID4+PiBjb3N0IHByb2hpYml0aXZlIGZvciBzbWFsbCBhbmQgbWVkaXVtIGJ1c2lu ZXNzIHNlcnZlZCANCj4gdHlwaWNhbGx5IGJ5IENMRUMncy4NCj4gPj4+IFRoYXQncyB0aGUgd2hv bGUgYnVzaW5lc3MgYW5kIHRlY2huaWNhbCBtb2RlbCBiZWhpbmQgaW1wbGljaXQgDQo+ID4+PiBy ZWdpc3RyYXRpb24gU01CJ3MgYW5kIGNvbXBldGl0aW9uLg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJvbTogbWFydGluaS1ib3VuY2VzQGll dGYub3JnIA0KPiBbbWFpbHRvOm1hcnRpbmktYm91bmNlc0BpZXRmLm9yZ10gT24gDQo+ID4+PiBC ZWhhbGYgT2YgRGVhbiBXaWxsaXMNCj4gPj4+IFNlbnQ6IFN1bmRheSwgQXByaWwgMDQsIDIwMTAg MTowNCBQTQ0KPiA+Pj4gVG86IERPTExZLCBNQVJUSU4gQyAoQVRUTEFCUyk7IEJlcm5hcmQgQWJv YmE7IG1hcnRpbmlAaWV0Zi5vcmcNCj4gPj4+IFN1YmplY3Q6IFJlOiBbbWFydGluaV0gVGhlIElF VEYgdmVyc3VzIHJlYWxpdHkgKHdhczogDQo+IHByb2JsZW1zIHdpdGggDQo+ID4+PiBleGlzdGlu ZyBTSVAgdHJ1bmtpbmcgc29sdXRpb25zKQ0KPiA+Pj4NCj4gPj4+IEFyZSB5b3Ugc2F5aW5nIHRo YXQgdGhlIElNUyBzb2x1dGlvbiBpcyB3aGF0IHRoZSBzZXJ2aWNlIA0KPiBwcm92aWRlcnMgbmVl ZD8NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICJET0xMWSwgTUFSVElOIEMgKEFUVExBQlMp IjxtZDMxMzVAYXR0LmNvbT4gIHdyb3RlOg0KPiA+Pj4NCj4gPj4+ICAgICAgICANCj4gPj4+PiBT cGVha2luZyBhcyBhIFNlcnZpY2UgUHJvdmlkZXIsIHRoZSBzb2x1dGlvbiBiZWluZyBwcm9kdWNl ZCBieSANCj4gPj4+PiBNYXJ0aW5pIGRvZXMgbm90IGFkZHJlc3Mgd2hhdCBpcyBuZWVkZWQgZm9y IGN1cnJlbnQgdG8gbWlkLXRlcm0gDQo+ID4+Pj4gZGVwbG95bWVudHMsIGFuZCBjcmVhdGVzIGlu dGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMgaW4gDQo+IHRoZSBsb25nIGhhdWwgLg0KPiA+Pj4+ICAg ICAgICAgIA0KPiA+Pj4gLS0NCj4gPj4+IERlYW4gV2lsbGlzDQo+ID4+Pg0KPiA+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+IG1hcnRpbmkg bWFpbGluZyBsaXN0DQo+ID4+PiBtYXJ0aW5pQGlldGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hcnRpbmkNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g Pj4+IFRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBpbiB0aGlzIGVtYWlsIGFuZCBhbnkgb2Yg aXRzIA0KPiBhdHRhY2htZW50cyANCj4gPj4+IGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJz b24gb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIA0KPiBhZGRyZXNzZWQgDQo+ID4+PiBhbmQgbWF5 IGNvbnRhaW4gaW5mb3JtYXRpb24gY29uY2VybmluZyBDYWJsZXZpc2lvbiBhbmQvb3IgaXRzIA0K PiA+Pj4gYWZmaWxpYXRlcyBhbmQgc3Vic2lkaWFyaWVzIHRoYXQgaXMgcHJvcHJpZXRhcnksIHBy aXZpbGVnZWQsIA0KPiA+Pj4gY29uZmlkZW50aWFsIGFuZC9vciBzdWJqZWN0IHRvIGNvcHlyaWdo dC4gQW55IHJldmlldywgDQo+ID4+PiByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBvciBv dGhlciB1c2Ugb2YsIG9yIHRha2luZyBvZiBhbnkgDQo+ID4+PiBhY3Rpb24gaW4gcmVsaWFuY2Ug dXBvbiwgdGhpcyBpbmZvcm1hdGlvbiBieSBwZXJzb25zIG9yIGVudGl0aWVzIA0KPiA+Pj4gb3Ro ZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQgYW5kIG1heSBi ZSANCj4gPj4+IHVubGF3ZnVsLiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBpbiBlcnJvciwgcGxlYXNl IGNvbnRhY3QgDQo+IHRoZSBzZW5kZXIgDQo+ID4+PiBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGFu ZCBkZXN0cm95IHRoZSBjb21tdW5pY2F0aW9uIGFuZCANCj4gYWxsIG9mIHRoZSBhdHRhY2htZW50 cyB5b3UgaGF2ZSByZWNlaXZlZCBhbmQgYWxsIGNvcGllcyB0aGVyZW9mLg0KPiA+Pj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+PiAtLS0tDQo+ID4+Pg0KPiA+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+IG1h cnRpbmkgbWFpbGluZyBsaXN0DQo+ID4+PiBtYXJ0aW5pQGlldGYub3JnDQo+ID4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hcnRpbmkNCj4gPj4+ICAgICAgICANCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG1h cnRpbmkgbWFpbGluZyBsaXN0DQo+ID4gbWFydGluaUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFydGluaQ0KPiA+ICAgIA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbWFydGluaSBtYWls aW5nIGxpc3QNCj4gbWFydGluaUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21hcnRpbmkNCj4g From spencer@wonderhamster.org Tue Apr 6 09:28:43 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 731A23A6933 for ; Tue, 6 Apr 2010 09:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2ttxW6eafuJ for ; Tue, 6 Apr 2010 09:28:42 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 944693A68F7 for ; Tue, 6 Apr 2010 09:28:42 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lz3Wq-1NUROg2p0q-0145Io; Tue, 06 Apr 2010 12:28:39 -0400 Message-ID: <5B78CBE6F1044B4F847DE5A572CB8FC2@china.huawei.com> From: "Spencer Dawkins" To: References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E5F@gaalpa1msgusr7e.ugd.att.com><4BBA14F9.30202@cisco.com><14C85D6CCBE92743AF33663BF5D24EBA061F5349@gaalpa1msgusr7e.ugd.att.com><4BBA1CD9.2060909@cisco.com><14C85D6CCBE92743AF33663BF5D24EBA061F5391@gaalpa1msgusr7e.ugd.att.com><4BBA2102.4010308@nostrum.com> Date: Tue, 6 Apr 2010 11:28:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19a9hTgZMTcuwNpt8cmqEWMYPUyiGCIayX2Qz2 XVRklEQFFy+KSdnoANcHSx6ZymUXzRIwYqF8PHBlPZp1hEXl4g gG1I+OrOMzT4PK6YBmb4juMDhdWZxFaTwAt6rLlZfk= Subject: Re: [martini] The IETF versus reality(was: problemswith existing SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 16:28:43 -0000 OK, this is the Tuesday "speaking as co-chair" note. > Well I guess that is what you get when chairs declare consensus where none > apparently exists. The chairs have not declared that consensus exists on the requirements draft - we are still discussing it, and if we had declared that we had consensus to publish it, we would have requested publication. We have been told that people have concerns about the requirements draft that they have not yet sent to the list. That's not helpful. We need everything out on the table. The chairs have not declared that consensus exists on the solutions draft - we are still discussing it, and the chairs are on record as being open to counterproposals. To the PR-action question - Bernard and I do not think that the level of discussion has sunk low enough to justify requesting a PR-action - that's extreme; the IETF has only two on file at http://www.ietf.org/iesg/pr-action.html, so this would have to be the third-worst discussion in the history of the IETF, for us to go there. But we would like to see the technical content of discussion significantly increase from what we've had on-list, post IETF 77. Thanks, Spencer, speaking as co-chair From HKaplan@acmepacket.com Tue Apr 6 09:31:50 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148D23A6868 for ; Tue, 6 Apr 2010 09:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.314 X-Spam-Level: X-Spam-Status: No, score=-1.314 tagged_above=-999 required=5 tests=[AWL=1.284, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuYyGYMxlxkx for ; Tue, 6 Apr 2010 09:31:43 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 59DDF3A67AE for ; Tue, 6 Apr 2010 09:31:43 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 6 Apr 2010 12:31:40 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 6 Apr 2010 12:31:40 -0400 From: Hadriel Kaplan To: Tyler Parkin , "martini@ietf.org" Date: Tue, 6 Apr 2010 12:31:38 -0400 Thread-Topic: [martini] Request for SSP perspective Thread-Index: AcrVnFV6w1wdLRk3TMuG7CbhWN/v8AAARB3Q Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3CE46@mail> References: <00cb01cad59c$36507f20$150510ac@CORPORATE.VOX.NET> In-Reply-To: <00cb01cad59c$36507f20$150510ac@CORPORATE.VOX.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A79F3CE46mail_" MIME-Version: 1.0 Subject: Re: [martini] Request for SSP perspective X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 16:31:50 -0000 --_000_430FC6BDED356B4C8498F634416644A91A79F3CE46mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tyler, Comments inline... ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Tyler Parkin Sent: Tuesday, April 06, 2010 11:17 AM To: martini@ietf.org Subject: [martini] Request for SSP perspective Looking at the list, it seems there is a large (and vocal) group of PBX rep= resentatives and a smaller (and nearly inaudible) list of SSP's. I guess w= hat I'd like to see as an SSP is for other SSP's to speak up and constructi= vely point out the issues they see with GIN, if not propose solutions. For a while it looked like there was one SSP saying "Looks good" and anothe= r saying "wait a sec...," but it seems that now there are a couple more voi= cing concerns about the proposal. As an example, as an SSP my concerns are the following (and I've repeatedly= argued these in the past): 1) Interoperability with PBX's that don't support implicit reg (I'm in favo= r of the options tag) [hsk] Cool, we have agreement on at least one point. :) 2) Not defining the behavior of middle boxes's and proxy's along with the r= egistrars, even generically. I've got a half dozen major players in my net= work; I don't care if your PBX supports implicit reg, if either my SBC (or = yours) or my registrar don't interop in the same fashion your PBX will neve= r be able to bulk reg with me. Do you mean define what they should do at a policy layer? That's really har= d to do in the IETF, because it's basically specific to every deployment. If you mean at a protocol layer, then I think we have the proxy and Registr= ar behavior in the draft. For B2BUA's, if what you're worried about is the= contact-URI stuff we could put some helpful guidance in the draft. What i= n particular are you concerned about? 3) Not indicating some sort of contact based registration status. If you t= hink you're implicitly registering 400 telnos and I think you're registerin= g 395, we've got a mismatch. I don't want a PBX sending me notify's and su= bscribe's every 15 seconds for a number I don't have on that account. Alte= rnatively, if you think you're registering 395 and I think you have 400, yo= u don't want me sending you calls for numbers you don't have configured (an= d I sure as heck don't want to lol). There's been griping about provisioni= ng, and how it's not included in MARTINI, but I see provisioning and some a= greement on registered contacts as different items. Even if at minimum it'= s just an indicator of how MANY different contacts you think you're registe= ring, that's better than the blind faith model. If I 404 your bulk reg req= uest, you could fall back to individual registrations. That's not a bad idea (sending the number of contacts), but I'm worried it = will cause more issues than it solves, by having false positives/negatives.= And I definitely would not want a PBX automatically reverting to individua= l Registrations if it gets a mismatch. As an aside on the rteg-event piece: I believe the idea with doing the reg-= event subscription was it would be in bulk as well - i.e., one Subscription= , which sends you one Notify with all the contacts in it. -hadriel --_000_430FC6BDED356B4C8498F634416644A91A79F3CE46mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tyler,

Comments inline…

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Tyler Parkin
Sent: Tuesday, April 06, 201= 0 11:17 AM
To: martini@ietf.org
Subject: [martini] Request f= or SSP perspective

 

Looking at the list, it seems there is a large (and voca= l) group of PBX representatives and a smaller (and nearly inaudible) list of SSP's.  I guess what I'd like to see as an SSP is for other SSP's to s= peak up and constructively point out the issues they see with GIN, if not propos= e solutions. 

 

For a while it looked like there was one SSP saying "Looks good" and another saying "wait a sec...," but it seems that now there are a couple more voicing concerns about the proposal.=

 

As an example, as an SSP my concerns are the following (= and I've repeatedly argued these in the past):

 

1) Interoperability with PBX's that don't support implic= it reg (I'm in favor of the options tag)

<= span style=3D'font-size:12.0pt;color:navy'> 

[hsk] Cool, we have agreement on at le= ast one point. J=

 

2) Not defining the behavior of middle boxes's and proxy= 's along with the registrars, even generically.  I've got a half dozen ma= jor players in my network; I don't care if your PBX supports implicit reg, if either my SBC (or yours) or my registrar don't interop in the same fashion = your PBX will never be able to bulk reg with me.

<= span style=3D'font-size:12.0pt;color:navy'> 

Do you mean define what they should do= at a policy layer? That’s really hard to do in the IETF, because it̵= 7;s basically specific to every deployment.

If you mean at a protocol layer, then = I think we have the proxy and Registra= r behavior in the draft.  For B2BUA’s, if what you’re worried about i= s the contact-URI stuff we could put some helpful guidance in the draft. &nbs= p;What in particular are you concerned about?

 

 

3) Not indicating some sort of contact based registratio= n status.  If you think you're implicitly registering 400 telnos and I t= hink you're registering 395, we've got a mismatch.  I don't want a PBX send= ing me notify's and subscribe's every 15 seconds for a number I don't have= on that account.  Alternatively, if you think you're registering 395 and = I think you have 400, you don't want me sending you calls for numbers you don= 't have configured (and I sure as heck don't want to lol).  There's been griping about provisioning, and how it's not included in MARTINI, but I see provisioning and some agreement on registered contacts as different items.  Even if at minimum it's just an indicator of how MANY differen= t contacts you think you're registering, that's better than the blind faith model.  If I 404 your bulk reg request, you could fall back to individ= ual registrations.

 

<= span style=3D'font-size:12.0pt;color:navy'>That’s not a bad idea (sending = the number of contacts), but I’m worried it will cause more issues than i= t solves, by having false positives/negatives. And I definitely would not wan= t a PBX automatically reverting to individual Registrations if it gets a mismat= ch.

<= span style=3D'font-size:12.0pt;color:navy'>As an aside on the rteg-event piece: = I believe the idea with doing the reg-event subscription was it would be in b= ulk as well – i.e., one Subscription, which sends you one Notify with all= the contacts in it.

 

<= span style=3D'font-size:12.0pt;color:navy'>-hadriel 

--_000_430FC6BDED356B4C8498F634416644A91A79F3CE46mail_-- From spencer@wonderhamster.org Tue Apr 6 09:49:59 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D843A696B for ; Tue, 6 Apr 2010 09:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGw0MWynM+TR for ; Tue, 6 Apr 2010 09:49:57 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 9DE943A6951 for ; Tue, 6 Apr 2010 09:49:57 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M7XqB-1NdY8y1b5L-00x9Zp; Tue, 06 Apr 2010 12:49:34 -0400 Message-ID: From: "Spencer Dawkins" To: "Hadriel Kaplan" , "Tyler Parkin" , References: <00cb01cad59c$36507f20$150510ac@CORPORATE.VOX.NET> <430FC6BDED356B4C8498F634416644A91A79F3CE46@mail> Date: Tue, 6 Apr 2010 11:49:22 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1DEA_01CAD57F.32FE2600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+dSlOSgPK9+0vhHMpaGKg2FkU1vOev8kl18R2 yoW1F0nWCCaOGg5tWZgvoQ/+Ci1nkMWkka2bpHH1R04mPDSkhK TxFo1sQjSssLQxURib9sbsCOaMRFlG9irDkyYKy2fc= Subject: Re: [martini] Request for SSP perspective X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 16:49:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1DEA_01CAD57F.32FE2600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As an individual contributor... I'm not any happier about the current "say nothing" behavior than Tyler = is. The question is, how much can the endpoints actually say to each = other about what's being registered. My hangup on sending lists of AoRs back and forth has been completely on = the basis of MTU size restrictions, and concerns about whether TCP could = be successfully used, either as primary transport or as fallback. If = these concerns are real, wishing that they could be overcome isn't = helpful - we need to either overcome them or try something else. I could be talked into sending a count of AoRs expected to be = registered/actually registered in both directions. If other people share = Hadriel's concerns about false positives (my 500 AoRs aren't your 500 = AoRs), I could be talked into sending a hash of the AoRs in both = directions - if these don't match, knowing about that mismatch could be = helpful as well. If we required TCP, we'd be having a different discussion, and = SIPconnect strongly prefers TCP, but I've gotten no encouragement that = this would be acceptable in the IETF, so haven't pursued it further. Thoughts? Spencer, as individual contributor ----- Original Message -----=20 From: Hadriel Kaplan=20 To: Tyler Parkin ; martini@ietf.org=20 Sent: Tuesday, April 06, 2010 11:31 AM Subject: Re: [martini] Request for SSP perspective Hi Tyler, Comments inline. =20 -------------------------------------------------------------------------= ----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of Tyler Parkin Sent: Tuesday, April 06, 2010 11:17 AM To: martini@ietf.org Subject: [martini] Request for SSP perspective =20 Looking at the list, it seems there is a large (and vocal) group of = PBX representatives and a smaller (and nearly inaudible) list of SSP's. = I guess what I'd like to see as an SSP is for other SSP's to speak up = and constructively point out the issues they see with GIN, if not = propose solutions. =20 =20 For a while it looked like there was one SSP saying "Looks good" and = another saying "wait a sec...," but it seems that now there are a couple = more voicing concerns about the proposal. =20 As an example, as an SSP my concerns are the following (and I've = repeatedly argued these in the past): =20 1) Interoperability with PBX's that don't support implicit reg (I'm in = favor of the options tag) =20 [hsk] Cool, we have agreement on at least one point. J =20 2) Not defining the behavior of middle boxes's and proxy's along with = the registrars, even generically. I've got a half dozen major players = in my network; I don't care if your PBX supports implicit reg, if either = my SBC (or yours) or my registrar don't interop in the same fashion your = PBX will never be able to bulk reg with me. =20 Do you mean define what they should do at a policy layer? That's = really hard to do in the IETF, because it's basically specific to every = deployment. If you mean at a protocol layer, then I think we have the proxy and = Registrar behavior in the draft. For B2BUA's, if what you're worried = about is the contact-URI stuff we could put some helpful guidance in the = draft. What in particular are you concerned about? =20 =20 3) Not indicating some sort of contact based registration status. If = you think you're implicitly registering 400 telnos and I think you're = registering 395, we've got a mismatch. I don't want a PBX sending me = notify's and subscribe's every 15 seconds for a number I don't have on = that account. Alternatively, if you think you're registering 395 and I = think you have 400, you don't want me sending you calls for numbers you = don't have configured (and I sure as heck don't want to lol). There's = been griping about provisioning, and how it's not included in MARTINI, = but I see provisioning and some agreement on registered contacts as = different items. Even if at minimum it's just an indicator of how MANY = different contacts you think you're registering, that's better than the = blind faith model. If I 404 your bulk reg request, you could fall back = to individual registrations. =20 That's not a bad idea (sending the number of contacts), but I'm = worried it will cause more issues than it solves, by having false = positives/negatives. And I definitely would not want a PBX automatically = reverting to individual Registrations if it gets a mismatch. As an aside on the rteg-event piece: I believe the idea with doing the = reg-event subscription was it would be in bulk as well - i.e., one = Subscription, which sends you one Notify with all the contacts in it. =20 -hadriel=20 -------------------------------------------------------------------------= ----- _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini ------=_NextPart_000_1DEA_01CAD57F.32FE2600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As an individual contributor...
 
I'm not any happier about the current "say nothing" = behavior=20 than Tyler is. The question is, how much can the endpoints actually say = to each=20 other about what's being registered.
 
My hangup on sending lists of AoRs back and forth has been = completely on=20 the basis of MTU size restrictions, and concerns about whether TCP could = be=20 successfully used, either as primary transport or as fallback. If these = concerns=20 are real, wishing that they could be overcome isn't helpful - we need to = either=20 overcome them or try something else.
 
I could be talked into sending a count of AoRs = expected to be=20 registered/actually registered in both directions. If other people share = Hadriel's concerns about false positives (my 500 AoRs aren't your 500 = AoRs), I=20 could be talked into sending a hash of the AoRs in both directions - if = these=20 don't match, knowing about that mismatch could be helpful as = well.
 
If we required TCP, we'd be having a different = discussion, and=20 SIPconnect strongly prefers TCP, but I've gotten no encouragement that = this=20 would be acceptable in the IETF, so haven't pursued it = further.
 
Thoughts?
 
Spencer, as individual contributor
----- Original Message -----
From:=20 Hadriel=20 Kaplan
Sent: Tuesday, April 06, 2010 = 11:31=20 AM
Subject: Re: [martini] Request = for SSP=20 perspective

Hi=20 Tyler,

Comments=20 inline=85

 

From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf=20 Of Tyler Parkin
Sent: Tuesday, April 06, 2010 = 11:17=20 AM
To: martini@ietf.org
Subject: [martini] Request for = SSP=20 perspective

 

Looking at the list, it = seems=20 there is a large (and vocal) group of PBX representatives and a = smaller (and=20 nearly inaudible) list of SSP's.  I guess what I'd like to see as = an SSP=20 is for other SSP's to speak up and constructively point out the issues = they=20 see with GIN, if not propose solutions. =20

 

For a while it looked = like there=20 was one SSP saying "Looks good" and another saying "wait a sec...," = but it=20 seems that now there are a couple more voicing concerns about the=20 proposal.

 

As an example, as an SSP = my=20 concerns are the following (and I've repeatedly argued these in the=20 past):

 

1) Interoperability with = PBX's=20 that don't support implicit reg (I'm in favor of the options=20 tag)

 

[hsk] Cool, = we have=20 agreement on at least one point. J

 

2) Not defining the = behavior of=20 middle boxes's and proxy's along with the registrars, even = generically. =20 I've got a half dozen major players in my network; I don't care if = your PBX=20 supports implicit reg, if either my SBC (or yours) or my registrar = don't=20 interop in the same fashion your PBX will never be able to bulk reg = with=20 me.

 

Do you mean = define=20 what they should do at a policy layer? That=92s really hard to do in = the IETF,=20 because it=92s basically specific to every=20 deployment.

If you mean = at a=20 protocol layer, then I think we=20 have the proxy and Registrar behavior in the draft.  For = B2BUA=92s, if what=20 you=92re worried about is the contact-URI stuff we could put some = helpful=20 guidance in the draft.  What in particular are you concerned=20 about?

 

 

3) Not indicating some = sort of=20 contact based registration status.  If you think you're = implicitly=20 registering 400 telnos and I think you're registering 395, we've got a = mismatch.  I don't want a PBX sending me notify's and subscribe's = every=20 15 seconds for a number I don't have on that account. =20 Alternatively, if you think you're registering 395 and I think you = have 400,=20 you don't want me sending you calls for numbers you don't have = configured (and=20 I sure as heck don't want to lol).  There's been griping about=20 provisioning, and how it's not included in MARTINI, but I see = provisioning and=20 some agreement on registered contacts as different items.  Even = if at=20 minimum it's just an indicator of how MANY different contacts you = think you're=20 registering, that's better than the blind faith model.  If I 404 = your=20 bulk reg request, you could fall back to individual=20 registrations.

 

That=92s not a bad idea = (sending the number=20 of contacts), but I=92m worried it will cause more issues than it = solves, by=20 having false positives/negatives. And I definitely would not want a = PBX=20 automatically reverting to individual Registrations if it gets a=20 mismatch.

As an aside on the rteg-event = piece: I=20 believe the idea with doing the reg-event subscription was it would be = in bulk=20 as well =96 i.e., one Subscription, which sends you one Notify with = all the=20 contacts in it.

 

-hadriel 

_______________________________________________
martini = mailing=20 = list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini=
------=_NextPart_000_1DEA_01CAD57F.32FE2600-- From HKaplan@acmepacket.com Tue Apr 6 09:56:16 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B19D3A69B8 for ; Tue, 6 Apr 2010 09:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=1.204, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6vcVwa4tpB1 for ; Tue, 6 Apr 2010 09:56:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 368AC3A69AB for ; Tue, 6 Apr 2010 09:56:07 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 6 Apr 2010 12:56:00 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 6 Apr 2010 12:56:00 -0400 From: Hadriel Kaplan To: Spencer Dawkins , Tyler Parkin , "martini@ietf.org" Date: Tue, 6 Apr 2010 12:55:58 -0400 Thread-Topic: [martini] Request for SSP perspective Thread-Index: AcrVqThTbDNuBT9iRFWT2zWW4ZbC1gAAGKnA Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3CE54@mail> References: <00cb01cad59c$36507f20$150510ac@CORPORATE.VOX.NET> <430FC6BDED356B4C8498F634416644A91A79F3CE46@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A79F3CE54mail_" MIME-Version: 1.0 Subject: Re: [martini] Request for SSP perspective X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 16:56:16 -0000 --_000_430FC6BDED356B4C8498F634416644A91A79F3CE54mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually my concern was more that I think I'm registering 500 AoR's, but un= beknownst to me in the reg-DB it's (correctly) instantiated as 501 or 499 o= r a regex wildcard or who knows what, and I get back the number "501" or "4= 99" or "1" - even though it's actually all correct/right. -hadriel ________________________________ From: Spencer Dawkins [mailto:spencer@wonderhamster.org] Sent: Tuesday, April 06, 2010 12:49 PM To: Hadriel Kaplan; Tyler Parkin; martini@ietf.org Subject: Re: [martini] Request for SSP perspective As an individual contributor... I'm not any happier about the current "say nothing" behavior than Tyler is.= The question is, how much can the endpoints actually say to each other abo= ut what's being registered. My hangup on sending lists of AoRs back and forth has been completely on th= e basis of MTU size restrictions, and concerns about whether TCP could be s= uccessfully used, either as primary transport or as fallback. If these conc= erns are real, wishing that they could be overcome isn't helpful - we need = to either overcome them or try something else. I could be talked into sending a count of AoRs expected to be registered/ac= tually registered in both directions. If other people share Hadriel's conce= rns about false positives (my 500 AoRs aren't your 500 AoRs), I could be ta= lked into sending a hash of the AoRs in both directions - if these don't ma= tch, knowing about that mismatch could be helpful as well. If we required TCP, we'd be having a different discussion, and SIPconnect s= trongly prefers TCP, but I've gotten no encouragement that this would be ac= ceptable in the IETF, so haven't pursued it further. Thoughts? Spencer, as individual contributor ----- Original Message ----- From: Hadriel Kaplan To: Tyler Parkin ; martini@ietf.org Sent: Tuesday, April 06, 2010 11:31 AM Subject: Re: [martini] Request for SSP perspective Hi Tyler, Comments inline... ________________________________ From: martini-bounces@ietf.org [mailto:mar= tini-bounces@ietf.org] On Behalf Of Tyler Parkin Sent: Tuesday, April 06, 2010 11:17 AM To: martini@ietf.org Subject: [martini] Request for SSP perspective Looking at the list, it seems there is a large (and vocal) group of PBX rep= resentatives and a smaller (and nearly inaudible) list of SSP's. I guess w= hat I'd like to see as an SSP is for other SSP's to speak up and constructi= vely point out the issues they see with GIN, if not propose solutions. For a while it looked like there was one SSP saying "Looks good" and anothe= r saying "wait a sec...," but it seems that now there are a couple more voi= cing concerns about the proposal. As an example, as an SSP my concerns are the following (and I've repeatedly= argued these in the past): 1) Interoperability with PBX's that don't support implicit reg (I'm in favo= r of the options tag) [hsk] Cool, we have agreement on at least one point. :) 2) Not defining the behavior of middle boxes's and proxy's along with the r= egistrars, even generically. I've got a half dozen major players in my net= work; I don't care if your PBX supports implicit reg, if either my SBC (or = yours) or my registrar don't interop in the same fashion your PBX will neve= r be able to bulk reg with me. Do you mean define what they should do at a policy layer? That's really har= d to do in the IETF, because it's basically specific to every deployment. If you mean at a protocol layer, then I think we have the proxy and Registr= ar behavior in the draft. For B2BUA's, if what you're worried about is the= contact-URI stuff we could put some helpful guidance in the draft. What i= n particular are you concerned about? 3) Not indicating some sort of contact based registration status. If you t= hink you're implicitly registering 400 telnos and I think you're registerin= g 395, we've got a mismatch. I don't want a PBX sending me notify's and su= bscribe's every 15 seconds for a number I don't have on that account. Alte= rnatively, if you think you're registering 395 and I think you have 400, yo= u don't want me sending you calls for numbers you don't have configured (an= d I sure as heck don't want to lol). There's been griping about provisioni= ng, and how it's not included in MARTINI, but I see provisioning and some a= greement on registered contacts as different items. Even if at minimum it'= s just an indicator of how MANY different contacts you think you're registe= ring, that's better than the blind faith model. If I 404 your bulk reg req= uest, you could fall back to individual registrations. That's not a bad idea (sending the number of contacts), but I'm worried it = will cause more issues than it solves, by having false positives/negatives.= And I definitely would not want a PBX automatically reverting to individua= l Registrations if it gets a mismatch. As an aside on the rteg-event piece: I believe the idea with doing the reg-= event subscription was it would be in bulk as well - i.e., one Subscription= , which sends you one Notify with all the contacts in it. -hadriel ________________________________ _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini --_000_430FC6BDED356B4C8498F634416644A91A79F3CE54mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Actually my concern was more that I th= ink I’m registering 500 AoR’s, but unbeknownst to me in the reg-DB = it’s (correctly) instantiated as 501 or 499 or a regex wildcard or who knows what, and I get back the number “501” or “499” or “1” &= #8211; even though it’s actually all correct/right.=

 

-hadriel

 

 

From: Spencer = Dawkins [mailto:spencer@wonderhamster.org]
Sent: Tuesday, April 06, 201= 0 12:49 PM
To: Hadriel Kaplan; Tyler Pa= rkin; martini@ietf.org
Subject: Re: [martini] Reque= st for SSP perspective

 

As an individual contributor...

 

I'm not any happier about the current "say nothing" behav= ior than Tyler is. The question is, how much can the endpoints actually say to each other abou= t what's being registered.

 

My hangup on sending lists of AoRs back and forth has been complete= ly on the basis of MTU size restrictions, and concerns about whether TCP could= be successfully used, either as primary transport or as fallback. If these concerns are real, wishing that they could be overcome isn't helpful - we n= eed to either overcome them or try something else.

 

I could be talked into sending a count of AoRs expected to be registered/actually registered in both directions. If other people share Hadriel's concerns about false positives (my 500 AoRs aren't your 500 AoRs)= , I could be talked into sending a hash of the AoRs in both directions - if the= se don't match, knowing about that mismatch could be helpful as well.

 

If we required TCP, we'd be having a different discussion, and SIPconnect strongly prefers TCP, but I've gotten no encouragement that this would be acceptable in the IETF, so haven't pursued it further.

 

Thoughts?

 

Spencer, as individual contributor

----- Original Message -----

From:<= /font> <= a href=3D"mailto:HKaplan@acmepacket.com" title=3D"HKaplan@acmepacket.com">Had= riel Kaplan

Sent: Tuesday, A= pril 06, 2010 11:31 AM

Subject: Re: [marti= ni] Request for SSP perspective

 

Hi Tyler,

Comments inline…

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Be= half Of Tyler Parkin
Sent: Tuesday, April 06, 201= 0 11:17 AM
To: martini@ietf.org
Subject: [martini] Request f= or SSP perspective

 

Looking at the list, it seems there is a large (and voca= l) group of PBX representatives and a smaller (and nearly inaudible) list of SSP's.  I guess what I'd like to see as an SSP is for other SSP's to s= peak up and constructively point out the issues they see with GIN, if not propos= e solutions. 

 

For a while it looked like there was one SSP saying "Looks good" and another saying "wait a sec...," but it seems that now there are a couple more voicing concerns about the proposal.=

 

As an example, as an SSP my concerns are the following (= and I've repeatedly argued these in the past):

 

1) Interoperability with PBX's that don't support implic= it reg (I'm in favor of the options tag)

<= span style=3D'font-size:12.0pt;color:navy'> 

[hsk] Cool, we have agreement on at le= ast one point. J=

 

2) Not defining the behavior of middle boxes's and proxy= 's along with the registrars, even generically.  I've got a half dozen ma= jor players in my network; I don't care if your PBX supports implicit reg, if either my SBC (or yours) or my registrar don't interop in the same fashion = your PBX will never be able to bulk reg with me.

<= span style=3D'font-size:12.0pt;color:navy'> 

Do you mean define what they should do= at a policy layer? That’s really hard to do in the IETF, because it̵= 7;s basically specific to every deployment.

If you mean at a protocol layer, then = I think we have the proxy and Registra= r behavior in the draft.  For B2BUA’s, if what you’re worrie= d about is the contact-URI stuff we could put some helpful guidance in the draft.  Wh= at in particular are you concerned about?

 

 

3) Not indicating some sort of contact based registratio= n status.  If you think you're implicitly registering 400 telnos and I t= hink you're registering 395, we've got a mismatch.  I don't want a PBX send= ing me notify's and subscribe's every 15 seconds for a number I don't have= on that account.  Alternatively, if you think you're registering 395 and = I think you have 400, you don't want me sending you calls for numbers you don= 't have configured (and I sure as heck don't want to lol).  There's been griping about provisioning, and how it's not included in MARTINI, but I see provisioning and some agreement on registered contacts as different items.&= nbsp; Even if at minimum it's just an indicator of how MANY different contacts yo= u think you're registering, that's better than the blind faith model.  I= f I 404 your bulk reg request, you could fall back to individual registrations.=

 

<= span style=3D'font-size:12.0pt;color:navy'>That’s not a bad idea (sending = the number of contacts), but I’m worried it will cause more issues than it solve= s, by having false positives/negatives. And I definitely would not want a PBX automatically reverting to individual Registrations if it gets a mismatch.<= o:p>

<= span style=3D'font-size:12.0pt;color:navy'>As an aside on the rteg-event piece: = I believe the idea with doing the reg-event subscription was it would be in b= ulk as well – i.e., one Subscription, which sends you one Notify with all= the contacts in it.

 

<= span style=3D'font-size:12.0pt;color:navy'>-hadriel 

_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini

--_000_430FC6BDED356B4C8498F634416644A91A79F3CE54mail_-- From tyler@foxfam.com Tue Apr 6 09:57:20 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D8E93A6966 for ; Tue, 6 Apr 2010 09:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbT7MAOMzdoD for ; Tue, 6 Apr 2010 09:57:18 -0700 (PDT) Received: from smtp05.atlngahp.sys.nuvox.net (smtp-out5.atlngahp.sys.nuvox.net [70.43.63.23]) by core3.amsl.com (Postfix) with ESMTP id 560693A6868 for ; Tue, 6 Apr 2010 09:57:18 -0700 (PDT) Received: from LT6KW7CD1 (fw.newsouth.com [209.177.200.190]) by smtp05.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with SMTP id o36Gv9sv012519; Tue, 6 Apr 2010 12:57:10 -0400 Message-ID: <010801cad5aa$3291e820$150510ac@CORPORATE.VOX.NET> From: "Tyler Parkin" To: "Hadriel Kaplan" , References: <00cb01cad59c$36507f20$150510ac@CORPORATE.VOX.NET> <430FC6BDED356B4C8498F634416644A91A79F3CE46@mail> Date: Tue, 6 Apr 2010 12:57:09 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0105_01CAD588.AB046160" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [martini] Request for SSP perspective X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 16:57:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0105_01CAD588.AB046160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hadriel, My comments inline also. Thanks, Tyler ----- Original Message -----=20 From: Hadriel Kaplan=20 To: Tyler Parkin ; martini@ietf.org=20 Sent: Tuesday, April 06, 2010 12:31 PM Subject: RE: [martini] Request for SSP perspective Hi Tyler, Comments inline. =20 -------------------------------------------------------------------------= ----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of Tyler Parkin Sent: Tuesday, April 06, 2010 11:17 AM To: martini@ietf.org Subject: [martini] Request for SSP perspective =20 Looking at the list, it seems there is a large (and vocal) group of = PBX representatives and a smaller (and nearly inaudible) list of SSP's. = I guess what I'd like to see as an SSP is for other SSP's to speak up = and constructively point out the issues they see with GIN, if not = propose solutions. =20 =20 For a while it looked like there was one SSP saying "Looks good" and = another saying "wait a sec...," but it seems that now there are a couple = more voicing concerns about the proposal. =20 As an example, as an SSP my concerns are the following (and I've = repeatedly argued these in the past): =20 1) Interoperability with PBX's that don't support implicit reg (I'm in = favor of the options tag) =20 [hsk] Cool, we have agreement on at least one point. J =20 2) Not defining the behavior of middle boxes's and proxy's along with = the registrars, even generically. I've got a half dozen major players = in my network; I don't care if your PBX supports implicit reg, if either = my SBC (or yours) or my registrar don't interop in the same fashion your = PBX will never be able to bulk reg with me. =20 Do you mean define what they should do at a policy layer? That's = really hard to do in the IETF, because it's basically specific to every = deployment. If you mean at a protocol layer, then I think we have the proxy and = Registrar behavior in the draft. For B2BUA's, if what you're worried = about is the contact-URI stuff we could put some helpful guidance in the = draft. What in particular are you concerned about? =20 [TP] I don't mean to suggest that the draft say how the registrar/SBC = should impliment this, but at the protocal layer it would be nice to = have agreement on whether a GRUU should be appended, or a cookie, etc. = There have been different suggestions, but with respect to the = suggestors, if we can get 3 diff proposals "off the top of the head" on = this list, then that's at least three diff ways that the different = SBC/Registrar vendors can impliment their support for GIN, which leads = to interop issues. Say, just for example, if we were to use a standard = SIP-NAT with an Acme SBC, I'm sure you know the result is that all the = different public addresses are NAT'd at the IP and Protocol layer so = that they show up to the registrar as originating from a single Private = IP on the SBC core side. So if a PBX registers the BNC contact (i.e. = bnc@privateip), I guess my concern is when the BNC is sent to the = registrar that is the ONLY contact the SBC has for that PBX. So if the = registrar then sends a request to the SBC for an individual contact = (i.e. user@privateip) how is the SBC going to know which PBX to send the = request to. Obviously, a cookie on the initial registration seems most = likely, all I'm asking is that it be specified in the draft so that 4 = different SBC vendors don't do a cookie, or a request-uri as the BNC and = the contact URI as the user, or map to some PAU, etc. My interest is = that everybody play nice from the get go so we can get this in = production more quickly. =20 3) Not indicating some sort of contact based registration status. If = you think you're implicitly registering 400 telnos and I think you're = registering 395, we've got a mismatch. I don't want a PBX sending me = notify's and subscribe's every 15 seconds for a number I don't have on = that account. Alternatively, if you think you're registering 395 and I = think you have 400, you don't want me sending you calls for numbers you = don't have configured (and I sure as heck don't want to lol). There's = been griping about provisioning, and how it's not included in MARTINI, = but I see provisioning and some agreement on registered contacts as = different items. Even if at minimum it's just an indicator of how MANY = different contacts you think you're registering, that's better than the = blind faith model. If I 404 your bulk reg request, you could fall back = to individual registrations. =20 That's not a bad idea (sending the number of contacts), but I'm = worried it will cause more issues than it solves, by having false = positives/negatives. And I definitely would not want a PBX automatically = reverting to individual Registrations if it gets a mismatch. As an aside on the rteg-event piece: I believe the idea with doing the = reg-event subscription was it would be in bulk as well - i.e., one = Subscription, which sends you one Notify with all the contacts in it. [TP] Agreed on the rteg-event piece, but my issue is that it's = reactive and not required. If my registrar thinks there are 400 numbers = registered, and the PBX subcribes to receive the list of contacts, that = doesn't prevent me from sending calls to the mismatched URI's and = there's nothing to even require that the PBX subscribe to the event in = the first place. The point of this, I believe, is to reduce the amount = of messaging required to register hundreds or thousands of contacts. = IMO, I'd rather receive registrations that I can throttle (using your = nifty tools) and that have a hold down timer for 404'd reg's on the UA = side, than have a PBX think a dozen or more telnos are registered when = they aren't and send me a ton of ancillary messages for them at very = short intervals. On example would be where a customer calls in a MAC to = disco a range of 100 DID's out of 500 and their vendor doesn't get there = for two weeks to disable them in the PBX. =20 -hadriel=20 Tyler ------=_NextPart_000_0105_01CAD588.AB046160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Hadriel,
 
My comments inline also.
 
Thanks,
Tyler
----- Original Message -----
From:=20 Hadriel=20 Kaplan
Sent: Tuesday, April 06, 2010 = 12:31=20 PM
Subject: RE: [martini] Request = for SSP=20 perspective

Hi=20 Tyler,

Comments=20 inline=85

 

From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf=20 Of Tyler Parkin
Sent: Tuesday, April 06, 2010 = 11:17=20 AM
To: martini@ietf.org
Subject: [martini] Request for = SSP=20 perspective

 

Looking at the list, it = seems=20 there is a large (and vocal) group of PBX representatives and a = smaller (and=20 nearly inaudible) list of SSP's.  I guess what I'd like to see as = an SSP=20 is for other SSP's to speak up and constructively point out the issues = they=20 see with GIN, if not propose solutions. =20

 

For a while it looked = like there=20 was one SSP saying "Looks good" and another saying "wait a sec...," = but it=20 seems that now there are a couple more voicing concerns about the=20 proposal.

 

As an example, as an SSP = my=20 concerns are the following (and I've repeatedly argued these in the=20 past):

 

1) Interoperability with = PBX's=20 that don't support implicit reg (I'm in favor of the options=20 tag)

 

[hsk] Cool, = we have=20 agreement on at least one point. J

 

2) Not defining the = behavior of=20 middle boxes's and proxy's along with the registrars, even = generically. =20 I've got a half dozen major players in my network; I don't care if = your PBX=20 supports implicit reg, if either my SBC (or yours) or my registrar = don't=20 interop in the same fashion your PBX will never be able to bulk reg = with=20 me.

 

Do you mean = define=20 what they should do at a policy layer? That=92s really hard to do in = the IETF,=20 because it=92s basically specific to every=20 deployment.

If you mean = at a=20 protocol layer, then I think we=20 have the proxy and Registrar behavior in the draft.  For = B2BUA=92s, if what=20 you=92re worried about is the contact-URI stuff we could put some = helpful=20 guidance in the draft.  What in particular are you concerned=20 about?

 

[TP] I don't=20 mean to suggest that the draft say how the registrar/SBC should = impliment=20 this, but at the protocal layer it would be nice to have agreement on = whether=20 a GRUU should be appended, or a cookie, etc.  There have been = different=20 suggestions, but with respect to the suggestors, if we can get 3 diff=20 proposals "off the top of the head" on this list, then that's at least = three=20 diff ways that the different SBC/Registrar vendors can impliment their = support=20 for GIN, which leads to interop issues.  Say, just for example, = if we=20 were to use a standard SIP-NAT with an Acme SBC, I'm sure you know the = result=20 is that all the different public addresses are NAT'd at the IP and = Protocol=20 layer so that they show up to the registrar as originating from a = single=20 Private IP on the SBC core side.  So if a PBX registers the = BNC=20 contact (i.e. bnc@privateip), I guess = my=20 concern is when the BNC is sent to the registrar that is the ONLY = contact the=20 SBC has for that PBX.  So if the registrar then sends a request = to the=20 SBC for an individual contact (i.e. user@privateip) how is = the SBC=20 going to know which PBX to send the request to.  Obviously, a = cookie on=20 the initial registration seems most likely, all I'm asking is that it = be=20 specified in the draft so that 4 different SBC vendors don't do a = cookie, or a=20 request-uri as the BNC and the contact URI as the user, or map to some = PAU,=20 etc.  My interest is that everybody play nice from the get go so = we can=20 get this in production more quickly.

 

3) Not indicating some = sort of=20 contact based registration status.  If you think you're = implicitly=20 registering 400 telnos and I think you're registering 395, we've got a = mismatch.  I don't want a PBX sending me notify's and subscribe's = every=20 15 seconds for a number I don't have on that account. =20 Alternatively, if you think you're registering 395 and I think you = have 400,=20 you don't want me sending you calls for numbers you don't have = configured (and=20 I sure as heck don't want to lol).  There's been griping about=20 provisioning, and how it's not included in MARTINI, but I see = provisioning and=20 some agreement on registered contacts as different items.  Even = if at=20 minimum it's just an indicator of how MANY different contacts you = think you're=20 registering, that's better than the blind faith model.  If I 404 = your=20 bulk reg request, you could fall back to individual=20 registrations.

 

That=92s not a bad idea = (sending the number=20 of contacts), but I=92m worried it will cause more issues than it = solves, by=20 having false positives/negatives. And I definitely would not want a = PBX=20 automatically reverting to individual Registrations if it gets a=20 mismatch.

As an aside on the rteg-event = piece: I=20 believe the idea with doing the reg-event subscription was it would be = in bulk=20 as well =96 i.e., one Subscription, which sends you one Notify with = all the=20 contacts in it.

 

[TP] Agreed on the = rteg-event piece,=20 but my issue is that it's reactive and not required.  If my = registrar=20 thinks there are 400 numbers registered, and the PBX subcribes to = receive the=20 list of contacts, that doesn't prevent me from sending calls to the = mismatched=20 URI's and there's nothing to even require that the PBX subscribe to = the event=20 in the first place.  The point of this, I believe, is to reduce = the=20 amount of messaging required to register hundreds or thousands of=20 contacts.  IMO, I'd rather receive registrations that I can = throttle=20 (using your nifty tools) and that have a hold down timer for = 404'd reg's=20 on the UA side, than have a PBX think a dozen or more telnos are = registered=20 when they aren't and send me a ton of ancillary messages for them at = very=20 short intervals.  On example would be where a customer calls in a = MAC to=20 disco a range of 100 DID's out of 500 and their vendor doesn't get = there for=20 two weeks to disable them in the PBX.

 

-hadriel 

 

Tyler

------=_NextPart_000_0105_01CAD588.AB046160-- From adam@nostrum.com Tue Apr 6 10:01:36 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776E228C0DC for ; Tue, 6 Apr 2010 10:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+PO8S+fE6U3 for ; Tue, 6 Apr 2010 10:01:27 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6DD563A69AB for ; Tue, 6 Apr 2010 10:01:26 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o36H17Ka054215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2010 12:01:07 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBB68D3.7040903@nostrum.com> Date: Tue, 06 Apr 2010 12:01:07 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Hadriel Kaplan References: <00cb01cad59c$36507f20$150510ac@CORPORATE.VOX.NET> <430FC6BDED356B4C8498F634416644A91A79F3CE46@mail> <430FC6BDED356B4C8498F634416644A91A79F3CE54@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3CE54@mail> Content-Type: multipart/alternative; boundary="------------040407080403070903030500" Cc: "martini@ietf.org" Subject: Re: [martini] Request for SSP perspective X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 17:01:36 -0000 This is a multi-part message in MIME format. --------------040407080403070903030500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit If I may be so bold as to extrapolate from what Spencer said -- I read his suggestion to mean you would include a count and/or hash of the E.164 numbers in the range. If the SSP is doing other database magic for operational or efficiency reasons, that's just fine -- but it doesn't need to be visible on the wire. I think the hash approach is actually quite clever, as it completely solves the half of the problem dealing with provisioning mismatches. /a On 4/6/10 11:55, Apr 6, Hadriel Kaplan wrote: > > Actually my concern was more that I think I'm registering 500 AoR's, > but unbeknownst to me in the reg-DB it's (correctly) instantiated as > 501 or 499 or a regex wildcard or who knows what, and I get back the > number "501" or "499" or "1" -- even though it's actually all > correct/right. > > -hadriel > > ------------------------------------------------------------------------ > > *From:* Spencer Dawkins [mailto:spencer@wonderhamster.org] > *Sent:* Tuesday, April 06, 2010 12:49 PM > *To:* Hadriel Kaplan; Tyler Parkin; martini@ietf.org > *Subject:* Re: [martini] Request for SSP perspective > > As an individual contributor... > > I'm not any happier about the current "say nothing" behavior than > Tyler is. The question is, how much can the endpoints actually say to > each other about what's being registered. > > My hangup on sending lists of AoRs back and forth has been completely > on the basis of MTU size restrictions, and concerns about whether TCP > could be successfully used, either as primary transport or as > fallback. If these concerns are real, wishing that they could be > overcome isn't helpful - we need to either overcome them or try > something else. > > I could be talked into sending a count of AoRs expected to be > registered/actually registered in both directions. If other people > share Hadriel's concerns about false positives (my 500 AoRs aren't > your 500 AoRs), I could be talked into sending a hash of the AoRs in > both directions - if these don't match, knowing about that mismatch > could be helpful as well. > > If we required TCP, we'd be having a different discussion, and > SIPconnect strongly prefers TCP, but I've gotten no encouragement that > this would be acceptable in the IETF, so haven't pursued it further. > > Thoughts? > > Spencer, as individual contributor > > ----- Original Message ----- > > *From:* Hadriel Kaplan > > *To:* Tyler Parkin ; martini@ietf.org > > > *Sent:* Tuesday, April 06, 2010 11:31 AM > > *Subject:* Re: [martini] Request for SSP perspective > > Hi Tyler, > > Comments inline... > > ------------------------------------------------------------------------ > > *From:* martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] *On Behalf Of *Tyler Parkin > *Sent:* Tuesday, April 06, 2010 11:17 AM > *To:* martini@ietf.org > *Subject:* [martini] Request for SSP perspective > > Looking at the list, it seems there is a large (and vocal) group > of PBX representatives and a smaller (and nearly inaudible) list > of SSP's. I guess what I'd like to see as an SSP is for other > SSP's to speak up and constructively point out the issues they see > with GIN, if not propose solutions. > > For a while it looked like there was one SSP saying "Looks good" > and another saying "wait a sec...," but it seems that now there > are a couple more voicing concerns about the proposal. > > As an example, as an SSP my concerns are the following (and I've > repeatedly argued these in the past): > > 1) Interoperability with PBX's that don't support implicit reg > (I'm in favor of the options tag) > > [hsk] Cool, we have agreement on at least one point. J > > 2) Not defining the behavior of middle boxes's and proxy's along > with the registrars, even generically. I've got a half dozen > major players in my network; I don't care if your PBX supports > implicit reg, if either my SBC (or yours) or my registrar don't > interop in the same fashion your PBX will never be able to bulk > reg with me. > > Do you mean define what they should do at a policy layer? That's > really hard to do in the IETF, because it's basically specific to > every deployment. > > If you mean at a protocol layer, then I /think/ we have the proxy > and Registrar behavior in the draft. For B2BUA's, if what you're > worried about is the contact-URI stuff we could put some helpful > guidance in the draft. What in particular are you concerned about? > > 3) Not indicating some sort of contact based registration status. > If you think you're implicitly registering 400 telnos and I think > you're registering 395, we've got a mismatch. I don't want a PBX > sending me notify's and subscribe's every 15 seconds for a > number I don't have on that account. Alternatively, if you think > you're registering 395 and I think you have 400, you don't want me > sending you calls for numbers you don't have configured (and I > sure as heck don't want to lol). There's been griping about > provisioning, and how it's not included in MARTINI, but I see > provisioning and some agreement on registered contacts as > different items. Even if at minimum it's just an indicator of how > MANY different contacts you think you're registering, that's > better than the blind faith model. If I 404 your bulk reg > request, you could fall back to individual registrations. > > That's not a bad idea (sending the number of contacts), but I'm > worried it will cause more issues than it solves, by having false > positives/negatives. And I definitely would not want a PBX > automatically reverting to individual Registrations if it gets a > mismatch. > > As an aside on the rteg-event piece: I believe the idea with doing > the reg-event subscription was it would be in bulk as well -- > i.e., one Subscription, which sends you one Notify with all the > contacts in it. > > -hadriel > > ------------------------------------------------------------------------ > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > --------------040407080403070903030500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit If I may be so bold as to extrapolate from what Spencer said -- I read his suggestion to mean you would include a count and/or hash of the E.164 numbers in the range. If the SSP is doing other database magic for operational or efficiency reasons, that's just fine -- but it doesn't need to be visible on the wire.

I think the hash approach is actually quite clever, as it completely solves the half of the problem dealing with provisioning mismatches.

/a

On 4/6/10 11:55, Apr 6, Hadriel Kaplan wrote:

 

Actually my concern was more that I think I’m registering 500 AoR’s, but unbeknownst to me in the reg-DB it’s (correctly) instantiated as 501 or 499 or a regex wildcard or who knows what, and I get back the number “501” or “499” or “1” – even though it’s actually all correct/right.

 

-hadriel

 

 

From: Spencer Dawkins [mailto:spencer@wonderhamster.org]
Sent: Tuesday, April 06, 2010 12:49 PM
To: Hadriel Kaplan; Tyler Parkin; martini@ietf.org
Subject: Re: [martini] Request for SSP perspective

 

As an individual contributor...

 

I'm not any happier about the current "say nothing" behavior than Tyler is. The question is, how much can the endpoints actually say to each other about what's being registered.

 

My hangup on sending lists of AoRs back and forth has been completely on the basis of MTU size restrictions, and concerns about whether TCP could be successfully used, either as primary transport or as fallback. If these concerns are real, wishing that they could be overcome isn't helpful - we need to either overcome them or try something else.

 

I could be talked into sending a count of AoRs expected to be registered/actually registered in both directions. If other people share Hadriel's concerns about false positives (my 500 AoRs aren't your 500 AoRs), I could be talked into sending a hash of the AoRs in both directions - if these don't match, knowing about that mismatch could be helpful as well.

 

If we required TCP, we'd be having a different discussion, and SIPconnect strongly prefers TCP, but I've gotten no encouragement that this would be acceptable in the IETF, so haven't pursued it further.

 

Thoughts?

 

Spencer, as individual contributor

----- Original Message -----

Sent: Tuesday, April 06, 2010 11:31 AM

Subject: Re: [martini] Request for SSP perspective

 

Hi Tyler,

Comments inline…

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Tyler Parkin
Sent: Tuesday, April 06, 2010 11:17 AM
To: martini@ietf.org
Subject: [martini] Request for SSP perspective

 

Looking at the list, it seems there is a large (and vocal) group of PBX representatives and a smaller (and nearly inaudible) list of SSP's.  I guess what I'd like to see as an SSP is for other SSP's to speak up and constructively point out the issues they see with GIN, if not propose solutions. 

 

For a while it looked like there was one SSP saying "Looks good" and another saying "wait a sec...," but it seems that now there are a couple more voicing concerns about the proposal.

 

As an example, as an SSP my concerns are the following (and I've repeatedly argued these in the past):

 

1) Interoperability with PBX's that don't support implicit reg (I'm in favor of the options tag)

 

[hsk] Cool, we have agreement on at least one point. J

 

2) Not defining the behavior of middle boxes's and proxy's along with the registrars, even generically.  I've got a half dozen major players in my network; I don't care if your PBX supports implicit reg, if either my SBC (or yours) or my registrar don't interop in the same fashion your PBX will never be able to bulk reg with me.

 

Do you mean define what they should do at a policy layer? That’s really hard to do in the IETF, because it’s basically specific to every deployment.

If you mean at a protocol layer, then I think we have the proxy and Registrar behavior in the draft.  For B2BUA’s, if what you’re worried about is the contact-URI stuff we could put some helpful guidance in the draft.  What in particular are you concerned about?

 

 

3) Not indicating some sort of contact based registration status.  If you think you're implicitly registering 400 telnos and I think you're registering 395, we've got a mismatch.  I don't want a PBX sending me notify's and subscribe's every 15 seconds for a number I don't have on that account.  Alternatively, if you think you're registering 395 and I think you have 400, you don't want me sending you calls for numbers you don't have configured (and I sure as heck don't want to lol).  There's been griping about provisioning, and how it's not included in MARTINI, but I see provisioning and some agreement on registered contacts as different items.  Even if at minimum it's just an indicator of how MANY different contacts you think you're registering, that's better than the blind faith model.  If I 404 your bulk reg request, you could fall back to individual registrations.

 

That’s not a bad idea (sending the number of contacts), but I’m worried it will cause more issues than it solves, by having false positives/negatives. And I definitely would not want a PBX automatically reverting to individual Registrations if it gets a mismatch.

As an aside on the rteg-event piece: I believe the idea with doing the reg-event subscription was it would be in bulk as well – i.e., one Subscription, which sends you one Notify with all the contacts in it.

 

-hadriel 

_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini


_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini

--------------040407080403070903030500-- From christer.holmberg@ericsson.com Tue Apr 6 10:15:51 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4A03A6803 for ; Tue, 6 Apr 2010 10:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTsZjahVqypI for ; Tue, 6 Apr 2010 10:15:50 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E47703A67DF for ; Tue, 6 Apr 2010 10:15:49 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-fb-4bbb6c426474 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id BF.8E.23740.24C6BBB4; Tue, 6 Apr 2010 19:15:46 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 6 Apr 2010 19:15:45 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Tue, 6 Apr 2010 19:15:45 +0200 From: Christer Holmberg To: "bruno.chatras@orange-ftgroup.com" , "richard@shockey.us" , "dean.willis@softarmor.com" , "md3135@att.com" , "bernard_aboba@hotmail.com" , "martini@ietf.org" Date: Tue, 6 Apr 2010 19:14:17 +0200 Thread-Topic: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) Thread-Index: AcrUGPUllJsWtr48TgKAWCE3kZno2wBQViXgAA0tRXAAALPbsAAGsSBe Message-ID: References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us>, <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 17:15:51 -0000 Hi, I have no problem with an option-tag either, if that's an issue. Regards, Christer ________________________________________ From: martini-bounces@ietf.org [martini-bounces@ietf.org] On Behalf Of brun= o.chatras@orange-ftgroup.com [bruno.chatras@orange-ftgroup.com] Sent: Tuesday, April 06, 2010 5:40 PM To: richard@shockey.us; dean.willis@softarmor.com; md3135@att.com; bernard_= aboba@hotmail.com; martini@ietf.org Subject: Re: [martini] The IETF versus reality (was: problems wit= hexisting SIP trunking solutions) Adding an option tag is fine. That's what the shaken draft was bascially do= ing on top of the IMS solution. The problem I have is that the gin draft g= oes beyond that. BC > -----Message d'origine----- > De : Richard Shockey [mailto:richard@shockey.us] > Envoy=E9 : mardi 6 avril 2010 15:47 > =C0 : CHATRAS Bruno RD-CORE-ISS; dean.willis@softarmor.com; > md3135@att.com; bernard_aboba@hotmail.com; martini@ietf.org > Objet : RE: [martini] The IETF versus reality (was: problems > withexisting SIP trunking solutions) > > > 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: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of > bruno.chatras@orange-ftgroup.com > Sent: Tuesday, April 06, 2010 4:23 AM > To: dean.willis@softarmor.com; md3135@att.com; > bernard_aboba@hotmail.com; martini@ietf.org > 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. > > > -----Message d'origine----- > > De : martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] De la part de Dean Willis > Envoy=E9 : > > dimanche 4 avril 2010 19:04 =C0 : DOLLY, MARTIN C (ATTLABS); Bernard > > Aboba; martini@ietf.org Objet : Re: [martini] The IETF > versus reality > > (was: problems withexisting SIP trunking solutions) > > > > Are you saying that the IMS solution is what the service providers > > need? > > > > > > > > "DOLLY, MARTIN C (ATTLABS)" 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 > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini= From christer.holmberg@ericsson.com Tue Apr 6 10:26:01 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4EF23A67B2 for ; Tue, 6 Apr 2010 10:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[AWL=1.966, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFazaoGHnUrh for ; Tue, 6 Apr 2010 10:26:00 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D07823A68C6 for ; Tue, 6 Apr 2010 10:25:54 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-1b-4bbb6e9f08a0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id B7.E0.23532.F9E6BBB4; Tue, 6 Apr 2010 19:25:51 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 6 Apr 2010 19:25:51 +0200 From: Christer Holmberg To: "DOLLY, MARTIN C (ATTLABS)" , Adam Roach , "bruno.chatras@orange-ftgroup.com" Date: Tue, 6 Apr 2010 19:24:22 +0200 Thread-Topic: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) Thread-Index: AcrVm4PF0T6vobDfRlevhYeYUWDEswAAFZcgAASJSVo= Message-ID: References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com>, <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 17:26:02 -0000 Hi Adam, >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." If that was the case I don't think people would be here arguing for the IMS= solution. Regards, Christer On 4/6/10 09:40, Apr 6, bruno.chatras@orange-ftgroup.com wrote: > 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 > > >> -----Message d'origine----- >> De : Richard Shockey [mailto:richard@shockey.us] >> Envoy=E9 : mardi 6 avril 2010 15:47 >> =C0 : CHATRAS Bruno RD-CORE-ISS; dean.willis@softarmor.com; >> md3135@att.com; bernard_aboba@hotmail.com; martini@ietf.org >> Objet : RE: [martini] The IETF versus reality (was: problems >> withexisting SIP trunking solutions) >> >> >> 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: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of >> bruno.chatras@orange-ftgroup.com >> Sent: Tuesday, April 06, 2010 4:23 AM >> To: dean.willis@softarmor.com; md3135@att.com; >> bernard_aboba@hotmail.com; martini@ietf.org >> 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. >> >> >>> -----Message d'origine----- >>> De : martini-bounces@ietf.org >>> [mailto:martini-bounces@ietf.org] De la part de Dean Willis >>> >> Envoy=E9 : >> >>> dimanche 4 avril 2010 19:04 =C0 : DOLLY, MARTIN C (ATTLABS); Bernard >>> Aboba; martini@ietf.org Objet : Re: [martini] The IETF >>> >> versus reality >> >>> (was: problems withexisting SIP trunking solutions) >>> >>> Are you saying that the IMS solution is what the service providers >>> need? >>> >>> >>> >>> "DOLLY, MARTIN C (ATTLABS)" 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 >>> >>> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> >> >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini= From adam@nostrum.com Tue Apr 6 10:34:50 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB8E3A69B8 for ; Tue, 6 Apr 2010 10:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGGMMwVDYmRy for ; Tue, 6 Apr 2010 10:34:50 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 297533A68C2 for ; Tue, 6 Apr 2010 10:33:14 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o36HX81Y056582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2010 12:33:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBB7054.7040808@nostrum.com> Date: Tue, 06 Apr 2010 12:33:08 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "DOLLY, MARTIN C (ATTLABS)" References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: martini@ietf.org Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 17:34:51 -0000 On 4/6/10 10:18, Apr 6, DOLLY, MARTIN C (ATTLABS) wrote: > 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 spencer@wonderhamster.org Tue Apr 6 10:45:54 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A371E3A69EF for ; Tue, 6 Apr 2010 10:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3czs-3NMgpw for ; Tue, 6 Apr 2010 10:45:53 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id CE6253A677D for ; Tue, 6 Apr 2010 10:45:52 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MgM9u-1OCs523QKk-00NHYc; Tue, 06 Apr 2010 13:45:47 -0400 Message-ID: <6FAA0E4C0764425FB80BF4386ADC4317@china.huawei.com> From: "Spencer Dawkins" To: "Adam Roach" , "Hadriel Kaplan" References: <00cb01cad59c$36507f20$150510ac@CORPORATE.VOX.NET> <430FC6BDED356B4C8498F634416644A91A79F3CE46@mail> <430FC6BDED356B4C8498F634416644A91A79F3CE54@mail> <4BBB68D3.7040903@nostrum.com> Date: Tue, 6 Apr 2010 12:45:34 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1E38_01CAD587.0C94F3B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+cyEEmfW/ddBilAeKMGrQQ7Pt37k7cDAoAqeA DxULSLuFybHddoS7ZS6q7JRpX+/saYfH14L4mwvDkou5plsxLz dNYPUZib6xIdx2Uk3uYIaXzEEBF0G6EKTJepZYZXew= Cc: martini@ietf.org Subject: Re: [martini] Request for SSP perspective X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 17:45:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1E38_01CAD587.0C94F3B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Adam, Yes, that's what I was thinking exactly - thanks for translating! Spencer ----- Original Message -----=20 From: Adam Roach=20 To: Hadriel Kaplan=20 Cc: Spencer Dawkins ; Tyler Parkin ; martini@ietf.org=20 Sent: Tuesday, April 06, 2010 12:01 PM Subject: Re: [martini] Request for SSP perspective If I may be so bold as to extrapolate from what Spencer said -- I read = his suggestion to mean you would include a count and/or hash of the = E.164 numbers in the range. If the SSP is doing other database magic for = operational or efficiency reasons, that's just fine -- but it doesn't = need to be visible on the wire. I think the hash approach is actually quite clever, as it completely = solves the half of the problem dealing with provisioning mismatches. /a On 4/6/10 11:55, Apr 6, Hadriel Kaplan wrote:=20 Actually my concern was more that I think I'm registering 500 AoR's, = but unbeknownst to me in the reg-DB it's (correctly) instantiated as 501 = or 499 or a regex wildcard or who knows what, and I get back the number = "501" or "499" or "1" - even though it's actually all correct/right. -hadriel -------------------------------------------------------------------------= --- From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 Sent: Tuesday, April 06, 2010 12:49 PM To: Hadriel Kaplan; Tyler Parkin; martini@ietf.org Subject: Re: [martini] Request for SSP perspective As an individual contributor... I'm not any happier about the current "say nothing" behavior than = Tyler is. The question is, how much can the endpoints actually say to = each other about what's being registered. My hangup on sending lists of AoRs back and forth has been = completely on the basis of MTU size restrictions, and concerns about = whether TCP could be successfully used, either as primary transport or = as fallback. If these concerns are real, wishing that they could be = overcome isn't helpful - we need to either overcome them or try = something else. I could be talked into sending a count of AoRs expected to be = registered/actually registered in both directions. If other people share = Hadriel's concerns about false positives (my 500 AoRs aren't your 500 = AoRs), I could be talked into sending a hash of the AoRs in both = directions - if these don't match, knowing about that mismatch could be = helpful as well. If we required TCP, we'd be having a different discussion, and = SIPconnect strongly prefers TCP, but I've gotten no encouragement that = this would be acceptable in the IETF, so haven't pursued it further. Thoughts? Spencer, as individual contributor ----- Original Message -----=20 From: Hadriel Kaplan=20 To: Tyler Parkin ; martini@ietf.org=20 Sent: Tuesday, April 06, 2010 11:31 AM Subject: Re: [martini] Request for SSP perspective Hi Tyler, Comments inline. -------------------------------------------------------------------------= - From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] = On Behalf Of Tyler Parkin Sent: Tuesday, April 06, 2010 11:17 AM To: martini@ietf.org Subject: [martini] Request for SSP perspective Looking at the list, it seems there is a large (and vocal) group = of PBX representatives and a smaller (and nearly inaudible) list of = SSP's. I guess what I'd like to see as an SSP is for other SSP's to = speak up and constructively point out the issues they see with GIN, if = not propose solutions. =20 For a while it looked like there was one SSP saying "Looks good" = and another saying "wait a sec...," but it seems that now there are a = couple more voicing concerns about the proposal. As an example, as an SSP my concerns are the following (and I've = repeatedly argued these in the past): 1) Interoperability with PBX's that don't support implicit reg = (I'm in favor of the options tag) [hsk] Cool, we have agreement on at least one point. J 2) Not defining the behavior of middle boxes's and proxy's along = with the registrars, even generically. I've got a half dozen major = players in my network; I don't care if your PBX supports implicit reg, = if either my SBC (or yours) or my registrar don't interop in the same = fashion your PBX will never be able to bulk reg with me. Do you mean define what they should do at a policy layer? That's = really hard to do in the IETF, because it's basically specific to every = deployment. If you mean at a protocol layer, then I think we have the proxy = and Registrar behavior in the draft. For B2BUA's, if what you're = worried about is the contact-URI stuff we could put some helpful = guidance in the draft. What in particular are you concerned about? 3) Not indicating some sort of contact based registration status. = If you think you're implicitly registering 400 telnos and I think you're = registering 395, we've got a mismatch. I don't want a PBX sending me = notify's and subscribe's every 15 seconds for a number I don't have on = that account. Alternatively, if you think you're registering 395 and I = think you have 400, you don't want me sending you calls for numbers you = don't have configured (and I sure as heck don't want to lol). There's = been griping about provisioning, and how it's not included in MARTINI, = but I see provisioning and some agreement on registered contacts as = different items. Even if at minimum it's just an indicator of how MANY = different contacts you think you're registering, that's better than the = blind faith model. If I 404 your bulk reg request, you could fall back = to individual registrations. That's not a bad idea (sending the number of contacts), but I'm = worried it will cause more issues than it solves, by having false = positives/negatives. And I definitely would not want a PBX automatically = reverting to individual Registrations if it gets a mismatch. As an aside on the rteg-event piece: I believe the idea with doing = the reg-event subscription was it would be in bulk as well - i.e., one = Subscription, which sends you one Notify with all the contacts in it. -hadriel=20 -------------------------------------------------------------------------= - _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini =20 ------=_NextPart_000_1E38_01CAD587.0C94F3B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, Adam,
 
Yes, that's what I was thinking exactly - thanks for = translating!
 
Spencer
----- Original Message -----
From:=20 Adam = Roach
Cc: Spencer Dawkins ; Tyler = Parkin ; martini@ietf.org=20
Sent: Tuesday, April 06, 2010 = 12:01=20 PM
Subject: Re: [martini] Request = for SSP=20 perspective

If I may be so bold as to extrapolate from what Spencer = said --=20 I read his suggestion to mean you would include a count and/or hash of = the=20 E.164 numbers in the range. If the SSP is doing other database magic = for=20 operational or efficiency reasons, that's just fine -- but it doesn't = need to=20 be visible on the wire.

I think the hash approach is actually = quite=20 clever, as it completely solves the half of the problem dealing with=20 provisioning mismatches.

/a

On 4/6/10 11:55, Apr 6, = Hadriel=20 Kaplan wrote:=20

Actually = my concern=20 was more that I think I=92m registering 500 AoR=92s, but unbeknownst = to me in=20 the reg-DB it=92s (correctly) instantiated as 501 or 499 or a regex = wildcard=20 or who knows what, and I get back the number =93501=94 or =93499=94 = or =931=94 =96 even=20 though it=92s actually all = correct/right.

-hadriel

From:=20 Spencer Dawkins [mailto:spencer@wonderhamster.or= g]=20
Sent: Tuesday, = April 06,=20 2010 12:49 PM
To: = Hadriel=20 Kaplan; Tyler Parkin; martini@ietf.org
Subject: Re: [martini] = Request for SSP=20 perspective

As an individual=20 contributor...

I'm not any happier about the current "say = nothing"=20 behavior than Tyler is. The question is, how = much can the=20 endpoints actually say to each other about what's being=20 registered.

My hangup on sending lists of AoRs back = and forth=20 has been completely on the basis of MTU size restrictions, and = concerns=20 about whether TCP could be successfully used, either as primary = transport or=20 as fallback. If these concerns are real, wishing that they could be = overcome=20 isn't helpful - we need to either overcome them or try something=20 else.

I could be talked into sending a count of = AoRs=20 expected to be registered/actually registered in both directions. If = other=20 people share Hadriel's concerns about false positives (my 500 AoRs = aren't=20 your 500 AoRs), I could be talked into sending a hash of the AoRs in = both=20 directions - if these don't match, knowing about that mismatch could = be=20 helpful as well.

If we required TCP, we'd be having a = different=20 discussion, and SIPconnect strongly prefers TCP, but I've gotten no=20 encouragement that this would be acceptable in the IETF, so haven't = pursued=20 it further.

Thoughts?

Spencer, as individual=20 contributor

----- Original = Message -----=20

From: Hadriel Kaplan=20

To: Tyler Parkin ; martini@ietf.org=20

Sent:=20 Tuesday, April 06, 2010 11:31 = AM

Subject: Re:=20 [martini] Request for SSP = perspective

Hi=20 Tyler,

Comments=20 inline=85

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org<= /A>]=20 On Behalf Of Tyler = Parkin
Sent: = Tuesday,=20 April 06, 2010 11:17 AM
To: martini@ietf.org
Subject: [martini] Request = for SSP=20 perspective

Looking at the list, = it seems=20 there is a large (and vocal) group of PBX representatives and a = smaller=20 (and nearly inaudible) list of SSP's.  I guess what I'd like = to see=20 as an SSP is for other SSP's to speak up and constructively point = out the=20 issues they see with GIN, if not propose solutions. =20

For a while it = looked like=20 there was one SSP saying "Looks good" and another saying "wait a = sec...,"=20 but it seems that now there are a couple more voicing concerns = about the=20 proposal.

As an example, as an = SSP my=20 concerns are the following (and I've repeatedly argued these in = the=20 past):

1) Interoperability = with PBX's=20 that don't support implicit reg (I'm in favor of the options=20 tag)

[hsk] = Cool, we=20 have agreement on at least one point. J

2) Not defining the = behavior=20 of middle boxes's and proxy's along with the registrars, even=20 generically.  I've got a half dozen major players in my = network; I=20 don't care if your PBX supports implicit reg, if either my SBC (or = yours)=20 or my registrar don't interop in the same fashion your PBX will = never be=20 able to bulk reg with me.

Do you = mean=20 define what they should do at a policy layer? That=92s really hard = to do in=20 the IETF, because it=92s basically specific to every=20 deployment.

If you = mean at a=20 protocol layer, then I think we have the proxy = and=20 Registrar behavior in the draft.  For B2BUA=92s, if what = you=92re worried=20 about is the contact-URI stuff we could put some helpful guidance = in the=20 draft.  What in particular are you concerned=20 about?

3) Not indicating = some sort of=20 contact based registration status.  If you think you're = implicitly=20 registering 400 telnos and I think you're registering 395, we've = got a=20 mismatch.  I don't want a PBX sending me notify's and = subscribe's=20 every 15 seconds for a number I don't have on that = account. =20 Alternatively, if you think you're registering 395 and I think you = have=20 400, you don't want me sending you calls for numbers you don't = have=20 configured (and I sure as heck don't want to lol).  There's = been=20 griping about provisioning, and how it's not included in MARTINI, = but I=20 see provisioning and some agreement on registered contacts as = different=20 items.  Even if at minimum it's just an indicator of how MANY = different contacts you think you're registering, that's better = than the=20 blind faith model.  If I 404 your bulk reg request, you could = fall=20 back to individual = registrations.

That=92s not a bad idea = (sending the=20 number of contacts), but I=92m worried it will cause more issues = than it=20 solves, by having false positives/negatives. And I definitely = would not=20 want a PBX automatically reverting to individual Registrations if = it gets=20 a mismatch.

As an aside on the = rteg-event piece:=20 I believe the idea with doing the reg-event subscription was it = would be=20 in bulk as well =96 i.e., one Subscription, which sends you one = Notify with=20 all the contacts in it.

-hadriel 

_______________________________________________
martini=20 mailing list
martini@ietf.org
https://www.ietf.o= rg/mailman/listinfo/martini

= 

_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/martini
  =

------=_NextPart_000_1E38_01CAD587.0C94F3B0-- From BLINDSAY@nortel.com Tue Apr 6 10:55:11 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0743A67B3 for ; Tue, 6 Apr 2010 10:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfL57BLa0xzR for ; Tue, 6 Apr 2010 10:55:01 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 99BA73A6841 for ; Tue, 6 Apr 2010 10:55:00 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o36HsFB14672; Tue, 6 Apr 2010 17:54:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD5B2.2B3F0CEB" Date: Tue, 6 Apr 2010 13:54:14 -0400 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141D1EA007@zcarhxm1.corp.nortel.com> In-Reply-To: <6FAA0E4C0764425FB80BF4386ADC4317@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Request for SSP perspective Thread-Index: AcrVsQdJ2WrZl2H4Suuq5hRjDxVxXQAABDpg References: <00cb01cad59c$36507f20$150510ac@CORPORATE.VOX.NET> <430FC6BDED356B4C8498F634416644A91A79F3CE46@mail> <430FC6BDED356B4C8498F634416644A91A79F3CE54@mail><4BBB68D3.7040903@nostrum.com> <6FAA0E4C0764425FB80BF4386ADC4317@china.huawei.com> From: "Brian Lindsay" To: "Spencer Dawkins" , "Adam Roach" , "Hadriel Kaplan" Cc: martini@ietf.org Subject: Re: [martini] Request for SSP perspective X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 17:55:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD5B2.2B3F0CEB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Spencer/all, =20 Regarding detection of provisioning mismatches, my thought is this should be out of scope since the provisioning mechanism itself is out of scope of MARTINI. (It seems hard to argue that we need a way to detect mismatches in the MARTINI mechanism when the provisioning mechanism itself could be robust and prevent/preclude/minimize mismatches). =20 Thanks Brian ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Tuesday, April 06, 2010 1:46 PM To: Adam Roach; Hadriel Kaplan Cc: martini@ietf.org Subject: Re: [martini] Request for SSP perspective Hi, Adam, =20 Yes, that's what I was thinking exactly - thanks for translating! =20 Spencer ----- Original Message -----=20 From: Adam Roach =20 To: Hadriel Kaplan =20 Cc: Spencer Dawkins ; Tyler Parkin ; martini@ietf.org=20 Sent: Tuesday, April 06, 2010 12:01 PM Subject: Re: [martini] Request for SSP perspective If I may be so bold as to extrapolate from what Spencer said -- I read his suggestion to mean you would include a count and/or hash of the E.164 numbers in the range. If the SSP is doing other database magic for operational or efficiency reasons, that's just fine -- but it doesn't need to be visible on the wire. =09 I think the hash approach is actually quite clever, as it completely solves the half of the problem dealing with provisioning mismatches. =09 /a =09 On 4/6/10 11:55, Apr 6, Hadriel Kaplan wrote:=20 =09 Actually my concern was more that I think I'm registering 500 AoR's, but unbeknownst to me in the reg-DB it's (correctly) instantiated as 501 or 499 or a regex wildcard or who knows what, and I get back the number "501" or "499" or "1" - even though it's actually all correct/right. =09 -hadriel =09 =09 =09 ________________________________ From: Spencer Dawkins [mailto:spencer@wonderhamster.org] Sent: Tuesday, April 06, 2010 12:49 PM To: Hadriel Kaplan; Tyler Parkin; martini@ietf.org Subject: Re: [martini] Request for SSP perspective =09 As an individual contributor... =09 I'm not any happier about the current "say nothing" behavior than Tyler is. The question is, how much can the endpoints actually say to each other about what's being registered. =09 My hangup on sending lists of AoRs back and forth has been completely on the basis of MTU size restrictions, and concerns about whether TCP could be successfully used, either as primary transport or as fallback. If these concerns are real, wishing that they could be overcome isn't helpful - we need to either overcome them or try something else. =09 I could be talked into sending a count of AoRs expected to be registered/actually registered in both directions. If other people share Hadriel's concerns about false positives (my 500 AoRs aren't your 500 AoRs), I could be talked into sending a hash of the AoRs in both directions - if these don't match, knowing about that mismatch could be helpful as well. =09 If we required TCP, we'd be having a different discussion, and SIPconnect strongly prefers TCP, but I've gotten no encouragement that this would be acceptable in the IETF, so haven't pursued it further. =09 Thoughts? =09 Spencer, as individual contributor ----- Original Message -----=20 From: Hadriel Kaplan =20 To: Tyler Parkin ; martini@ietf.org=20 Sent: Tuesday, April 06, 2010 11:31 AM Subject: Re: [martini] Request for SSP perspective =09 Hi Tyler, Comments inline... =09 =09 ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Tyler Parkin Sent: Tuesday, April 06, 2010 11:17 AM To: martini@ietf.org Subject: [martini] Request for SSP perspective =09 Looking at the list, it seems there is a large (and vocal) group of PBX representatives and a smaller (and nearly inaudible) list of SSP's. I guess what I'd like to see as an SSP is for other SSP's to speak up and constructively point out the issues they see with GIN, if not propose solutions. =20 =09 For a while it looked like there was one SSP saying "Looks good" and another saying "wait a sec...," but it seems that now there are a couple more voicing concerns about the proposal. =09 As an example, as an SSP my concerns are the following (and I've repeatedly argued these in the past): =09 1) Interoperability with PBX's that don't support implicit reg (I'm in favor of the options tag) =09 [hsk] Cool, we have agreement on at least one point. :-) =09 2) Not defining the behavior of middle boxes's and proxy's along with the registrars, even generically. I've got a half dozen major players in my network; I don't care if your PBX supports implicit reg, if either my SBC (or yours) or my registrar don't interop in the same fashion your PBX will never be able to bulk reg with me. =09 Do you mean define what they should do at a policy layer? That's really hard to do in the IETF, because it's basically specific to every deployment. If you mean at a protocol layer, then I think we have the proxy and Registrar behavior in the draft. For B2BUA's, if what you're worried about is the contact-URI stuff we could put some helpful guidance in the draft. What in particular are you concerned about? =09 =09 3) Not indicating some sort of contact based registration status. If you think you're implicitly registering 400 telnos and I think you're registering 395, we've got a mismatch. I don't want a PBX sending me notify's and subscribe's every 15 seconds for a number I don't have on that account. Alternatively, if you think you're registering 395 and I think you have 400, you don't want me sending you calls for numbers you don't have configured (and I sure as heck don't want to lol). There's been griping about provisioning, and how it's not included in MARTINI, but I see provisioning and some agreement on registered contacts as different items. Even if at minimum it's just an indicator of how MANY different contacts you think you're registering, that's better than the blind faith model. If I 404 your bulk reg request, you could fall back to individual registrations. =09 That's not a bad idea (sending the number of contacts), but I'm worried it will cause more issues than it solves, by having false positives/negatives. And I definitely would not want a PBX automatically reverting to individual Registrations if it gets a mismatch. As an aside on the rteg-event piece: I believe the idea with doing the reg-event subscription was it would be in bulk as well - i.e., one Subscription, which sends you one Notify with all the contacts in it. =09 -hadriel=20 =09 ________________________________ _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini =09 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini =20 ------_=_NextPart_001_01CAD5B2.2B3F0CEB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Spencer/all,
 
    Regarding detection of = provisioning=20 mismatches, my thought is = this should=20 be out of scope since the provisioning mechanism itself is out of = scope of=20 MARTINI. (It seems hard to argue that we need a way to detect mismatches = in the=20 MARTINI mechanism when the provisioning mechanism itself could be robust = and=20 prevent/preclude/minimize mismatches).
 
    = Thanks
      =20 Brian
From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf Of Spencer=20 Dawkins
Sent: Tuesday, April 06, 2010 1:46 PM
To: = Adam=20 Roach; Hadriel Kaplan
Cc: martini@ietf.org
Subject: = Re:=20 [martini] Request for SSP perspective

Hi, Adam,
 
Yes, that's what I was thinking exactly - thanks for = translating!
 
Spencer
----- Original Message -----
From:=20 Adam = Roach
Cc: Spencer Dawkins ; Tyler = Parkin ; martini@ietf.org=20
Sent: Tuesday, April 06, 2010 = 12:01=20 PM
Subject: Re: [martini] Request = for SSP=20 perspective

If I may be so bold as to extrapolate from what Spencer = said --=20 I read his suggestion to mean you would include a count and/or hash of = the=20 E.164 numbers in the range. If the SSP is doing other database magic = for=20 operational or efficiency reasons, that's just fine -- but it doesn't = need to=20 be visible on the wire.

I think the hash approach is actually = quite=20 clever, as it completely solves the half of the problem dealing with=20 provisioning mismatches.

/a

On 4/6/10 11:55, Apr 6, = Hadriel=20 Kaplan wrote:=20

Actually = my concern=20 was more that I think I’m registering 500 AoR’s, but = unbeknownst to me in=20 the reg-DB it’s (correctly) instantiated as 501 or 499 or a = regex wildcard=20 or who knows what, and I get back the number “501” or = “499” or “1” – even=20 though it’s actually all = correct/right.

-hadriel

From:=20 Spencer Dawkins [mailto:spencer@wonderhamster.or= g]=20
Sent: Tuesday, = April 06,=20 2010 12:49 PM
To: = Hadriel=20 Kaplan; Tyler Parkin; martini@ietf.org
Subject: Re: [martini] = Request for SSP=20 perspective

As an individual=20 contributor...

I'm not any happier about the current "say = nothing"=20 behavior than Tyler is. The question is, how = much can the=20 endpoints actually say to each other about what's being=20 registered.

My hangup on sending lists of AoRs back = and forth=20 has been completely on the basis of MTU size restrictions, and = concerns=20 about whether TCP could be successfully used, either as primary = transport or=20 as fallback. If these concerns are real, wishing that they could be = overcome=20 isn't helpful - we need to either overcome them or try something=20 else.

I could be talked into sending a count of = AoRs=20 expected to be registered/actually registered in both directions. If = other=20 people share Hadriel's concerns about false positives (my 500 AoRs = aren't=20 your 500 AoRs), I could be talked into sending a hash of the AoRs in = both=20 directions - if these don't match, knowing about that mismatch could = be=20 helpful as well.

If we required TCP, we'd be having a = different=20 discussion, and SIPconnect strongly prefers TCP, but I've gotten no=20 encouragement that this would be acceptable in the IETF, so haven't = pursued=20 it further.

Thoughts?

Spencer, as individual=20 contributor

----- Original = Message -----=20

From: Hadriel Kaplan=20

To: Tyler Parkin ; martini@ietf.org=20

Sent:=20 Tuesday, April 06, 2010 11:31 = AM

Subject: Re:=20 [martini] Request for SSP = perspective

Hi=20 Tyler,

Comments=20 inline…

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org<= /A>]=20 On Behalf Of Tyler = Parkin
Sent: = Tuesday,=20 April 06, 2010 11:17 AM
To: martini@ietf.org
Subject: [martini] Request = for SSP=20 perspective

Looking at the list, = it seems=20 there is a large (and vocal) group of PBX representatives and a = smaller=20 (and nearly inaudible) list of SSP's.  I guess what I'd like = to see=20 as an SSP is for other SSP's to speak up and constructively point = out the=20 issues they see with GIN, if not propose solutions. =20

For a while it = looked like=20 there was one SSP saying "Looks good" and another saying "wait a = sec...,"=20 but it seems that now there are a couple more voicing concerns = about the=20 proposal.

As an example, as an = SSP my=20 concerns are the following (and I've repeatedly argued these in = the=20 past):

1) Interoperability = with PBX's=20 that don't support implicit reg (I'm in favor of the options=20 tag)

[hsk] = Cool, we=20 have agreement on at least one point. J

2) Not defining the = behavior=20 of middle boxes's and proxy's along with the registrars, even=20 generically.  I've got a half dozen major players in my = network; I=20 don't care if your PBX supports implicit reg, if either my SBC (or = yours)=20 or my registrar don't interop in the same fashion your PBX will = never be=20 able to bulk reg with me.

Do you = mean=20 define what they should do at a policy layer? That’s really = hard to do in=20 the IETF, because it’s basically specific to every=20 deployment.

If you = mean at a=20 protocol layer, then I think we have the proxy = and=20 Registrar behavior in the draft.  For B2BUA’s, if what = you’re worried=20 about is the contact-URI stuff we could put some helpful guidance = in the=20 draft.  What in particular are you concerned=20 about?

3) Not indicating = some sort of=20 contact based registration status.  If you think you're = implicitly=20 registering 400 telnos and I think you're registering 395, we've = got a=20 mismatch.  I don't want a PBX sending me notify's and = subscribe's=20 every 15 seconds for a number I don't have on that = account. =20 Alternatively, if you think you're registering 395 and I think you = have=20 400, you don't want me sending you calls for numbers you don't = have=20 configured (and I sure as heck don't want to lol).  There's = been=20 griping about provisioning, and how it's not included in MARTINI, = but I=20 see provisioning and some agreement on registered contacts as = different=20 items.  Even if at minimum it's just an indicator of how MANY = different contacts you think you're registering, that's better = than the=20 blind faith model.  If I 404 your bulk reg request, you could = fall=20 back to individual = registrations.

That’s not a bad idea = (sending the=20 number of contacts), but I’m worried it will cause more = issues than it=20 solves, by having false positives/negatives. And I definitely = would not=20 want a PBX automatically reverting to individual Registrations if = it gets=20 a mismatch.

As an aside on the = rteg-event piece:=20 I believe the idea with doing the reg-event subscription was it = would be=20 in bulk as well – i.e., one Subscription, which sends you = one Notify with=20 all the contacts in it.

-hadriel 

_______________________________________________
martini=20 mailing list
martini@ietf.org
https://www.ietf.o= rg/mailman/listinfo/martini

= 

_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/martini
  =

------_=_NextPart_001_01CAD5B2.2B3F0CEB-- From adam@nostrum.com Tue Apr 6 11:19:47 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6276F28C183 for ; Tue, 6 Apr 2010 11:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvcKvfB+XgnL for ; Tue, 6 Apr 2010 11:19:45 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id DAAAE3A6AF2 for ; Tue, 6 Apr 2010 11:15:50 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o36IFaFI059901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2010 13:15:37 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBB7A48.7050801@nostrum.com> Date: Tue, 06 Apr 2010 13:15:36 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Christer Holmberg References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com>, <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 18:19:47 -0000 On 4/6/10 12:24, Apr 6, Christer Holmberg wrote: > Hi Adam, > >> 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." >> > 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@hotmail.com Tue Apr 6 12:30:06 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22E128C0D0 for ; Tue, 6 Apr 2010 12:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.433 X-Spam-Level: X-Spam-Status: No, score=0.433 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9reL4KApBoz for ; Tue, 6 Apr 2010 12:30:05 -0700 (PDT) Received: from blu0-omc3-s6.blu0.hotmail.com (blu0-omc3-s6.blu0.hotmail.com [65.55.116.81]) by core3.amsl.com (Postfix) with ESMTP id 6E15728C108 for ; Tue, 6 Apr 2010 12:27:20 -0700 (PDT) Received: from BLU137-W31 ([65.55.116.72]) by blu0-omc3-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 12:27:18 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_32ce2dfd-f2d4-44ec-9ff4-b2509c872bbd_" X-Originating-IP: [131.107.0.74] From: Bernard Aboba To: , Date: Tue, 6 Apr 2010 12:27:17 -0700 Importance: Normal In-Reply-To: <007b01cad58f$aaff0600$00fd1200$@us> References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr>, <007b01cad58f$aaff0600$00fd1200$@us> MIME-Version: 1.0 X-OriginalArrivalTime: 06 Apr 2010 19:27:18.0439 (UTC) FILETIME=[2BD5EB70:01CAD5BF] Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 19:30:06 -0000 --_32ce2dfd-f2d4-44ec-9ff4-b2509c872bbd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 i= n favor of large scale enterprise deployments which=2C at least in North Amer= ica are not the majority of customers." [BA] I assume you're referring to "branch office" deployments in enterprise= =2C rather than central campuses (which are more likely to use static mode= =2C in my experience). Out of curiosity=2C what features of the ETSI solu= tion would tend to appeal to those customers? Personally=2C I have not see= n any "branch office" deployments using the ETSI solution=2C mostly variant= s of SIPconnect 1.0.=20 = --_32ce2dfd-f2d4-44ec-9ff4-b2509c872bbd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Richard Shockey said:

"Well actually the so called IMS solution has = its own interoperability
problems caused by the same poor design the ori= ginal implicit registration
process had. The problem is the registration= proxy does not have sufficient
information on what the message is to of= ten process correctly which is why
after 16 months or so of looking at t= he 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 sti= ll hold that the ETSI solution has a bias in
favor of large scale enterp= rise deployments which=2C at least in North America
are not the majority= of customers."

[BA] I assume you're referring to "branch office" de= ployments in enterprise=2C rather than central campuses (which are more lik= ely to use static mode=2C in my experience). =3B =3B Out of curiosi= ty=2C what features of the ETSI solution would tend to appeal to those cust= omers? =3B Personally=2C I have not seen any "branch office" deployment= s using the ETSI solution=2C mostly variants of SIPconnect 1.0.
= = --_32ce2dfd-f2d4-44ec-9ff4-b2509c872bbd_-- From christer.holmberg@ericsson.com Tue Apr 6 13:47:41 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30653A6A37 for ; Tue, 6 Apr 2010 13:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.926 X-Spam-Level: X-Spam-Status: No, score=-4.926 tagged_above=-999 required=5 tests=[AWL=1.673, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vECwxhyzBMN9 for ; Tue, 6 Apr 2010 13:47:40 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 624AF3A698E for ; Tue, 6 Apr 2010 13:46:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-35-4bbb9da451d9 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D6.EC.23532.4AD9BBB4; Tue, 6 Apr 2010 22:46:28 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 6 Apr 2010 22:46:28 +0200 From: Christer Holmberg To: Adam Roach Date: Tue, 6 Apr 2010 22:46:27 +0200 Thread-Topic: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) Thread-Index: AcrVtSrMMmpdZqodTPONibI6il9kxwAEYAf2 Message-ID: References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com>, <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> , <4BBB7A48.7050801@nostrum.com> In-Reply-To: <4BBB7A48.7050801@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 20:47:41 -0000 Hi, >>> 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 lis= t >>> 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." >>> >> 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. [Yes, I did read the text at the end of your e-mail before writing the foll= owing] 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 bu= ild upon IETF standards. >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. The ETSI/3GPP solution has been has been part of the discussion more or les= s 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 [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 adam@nostrum.com Tue Apr 6 15:05:54 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01B393A68A4 for ; Tue, 6 Apr 2010 15:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzcyVR7J3XUm for ; Tue, 6 Apr 2010 15:05:53 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 14E0B3A699A for ; Tue, 6 Apr 2010 15:05:49 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o36M1YpF076571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Apr 2010 17:01:34 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBBAF3E.2080400@nostrum.com> Date: Tue, 06 Apr 2010 17:01:34 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Christer Holmberg References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com>, <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> , <4BBB7A48.7050801@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 22:05:54 -0000 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 trac@tools.ietf.org Tue Apr 6 15:10:35 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2910A3A69AA for ; Tue, 6 Apr 2010 15:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLCdqED5YDGT for ; Tue, 6 Apr 2010 15:10:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D6E5B3A6933 for ; Tue, 6 Apr 2010 15:10:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NzGyN-0007AB-DS; Tue, 06 Apr 2010 15:10:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com, francois.audet@skype.net X-Trac-Project: martini Date: Tue, 06 Apr 2010 22:10:15 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/25 Message-ID: <066.4c051f23c1899cccfe7d75c77c3b0ff6@tools.ietf.org> X-Trac-Ticket-ID: 25 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, francois.audet@skype.net, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #25: Sections 7.1-7.5 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 22:10:37 -0000 #25: Sections 7.1-7.5 --------------------------------------+------------------------------------- Reporter: francois.audet@… | Owner: adam@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Keywords: --------------------------------------+------------------------------------- I had a quick look at draft-roach-martini-gin-01, and specifically at sections 7.1, 7.3, 7.4, 7.5. I don't believe that it makes any sense to have sections 7.3 (on Outbound), 7.4 (on Path) and section 7.5 (Service route) as separate sections. In particular, I feel the topic of outbound is really intertwined with section 7.1 (GRUU). Section 7.1 talks first about Self-made GRUUs (7.1.1) and then Anonymous GRUUs (7.1.2). When I read this section, it feels very theoretical to me (as it is crafted on the GRUU specification). The second paragraph of 7.1.2.1 attempts to explain when a self-made GRUU is not appropriate, but it is not easy to follow. Rather, it seems to me that we should think about what is our target audience for this specification: who will be deploying this? For example, it seems to me that lots of PBXs will be deployed behind a NAT/FW. This points to the use of Outbound. Furthermore, the fact that many virtual end-users are effectively using the same registration, it seems to me that a good high-availability mechanism (multiple signaling connections) is required, in case a connection fails. Again, this points to using Outbound. In other words, the questions the reader will have is more likely to be "Am I using this behind a NAT/FW?" and "Do I need redundant signaling connections?", rather than "Do I want to use a self-made GRUU?" or "Do I want an anonymous public GRUU?". I would therefore rewrite section 7.1 to talk about the topology of the deployment first. In the more common deployment model, this will imply Outbound (which includes support for Path, and the +sip.instance). Sections 7.3-7.5 can then be eliminated. The use of the "self-made" GRUUs will be restricted to the case of "I'm not behind a NAT/FW", and "I don't need multiple signaling connections". PS: I really don't see much to be said about Service routes. [BA] Posted by Francois on March 23, 2010: http://www.ietf.org/mail-archive/web/martini/current/msg01025.html -- Ticket URL: martini From bernard_aboba@hotmail.com Tue Apr 6 16:13:08 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166B43A6A2E for ; Tue, 6 Apr 2010 16:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.361 X-Spam-Level: X-Spam-Status: No, score=0.361 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5edAJe+92Dd for ; Tue, 6 Apr 2010 16:13:06 -0700 (PDT) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by core3.amsl.com (Postfix) with ESMTP id 2D85C3A6905 for ; Tue, 6 Apr 2010 16:13:06 -0700 (PDT) Received: from BLU137-W6 ([65.55.111.71]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 16:13:04 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_6987e2d0-d1e1-4d3d-86f7-590a4f68b0e1_" X-Originating-IP: [68.178.109.244] From: Bernard Aboba To: Date: Tue, 6 Apr 2010 16:13:03 -0700 Importance: Normal In-Reply-To: <4BBBAF3E.2080400@nostrum.com> References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com>, <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> , <4BBB7A48.7050801@nostrum.com> , <4BBBAF3E.2080400@nostrum.com> MIME-Version: 1.0 X-OriginalArrivalTime: 06 Apr 2010 23:13:04.0388 (UTC) FILETIME=[B5D9B440:01CAD5DE] Cc: martini@ietf.org Subject: Re: [martini] The IETF versus reality X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 23:13:08 -0000 --_6987e2d0-d1e1-4d3d-86f7-590a4f68b0e1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Adam Roach said: =20 "You missed my point. I'll rephrase what I was trying to say: if we're=20 just re-publishing someone else's mechanism as-is=2C then all the work in=20 DISPATCH and all the work in DREGS was a terrible waste of time. If the=20 problem is already solved and working=2C then we didn't (and don't) need=20 to do anything." =20 [BA] Believe me=2C if there were any easy way out of the mess we're curren= tly in=2C we'd have taken it by now. I'd be one of the first people to arg= ue for the documentation of widely deployed protocols (regardless of flaws)= . If that had been a viable approach in this case=2C SIPconnect 1.0 would = have been a rousing success and SIPconnect 1.1 would be done by now. =20 =20 The formation of MARTINI WG was made necessary by the reality that multiple= mechanisms were already deployed=2C each with their own set of issues=2C b= ut none of the variants seemed to have gotten to critical mass. SIPconnect= 1.1 contained one of those variants=2C but so many ballot issues were rais= ed about exactly how it would work (and if it would work)=2C that after mon= ths and months of discussion by at lots and lots of people=2C the issue was= brought to the IETF.=20 =20 At this point=2C we're well beyond assertions like "the dogs SHOULD like th= e dogfood=2C look how nutritious it is!" or "the dogs will eat the dogfood = if you put an IETF stamp on it." In general=2C "IETF" doesn't mean much to= a dog=2C they go by smell and taste. A number of varieties have been put = out=2C the dogs have either refused to eat=2C or in some cases=2C have gott= en sick and misbehaved in various ways after tasting it. =20 =20 = --_6987e2d0-d1e1-4d3d-86f7-590a4f68b0e1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Adam Roach said:
 =3B
"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=2C then all the work in <= BR>DISPATCH and all the work in DREGS was a terrible waste of time. If the =
problem is already solved and working=2C then we didn't (and don't) nee= d
to do anything."
 =3B
[BA] =3B Believe me=2C if there were any easy way out of the mess we're= currently in=2C we'd have taken it by now. =3B I'd be one of the first= people to argue for the documentation of widely deployed =3Bprotocols = (regardless of flaws). =3B If =3Bthat had been a viable approach in= this case=2C SIPconnect 1.0 would have been a rousing success and SIPconne= ct 1.1 would be done by now. =3B
 =3B
The formation of MARTINI WG was made necessary by the reality that multiple= mechanisms were already deployed=2C each with their own set of issues=2C b= ut none of the variants seemed to have gotten to critical mass. =3B SIP= connect 1.1 contained one of those variants=2C but so many ballot issues we= re raised about exactly how it would work (and if it would work)=2C that af= ter months and months of discussion by at lots and lots of people=2C the is= sue was brought to the IETF.
 =3B
At this point=2C we're well beyond assertions like "the dogs SHOULD like th= e dogfood=2C look how nutritious it is!" or "the dogs will eat the dogfood = if you put an IETF stamp on it." =3B In general=2C "IETF" doesn't mean = much to a dog=2C they go by smell and taste. =3B A number of varieties = have been put out=2C the dogs have either refused to eat=2C or in some case= s=2C have gotten sick and misbehaved in various ways after tasting it.
 =3B
 =3B
= --_6987e2d0-d1e1-4d3d-86f7-590a4f68b0e1_-- From trac@tools.ietf.org Tue Apr 6 17:27:12 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758603A672F for ; Tue, 6 Apr 2010 17:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.282 X-Spam-Level: X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z58i6bGtorY6 for ; Tue, 6 Apr 2010 17:27:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A4D593A62C1 for ; Tue, 6 Apr 2010 17:27:11 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NzJ6q-0005Ot-B1; Tue, 06 Apr 2010 17:27:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens.com X-Trac-Project: martini Date: Wed, 07 Apr 2010 00:27:07 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/26 Message-ID: <067.48dbda15e6bbc9a3dee4b07c97a7459f@tools.ietf.org> X-Trac-Ticket-ID: 26 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #26: Domain routing limitations X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 00:27:12 -0000 #26: Domain routing limitations ---------------------------------------+------------------------------------ Reporter: jon.peterson@… | Owner: john.elwell@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ From the IETF 77 meeting minutes: Jon Peterson: It would be useful to explain somewhere why support of private numbers wasn’t included as a requirement. John Elwell: The issue is that if we open it up to support AOR forms beyond E.164 numbers, then we have to support domain routing. And domain routing has issues such as ambiguity of ownership, say when an enterprise user AOR has the domain of the SSP. These issues can be bypassed if we limit AORs to E.164-only, since E.164 numbers are globally unique and therefore routing is unambiguous. Jon Peterson: That information should be explicitly documented then. Bernard Aboba: Where do we add that text? Req’s doc or GIN draft? Jon Peterson: It should be documented in the requirements doc. Add something about domain routing concerns. (Agreed**) -- Ticket URL: martini From trac@tools.ietf.org Tue Apr 6 17:28:51 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1273A63D3 for ; Tue, 6 Apr 2010 17:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.321 X-Spam-Level: X-Spam-Status: No, score=-102.321 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+cFRvuGGAmE for ; Tue, 6 Apr 2010 17:28:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 04CB13A62C1 for ; Tue, 6 Apr 2010 17:28:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NzJ8S-0007aW-RC; Tue, 06 Apr 2010 17:28:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens.com, bernard_aboba@hotmail.com X-Trac-Project: martini Date: Wed, 07 Apr 2010 00:28:48 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/26#comment:1 Message-ID: <076.978edf803c0239411562acc9219643e0@tools.ietf.org> References: <067.48dbda15e6bbc9a3dee4b07c97a7459f@tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <067.48dbda15e6bbc9a3dee4b07c97a7459f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens.com, bernard_aboba@hotmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #26: Domain routing limitations X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 00:28:51 -0000 #26: Domain routing limitations ---------------------------------------+------------------------------------ Reporter: jon.peterson@… | Owner: john.elwell@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Comment(by bernard_aboba@…): Keith Drage: E.164 numbers can be carried either in a Tel URI or a SIP URI containing a Tel URI. In the case of SIP URI there is still a domain name, so how does that avoid the problem you raised? Gonzalo Camarillo: The requirements document needs to be explicit – when referring to E.164 numbers are we talking about Tel or SIP URIs? (Agreed**) -- Ticket URL: martini From trac@tools.ietf.org Tue Apr 6 17:38:55 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21CAD3A6A5A for ; Tue, 6 Apr 2010 17:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.352 X-Spam-Level: X-Spam-Status: No, score=-102.352 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J7fCxNTiWZQ for ; Tue, 6 Apr 2010 17:38:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5E8733A6A48 for ; Tue, 6 Apr 2010 17:38:54 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NzJIC-0007rl-7Z; Tue, 06 Apr 2010 17:38:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Wed, 07 Apr 2010 00:38:52 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/27 Message-ID: <073.0ef4965837f22ad1a2542e2ddf89134d@tools.ietf.org> X-Trac-Ticket-ID: 27 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #27: Add/remove AORs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 00:38:55 -0000 #27: Add/remove AORs ---------------------------------------------+------------------------------ Reporter: christer.holmberg@… | Owner: adam@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------------+------------------------------ From the IETF 77 minutes: Christer Holmberg: Once a PBX is registered can I add/remove AORs from the list? Adam Roach: There is a hole in the current GIN text related to this. Will resolve in the next version. -- Ticket URL: martini From bernard_aboba@hotmail.com Tue Apr 6 18:06:29 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2054C3A6876 for ; Tue, 6 Apr 2010 18:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.871 X-Spam-Level: X-Spam-Status: No, score=0.871 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuDsPWx1J9X4 for ; Tue, 6 Apr 2010 18:06:10 -0700 (PDT) Received: from blu0-omc2-s15.blu0.hotmail.com (blu0-omc2-s15.blu0.hotmail.com [65.55.111.90]) by core3.amsl.com (Postfix) with ESMTP id 61B073A62C1 for ; Tue, 6 Apr 2010 18:06:10 -0700 (PDT) Received: from BLU137-DS10 ([65.55.111.72]) by blu0-omc2-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 18:06:07 -0700 X-Originating-IP: [68.178.109.244] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 6 Apr 2010 18:06:50 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01CAD5B3.EEB21170" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrV7prFoGwV20CuTfCQhwya5gwOrQ== Content-Language: en-us X-OriginalArrivalTime: 07 Apr 2010 01:06:07.0237 (UTC) FILETIME=[80BE5350:01CAD5EE] Subject: [martini] Draft IETF 77 minutes (cleaned up) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 01:06:29 -0000 ------=_NextPart_000_0033_01CAD5B3.EEB21170 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI WG Minutes IETF 77 Anaheim, California USA Working Group Home Page Jabber room: martini at jabber.ietf.org Chairs Bernard Aboba Spencer Dawkins Minute taker: David Hancock d.hancock@cablelabs.com Meeting Slot I Monday, March 22, 2010 1 PM - 3 PM Pacific Time Palos Verdes Room 1. Preliminaries (Bernard & Spencer) Topic Draft Time Discussion Leader Preliminaries Blue Sheets Note Takers Note Well Agenda bash Document Status none 10 min chairs Chair Slides Bernard Aboba: Encourage people to submit comments regarding GIN to the issue tracker. Keith Drage: . Not only tracker entries are comments -- anything that appears on the mailing list should also be considered a comment. . Group is moving too fast to allow sufficient review time, especially given 3GPP meeting conflicts. Bernard Aboba: In the WG last call and Call for Adoption notices, comments were solicited on the mailing list as well as in the issue tracker. So we don't require that comments be submitted via the Issue tracker. With respect to milestones, we're actually behind with respect to the milestones in the Charter by at least two months. Keith Drage: Due to meeting conflicts, etc, did not have an opportunity to contribute due to the schedule. Cullen Jennings: Words of praise for the current MARTINI process/progress. 2. Requirements (John Elwell & Hadriel Kaplan) Requirements http://tools.ietf.org/html/draft-elwell-martini-reqs 40 min John Elwell Requirements Slides John Elwell's presentation on "Recent Issues" (slides 2 thru 5) . John Elwell: Issue # 16 - requirement for AOR extensibility is still open Keith Drage: Believe there should be a requirement to support private numbers John Elwell: Yes, issue 16 is being re-opened so solution can support extensibility. Bernard Aboba: What does extensibility mean - does it mean a new version of GIN (e.g. a different option tag)? Adam Roach: It means that GIN would not constrain the support of additional AOR forms. Hadriel Kaplan: The requirements doc should only state what is required, and we've always said we're not required to support private numbers. Jon Peterson: It would be useful to explain somewhere why support of private numbers wasn't included as a requirement. John Elwell: The issue is that if we open it up to support AOR forms beyond E.164 numbers, then we have to support domain routing. And domain routing has issues such as ambiguity of ownership, say when an enterprise user AOR has the domain of the SSP. These issues can be bypassed if we limit AORs to E.164-only, since E.164 numbers are globally unique and therefore routing is unambiguous. Jon Peterson: That information should be explicitly documented then. Bernard Aboba: Where do we add that text? Req's doc or GIN draft? Jon Peterson: It should be documented in the requirements doc. Add something about domain routing concerns. (Agreed**) Keith Drage: E.164 numbers can be carried either in a Tel URI or a SIP URI containing a Tel URI. In the case of SIP URI there is still a domain name, so how does that avoid the problem you raised? Gonzalo Camarillo: The requirements document needs to be explicit - when referring to E.164 numbers are we talking about Tel or SIP URIs? (Agreed**) John Elwell introduces new issue - should there be a requirement to support Private numbers? John Elwell: Even without an explicit requirement, it may just work. Paul Kyzivat: What is the real requirement? Is it to support service numbers like 911, 411, etc? They aren't E.164 numbers, and there isn't general agreement on how they're encoded as local numbers. John Elwell: This requirement is about support of private numbers for PBX extensions. Adopting this requirement would mean that the SSP network must be able to route a call between PBXs serving a single enterprise based on the private number of the called enterprise user (not the public E.164-based AOR). Keith Drage: Agreed. In addition this requirement includes the case where an enterprise has both PBX and Centrex users that want to call each other via abbreviated dialing. Adam Roach: Can we assume that there is a mechanism to route inter-PBX calls directly, thus bypassing the SSP network? If we require the SSP to route these private calls then it breaks enterprise user mobility. Keith Drage: Unfortunately, the bypass option doesn't work for the Centrex-to-PBX case. Adam Roach: If we have to support this, then it'll destroy user mobility. Hadriel Kaplan: We don't have to support Centrex. Rather, Centrex is an example showing why the SSP has to support private number routing. Hadriel thinks it will actually work, and doesn't see the problem Adam has with mobility. Also, Hadriel doesn't think this needs to be a requirement. Spencer Dawkins (as WG chair): Let's take this to the list. Hadriel Kaplan's presentation on "Current Problems" (slides 6 thru 8) . Hadriel Kaplan: One of the problems with current mechanisms is there is no explicit indicator that this registration (from the SIP-PBX) is any different than normal RC3261 registration. Keith Drage: Instead of using an indicator, current solutions like the one defined for IMS use configured data in the SSP to indicate that the register is coming from a PBX. Even if we add an option tag, the SSP will still need some configuration data to indicate this is a PBX registration, so it isn't clear how the addition of the option tag adds any value. Request from Hadriel asking Keith to submit to list why SSP configuration data is still needed when an indicator is used. Richard Shockey: The need for an option tag was the primary driver for bringing this problem to MARTINI. 3. Solution Updates 3.1 Adam Roach - GIN draft presentation MARTINI with Globally Identifiable Numbers http://tools.ietf.org/html/draft-roach-martini-gin 30 min Adam Roach GIN Slides Adam Roach: The risk in adding a Proxy-Require option tag is that proxies in the signaling chain that don't need to do anything special with this extension but don't recognize the option-tag will reject the request. The risk is mitigated in this case since a REGISTER request traverses a tightly constrained set of proxies that are owned by and under the control of the serving SSP. Dean Willis: Is the Proxy-Require option tag or the new contact parameter required by intermediaries? Adam Roach: It's both -- the option tag says I'm using a new parameter in my Contact header, and the 'bnc' parameter is that parameter. You could have multiple contacts, only some of which had the 'bnc' parameter. Adam Roach: One of the restrictions of using this mechanism is that the PBX can't put anything in the user portion of the Contact URI. Therefore, the PBX will have to use Contact URI parameters to carry any data that it wants returned in subsequent incoming requests. Adam Roach: There is an open issue regarding use of the user=phone parameter in the REGISTER Contact header. The issue being -- is it valid for the PBX to include a "user=phone" parameter in a contact URI that has no user portion? Here are the resolution options. 1. Keep mechanism as-is (i.e., let PBX choose whether it needs "user=phone") 2. Forbid "user=phone" on "bnc" URIs, and specify that the SSP must add "user=phone" 3. Forbid "user=phone" altogether Henning Schulzrinne: The solution should be close to what is implemented. Do what is pragmatic and simple, and avoid creating new error conditions; i.e. a vote for option 1. Christer Holmberg: Are you allowed to have "user=phone" without a user part? John Elwell: Didn't understand that it was OK for the PBX not to include user=phone. Which means there's a 4th option - which is to require inclusion of user=phone. Hadriel Kaplan: There is talk of using new parameters instead of user=phone, such as user=fax. For example, the originator of a call wants to target the request to a FAX machine. Adam Roach: One solution for this would be to register FAX URIs with a separate REGISTER request. Paul Kyzivat: Has anyone actually proposed defining a user=fax parameter? If not, we could consider it out-of-scope. Hadriel Kaplan: Want to avoid having to open GIN up every time someone adds a new parameter, so we need to think about this. Bernard Aboba: Any other contact URI parameters added by the PBX need to be echoed back in subsequent requests. Jon Peterson: In this case the 'bnc' parameter is the most significant parameter carried in the Contact URI, and its presence should remove any confusion over the use and meaning of "user=phone" in the Contact URI (i.e., support for option-1). HUM - does group favor option-1? HUM results: in favor of option of #1. Keith Drage: Object to taking a HUM on something that isn't adopted as a WG item. Cullen Jennings: Believes the HUM is OK in this case - take the temperature of the room on a specific technical point to provide input to draft author. Keith Drage: Some service providers have voiced their opposition to the GIN solution on the list. Richard Shockey: Agreed, although there has also been support for GIN from cable operators. Adam Roach introduces new open issue - Is there a need to signal the list of enterprise phone numbers between PBX and SSP network? David Schwartz: Would it be possible to propose a mechanism without mandating it? Spencer Dawkins (as WG chair): Haven't seen people saying that we have to have this. Anyone who feels strongly that this is needed should write their own draft. It's not worth trying to solve this as part of GIN because of the "size of response" issue. Hadriel Kaplan: People that need this information have other ways to get it. Keith Drage: Need to understand the root requirement, since that may dictate what solution applies. For example, if the requirement is to provide a way for the SSP network to tell the PBX that an enterprise user is no longer registered, then an extension to the reg-event package may be a better solution. Jon Peterson: It may be odious (onerous?) to support this, but we should do it. If we decide to not to, then we need to put a warning in GIN that it isn't supported. Adam Roach: To be semantically consistent with the way REGISTER works today, the list would be communicated as part of REGISTER transaction. Any solution we come up with can probably be retrofitted on top of the GIN solution. John Elwell: Supports documenting the solution as a separate draft using a mechanism outside of registration (e.g., reg-event package). If we do use REGISTER, then put the list in the REGISTER request. Hadriel Kaplan: With the GIN solution you're registering a template, not the actual AORs. Martin Thompson: Could we use indirection to solve the response-size problem? Instead of sending the registered AORs in the response, send a pointer to them. Christer Holmberg: Once a PBX is registered can I add/remove AORs from the list? Adam Roach: There is a hole in the current GIN text related to this. Will resolve in the next version Dale Worley: Agree with Hadriel that GIN is registering a template. Therefore, if the SSP assigns a new number to an already-registered PBX, then it is immediately available for use, you don't have to wait for the next REGISTER. Adam Roach: New topic - Outbound, Service Route & Path need to be looked at with respect to GIN. Adam Roach: The intermediaries originally could assume that REGISTER was for the single AOR in the To: header. Are there any impacts or security concerns due to fact that now we're registering multiple AORs? Bernard Aboba: How many of these pending issues can we resolve by Friday? Could we spin anther version of the draft this week for review at the Friday meeting? Also, can we get volunteers to review potential impacts to Outbound, Service Route, and Path? Cullen: Ask Francois Audet to review the document relating to Outbound. Will contact Francois on this, and will work offline to get volunteers to look at Service Route and Path. Hadriel Kaplan: Request that MARTINI mandate support of Path. Adam Roach: If SIP-PBX wants to put an FQDN in the domain of the Contact URI, then it needs to support Path to convey PBX IP address. MARTINI WG Meeting Slot II Friday, March 26, 2010 1415 - 1515 Pacific Time California D 4. Preliminaries Topic Draft Time Discussion Leader Preliminaries Blue Sheets Note Takers Note Well Agenda bash Document Status none 10 min Chairs Chair Slides (Friday Session) 5. GIN Update GIN Update http://tools.ietf.org/html/draft-roach-martini-gin 10 min Adam Roach Adam Roach's presentation of new version of GIN draft: GIN Update Slides - Provided summary of updates. TRAC Issue #7-10 addressed in the -02 update. Need (external?) security analysis of interaction between Path, Outbound and Service Route with multiple AORs in a single REGISTER. Issue #14 requires fixes to examples. - No comments received so far relating to the -02 update (submitted yesterday). 6. Path and Service-Route Path and Service Route http://tools.ietf.org/html/draft-roach-martini-gin 10 min Dean Willis Dean Willis' presentation on security considerations on Path and Service-Route Path and Service Route 1. GIN effectively registers multiple AORs. 2. All AORs will have same path, Service-Route. 3. If Service-Route invokes registrar-side services, all users on PBX will get the same services invoked. Otherwise, it should "just work". There may be an issue between Service Route and Outbound Keith Drage: Service Route works for IMS implicit registration, which is different than the registration procedure proposed by GIN. Hadriel Kaplan: Although IMS and GIN registration procedures differ, they are the same with respect to Service Route; i.e., they are both registering multiple AORs with a single REGISER transaction. 7. Requirements Analysis Analysis of GIN against Requirements http://tools.ietf.org/html/draft-ietf-martini-reqs http://tools.ietf.org/html/draft-roach-martini-gin 30 min Adam Roach John Elwell John Elwell's presentation on evaluation of GIN according to requirements in MARTINI requirements draft Requirements Analysis Slides John Elwell: Requirement 17 duplicates Requirement 5 and will be removed from the requirements document. DES4 is difficult to quantify and a proposal has been made to remove it. Otherwise, GIN appears to satisfy all the requirements. Christer Holmberg: Has a problem with REQ16 - the GRUU requirement. Dale Worley: Clarified this requirement. It doesn't require support for GRUU, only that the solution should not constrain the PBX from assigning GRUUs to its UAs in the usual way. Paul Kyzivat: This requirement is also about addressing the fact that the SIP-PBX may not itself have a globally unique address, and therefore must get some help from the SSP network to provide a globally unique address. Dale Worley: must allow the SIP-PBX to provide the UAs with GRUUs as defined in the GRUU RFC. John Elwell: Please post clarifying updates to the list. 8. Discussion and Wrapup Wrapup - Hums and Next Steps None 10 min Chairs and ADs Adam Roach: What are the next steps on GIN? Bernard Aboba: We had a Call for Adoption on the GIN document, which ended on March 19, 2010. Adam Roach: We did? (looks at laptop). Oh yes! I forget about that. I even replied to the thread. Bernard Aboba: We will go over the replies to the Call for Adoption and will summarize the o ------=_NextPart_000_0033_01CAD5B3.EEB21170 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI WG Minutes

IETF 77

Anaheim, California USA

 

Working Group Home = Page

Jabber = room:  martini at jabber.ietf.org

Chairs
        Bernard Aboba <bernard_aboba@hotmail.com&g= t;
        Spencer Dawkins <spencer@wonderhamster.org&g= t;

Minute = taker:  David Hancock d.hancock@cablelabs.com<= /o:p>

 Meeting Slot I=

Monday, March 22, 2010

1 PM – 3 PM Pacific Time

Palos Verdes Room

1.    Preliminaries (Bernard & = Spencer)

Topic

Draft

Time

Discussion Leader

Preliminaries=

   =   Blue Sheets

   =   Note Takers

   =   Note Well

   =   Agenda bash

   =   Document Status

none

10  = min

chairs<= /span>

 

Chair= Slides

 

Bernard Aboba: Encourage people to submit comments regarding GIN to the issue = tracker.

 

Keith Drage:

·          Not only tracker entries are comments -- anything that appears on the = mailing list should also be considered a comment.

·          Group is moving too fast to allow sufficient review time, especially given = 3GPP meeting conflicts.

 

Bernard Aboba: In the WG last call and Call for Adoption notices, comments were solicited on the mailing list as well as in the issue tracker.  So = we don’t require that comments be submitted via the Issue = tracker.  With respect to milestones, we’re actually behind with respect to the milestones in the Charter by at least two months.

 

Keith Drage: Due to meeting conflicts, etc, did not have an opportunity to = contribute due to the schedule.

Cullen Jennings: Words of praise for the current MARTINI process/progress. =

2.    Requirements (John Elwell & Hadriel = Kaplan)

Requirements<= /o:p>

http://tool= s.ietf.org/html/draft-elwell-martini-reqs =

40 = min

John Elwell

 

Requirements = Slides

 

John Elwell’s presentation on “Recent Issues” (slides 2 = thru 5) …

 

John Elwell: Issue # 16 – requirement for AOR extensibility is still = open

Keith Drage: Believe there should be a requirement to support private = numbers

John Elwell: Yes, issue 16 is being re-opened so solution can support = extensibility.

Bernard Aboba: What does extensibility mean – does it mean a new version = of GIN (e.g. a different option tag)?

Adam Roach: It means that GIN would not constrain the support of additional = AOR forms.

Hadriel Kaplan: The requirements doc should only state what is required, and we’ve always said we’re not required to support private = numbers.

Jon Peterson: It would be useful to explain somewhere why support of private numbers wasn’t included as a requirement.

John Elwell: The issue is that if we open it up to support AOR forms beyond = E.164 numbers, then we have to support domain routing. And domain routing has = issues such as ambiguity of ownership, say when an enterprise user AOR has the = domain of the SSP. These issues can be bypassed if we limit AORs to E.164-only, = since E.164 numbers are globally unique and therefore routing is unambiguous. =

Jon Peterson: That information should be explicitly documented then. =

Bernard Aboba: Where do we add that text? Req’s doc or GIN draft? =

Jon Peterson: It should be documented in the requirements doc. Add something = about domain routing concerns. (Agreed**)

Keith Drage: E.164 numbers can be carried either in a Tel URI or a SIP URI = containing a Tel URI. In the case of SIP URI there is still a domain name, so how = does that avoid the problem you raised?

Gonzalo Camarillo: The requirements document needs to be explicit – when referring to E.164 numbers are we talking about Tel or SIP URIs? = (Agreed**)

John Elwell introduces new issue – should there be a requirement to = support Private numbers?

John Elwell: Even without an explicit requirement, it may just work. =

Paul Kyzivat: What is the real requirement?  Is it to support service = numbers like 911, 411, etc? They aren’t E.164 numbers, and there isn’t = general agreement on how they’re encoded as local numbers. =

John Elwell: This requirement is about support of private numbers for PBX extensions. Adopting this requirement would mean that the SSP network = must be able to route a call between PBXs serving a single enterprise based on the = private number of the called enterprise user (not the public E.164-based = AOR).

Keith Drage: Agreed. In addition this requirement includes the case where an enterprise has both PBX and Centrex users that want to call each other = via abbreviated dialing. 

Adam Roach: Can we assume that there is a mechanism to route inter-PBX calls directly, thus bypassing the SSP network? If we require the SSP to route = these private calls then it breaks enterprise user mobility. =

Keith Drage: Unfortunately, the bypass option doesn’t work for the Centrex-to-PBX case. 

Adam Roach: If we have to support this, then it’ll destroy user = mobility.

Hadriel Kaplan: We don’t have to support Centrex. Rather, Centrex is an = example showing why the SSP has to support private number routing. Hadriel = thinks it will actually work, and doesn’t see the problem Adam has with = mobility. Also, Hadriel doesn’t think this needs to be a requirement. =

Spencer Dawkins (as WG chair): Let’s take this to the = list.

 

Hadriel Kaplan’s presentation on “Current Problems” (slides 6 = thru 8) …

 

Hadriel Kaplan: One of the problems with current mechanisms is there is no = explicit indicator that this registration (from the SIP-PBX) is any different = than normal RC3261 registration.

Keith Drage: Instead of using an indicator, current solutions like the one = defined for IMS use configured data in the SSP to indicate that the register is = coming from a PBX. Even if we add an option tag, the SSP will still need some configuration data to indicate this is a PBX registration, so it = isn’t clear how the addition of the option tag adds any value. =

Request from Hadriel asking Keith to submit to list why SSP configuration data = is still needed when an indicator is used.

Richard Shockey: The need for an option tag was the primary driver for bringing = this problem to MARTINI.

 

3. Solution Updates

 

3.1           Adam Roach – GIN draft = presentation

MARTINI with Globally Identifiable Numbers

http://tools.= ietf.org/html/draft-roach-martini-gin

30  = min

Adam = Roach

 

GIN = Slides

 

Adam Roach: The risk in adding a Proxy-Require option tag is that proxies in = the signaling chain that don’t need to do anything special with this extension = but don’t recognize the option-tag will reject the request. The risk = is mitigated in this case since a REGISTER request traverses a tightly = constrained set of proxies that are owned by and under the control of the serving = SSP.

Dean Willis: Is the Proxy-Require option tag or the new contact parameter = required by intermediaries?

Adam Roach: It’s both -- the option tag says I’m using a new = parameter in my Contact header, and the ‘bnc’ parameter is that = parameter. You could have multiple contacts, only some of which had the = ‘bnc’ parameter.

Adam Roach: One of the restrictions of using this mechanism is that the PBX can’t put anything in the user portion of the Contact URI. = Therefore, the PBX will have to use Contact URI parameters to carry any data that it = wants returned in subsequent incoming requests.

 

Adam Roach: There is an open issue regarding use of the user=3Dphone = parameter in the REGISTER Contact header. The issue being -- is it valid for the PBX to = include a “user=3Dphone” parameter in a contact URI that has no user = portion? Here are the resolution options…

1. Keep mechanism as-is (i.e., let PBX choose whether it needs “user=3Dphone”)

2. Forbid “user=3Dphone” on “bnc” URIs, and specify = that the SSP must add “user=3Dphone”

3. Forbid “user=3Dphone” altogether  =

 

Henning Schulzrinne: The solution should be close to what is implemented. Do = what is pragmatic and simple, and avoid creating new error conditions; i.e. a = vote for option 1.

Christer Holmberg: Are you allowed to have “user=3Dphone” without a = user part?

John Elwell: Didn’t understand that it was OK for the PBX not to = include user=3Dphone. Which means there’s a 4th option – which is to = require inclusion of user=3Dphone.

Hadriel Kaplan: There is talk of using new parameters instead of user=3Dphone, = such as user=3Dfax. For example, the originator of a call wants to target the = request to a FAX machine.

Adam Roach: One solution for this would be to register FAX URIs with a = separate REGISTER request.

Paul Kyzivat: Has anyone actually proposed defining a user=3Dfax parameter? = If not, we could consider it out-of-scope.

Hadriel Kaplan: Want to avoid having to open GIN up every time someone adds a = new parameter, so we need to think about this.

Bernard Aboba: Any other contact URI parameters added by the PBX need to be = echoed back in subsequent requests.

Jon Peterson: In this case the ‘bnc’ parameter is the most = significant parameter carried in the Contact URI, and its presence should remove any confusion over the use and meaning of “user=3Dphone” in the = Contact URI (i.e., support for option-1).

 

HUM – does group favor option-1? HUM results: in favor of option of = #1.

 

Keith Drage: Object to taking a HUM on something that isn’t adopted as a = WG item.

Cullen Jennings: Believes the HUM is OK in this case – take the = temperature of the room on a specific technical point to provide input to draft = author.

Keith Drage: Some service providers have voiced their opposition to the GIN = solution on the list.

Richard Shockey: Agreed, although there has also been support for GIN from cable operators.

 

Adam Roach introduces new open issue – Is there a need to signal the = list of enterprise phone numbers between PBX and SSP = network?

 

David Schwartz: Would it be possible to propose a mechanism without mandating = it?

Spencer Dawkins (as WG chair): Haven’t seen people saying that we have to = have this. Anyone who feels strongly that this is needed should write their = own draft. It’s not worth trying to solve this as part of GIN because = of the “size of response” issue. 

Hadriel Kaplan: People that need this information have other ways to get it. =

Keith Drage: Need to understand the root requirement, since that may dictate = what solution applies. For example, if the requirement is to provide a way = for the SSP network to tell the PBX that an enterprise user is no longer = registered, then an extension to the reg-event package may be a better = solution.

Jon Peterson: It may be odious (onerous?) to support this, but we should do = it. If we decide to not to, then we need to put a warning in GIN that it = isn’t supported.

Adam Roach: To be semantically consistent with the way REGISTER works today, = the list would be  communicated as part of REGISTER transaction. Any = solution we come up with can probably be retrofitted on top of the GIN = solution.

John Elwell: Supports documenting the solution as a separate draft using a = mechanism outside of registration (e.g., reg-event package). If we do use = REGISTER, then put the list in the REGISTER request.

Hadriel Kaplan: With the GIN solution you’re registering a template, not = the actual AORs.

Martin Thompson: Could we use indirection to solve the response-size problem? = Instead of sending the registered AORs in the response, send a pointer to them. =

Christer Holmberg: Once a PBX is registered can I add/remove AORs from the = list?

Adam Roach: There is a hole in the current GIN text related to this. Will = resolve in the next version

Dale Worley: Agree with Hadriel that GIN is registering a template. = Therefore, if the SSP assigns a new number to an already-registered PBX, then it is immediately available for use, you don’t have to wait for the next REGISTER.

 

Adam Roach:  New topic – Outbound, Service Route & Path need = to be looked at with respect to GIN.

 

Adam Roach: The intermediaries originally could assume that REGISTER was for = the single AOR in the To: header. Are there any impacts or security concerns = due to fact that now we’re registering multiple = AORs?

Bernard Aboba: How many of these pending issues can we resolve by Friday? Could = we spin anther version of the draft this week for review at the Friday meeting? = Also, can we get volunteers to review potential impacts to Outbound, Service = Route, and Path?

Cullen:  Ask Francois Audet to review the document relating to Outbound. Will = contact Francois on this, and will work offline to get volunteers to look at = Service Route and Path.

Hadriel Kaplan: Request that MARTINI mandate support of Path.  =

Adam Roach: If SIP-PBX wants to put an FQDN in the domain of the Contact URI, = then it needs to support Path to convey PBX IP address.

 

MARTINI WG = Meeting Slot II

Friday, March 26, 2010

1415 - 1515 Pacific Time

California = D

4.    Preliminaries

 

Topic

Draft

Time

Discussion Leader

Preliminaries=

   =   Blue Sheets

   =  Note Takers

   =   Note Well

   =   Agenda bash

   =   Document Status

none

10  = min

Chairs =

 

 

Chair= Slides (Friday Session)

5.    GIN Update

GIN = Update

 http://tools.= ietf.org/html/draft-roach-martini-gin =

10 = min

Adam = Roach

 

Adam Roach’s presentation of new version of GIN = draft:

 

GIN Update Slides

 

-          Provided summary of updates.  TRAC Issue #7-10 addressed in the -02 = update. Need (external?) security analysis of interaction between Path, Outbound = and Service Route with multiple AORs in a single REGISTER. Issue #14 = requires fixes to examples.

-          No comments received so far relating to the -02 update = (submitted yesterday).

6.    Path and Service-Route

Path and Service Route

 http://tools.= ietf.org/html/draft-roach-martini-gin =

10 = min

Dean Willis

 

 

Dean Willis’ presentation on security considerations on Path and = Service-Route

 

Path = and Service Route

 

 

1. GIN effectively registers multiple AORs.

2. All AORs will have same path, Service-Route.

3. If Service-Route invokes registrar-side services, all users on PBX will = get the same services invoked.

 

Otherwise, it should “just work”.

 

There may be an issue between Service Route and Outbound

 

Keith Drage: Service Route works for IMS implicit registration, which is = different than the registration procedure proposed by GIN.

Hadriel Kaplan: Although IMS and GIN registration procedures differ, they are = the same with respect to Service Route; i.e., they are both registering multiple AORs = with a single REGISER transaction.

7.    Requirements Analysis

Analysis of GIN against Requirements

http://tools.= ietf.org/html/draft-ietf-martini-reqs

http://tools.= ietf.org/html/draft-roach-martini-gin

30  = min

Adam = Roach

John Elwell

 

John Elwell’s presentation on evaluation of GIN according to = requirements in MARTINI requirements draft

 

Requirements Analysis Slides

 

John Elwell: Requirement 17 duplicates Requirement 5 and will be removed from = the requirements document. DES4 is difficult to quantify and a proposal has = been made to remove it.  Otherwise, GIN appears to satisfy all the = requirements.

Christer Holmberg: Has a problem with REQ16 – the GRUU = requirement.

Dale Worley: Clarified this requirement.  It doesn’t require = support for GRUU, only that the solution should not constrain the PBX from assigning GRUUs = to its UAs in the usual way.

Paul Kyzivat: This requirement is also about addressing the fact that the = SIP-PBX may not itself have a globally unique address, and therefore must get = some help from the SSP network to provide a globally unique = address.

Dale Worley: must allow the SIP-PBX to provide the UAs with GRUUs as defined = in the GRUU RFC.

John Elwell: Please post clarifying updates to the = list.

 

8.    Discussion and Wrapup

Wrapup – Hums and Next Steps

None

10 = min

Chairs and ADs

 

Adam Roach:  What are the next steps on GIN?

Bernard Aboba:  We had a Call for Adoption on the GIN document, which ended = on March 19, 2010.

Adam Roach:  We did?  (looks at laptop).  Oh yes! I forget = about that.  I even replied to the thread.

Bernard Aboba:  We will go over the replies to the = Call for Adoption and will summarize the o

------=_NextPart_000_0033_01CAD5B3.EEB21170-- From ietf.hanserik@gmail.com Tue Apr 6 18:13:47 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166F93A6782 for ; Tue, 6 Apr 2010 18:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQiKfQpu9hJX for ; Tue, 6 Apr 2010 18:13:45 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 914E63A672F for ; Tue, 6 Apr 2010 18:13:44 -0700 (PDT) Received: by ewy24 with SMTP id 24so279740ewy.13 for ; Tue, 06 Apr 2010 18:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=tfKF7qOER5xdCUuqIIfEPTGUTGHtQ2piT2E7GXFhyD0=; b=kinMxjHaMZaGR773hEhrWrmBhIdJP5+pPWKfPIf9QUrCS4ylXm9SWUJ6XLsdsA0Fco ta+ohJ72UOdMvUFJS4f3ITR9Y5cwMUTFPVBkJCOwV121XZpRXEzP7Tl7OvpbiGnK7pF5 qQZvS5I/jSUzrsnLTLITP+IoBVjMG7NvRCzMQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XuuIfHNu8YU/iWGo+STjndNIutCup7GUya8ofLyZ5ESRAniTi01u9hiISQIKbFSLqF 2LN3ZmtCgIjpbwhWS0qlM6xPQHEi7JFJNdPWsAPfzDUKKAJgei7y8jk0xsYFsRIIxrcv LIcQ4MxPSnrDeXU7PM5rd3H/npp/dqj137xx4= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Tue, 6 Apr 2010 18:13:36 -0700 (PDT) In-Reply-To: <4BBBAF3E.2080400@nostrum.com> References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com> <4BBBAF3E.2080400@nostrum.com> Date: Wed, 7 Apr 2010 03:13:36 +0200 Received: by 10.213.57.138 with SMTP id c10mr1473434ebh.58.1270602816480; Tue, 06 Apr 2010 18:13:36 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Adam Roach Content-Type: multipart/alternative; boundary=00c09ffb4e2386e63604839b455f Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 01:13:47 -0000 --00c09ffb4e2386e63604839b455f Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > 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 > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > --00c09ffb4e2386e63604839b455f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think most people are willing to investigate and accept technical fixes a= s long as there arguments are taken seriously and can agree that issues rai= sed are really issues.

Now where are the issues "the routing a= nd URI issues in the ETSI/3GPP solution" enumerated? Then we can addre= ss 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 trunk= ing variant, that the PBX supports. That would solve the main issues that a= re presented in the requirements document. I have nothing against such a fr= amework also describing the GIN variant as one of the alternatives. If it i= s so good for pure SIP proxy implementations, why not?=A0

There is another alternative that is that martini only creates a SIP fo= rum specific solution, nothing wrong with that. But then please state it in= the title and make this an informative draft.=A0 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 wall= ed garden solutions...

/Hans Erik van Elburg

O= n Wed, Apr 7, 2010 at 12:01 AM, Adam Roach <adam@nostrum.com> wrote:
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 les= s 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, p= eople think that slapping an options tag into the ETSI/3GPP solution will m= agically 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 U= RI issues in the ETSI/3GPP solution, it's a non-starter. I fear, howeve= r, that the very property that the advocates of that solution hold most dea= r is quite precisely the property that makes it run afoul core SIP routing = behavior.

/a

_______________________________________________
martini mailing list
martini@ietf.org<= br> https://www.ietf.org/mailman/listinfo/martini

--00c09ffb4e2386e63604839b455f-- From md3135@att.com Tue Apr 6 18:27:43 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD12D3A62C1 for ; Tue, 6 Apr 2010 18:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.004 X-Spam-Level: X-Spam-Status: No, score=-106.004 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDNfi2nxBDtW for ; Tue, 6 Apr 2010 18:27:42 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 622893A63D3 for ; Tue, 6 Apr 2010 18:27:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-15.tower-167.messagelabs.com!1270603657!21463343!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 8829 invoked from network); 7 Apr 2010 01:27:38 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Apr 2010 01:27:38 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o371ROW5027524; Tue, 6 Apr 2010 21:27:24 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o371RItk027482; Tue, 6 Apr 2010 21:27:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD5F1.7DD3676E" Date: Tue, 6 Apr 2010 21:27:30 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4E72@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] The IETF versus reality (was: problems withexistingSIP trunking solutions) Thread-Index: AcrV75gmSWL32FGnT2a9hqRYRQvV4wAAeXRT From: "DOLLY, MARTIN C (ATTLABS)" To: , Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality (was: problems withexistingSIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 01:27:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD5F1.7DD3676E Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWVkDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206IG1hcnRp bmktYm91bmNlc0BpZXRmLm9yZyA8bWFydGluaS1ib3VuY2VzQGlldGYub3JnPiANClRvOiBBZGFt IFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPiANCkNjOiBiZXJuYXJkX2Fib2JhQGhvdG1haWwuY29t IDxiZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tPjsgbWFydGluaUBpZXRmLm9yZyA8bWFydGluaUBp ZXRmLm9yZz4gDQpTZW50OiBUdWUgQXByIDA2IDIxOjEzOjM2IDIwMTANClN1YmplY3Q6IFJlOiBb bWFydGluaV0gVGhlIElFVEYgdmVyc3VzIHJlYWxpdHkgKHdhczogcHJvYmxlbXMgd2l0aGV4aXN0 aW5nU0lQIHRydW5raW5nIHNvbHV0aW9ucykgDQoNCg0KSSB0aGluayBtb3N0IHBlb3BsZSBhcmUg d2lsbGluZyB0byBpbnZlc3RpZ2F0ZSBhbmQgYWNjZXB0IHRlY2huaWNhbCBmaXhlcyBhcyBsb25n IGFzIHRoZXJlIGFyZ3VtZW50cyBhcmUgdGFrZW4gc2VyaW91c2x5IGFuZCBjYW4gYWdyZWUgdGhh dCBpc3N1ZXMgcmFpc2VkIGFyZSByZWFsbHkgaXNzdWVzLiANCg0KTm93IHdoZXJlIGFyZSB0aGUg aXNzdWVzICJ0aGUgcm91dGluZyBhbmQgVVJJIGlzc3VlcyBpbiB0aGUgRVRTSS8zR1BQIHNvbHV0 aW9uIiBlbnVtZXJhdGVkPyBUaGVuIHdlIGNhbiBhZGRyZXNzIHRoZW0gb25lIGJ5IG9uZS4gQXBw YXJlbnRseSBzb21lIHBlb3BsZSBoYXZlIGpvaW5lZCB0aGUgZGlzY3Vzc2lvbiBhZnRlciB0aGUg d2cgYWxyZWFkeSBodW1tZWQgdG8gc29tZSBwcmVsaW1pbmFyeSBjb25jbHVzaW9uLCBpdCBkb2Vz IG5vdCBoYXJtIHRvIHJlaXRlcmF0ZSB0aG9zZS4gSWYgdGhlc2UgYXJlIGFsbCByZWFsbHkgaXNz dWVzIEkgZ3Vlc3Mgd2UgYXJlIGFsbCBsZWFkIHRvIHRoZSBzYW1lIGNvbmNsdXNpb24gaW4gc29t ZSB3YXkuDQoNCkFub3RoZXIgd2F5IGZvcndhcmQgY291bGQgYmUgdGhhdCBtYXJ0aW5pIHJlY29n bmlzZXMgdGhhdCBpdHMgbWFpbiB0YXNrIGlzIHRoZSBkZWZpbml0aW9uIG9mIGEgU0lQIHByb3Rv Y29sIGV4dGVuc2lvbiBmb3Igc2lnbmFsbGluZyB0aGUgU0lQIHRydW5raW5nIHZhcmlhbnQsIHRo YXQgdGhlIFBCWCBzdXBwb3J0cy4gVGhhdCB3b3VsZCBzb2x2ZSB0aGUgbWFpbiBpc3N1ZXMgdGhh dCBhcmUgcHJlc2VudGVkIGluIHRoZSByZXF1aXJlbWVudHMgZG9jdW1lbnQuIEkgaGF2ZSBub3Ro aW5nIGFnYWluc3Qgc3VjaCBhIGZyYW1ld29yayBhbHNvIGRlc2NyaWJpbmcgdGhlIEdJTiB2YXJp YW50IGFzIG9uZSBvZiB0aGUgYWx0ZXJuYXRpdmVzLiBJZiBpdCBpcyBzbyBnb29kIGZvciBwdXJl IFNJUCBwcm94eSBpbXBsZW1lbnRhdGlvbnMsIHdoeSBub3Q/ICANCg0KVGhlcmUgaXMgYW5vdGhl ciBhbHRlcm5hdGl2ZSB0aGF0IGlzIHRoYXQgbWFydGluaSBvbmx5IGNyZWF0ZXMgYSBTSVAgZm9y dW0gc3BlY2lmaWMgc29sdXRpb24sIG5vdGhpbmcgd3Jvbmcgd2l0aCB0aGF0LiBCdXQgdGhlbiBw bGVhc2Ugc3RhdGUgaXQgaW4gdGhlIHRpdGxlIGFuZCBtYWtlIHRoaXMgYW4gaW5mb3JtYXRpdmUg ZHJhZnQuICBUaGlzIHdpbGwgYWxsb3cgeW91IHRvIGRvIGEgcXVpY2sgYW5kIGV4cGVkaWVudCBz cGVjaWZpY2F0aW9uIGFuZCBwZW9wbGUgd2lsbCBsZXQgeW91IGRvLiBUaGF0cyBob3cgb3RoZXIg U0RPJ3MgYWxzbyBuZWVkIHRvIGRvIHRoZWlyIGV4dGVuc2lvbnMsIGFzIHRoZXkgYXJlIGJ1aWxk aW5nIHdhbGxlZCBnYXJkZW4gc29sdXRpb25zLi4uDQoNCi9IYW5zIEVyaWsgdmFuIEVsYnVyZw0K DQoNCk9uIFdlZCwgQXByIDcsIDIwMTAgYXQgMTI6MDEgQU0sIEFkYW0gUm9hY2ggPGFkYW1Abm9z dHJ1bS5jb20+IHdyb3RlOg0KDQoNCglPbiA0LzYvMTAgMTU6NDYsIEFwciA2LCBDaHJpc3RlciBI b2xtYmVyZyB3cm90ZToNCgkNCg0KCQlUaGUgRVRTSS8zR1BQIHNvbHV0aW9uIGhhcyBiZWVuIGhh cyBiZWVuIHBhcnQgb2YgdGhlIGRpc2N1c3Npb24gbW9yZSBvciBsZXNzIGFsbCB0aGUgd2F5IGZy b20gdGhlIGJlZ2lubmluZyBvZiB0aGUgd29yaywgc28gSSBkb24ndCBpdCdzIGZhaXIgdGhhdCBp dCBoYXMgbm93IHN1ZGRlbmx5IGNhbWUgdXAsIGFuZCB0aGVyZWZvciB3ZSBoYXZlIHdhc3RlZCBv dXIgdGltZS4NCgkJDQoNCg0KCVlvdSBtaXNzZWQgbXkgcG9pbnQuIEknbGwgcmVwaHJhc2Ugd2hh dCBJIHdhcyB0cnlpbmcgdG8gc2F5OiBpZiB3ZSdyZSBqdXN0IHJlLXB1Ymxpc2hpbmcgc29tZW9u ZSBlbHNlJ3MgbWVjaGFuaXNtIGFzLWlzLCB0aGVuIGFsbCB0aGUgd29yayBpbiBESVNQQVRDSCBh bmQgYWxsIHRoZSB3b3JrIGluIERSRUdTIHdhcyBhIHRlcnJpYmxlIHdhc3RlIG9mIHRpbWUuIElm IHRoZSBwcm9ibGVtIGlzIGFscmVhZHkgc29sdmVkIGFuZCB3b3JraW5nLCB0aGVuIHdlIGRpZG4n dCAoYW5kIGRvbid0KSBuZWVkIHRvIGRvIGFueXRoaW5nLg0KCQ0KCUkgdGhpbmsgZGlzY3Vzc2lv biBvZiB0aGUgSU1TIHNvbHV0aW9uIGlzIHBlcmZlY3RseSByZWFzb25hYmxlLCBhcyBsb25nIGFz IHBlb3BsZSBhcmUgd2lsbGluZyB0byBpbnZlc3RpZ2F0ZSBhbmQgYWNjZXB0IHRlY2huaWNhbCBm aXhlcyB0byB0aGUgaXNzdWVzIHRoYXQgaGF2ZSBiZWVuIHJhaXNlZCBvbiB0aGUgbGlzdC4gQnV0 IHRoYXQncyBub3QgaGFwcGVuaW5nLiBTb21laG93LCBwZW9wbGUgdGhpbmsgdGhhdCBzbGFwcGlu ZyBhbiBvcHRpb25zIHRhZyBpbnRvIHRoZSBFVFNJLzNHUFAgc29sdXRpb24gd2lsbCBtYWdpY2Fs bHkgZml4IGFsbCBpdHMgaXNzdWVzLiBZb3UgaGF2ZSBlbm91Z2ggU0lQIGJhY2tncm91bmQgdGhh dCB5b3Ugc2hvdWxkIGtub3cgdGhhdCdzIHNpbXBseSBub3QgdGhlIGNhc2UuDQoJDQoJU28sIHVu dGlsIHNvbWVvbmUgc2hvd3MgdGhlIGluaXRpYXRpdmUgdG8gYWN0dWFsbHkgdGFja2xlIHRoZSBy b3V0aW5nIGFuZCBVUkkgaXNzdWVzIGluIHRoZSBFVFNJLzNHUFAgc29sdXRpb24sIGl0J3MgYSBu b24tc3RhcnRlci4gSSBmZWFyLCBob3dldmVyLCB0aGF0IHRoZSB2ZXJ5IHByb3BlcnR5IHRoYXQg dGhlIGFkdm9jYXRlcyBvZiB0aGF0IHNvbHV0aW9uIGhvbGQgbW9zdCBkZWFyIGlzIHF1aXRlIHBy ZWNpc2VseSB0aGUgcHJvcGVydHkgdGhhdCBtYWtlcyBpdCBydW4gYWZvdWwgY29yZSBTSVAgcm91 dGluZyBiZWhhdmlvci4NCgkNCgkvYQ0KDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCgltYXJ0aW5pIG1haWxpbmcgbGlzdA0KCW1hcnRpbmlAaWV0Zi5v cmcNCglodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hcnRpbmkNCgkNCg0K DQo= ------_=_NextPart_001_01CAD5F1.7DD3676E Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGRpdj48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPg0KQWdyZWVkPC9mb250Pjwv ZGl2Pg0KPGJyPjxkaXY+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmlu ZGV4PS0xPg0KPGZvbnQgZmFjZT1UYWhvbWEgc2l6ZT0yPg0KPGI+RnJvbTwvYj46IG1hcnRpbmkt Ym91bmNlc0BpZXRmLm9yZyAmbHQ7bWFydGluaS1ib3VuY2VzQGlldGYub3JnJmd0Ow08YnI+PGI+ VG88L2I+OiBBZGFtIFJvYWNoICZsdDthZGFtQG5vc3RydW0uY29tJmd0Ow08YnI+PGI+Q2M8L2I+ OiBiZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tICZsdDtiZXJuYXJkX2Fib2JhQGhvdG1haWwuY29t Jmd0OzsgbWFydGluaUBpZXRmLm9yZyAmbHQ7bWFydGluaUBpZXRmLm9yZyZndDsNPGJyPjxiPlNl bnQ8L2I+OiBUdWUgQXByIDA2IDIxOjEzOjM2IDIwMTA8YnI+PGI+U3ViamVjdDwvYj46IFJlOiBb bWFydGluaV0gVGhlIElFVEYgdmVyc3VzIHJlYWxpdHkgKHdhczogcHJvYmxlbXMgd2l0aGV4aXN0 aW5nU0lQIHRydW5raW5nIHNvbHV0aW9ucykNPGJyPjwvZm9udD48YnI+PC9kaXY+DQpJIHRoaW5r IG1vc3QgcGVvcGxlIGFyZSB3aWxsaW5nIHRvIGludmVzdGlnYXRlIGFuZCBhY2NlcHQgdGVjaG5p Y2FsIGZpeGVzIGFzIGxvbmcgYXMgdGhlcmUgYXJndW1lbnRzIGFyZSB0YWtlbiBzZXJpb3VzbHkg YW5kIGNhbiBhZ3JlZSB0aGF0IGlzc3VlcyByYWlzZWQgYXJlIHJlYWxseSBpc3N1ZXMuIDxicj48 YnI+Tm93IHdoZXJlIGFyZSB0aGUgaXNzdWVzICZxdW90O3RoZSByb3V0aW5nIGFuZCBVUkkgaXNz dWVzIGluIHRoZSBFVFNJLzNHUFAgc29sdXRpb24mcXVvdDsgZW51bWVyYXRlZD8gVGhlbiB3ZSBj YW4gYWRkcmVzcyB0aGVtIG9uZSBieSBvbmUuIEFwcGFyZW50bHkgc29tZSBwZW9wbGUgaGF2ZSBq b2luZWQgdGhlIGRpc2N1c3Npb24gYWZ0ZXIgdGhlIHdnIGFscmVhZHkgaHVtbWVkIHRvIHNvbWUg cHJlbGltaW5hcnkgY29uY2x1c2lvbiwgaXQgZG9lcyBub3QgaGFybSB0byByZWl0ZXJhdGUgdGhv c2UuIElmIHRoZXNlIGFyZSBhbGwgcmVhbGx5IGlzc3VlcyBJIGd1ZXNzIHdlIGFyZSBhbGwgbGVh ZCB0byB0aGUgc2FtZSBjb25jbHVzaW9uIGluIHNvbWUgd2F5Ljxicj4NCjxicj5Bbm90aGVyIHdh eSBmb3J3YXJkIGNvdWxkIGJlIHRoYXQgbWFydGluaSByZWNvZ25pc2VzIHRoYXQgaXRzIG1haW4g dGFzayBpcyB0aGUgZGVmaW5pdGlvbiBvZiBhIFNJUCBwcm90b2NvbCBleHRlbnNpb24gZm9yIHNp Z25hbGxpbmcgdGhlIFNJUCB0cnVua2luZyB2YXJpYW50LCB0aGF0IHRoZSBQQlggc3VwcG9ydHMu IFRoYXQgd291bGQgc29sdmUgdGhlIG1haW4gaXNzdWVzIHRoYXQgYXJlIHByZXNlbnRlZCBpbiB0 aGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50LiBJIGhhdmUgbm90aGluZyBhZ2FpbnN0IHN1Y2ggYSBm cmFtZXdvcmsgYWxzbyBkZXNjcmliaW5nIHRoZSBHSU4gdmFyaWFudCBhcyBvbmUgb2YgdGhlIGFs dGVybmF0aXZlcy4gSWYgaXQgaXMgc28gZ29vZCBmb3IgcHVyZSBTSVAgcHJveHkgaW1wbGVtZW50 YXRpb25zLCB3aHkgbm90P8KgIDxicj4NCjxicj5UaGVyZSBpcyBhbm90aGVyIGFsdGVybmF0aXZl IHRoYXQgaXMgdGhhdCBtYXJ0aW5pIG9ubHkgY3JlYXRlcyBhIFNJUCBmb3J1bSBzcGVjaWZpYyBz b2x1dGlvbiwgbm90aGluZyB3cm9uZyB3aXRoIHRoYXQuIEJ1dCB0aGVuIHBsZWFzZSBzdGF0ZSBp dCBpbiB0aGUgdGl0bGUgYW5kIG1ha2UgdGhpcyBhbiBpbmZvcm1hdGl2ZSBkcmFmdC7CoCBUaGlz IHdpbGwgYWxsb3cgeW91IHRvIGRvIGEgcXVpY2sgYW5kIGV4cGVkaWVudCBzcGVjaWZpY2F0aW9u IGFuZCBwZW9wbGUgd2lsbCBsZXQgeW91IGRvLiBUaGF0cyBob3cgb3RoZXIgU0RPJiMzOTtzIGFs c28gbmVlZCB0byBkbyB0aGVpciBleHRlbnNpb25zLCBhcyB0aGV5IGFyZSBidWlsZGluZyB3YWxs ZWQgZ2FyZGVuIHNvbHV0aW9ucy4uLjxicj4NCjxiciBjbGVhcj0iYWxsIj4vSGFucyBFcmlrIHZh biBFbGJ1cmc8YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBXZWQsIEFwciA3LCAy MDEwIGF0IDEyOjAxIEFNLCBBZGFtIFJvYWNoIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0i bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20iPmFkYW1Abm9zdHJ1bS5jb208L2E+Jmd0Ozwvc3Bhbj4g d3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjog MHB0IDBwdCAwcHQgMC44ZXg7IGJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAy MDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsiPg0KPGRpdiBjbGFzcz0iaW0iPk9uIDQvNi8xMCAxNTo0 NiwgQXByIDYsIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNz PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IGJvcmRlci1s ZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsiPg0K VGhlIEVUU0kvM0dQUCBzb2x1dGlvbiBoYXMgYmVlbiBoYXMgYmVlbiBwYXJ0IG9mIHRoZSBkaXNj dXNzaW9uIG1vcmUgb3IgbGVzcyBhbGwgdGhlIHdheSBmcm9tIHRoZSBiZWdpbm5pbmcgb2YgdGhl IHdvcmssIHNvIEkgZG9uJiMzOTt0IGl0JiMzOTtzIGZhaXIgdGhhdCBpdCBoYXMgbm93IHN1ZGRl bmx5IGNhbWUgdXAsIGFuZCB0aGVyZWZvciB3ZSBoYXZlIHdhc3RlZCBvdXIgdGltZS48YnI+DQoN CjwvYmxvY2txdW90ZT4NCjxicj48L2Rpdj4NCllvdSBtaXNzZWQgbXkgcG9pbnQuIEkmIzM5O2xs IHJlcGhyYXNlIHdoYXQgSSB3YXMgdHJ5aW5nIHRvIHNheTogaWYgd2UmIzM5O3JlIGp1c3QgcmUt cHVibGlzaGluZyBzb21lb25lIGVsc2UmIzM5O3MgbWVjaGFuaXNtIGFzLWlzLCB0aGVuIGFsbCB0 aGUgd29yayBpbiBESVNQQVRDSCBhbmQgYWxsIHRoZSB3b3JrIGluIERSRUdTIHdhcyBhIHRlcnJp YmxlIHdhc3RlIG9mIHRpbWUuIElmIHRoZSBwcm9ibGVtIGlzIGFscmVhZHkgc29sdmVkIGFuZCB3 b3JraW5nLCB0aGVuIHdlIGRpZG4mIzM5O3QgKGFuZCBkb24mIzM5O3QpIG5lZWQgdG8gZG8gYW55 dGhpbmcuPGJyPg0KDQo8YnI+DQpJIHRoaW5rIGRpc2N1c3Npb24gb2YgdGhlIElNUyBzb2x1dGlv biBpcyBwZXJmZWN0bHkgcmVhc29uYWJsZSwgYXMgbG9uZyBhcyBwZW9wbGUgYXJlIHdpbGxpbmcg dG8gaW52ZXN0aWdhdGUgYW5kIGFjY2VwdCB0ZWNobmljYWwgZml4ZXMgdG8gdGhlIGlzc3VlcyB0 aGF0IGhhdmUgYmVlbiByYWlzZWQgb24gdGhlIGxpc3QuIEJ1dCB0aGF0JiMzOTtzIG5vdCBoYXBw ZW5pbmcuIFNvbWVob3csIHBlb3BsZSB0aGluayB0aGF0IHNsYXBwaW5nIGFuIG9wdGlvbnMgdGFn IGludG8gdGhlIEVUU0kvM0dQUCBzb2x1dGlvbiB3aWxsIG1hZ2ljYWxseSBmaXggYWxsIGl0cyBp c3N1ZXMuIFlvdSBoYXZlIGVub3VnaCBTSVAgYmFja2dyb3VuZCB0aGF0IHlvdSBzaG91bGQga25v dyB0aGF0JiMzOTtzIHNpbXBseSBub3QgdGhlIGNhc2UuPGJyPg0KDQo8YnI+DQpTbywgdW50aWwg c29tZW9uZSBzaG93cyB0aGUgaW5pdGlhdGl2ZSB0byBhY3R1YWxseSB0YWNrbGUgdGhlIHJvdXRp bmcgYW5kIFVSSSBpc3N1ZXMgaW4gdGhlIEVUU0kvM0dQUCBzb2x1dGlvbiwgaXQmIzM5O3MgYSBu b24tc3RhcnRlci4gSSBmZWFyLCBob3dldmVyLCB0aGF0IHRoZSB2ZXJ5IHByb3BlcnR5IHRoYXQg dGhlIGFkdm9jYXRlcyBvZiB0aGF0IHNvbHV0aW9uIGhvbGQgbW9zdCBkZWFyIGlzIHF1aXRlIHBy ZWNpc2VseSB0aGUgcHJvcGVydHkgdGhhdCBtYWtlcyBpdCBydW4gYWZvdWwgY29yZSBTSVAgcm91 dGluZyBiZWhhdmlvci48YnI+DQo8Zm9udCBjb2xvcj0iIzg4ODg4OCI+DQo8YnI+DQovYTwvZm9u dD48ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0iaDUiPjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFydGluaSBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86bWFydGluaUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1h cnRpbmlAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tYXJ0aW5pIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tYXJ0aW5pPC9hPjxicj4NCjwvZGl2PjwvZGl2PjwvYmxvY2tx dW90ZT48L2Rpdj48YnI+DQo= ------_=_NextPart_001_01CAD5F1.7DD3676E-- From HKaplan@acmepacket.com Tue Apr 6 18:31:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3B403A62C1 for ; Tue, 6 Apr 2010 18:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.674 X-Spam-Level: X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndBsExXUw-ma for ; Tue, 6 Apr 2010 18:31:52 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E3E903A67D4 for ; Tue, 6 Apr 2010 18:31:51 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 6 Apr 2010 21:31:46 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 6 Apr 2010 21:31:46 -0400 From: Hadriel Kaplan To: Tyler Parkin , "martini@ietf.org" Date: Tue, 6 Apr 2010 21:31:45 -0400 Thread-Topic: [martini] Request for SSP perspective Thread-Index: AcrVqj8lE9QwELP6QZyAjMpcG+fCYgAKL43A Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3CF43@mail> References: <00cb01cad59c$36507f20$150510ac@CORPORATE.VOX.NET> <430FC6BDED356B4C8498F634416644A91A79F3CE46@mail> <010801cad5aa$3291e820$150510ac@CORPORATE.VOX.NET> In-Reply-To: <010801cad5aa$3291e820$150510ac@CORPORATE.VOX.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] Request for SSP perspective X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 01:31:52 -0000 [converting to plain text 'cause some folks have problems with the html for= matting] > -----Original Message----- > From: Tyler Parkin [mailto:tyler@foxfam.com]=20 > Sent: Tuesday, April 06, 2010 12:57 PM > > I don't mean to suggest that the draft say how the registrar/SBC should > impliment this, but at the protocal layer it would be nice to have > agreement on whether a GRUU should be appended, or a cookie, etc. There > have been different suggestions, but with respect to the suggestors, if w= e > can get 3 diff proposals "off the top of the head" on this list, then=20 > that's at least three diff ways that the different SBC/Registrar vendors= =20 > can impliment their support for GIN, which leads to interop issues.=A0=20 > > Say, just for example, if we were to use a standard SIP-NAT with an Acme > SBC, I'm sure you know the result is that all the different public=20 > addresses are NAT'd at the IP and Protocol layer so that they show up to= =20 > the registrar as originating from a single Private IP on the SBC core=20 > side.=A0 So if=A0a PBX registers the BNC contact (i.e. bnc@privateip), I = guess=20 > my concern is when the BNC is sent to the registrar that is the ONLY=20 > contact the SBC has for that PBX.=A0 So if the registrar then sends a=20 > request to the SBC for an individual contact (i.e. user@privateip) how is= =20 > the SBC going to know which PBX to send the request to.=A0=20 If the new option-tag is in the Register and Path is supported, we'd insert= cookies in a Path header URI of the Register, which would be reflected in = requests coming back to us in a Route header. =20 > Obviously, a=20 > cookie on the initial registration seems most likely, all I'm asking is=20 > that it be specified in the draft so that 4 different SBC vendors don't d= o=20 > a cookie, or a request-uri as the BNC and the contact URI as the user, or= =20 > map to some PAU, etc.=A0=20 OK, I'll suggest some wording that may be palatable. One thing we need to = warn Registrars about too is that they could get multiple IP-PBX's Register= ing all with the same contact URI, since there is no user portion to disamb= iguate them as there is today. This *shouldn't* matter to Registrars, but = since we seem to have needed to put cookies in a dozen different places and= flavors to accommodate different Registrars in the past, it can't hurt to = warn 'em. :) -hadriel From HKaplan@acmepacket.com Tue Apr 6 20:04:20 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DCB3A6867 for ; Tue, 6 Apr 2010 20:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq1ooD3lEEJf for ; Tue, 6 Apr 2010 20:04:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A9FD03A67BD for ; Tue, 6 Apr 2010 20:04:18 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 6 Apr 2010 23:04:10 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 6 Apr 2010 23:04:10 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg , Adam Roach Date: Tue, 6 Apr 2010 23:04:10 -0400 Thread-Topic: Hitchhiker's Guide to Making Martini (was: The IETF versus reality) Thread-Index: AcrV75QXT5BfOjNhTaikZSKcpLSaSgAArONA Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com> <4BBBAF3E.2080400@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: [martini] Hitchhiker's Guide to Making Martini (was: The IETF versus reality) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 03:04:20 -0000 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 3gp= p. So I'll just cover that. The problems found in the field are that different IP-PBX's expect differen= t 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 con= tact in the req-uri; some expect various username formats. It's all over t= he map. So we were trying to say "well if you do this option-tag then you must acce= pt XYZ". So then we got into what is the XYZ. We started with loose-route: the SSP just inserts the Registered Contact-UR= I 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 a= ctually 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 d= on't; some can handle the visual-separators, some can't; some do Tel-URI, s= ome don't. What the SSP gets is any/all forms with all kinds of number tra= nsform rules, but the IP-PBX type we're targeting is simple. There were se= veral 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 actu= ally expect/understand? In practice it usually expects its own (its hostna= me/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, f= or example - it could be and often is the SSP's Proxy's hostname or IP or s= ub-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 o= ne 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 expe= ct to get. The original concept was to "leave it alone", but it's not _real= ly_ left alone. And trust me it's virtually NEVER left alone, in practice.= Think about all the number translations, number manipulations, host repla= cement rules, etc., the Proxy and SBC vendors have. They're incredibly pop= ular, because they're what make calls actually succeed. But we're trying t= o 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 vend= ors - 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 ha= ve a request-uri 'transformation' and routing model for Registered AoR's: i= t'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 persona= lly 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).= =20 But in fairness there may well be unintended consequences for doing loose-r= oute in draft-shaken/IMS/etc. model for E.164 AoR's. For example, if the I= P-PBX *was* misconfigured and doesn't think it owns an AoR the SSP thinks i= t owns, what happens? The SSP routes it to the IP-PBX. The IP-PBX then ro= utes 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 doma= in A to domain B, with domain *A* as the target. -hadriel From bruno.chatras@orange-ftgroup.com Wed Apr 7 00:22:44 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A3403A685B for ; Wed, 7 Apr 2010 00:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWRS16gO7hKP for ; Wed, 7 Apr 2010 00:22:36 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id DA61B3A681D for ; Wed, 7 Apr 2010 00:22:34 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7A6438B8003; Wed, 7 Apr 2010 09:22:33 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 70C318B8005; Wed, 7 Apr 2010 09:22:33 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 09:22:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Apr 2010 09:22:21 +0200 Message-ID: <9ECCF01B52E7AB408A7EB85352642141014F5B43@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4BBB7A48.7050801@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) Thread-Index: AcrVtTVgIAL3Qi/0Q06g2sIUbzhTCAAbERBA References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com>, <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com> From: To: , X-OriginalArrivalTime: 07 Apr 2010 07:22:21.0552 (UTC) FILETIME=[10156F00:01CAD623] Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality (was: problems withexisting SIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 07:22:44 -0000 =20 > -----Message d'origine----- > De : Adam Roach [mailto:adam@nostrum.com]=20 > Envoy=E9 : mardi 6 avril 2010 20:16 > =C0 : Christer Holmberg > Cc : DOLLY, MARTIN C (ATTLABS); CHATRAS Bruno RD-CORE-ISS;=20 > bernard_aboba@hotmail.com; martini@ietf.org > Objet : Re: [martini] The IETF versus reality (was: problems=20 > withexisting SIP trunking solutions) >=20 > On 4/6/10 12:24, Apr 6, Christer Holmberg wrote: > > Hi Adam, > > =20 > >> The changes proposed in GIN are not mere caprice, nor are=20 > they simply=20 > >> aesthetic differences of opinion. We've been round and=20 > round on the=20 > >> list about the shortcomings of the ETSI/3GPP/IMS/etc=20 > solutions. The=20 > >> closest anyone favoring the IMS solutions have come to "solving"=20 > >> these problems is outright dismissal. The response has=20 > largely been=20 > >> of the form "it works for my walled gardens, and I don't=20 > care whether=20 > >> it works on the Internet at large." > >> =20 > > If that was the case I don't think people would be here=20 > arguing for the IMS solution. > > =20 >=20 > Without meaning to cast any aspersions on motives, I think a=20 > careful examination of the activities of those most vocally=20 > advocating adoption of the IMS solution would reveal to you=20 > that the preponderance[1] of them are relatively new to the=20 > IETF (approximately one year of active participation or=20 > less), and have worked in 3GPP and/or ETSI for a substantial=20 > amount of time. I love the fact that we're seeing new=20 > participation, but I fear that some of the reactions may be=20 > somewhat partisan in nature. >=20 > In particular, this appearance of partisanship is starkly=20 > amplified by the fact that the arguments raised against GIN=20 > are nearly uniformly statements that it isn't identical to=20 > the ETSI/3GPP solution. That's not helpful feedback.=20 =3D=3D>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=20 > If MARTINI simply intended to republish another SDO's documents,=20 > then this has all been a colossal waste of everyone's time. =3D=3D>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.=20 >=20 > /a >=20 > [1] Before you raise objections along the lines of "but=20 > person X objects, and he or she's been here for longer than=20 > that," I encourage you to meditate on the meaning of the word=20 > "preponderance." >=20 From john.elwell@siemens-enterprise.com Wed Apr 7 01:19:33 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932DC3A67F0 for ; Wed, 7 Apr 2010 01:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd4bIOfb9Hbm for ; Wed, 7 Apr 2010 01:19:22 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 54BE83A679F for ; Wed, 7 Apr 2010 01:19:22 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1465829; Wed, 7 Apr 2010 10:19:18 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 338821EB82AB; Wed, 7 Apr 2010 10:19:18 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 7 Apr 2010 10:19:18 +0200 From: "Elwell, John" To: "bruno.chatras@orange-ftgroup.com" , "HKaplan@acmepacket.com" , "christer.holmberg@ericsson.com" , "richard@shockey.us" , "ietf.hanserik@gmail.com" Date: Wed, 7 Apr 2010 10:19:17 +0200 Thread-Topic: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX Thread-Index: AcrQ23D3EqrCTe1bR2izj67MexoX3wAO4MiAACVdHdAAVrMb0AARaLKAAIPfbnAAMlxQIA== Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79E92C83@mail><000401cad1ac$f5111d00$df335700$@us> <430FC6BDED356B4C8498F634416644A91A79E93278@mail> <9ECCF01B52E7AB408A7EB85352642141014C2338@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141014C2338@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 08:19:34 -0000 Bruno, So the essential aspects of the 3GPP/ETSI solution, without unnecessary IMS= baggage, would need to be made available as an I-D. However, bear in mind = that we had two earlier drafts, Dregs/Stirred and Shaken, which were found = to be lacking, so any new draft would need to differentiate itself from tho= se. In my opinion, the gin draft, while not in line with some existing impl= ementations, is not far away from some other implementations, and seems to = meet requirements, particularly in terms of not breaking core SIP or DNS ar= chitecture. So it is my hope that we can progress that draft, and in the ab= sence of a competing proposal the gin draft does indeed appear to be the wa= y forward. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of=20 > bruno.chatras@orange-ftgroup.com > Sent: 06 April 2010 09:23 > To: HKaplan@acmepacket.com; christer.holmberg@ericsson.com;=20 > richard@shockey.us; ietf.hanserik@gmail.com > Cc: martini@ietf.org > Subject: Re: [martini] Issue with existing SIP trunking=20 > solutions, was Re: #21: 3.2.2 describes an issue with some PBX >=20 > =20 >=20 > > -----Message d'origine----- > > De : martini-bounces@ietf.org=20 > > [mailto:martini-bounces@ietf.org] De la part de Hadriel Kaplan > > Envoy=E9 : samedi 3 avril 2010 19:09 > > =C0 : Christer Holmberg; 'Richard Shockey'; 'Hans Erik van Elburg' > > Cc : martini@ietf.org > > Objet : Re: [martini] Issue with existing SIP trunking=20 > > solutions, was Re: #21: 3.2.2 describes an issue with some PBX > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Saturday, April 03, 2010 4:31 AM > > > To: 'Richard Shockey'; 'Hans Erik van Elburg'; Hadriel Kaplan > > >=20 > > >=20 > > > >No thank you. Some of us want to get this done before=20 > the next US > > > presidential election. > > >=20 > > > Also, I guess it is then ok for other SDOs (e.g. 3GPP) to start=20 > > > defining their own protocol extensions etc, instead of=20 > > bringing them=20 > > > to IETF - simply based on the argument (whether it's true=20 > > or not) that=20 > > > it will take too long to do it in IETF... > >=20 > > Umm... you do realize that is what some folks believe=20 > > happened in this case, right? > > Some folks view ETSI's usage of a loose-route model for=20 > > Registered contacts as conflicting with the current 3261=20 > > model. (i.e., extending it) Personally I think a good lawyer=20 > > could make the case it isn't, but we couldn't get consensus=20 > > to go that way. > > =20 > >=20 > > > Also, based on what argument do you think it would take a=20 > > long time to=20 > > > do this with 3GPP/ETSI? > >=20 > > I think he meant in the context of your suggested=20 > > "communicating changes with 3gpp". I too have been told that=20 > > trying to coordinate changes/updates to specs with both IETF=20 > > and 3GPP at the same time through liaisons takes a long time. > >=20 > > And it _would_ still require something to be published in the=20 > > IETF. There are plenty of SIP networks in existence which=20 > > are not IMS, and won't be IMS. > >=20 > > -hadriel > > p.s. And I'm not disparaging IMS (most of my revenue comes=20 > > from IMS!) - but it's not the only game in town. IP-PBX SIP=20 > > trunks need to work with any SSP network architecture. >=20 > BC: The solution documented in 3GPP/ETSI specifications would=20 > work with a different architecture than the IMS. We should=20 > actually refrain from calling it "IMS solution" as this sows=20 > confusion is people's mind. >=20 >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From christer.holmberg@ericsson.com Wed Apr 7 03:44:59 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 207513A694F for ; Wed, 7 Apr 2010 03:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWidhiqlRrjz for ; Wed, 7 Apr 2010 03:44:58 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id AAEC83A6861 for ; Wed, 7 Apr 2010 03:44:57 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-c2-4bbc622504ec Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 84.8C.23740.5226CBB4; Wed, 7 Apr 2010 12:44:53 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 7 Apr 2010 12:44:53 +0200 From: Christer Holmberg To: "Elwell, John" , "bruno.chatras@orange-ftgroup.com" , "HKaplan@acmepacket.com" , "richard@shockey.us" , "ietf.hanserik@gmail.com" Date: Wed, 7 Apr 2010 12:44:52 +0200 Thread-Topic: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX Thread-Index: AcrQ23D3EqrCTe1bR2izj67MexoX3wAO4MiAACVdHdAAVrMb0AARaLKAAIPfbnAAMlxQIAABiA4w Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79E92C83@mail><000401cad1ac$f5111d00$df335700$@us> <430FC6BDED356B4C8498F634416644A91A79E93278@mail> <9ECCF01B52E7AB408A7EB85352642141014C2338@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 10:44:59 -0000 Hi,=20 >So the essential aspects of the 3GPP/ETSI solution, without=20 >unnecessary IMS baggage, would need to be made available as=20 >an I-D. However, bear in mind that we had two earlier drafts,=20 >Dregs/Stirred and Shaken, which were found to be lacking, so=20 >any new draft would need to differentiate itself from those.=20 A draft is never perfect/complete from the beginning - that is why we discu= ss them and submit new versions :) Regards, Christer >In my opinion, the gin draft, while not in line with some=20 >existing implementations, is not far away from some other=20 >implementations, and seems to meet requirements, particularly=20 >in terms of not breaking core SIP or DNS architecture. So it=20 >is my hope that we can progress that draft, and in the=20 >absence of a competing proposal the gin draft does indeed=20 >appear to be the way forward. >=20 > John >=20 >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of=20 > > bruno.chatras@orange-ftgroup.com > > Sent: 06 April 2010 09:23 > > To: HKaplan@acmepacket.com; christer.holmberg@ericsson.com;=20 > > richard@shockey.us; ietf.hanserik@gmail.com > > Cc: martini@ietf.org > > Subject: Re: [martini] Issue with existing SIP trunking=20 > solutions, was=20 > > Re: #21: 3.2.2 describes an issue with some PBX > >=20 > > =20 > >=20 > > > -----Message d'origine----- > > > De : martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] De la part de Hadriel Kaplan=20 > > > Envoy=E9 : samedi 3 avril 2010 19:09 =C0 : Christer Holmberg;=20 > 'Richard=20 > > > Shockey'; 'Hans Erik van Elburg' > > > Cc : martini@ietf.org > > > Objet : Re: [martini] Issue with existing SIP trunking solutions,=20 > > > was Re: #21: 3.2.2 describes an issue with some PBX > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > > Sent: Saturday, April 03, 2010 4:31 AM > > > > To: 'Richard Shockey'; 'Hans Erik van Elburg'; Hadriel Kaplan > > > >=20 > > > >=20 > > > > >No thank you. Some of us want to get this done before > > the next US > > > > presidential election. > > > >=20 > > > > Also, I guess it is then ok for other SDOs (e.g. 3GPP) to start=20 > > > > defining their own protocol extensions etc, instead of > > > bringing them > > > > to IETF - simply based on the argument (whether it's true > > > or not) that > > > > it will take too long to do it in IETF... > > >=20 > > > Umm... you do realize that is what some folks believe happened in=20 > > > this case, right? > > > Some folks view ETSI's usage of a loose-route model for=20 > Registered=20 > > > contacts as conflicting with the current 3261 model. (i.e.,=20 > > > extending it) Personally I think a good lawyer could make=20 > the case=20 > > > it isn't, but we couldn't get consensus to go that way. > > > =20 > > >=20 > > > > Also, based on what argument do you think it would take a=20 > > > long time to=20 > > > > do this with 3GPP/ETSI? > > >=20 > > > I think he meant in the context of your suggested=20 > > > "communicating changes with 3gpp". I too have been told that=20 > > > trying to coordinate changes/updates to specs with both IETF=20 > > > and 3GPP at the same time through liaisons takes a long time. > > >=20 > > > And it _would_ still require something to be published in the=20 > > > IETF. There are plenty of SIP networks in existence which=20 > > > are not IMS, and won't be IMS. > > >=20 > > > -hadriel > > > p.s. And I'm not disparaging IMS (most of my revenue comes=20 > > > from IMS!) - but it's not the only game in town. IP-PBX SIP=20 > > > trunks need to work with any SSP network architecture. > >=20 > > BC: The solution documented in 3GPP/ETSI specifications would=20 > > work with a different architecture than the IMS. We should=20 > > actually refrain from calling it "IMS solution" as this sows=20 > > confusion is people's mind. > >=20 > >=20 > > > _______________________________________________ > > > martini mailing list > > > martini@ietf.org > > > https://www.ietf.org/mailman/listinfo/martini > > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > = From spencer@wonderhamster.org Wed Apr 7 05:45:00 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32CCF3A691E for ; Wed, 7 Apr 2010 05:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXhOkbfmZLkY for ; Wed, 7 Apr 2010 05:44:59 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 143E23A690A for ; Wed, 7 Apr 2010 05:44:59 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Mar7C-1OFMXH1HT8-00KcDv; Wed, 07 Apr 2010 08:43:56 -0400 Message-ID: From: "Spencer Dawkins" To: , , References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com>, <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com><4BBB7A48.7050801@nostrum.com> <9ECCF01B52E7AB408A7EB85352642141014F5B43@ftrdmel0.rd.francetelecom.fr> Date: Wed, 7 Apr 2010 07:43:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX181xYP6nAF1dUp0BG3amBEV6/L8hrS67VP2gPU e5YAsTXbwax5fQD4yQFfB8GHgcxenJDNBLCHolzkuNIposjwWS anqtp03UojrwJvDx0HEgfA0m8cjVq0A6WDlCbP7x5c= Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality (was: problems withexistingSIP trunking solutions) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 12:45:00 -0000 Hi, Bruno... See below... and this time, I'm speaking as an individual. > 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... 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... 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. 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. From pkyzivat@cisco.com Wed Apr 7 06:23:15 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD4483A6A70 for ; Wed, 7 Apr 2010 06:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.225 X-Spam-Level: X-Spam-Status: No, score=-10.225 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoeiGJH522XP for ; Wed, 7 Apr 2010 06:23:10 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 007C83A67F9 for ; Wed, 7 Apr 2010 06:22:52 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFgkvEtAZnwN/2dsb2JhbACbP3GgVJkrglWCNAQ X-IronPort-AV: E=Sophos;i="4.51,378,1267401600"; d="scan'208";a="99681471" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 07 Apr 2010 13:22:50 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o37DMnuf000922; Wed, 7 Apr 2010 13:22:49 GMT Message-ID: <4BBC8729.8090409@cisco.com> Date: Wed, 07 Apr 2010 09:22:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <00cb01cad59c$36507f20$150510ac@CORPORATE.VOX.NET> <430FC6BDED356B4C8498F634416644A91A79F3CE46@mail> <010801cad5aa$3291e820$150510ac@CORPORATE.VOX.NET> <430FC6BDED356B4C8498F634416644A91A79F3CF43@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3CF43@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] Request for SSP perspective X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 13:23:15 -0000 Hadriel Kaplan wrote: > One thing we need to warn Registrars about too is that they could get multiple IP-PBX's Registering all with the same contact URI, since there is no user portion to disambiguate them as there is today. This *shouldn't* matter to Registrars, but since we seem to have needed to put cookies in a dozen different places and flavors to accommodate different Registrars in the past, it can't hurt to warn 'em. :) Umm - can you explain further about that? Are you saying that two devices are using the same contact URI (containing a NATed address) and those identify distinct devices because of a Path header in the register? As long as the two don't (implicitly) register any numbers in common there won't be a problem, since its the supplied contact plus the number that ends up in the location service. But if perchance they have numbers in common, then there is indeed an issue. In that case they had better use outbound, which would take care of any ambiguity. Otherwise, 3261 registration rules will require only the most recent of conflicting registrations, based on the contact address, to be kept. Or else additional procedures for the registrar need to be defined. Thanks, Paul From ietf.hanserik@gmail.com Wed Apr 7 06:25:56 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0C4E3A6804 for ; Wed, 7 Apr 2010 06:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiL5bn1Tul4x for ; Wed, 7 Apr 2010 06:25:54 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 69FF03A67AB for ; Wed, 7 Apr 2010 06:25:53 -0700 (PDT) Received: by ewy24 with SMTP id 24so525048ewy.13 for ; Wed, 07 Apr 2010 06:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=ZlqwdLcicgYPdC3/uh4PBwKkX9pBg1wRTtB8pvyzFPU=; b=fv3mra8+xAvCozCB8HW7sujaoyl0dPh/gGmNqVSKpa2y5R5IQZxsniEZos+uKTsgQm VV+B38oIj4Zqf3/GzGnkxS06r+mNJ4bh0e97gDv/eAOAZz9BVMyigKgVStmi+orj0ThM Ixs/kF/razmjFf0YlJCodCH3ovfez0qYFDmLk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=id4dRGSHTaAH0s6MCaSXl69Np4Ni3kisPrqaR2v667h7Ms5KimuRq1SMzG1QGRPMai HVRmU77Iq16ul1IY4pHi/rtBDmVEQII4y4SWjZoWg3He8bOB5mHm5Doequ/Fdj6PFW/C CwlkZcfFnGjMuCreo1YUbl61CW/yXRy2QYYW0= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Wed, 7 Apr 2010 06:25:47 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> References: <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com> <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> Date: Wed, 7 Apr 2010 15:25:47 +0200 Received: by 10.213.43.83 with SMTP id v19mr5305771ebe.1.1270646747248; Wed, 07 Apr 2010 06:25:47 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan , Spencer Dawkins Content-Type: multipart/alternative; boundary=00148530ac610139290483a58080 Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] Hitchhiker's Guide to Making Martini (was: The IETF versus reality) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 13:25:57 -0000 --00148530ac610139290483a58080 Content-Type: text/plain; charset=ISO-8859-1 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: > 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. /Hans Erik van Elburg On Wed, Apr 7, 2010 at 5:04 AM, Hadriel Kaplan 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). > > 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 > > --00148530ac610139290483a58080 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Hadriel for providing the excellent overview, hope this gets the dis= cussion back on track.

Just to put this remark from Spencer on the r= ight thread, it seems important and the crucial fundamental point where peo= ple have different opinions:
<spencer>
=A0 <hadriel>
But in fairness there may well be unintended consequences for doing
loose-route in draft-shaken/IMS/etc. model for E.164 AoR's. =A0For=20 example,
if the IP-PBX *was* misconfigured and doesn't think it owns an AoR the<= br> SSP thinks it owns, what happens? =A0The SSP routes it to the IP-PBX. =A0Th= e
IP-PBX then routes it to the SSP (in some cases). =A0Nice loop. =A0But=20 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.
=A0=A0 </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=20 URI and route based on "something else" from a SIP node that was= =20 authoritative for the domain to a destination that wasn't authoritative= =20 for the domain.

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

And that's how we got to GIN.
</spencer>

/Hans Erik van Elburg


On Wed, Apr 7, 2010 at 5:04 AM, Hadriel = Kaplan <HKap= lan@acmepacket.com> wrote:

Let me try and cut to the chase, by trying to provide a road map for how we= got here. =A0Some of this history may be from the sip-forum and not Martin= i 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. =A0I think tha= t's also the change that most people are upset about being different fr= om 3gpp. =A0So I'll just cover that.

The problems found in the field are that different IP-PBX's expect diff= erent things in the request-uri: some expect only SIP URI's; some can&#= 39;t handle their contact-URI being in a Route header; some expect their re= gistered contact in the req-uri; some expect various username formats. =A0I= t's all over the map.

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

We started with loose-route: the SSP just inserts the Registered Contact-UR= I 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 a= ctually expect/understand? =A0We've seen problems with that in the fiel= d too - some expect a leading "+", some don't; some expect a = country-code, some don't; some can handle the visual-separators, some c= an't; some do Tel-URI, some don't. =A0What the SSP gets is any/all = forms with all kinds of number transform rules, but the IP-PBX type we'= re targeting is simple. =A0There were several proposals for how to handle t= his, including even just normalizing the username to some common format/sch= eme before sending it to the IP-PBX. =A0OK, 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 actu= ally expect/understand? =A0In practice it usually expects its own (its host= name/ip/domain). =A0It's not *actually* in the SSP's domain, after = all. =A0But we figured we'll just mandate it is for its specific AoR= 9;s, or that it least owns/controls/is-authoritative for those AoR's. = =A0But then we realized that the req-uri the SSP Proxy literally gets (befo= re looking it up and routing it) isn't always known to the IP-PBX eithe= r - 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 doma= in but instead one of its AoR's, which were really one of the SSP's= AoR's. =A0Confusing, 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" Ao= R it will expect to get. The original concept was to "leave it alone&q= uot;, but it's not _really_ left alone. =A0And trust me it's virtua= lly NEVER left alone, in practice. =A0Think about all the number translatio= ns, number manipulations, host replacement rules, etc., the Proxy and SBC v= endors have. =A0They're incredibly popular, because they're what ma= ke calls actually succeed. =A0But 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 n= ot talking about the vendors that go to standards bodies :)

Meanwhile, another group of folks were saying "wait a minute, we alrea= dy have a request-uri 'transformation' and routing model for Regist= ered AoR's: it's called RFC 3261. Why re-create the wheel, when the= re's already a wheel around that's proven to work?" =A0That= 9;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. = =A0I 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 en= ough 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-r= oute in draft-shaken/IMS/etc. model for E.164 AoR's. =A0For example, if= the IP-PBX *was* misconfigured and doesn't think it owns an AoR the SS= P thinks it owns, what happens? =A0The SSP routes it to the IP-PBX. =A0The = IP-PBX then routes it to the SSP (in some cases). =A0Nice loop. =A0But that= 's not the problem - it's a symptom, not the cause - the cause is w= e sent a request from domain A to domain B, with domain *A* as the target.<= br>
-hadriel


--00148530ac610139290483a58080-- From pkyzivat@cisco.com Wed Apr 7 06:37:41 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6372E3A67F9 for ; Wed, 7 Apr 2010 06:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEWta9NMVBI6 for ; Wed, 7 Apr 2010 06:37:39 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3F3E13A67AB for ; Wed, 7 Apr 2010 06:37:39 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKYmvEurR7Hu/2dsb2JhbACbP3Ggf5krhQkE X-IronPort-AV: E=Sophos;i="4.51,378,1267401600"; d="scan'208";a="179411147" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 07 Apr 2010 13:37:21 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o37DbK3J011893; Wed, 7 Apr 2010 13:37:20 GMT Message-ID: <4BBC8A90.7030202@cisco.com> Date: Wed, 07 Apr 2010 09:37:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com> <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] Hitchhiker's Guide to Making Martini X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 13:37:41 -0000 Hadriel, Thank you! This is a superb job of explaining where we are. Paul Hadriel Kaplan 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). > > 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 > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From pkyzivat@cisco.com Wed Apr 7 07:05:10 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238E53A67AF for ; Wed, 7 Apr 2010 07:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.269 X-Spam-Level: X-Spam-Status: No, score=-10.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAVH-9vrnYmZ for ; Wed, 7 Apr 2010 07:05:08 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3CD4B3A68F7 for ; Wed, 7 Apr 2010 07:04:59 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFALktvEtAZnwN/2dsb2JhbACPVotpcaEhmSyFCQQ X-IronPort-AV: E=Sophos;i="4.51,378,1267401600"; d="scan'208";a="99555834" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Apr 2010 14:04:56 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o37E4tQ6020079; Wed, 7 Apr 2010 14:04:56 GMT Message-ID: <4BBC9107.2070208@cisco.com> Date: Wed, 07 Apr 2010 10:04:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: bruno.chatras@orange-ftgroup.com References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com>, <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com> <9ECCF01B52E7AB408A7EB85352642141014F5B43@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141014F5B43@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 14:05:10 -0000 bruno.chatras@orange-ftgroup.com wrote: > ==>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. Thanks, Paul From spencer@wonderhamster.org Wed Apr 7 07:15:05 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2884A3A68F6 for ; Wed, 7 Apr 2010 07:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.676, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uYneZjsiqJl for ; Wed, 7 Apr 2010 07:15:04 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 393A43A6870 for ; Wed, 7 Apr 2010 07:15:04 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Md2yY-1OHjMy3U3e-00IOOr; Wed, 07 Apr 2010 10:15:00 -0400 Message-ID: <0CBA65C64F424AF19B96DF96E3B1FDEF@china.huawei.com> From: "Spencer Dawkins" To: "Paul Kyzivat" , References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com>, <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com><9ECCF01B52E7AB408A7EB85352642141014F5B43@ftrdmel0.rd.francetelecom.fr> <4BBC9107.2070208@cisco.com> Date: Wed, 7 Apr 2010 09:14:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19azK8nlgUVf69uVHuGNKfn/v2ZUa9PceOUD15 kN26a8teOZt15S/WZOsTCAx2v9H2NwkQRc+tqVXrfAe4EYnA8+ wd/ZvesyQ9v01H/5mlvzZR+vLWrziChj5vbYQMD1/4= Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] The IETF versus reality X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 14:15:05 -0000 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@ericsson.com Wed Apr 7 10:33:02 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E621D3A6A8E for ; Wed, 7 Apr 2010 10:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.29 X-Spam-Level: X-Spam-Status: No, score=-5.29 tagged_above=-999 required=5 tests=[AWL=1.309, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5tHUumUMmkL for ; Wed, 7 Apr 2010 10:33:02 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E66233A69C3 for ; Wed, 7 Apr 2010 10:33:01 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-da-4bbcc1c9479a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id AC.E8.23532.9C1CCBB4; Wed, 7 Apr 2010 19:32:58 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 7 Apr 2010 19:32:57 +0200 From: Christer Holmberg To: Paul Kyzivat , "bruno.chatras@orange-ftgroup.com" Date: Wed, 7 Apr 2010 19:29:50 +0200 Thread-Topic: [martini] The IETF versus reality Thread-Index: AcrWW09Fkf9u8U/KQ9eBLxmTp+ABIQAHJ3je Message-ID: References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com>, <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com> <9ECCF01B52E7AB408A7EB85352642141014F5B43@ftrdmel0.rd.francetelecom.fr>, <4BBC9107.2070208@cisco.com> In-Reply-To: <4BBC9107.2070208@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] The IETF versus reality X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 17:33:03 -0000 Hi, >> =3D=3D>BC: The real concern is that there will be two non-compatible alt= ernative standards to comply with:=20 >>GIN and 3GPP/ETSI. That's why some people including myself are advocating= alignment/consistency=20 >>between MARTINI and the 3GPP/ETSI solution. It's obsioulsy not because th= e solution comes from SDOs=20 >>where some of us are more involved than in IETF. On the other hand I hope= that the 3GPP/ETSI solution is=20 >>not discarded by some other people just because it comes from 3GPP and ET= SI... > >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 c= urrent 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 d= on't think MARTINI needs to go out and look for them. Regards, Christer= From D.Hancock@CableLabs.com Wed Apr 7 10:52:49 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E600B3A6A64 for ; Wed, 7 Apr 2010 10:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBTsKkswOwTl for ; Wed, 7 Apr 2010 10:52:48 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id DF3733A6AC5 for ; Wed, 7 Apr 2010 10:52:39 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o37HqX87013292; Wed, 7 Apr 2010 11:52:33 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 7 Apr 2010 11:52:33 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 7 Apr 2010 11:52:33 -0600 From: David Hancock To: Hadriel Kaplan , Hans Erik van Elburg , Adam Roach Date: Wed, 7 Apr 2010 11:52:32 -0600 Thread-Topic: [martini] Hitchhiker's Guide to Making Martini (was: The IETF versus reality) Thread-Index: AcrV75QXT5BfOjNhTaikZSKcpLSaSgAArONAAB3VRHA= Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4EDBA9E@srvxchg> References: <9ECCF01B52E7AB408A7EB85352642141014C2336@ftrdmel0.rd.francetelecom.fr> <007b01cad58f$aaff0600$00fd1200$@us> <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com> <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] Hitchhiker's Guide to Making Martini (was: The IETF versus reality) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 17:52:50 -0000 Thanks for the concise summary, Hadriel.=20 I'm sympathetic to the arguments being put forward now by the IMS camp on t= his issue. IMS has a well-defined procedure for support of IP-PBX registrat= ion, IMS is being adopted by a pretty sizeable portion of the industry, so = why introduce a new/alternate bulk-registration procedure now just to resol= ve some esoteric/academic/philosophical issues? And during most of this deb= ate, 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. =20 During the original discussion on the domain-ownership-ambiguity issue (whe= re PBX uses the SSP domain), we resolved the issue as suggested in your sum= mary below -- by saying the PBX will apply local policy to route the reques= t 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). How= ever, 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 I= MS/SHAKEN solutions do not. Another way to avoid the shared-domain routing & temp-gruu issues that exis= t 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 th= e domain of the temp-gruu points to that PBX. But assigning and managing th= ese 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 prett= y large.=20 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 numbe= r 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 IM= S does not have any explicit procedures for this retargeting step either. T= his issue does not exist with the GIN solution, since the home/terminating = SSP network retargets incoming requests destined for the IP-PBX based on no= rmal RFC 3261 section 16.5 routing procedures. David > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Hadriel Kaplan > Sent: Tuesday, April 06, 2010 9:04 PM > To: Hans Erik van Elburg; Adam Roach > Cc: bernard_aboba@hotmail.com; martini@ietf.org > Subject: [martini] Hitchhiker's Guide to Making Martini (was: The IETF > versus reality) >=20 >=20 > 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. >=20 > Probably the biggest issue we hit/debated about ETSI/3gpp/draft-shaken wa= s > 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. >=20 > 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. >=20 > 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. >=20 > We started with loose-route: the SSP just inserts the Registered Contact- > URI as a loose-route, and leaves the req-URI alone. >=20 > 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 o= f > 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 t= o > the IP-PBX. OK, so now the SSP is modifying the req-uri username, but > that's do-able. >=20 > 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 i= t > 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. >=20 > 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? >=20 > 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 wil= l > 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. Bu= t > 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 :) >=20 > 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 alread= y > a wheel around that's proven to work?" That's a pretty strong argument. >=20 > 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). >=20 > 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 th= e > IP-PBX *was* misconfigured and doesn't think it owns an AoR the SSP think= s > 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. >=20 > -hadriel >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From jan.van.geel@belgacom.be Wed Apr 7 23:37:34 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2753E3A69E6 for ; Wed, 7 Apr 2010 23:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3pUMdtwLJWn for ; Wed, 7 Apr 2010 23:37:32 -0700 (PDT) Received: from mx24.belgacom.be (mx24.belgacom.be [213.181.45.234]) by core3.amsl.com (Postfix) with ESMTP id DAE603A69D7 for ; Wed, 7 Apr 2010 23:37:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,168,1270418400"; d="scan'208,217";a="178395" Received: from unknown (HELO A03006.BGC.NET) ([10.121.129.161]) by mx24.belgacom.be with ESMTP; 08 Apr 2010 08:32:56 +0200 X-TM-IMSS-Message-ID: <02990d3c00003028@belgacom.be> Received: from A03167.BGC.NET ([45.223.1.34]) by belgacom.be ([10.121.129.161]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 02990d3c00003028 ; Thu, 8 Apr 2010 08:37:25 +0200 Received: from CMS03.BGC.NET ([10.120.128.133]) by A03167.BGC.NET ([45.223.1.34]) with mapi; Thu, 8 Apr 2010 08:37:25 +0200 From: To: , , Date: Thu, 8 Apr 2010 08:37:23 +0200 Thread-Topic: [martini] Hitchhiker's Guide to Making Martini (was: The IETF versus reality) Thread-Index: AcrWVd002KcI8CRkQ3qea2GTIweSAQAj+Llg Message-ID: <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> References: <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com> <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_208EAE1DFA28FC419529619ABB8622441617E1A960CMS03BGCNET_" MIME-Version: 1.0 Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] Hitchhiker's Guide to Making Martini (was: The IETF versus reality) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 06:37:34 -0000 --_000_208EAE1DFA28FC419529619ABB8622441617E1A960CMS03BGCNET_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi=20guys, To=20my=20opinion=20the=20network=20and=20protocol=20is=20not=20and=20sho= uld=20not=20be=20responsible=20for=20solving=20(human)=20errors=20like=20= misconfiguration=20! Kind=20regards Jan=20Van=20Geel IT=20and=20Network=20Development=20Specialist Belgacom=20SDE/SDV/PSE/NST/NCP Tel:=20+32=202=20202=201035 Tel:=20+32=202=20207=209032 Email=20:=20jan.van.geel@belgacom.be www.cyberwezz.tk From:=20martini-bounces@ietf.org=20[mailto:martini-bounces@ietf.org]=20On= =20Behalf=20Of=20Hans=20Erik=20van=20Elburg Sent:=2007=20April=202010=2015:26 To:=20Hadriel=20Kaplan;=20Spencer=20Dawkins Cc:=20bernard_aboba@hotmail.com;=20martini@ietf.org Subject:=20Re:=20[martini]=20Hitchhiker's=20Guide=20to=20Making=20Martini= =20(was:=20The=20IETF=20versus=20reality) Thanks=20Hadriel=20for=20providing=20the=20excellent=20overview,=20hope= =20this=20gets=20the=20discussion=20back=20on=20track. Just=20to=20put=20this=20remark=20from=20Spencer=20on=20the=20right=20thr= ead,=20it=20seems=20important=20and=20the=20crucial=20fundamental=20point= =20where=20people=20have=20different=20opinions: =20=20 But=20in=20fairness=20there=20may=20well=20be=20unintended=20consequences= =20for=20doing loose-route=20in=20draft-shaken/IMS/etc.=20model=20for=20E.164=20AoR's.= =20=20For=20example, if=20the=20IP-PBX=20*was*=20misconfigured=20and=20doesn't=20think=20it=20= owns=20an=20AoR=20the SSP=20thinks=20it=20owns,=20what=20happens?=20=20The=20SSP=20routes=20it= =20to=20the=20IP-PBX.=20=20The IP-PBX=20then=20routes=20it=20to=20the=20SSP=20(in=20some=20cases).=20=20= Nice=20loop.=20=20But=20that's not=20the=20problem=20-=20it's=20a=20symptom,=20not=20the=20cause=20-=20t= he=20cause=20is=20we=20sent=20a request=20from=20domain=20A=20to=20domain=20B,=20with=20domain=20*A*=20as= =20the=20target. =20=20=20 When=20we=20actually=20said=20this=20out=20loud,=20we=20realized=20that= =20we=20were=20entering=20a=20land=20where=20we=20expect=20SIP=20nodes=20= to=20ignore=20domain=20names=20in=20the=20request=20URI=20and=20route=20b= ased=20on=20"something=20else"=20from=20a=20SIP=20node=20that=20was=20aut= horitative=20for=20the=20domain=20to=20a=20destination=20that=20wasn't=20= authoritative=20for=20the=20domain. Hadriel=20was=20actually=20pretty=20eloquent,=20arguing=20that=20this=20w= as=20a=20"local=20policy"=20routing=20decision,=20allowed=20by=20RFC=2032= 61,=20but=20he=20got=20shot=20down.=20My=20impression,=20speaking=20as=20= an=20individual,=20was=20that=20the=20IETF=20would=20never=20standardize= =20this=20mode=20of=20operation. And=20that's=20how=20we=20got=20to=20GIN. /Hans=20Erik=20van=20Elburg On=20Wed,=20Apr=207,=202010=20at=205:04=20AM,=20Hadriel=20Kaplan=20>=20wrote: Let=20me=20try=20and=20cut=20to=20the=20chase,=20by=20trying=20to=20provi= de=20a=20road=20map=20for=20how=20we=20got=20here.=20=20Some=20of=20this= =20history=20may=20be=20from=20the=20sip-forum=20and=20not=20Martini=20or= =20Dispatch,=20but=20it=20gets=20to=20the=20general=20issue. Probably=20the=20biggest=20issue=20we=20hit/debated=20about=20ETSI/3gpp/d= raft-shaken=20was=20the=20specific=20details=20of=20how=20to=20route=20re= quests=20to=20the=20IP-PBX.=20=20I=20think=20that's=20also=20the=20change= =20that=20most=20people=20are=20upset=20about=20being=20different=20from= =203gpp.=20=20So=20I'll=20just=20cover=20that. The=20problems=20found=20in=20the=20field=20are=20that=20different=20IP-P= BX's=20expect=20different=20things=20in=20the=20request-uri:=20some=20exp= ect=20only=20SIP=20URI's;=20some=20can't=20handle=20their=20contact-URI= =20being=20in=20a=20Route=20header;=20some=20expect=20their=20registered= =20contact=20in=20the=20req-uri;=20some=20expect=20various=20username=20f= ormats.=20=20It's=20all=20over=20the=20map. So=20we=20were=20trying=20to=20say=20"well=20if=20you=20do=20this=20optio= n-tag=20then=20you=20must=20accept=20XYZ".=20=20So=20then=20we=20got=20in= to=20what=20is=20the=20XYZ. We=20started=20with=20loose-route:=20the=20SSP=20just=20inserts=20the=20R= egistered=20Contact-URI=20as=20a=20loose-route,=20and=20leaves=20the=20re= q-URI=20alone. And=20then=20we=20hit=20the=20first=20snag:=20what=20req-uri=20user=20por= tion=20does=20the=20IP-PBX=20actually=20expect/understand?=20=20We've=20s= een=20problems=20with=20that=20in=20the=20field=20too=20-=20some=20expect= =20a=20leading=20"+",=20some=20don't;=20some=20expect=20a=20country-code,= =20some=20don't;=20some=20can=20handle=20the=20visual-separators,=20some= =20can't;=20some=20do=20Tel-URI,=20some=20don't.=20=20What=20the=20SSP=20= gets=20is=20any/all=20forms=20with=20all=20kinds=20of=20number=20transfor= m=20rules,=20but=20the=20IP-PBX=20type=20we're=20targeting=20is=20simple.= =20=20There=20were=20several=20proposals=20for=20how=20to=20handle=20this= ,=20including=20even=20just=20normalizing=20the=20username=20to=20some=20= common=20format/scheme=20before=20sending=20it=20to=20the=20IP-PBX.=20=20= OK,=20so=20now=20the=20SSP=20is=20modifying=20the=20req-uri=20username,= =20but=20that's=20do-able. Then=20we=20hit=20the=20second=20snag:=20what=20req-uri=20host=20portion= =20does=20the=20IP-PBX=20actually=20expect/understand?=20=20In=20practice= =20it=20usually=20expects=20its=20own=20(its=20hostname/ip/domain).=20=20= It's=20not=20*actually*=20in=20the=20SSP's=20domain,=20after=20all.=20=20= But=20we=20figured=20we'll=20just=20mandate=20it=20is=20for=20its=20speci= fic=20AoR's,=20or=20that=20it=20least=20owns/controls/is-authoritative=20= for=20those=20AoR's.=20=20But=20then=20we=20realized=20that=20the=20req-u= ri=20the=20SSP=20Proxy=20literally=20gets=20(before=20looking=20it=20up= =20and=20routing=20it)=20isn't=20always=20known=20to=20the=20IP-PBX=20eit= her=20-=20it's=20not=20always=20the=20domain,=20for=20example=20-=20it=20= could=20be=20and=20often=20is=20the=20SSP's=20Proxy's=20hostname=20or=20I= P=20or=20sub-domain=20in=20the=20SSP. So=20now=20we're=20transforming=20the=20host=20portion=20too,=20to=20beco= me=20the=20SSP's=20domain,=20just=20so=20the=20IP-PBX=20recognizes=20that= =20it's=20NOT=20the=20SSP's=20domain=20but=20instead=20one=20of=20its=20A= oR's,=20which=20were=20really=20one=20of=20the=20SSP's=20AoR's.=20=20Conf= using,=20huh? So=20now=20we're=20deep=20into=20defining=20a=20request-uri=20transformat= ion=20model,=20to=20make=20sure=20the=20req-uri=20the=20IP-PBX=20gets=20l= ooks=20like=20a=20"canonical"=20AoR=20it=20will=20expect=20to=20get.=20Th= e=20original=20concept=20was=20to=20"leave=20it=20alone",=20but=20it's=20= not=20_really_=20left=20alone.=20=20And=20trust=20me=20it's=20virtually= =20NEVER=20left=20alone,=20in=20practice.=20=20Think=20about=20all=20the= =20number=20translations,=20number=20manipulations,=20host=20replacement= =20rules,=20etc.,=20the=20Proxy=20and=20SBC=20vendors=20have.=20=20They'r= e=20incredibly=20popular,=20because=20they're=20what=20make=20calls=20act= ually=20succeed.=20=20But=20we're=20trying=20to=20cover=20that=20SMB=20ma= rket=20thing,=20without=20unique=20rules=20per=20IP-PBX=20vendor/model,= =20and=20with=20frankly=20dumb,=20cheap,=20crappy=20IP-PBX's.=20(no=20off= ense=20to=20IP-PBX=20vendors=20-=20but=20I'm=20not=20talking=20about=20th= e=20vendors=20that=20go=20to=20standards=20bodies=20:) Meanwhile,=20another=20group=20of=20folks=20were=20saying=20"wait=20a=20m= inute,=20we=20already=20have=20a=20request-uri=20'transformation'=20and= =20routing=20model=20for=20Registered=20AoR's:=20it's=20called=20RFC=2032= 61.=20Why=20re-create=20the=20wheel,=20when=20there's=20already=20a=20whe= el=20around=20that's=20proven=20to=20work?"=20=20That's=20a=20pretty=20st= rong=20argument. There=20were=20also=20arguments=20that=20we=20technically=20have=20no=20l= oose-route=20mechanism=20for=20Registered=20AoR's=20-=20there=20was=20JDR= 's=20draft,=20but=20it=20got=20nixed.=20=20I=20personally=20wasn't=20buyi= ng=20that=20argument=20much=20(after=20all,=20we're=20defining=20a=20stan= dards-track=20spec,=20so=20we=20could=20just=20do=20it,=20and=20there's= =20enough=20wiggle=20room=20in=203261's=20language=20that=20one=20could= =20claim=20it's=20just=20a=20specific=20"local=20policy"=20step). But=20in=20fairness=20there=20may=20well=20be=20unintended=20consequences= =20for=20doing=20loose-route=20in=20draft-shaken/IMS/etc.=20model=20for= =20E.164=20AoR's.=20=20For=20example,=20if=20the=20IP-PBX=20*was*=20misco= nfigured=20and=20doesn't=20think=20it=20owns=20an=20AoR=20the=20SSP=20thi= nks=20it=20owns,=20what=20happens?=20=20The=20SSP=20routes=20it=20to=20th= e=20IP-PBX.=20=20The=20IP-PBX=20then=20routes=20it=20to=20the=20SSP=20(in= =20some=20cases).=20=20Nice=20loop.=20=20But=20that's=20not=20the=20probl= em=20-=20it's=20a=20symptom,=20not=20the=20cause=20-=20the=20cause=20is= =20we=20sent=20a=20request=20from=20domain=20A=20to=20domain=20B,=20with= =20domain=20*A*=20as=20the=20target. -hadriel ****=20DISCLAIMER=20**** http://www.belgacom.be/maildisclaimer --_000_208EAE1DFA28FC419529619ABB8622441617E1A960CMS03BGCNET_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi=20guys,

 

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

 

Kind=20regards

 

Jan=20Van=20Geel=20
IT=20and=20Network=20Development=20Specialist=20
Belgacom=20SDE/SDV/PSE/NST/NCP=20
Tel:=20+32=202=20202=201035=20
Tel:=20+32=202=20207=209032=20
Email=20:=20jan.van.geel@belgacom.be=20
www.cyberwezz.tk=20

 

From:=20martini-bounces@ietf.org [mailto:martini-bounces@ietf.org]=20On=20Behalf=20Of=20Hans=20Erik= =20van=20Elburg
Sent:=2007=20April=202010=2015:26
To:=20Hadriel=20Kaplan;=20Spencer=20Dawkins
Cc:=20bernard_aboba@hotmail.com;=20martini@ietf.org
Subject:=20Re:=20[martini]=20Hitchhiker's=20Guide=20to=20Making=20= Martini=20(was:=20The IETF=20versus=20reality)

 

Thanks=20Hadriel=20for=20providing=20the=20excelle= nt=20overview,=20hope this=20gets=20the=20discussion=20back=20on=20track.

Just=20to=20put=20this=20remark=20from=20Spencer=20on=20the=20right=20thr= ead,=20it=20seems=20important and=20the=20crucial=20fundamental=20point=20where=20people=20have=20diffe= rent=20opinions:
<spencer>
 =20<hadriel>

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

  =20&l= t;/hadriel>

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

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

And=20that's=20how=20we=20got=20to=20GIN.
</spencer>=20
/Hans=20Erik=20van=20Elburg

On=20Wed,=20Apr=207,=202010=20at=205:04=20AM,=20Ha= driel=20Kaplan=20<HKaplan@acmepacket.com>=20w= rote:


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

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

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

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

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

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

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

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

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

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

There=20were=20also=20arguments=20that=20we=20technically=20have=20no=20l= oose-route=20mechanism=20for Registered=20AoR's=20-=20there=20was=20JDR's=20draft,=20but=20it=20got=20= nixed.=20 I=20personally wasn't=20buying=20that=20argument=20much=20(after=20all,=20we're=20defini= ng=20a=20standards-track spec,=20so=20we=20could=20just=20do=20it,=20and=20there's=20enough=20wigg= le=20room=20in=203261's=20language that=20one=20could=20claim=20it's=20just=20a=20specific=20"local=20p= olicy"=20step).

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

-hadriel

 

****=20DI=
SCLAIMER=20****
http://www.belgacom.be/maildisclaimer
--_000_208EAE1DFA28FC419529619ABB8622441617E1A960CMS03BGCNET_-- From ietf.hanserik@gmail.com Thu Apr 8 01:56:14 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8B523A67FF for ; Thu, 8 Apr 2010 01:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FblbEF-ob2Fu for ; Thu, 8 Apr 2010 01:56:12 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 12D603A67CF for ; Thu, 8 Apr 2010 01:56:11 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so175617eyf.51 for ; Thu, 08 Apr 2010 01:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=jkY3zX8xWoprKpDYkUsc45SIItXIoXR0swr5Oru+hAw=; b=UGukIKaxXRe4TBaWnMYSrHOmsIJ0dVMuilap56s50uXnK8b3g0X/2arZpkTbtA65KI CZlIMO+SR+doLVTiSY8wz+ByL2cTsAlsLF7AFVl305W98JEUcvIeufN60tBxCURekAH0 Heo5fTdaeQdH5nOQKsk4onzgPURMsrVOIRw6I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=c5ifIodJBNcVtJTNMVlXy9CJxO1tfnQFxvnUgeJpjmX9MzH769cLKBJ/BUZpai5FKb QmB8jUf4a73cdWMaXJ3og8pmNg9alZOcquHY8+FlA9GxftoHFyamMBD/rvRpAXhjCnfK lCC05n4CN59ByPdY9XR3V5hgAh7Ppq8vfAy9o= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Thu, 8 Apr 2010 01:56:05 -0700 (PDT) In-Reply-To: <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> References: <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com> <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> Date: Thu, 8 Apr 2010 10:56:05 +0200 Received: by 10.213.45.197 with SMTP id g5mr6025433ebf.94.1270716965218; Thu, 08 Apr 2010 01:56:05 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: jan.van.geel@belgacom.be, martini@ietf.org, Hadriel Kaplan Content-Type: multipart/alternative; boundary=00c09fc2bee7526cb20483b5d94a Cc: bernard_aboba@hotmail.com Subject: Re: [martini] Hitchhiker's Guide to Making Martini (was: The IETF versus reality) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 08:56:14 -0000 --00c09fc2bee7526cb20483b5d94a Content-Type: text/plain; charset=ISO-8859-1 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, 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* > IT and Network Development Specialist > Belgacom SDE/SDV/PSE/NST/NCP > Tel: +32 2 202 1035 > Tel: +32 2 207 9032 > Email : jan.van.geel@belgacom.be > www.cyberwezz.tk > > > > *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] *On > Behalf Of *Hans Erik van Elburg > *Sent:* 07 April 2010 15:26 > *To:* Hadriel Kaplan; Spencer Dawkins > > *Cc:* bernard_aboba@hotmail.com; martini@ietf.org > *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: > > > > 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. > > > /Hans Erik van Elburg > > On Wed, Apr 7, 2010 at 5:04 AM, Hadriel Kaplan > 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). > > 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 > > > > **** DISCLAIMER ****http://www.belgacom.be/maildisclaimer > > --00c09fc2bee7526cb20483b5d94a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree misconfiguration is a pretty weak argument as it can be used to der= ail any solution. Although some solutions are more robust then others in th= e 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 t= he target." or more general "entering a land where we expect SIP nodes to ignore domain names in the request URI and=20 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.&q= uot;

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 us= ing the Route-header-to-PBX solution. I do think this aspect is underspecif= ied 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 n= odes to ignore [replace] domain names in the request URI and=20 route based on "something else" [configured policy, i own this user all= though i don't own the number (my operator owns it)] from a SIP node th= at was authoritative for the domain to a destination that wasn't authoritative for the domain.&q= uot; text in [] brackets added by me.

Because otherwise we would for= bid certain business models where certain activities (routing to the end us= er) 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, <jan.van.geel@belga= com.be> wrote:

Hi guys= ,

=A0

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

=A0

Kind re= gards

=A0

Jan= Van Geel
IT and Network Develop= ment Specialist
Belgacom SDE/SDV/PSE/N= ST/NCP
Tel: +32 2 202 1035
Tel: +32 2 207 9032
Email : jan.van.geel@belgacom.be
www.cyberwezz.tk

=A0

F= rom: martini-bounces@ietf.org= [mailto:marti= ni-bounces@ietf.org] On Behalf Of Hans Erik van Elburg
Sent: 07 April 2010 15:26
To: Hadriel Kaplan; Spencer Dawkins


Cc: b= ernard_aboba@hotmail.com; martini@ietf.org
Subject: Re: [martini] Hitchhiker's Guide to Making Martin= i (was: The IETF versus reality)

=A0

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 importan= t and the crucial fundamental point where people have different opinions:
<spencer>
=A0 <hadriel>

But in fairness there may well be unintended consequ= ences for doing
loose-route in draft-shaken/IMS/etc. model for E.164 AoR's. =A0For exam= ple,
if the IP-PBX *was* misconfigured and doesn't think it owns an AoR the<= br> SSP thinks it owns, what happens? =A0The SSP routes it to the IP-PBX. =A0The
IP-PBX then routes it to the SSP (in some cases). =A0Nice loop. =A0But 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.

=A0=A0 </hadriel&g= t;

When we actually said this out loud, we realized that we were entering a la= nd where we expect SIP nodes to ignore domain names in the request URI and rou= te 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. M= y 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>

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 5:04 AM, Hadriel Kaplan <<= a href=3D"mailto:HKaplan@acmepacket.com" target=3D"_blank">HKaplan@acmepack= et.com> wrote:


Let me try and cut to the chase, by trying to provide a road map for how we= got here. =A0Some 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. =A0I think that= 9;s also the change that most people are upset about being different from 3gpp. =A0So I'll just cover that.

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

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

We started with loose-route: the SSP just inserts the Registered Contact-UR= I 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? =A0We've seen problems with that in the fie= ld too - some expect a leading "+", some don't; some expect a country-code, some don't; some can handle the visual-separators, some c= an't; some do Tel-URI, some don't. =A0What the SSP gets is any/all forms with= all kinds of number transform rules, but the IP-PBX type we're targeting is= simple. =A0There 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. =A0OK, so now the SSP is modifying the req-uri username, but that&#= 39;s do-able.

Then we hit the second snag: what req-uri host portion does the IP-PBX actu= ally expect/understand? =A0In practice it usually expects its own (its hostname/ip/domain). =A0It's not *actually* in the SSP's domain, af= ter all. =A0But 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. =A0But then we realized that the req-uri the SSP Proxy literally gets (before looking it u= p 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 ho= stname 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 in= stead one of its AoR's, which were really one of the SSP's AoR's. =A0Confusi= ng, 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. =A0And trust me it's virtually NEVER left alon= e, in practice. =A0Think about all the number translations, number manipulations, host replacement rules, etc., the Proxy and SBC vendors have. =A0They'r= e incredibly popular, because they're what make calls actually succeed. = =A0But we're trying to cover that SMB market thing, without unique rules per I= P-PBX vendor/model, and with frankly dumb, cheap, crappy IP-PBX's. (no offens= e to IP-PBX vendors - but I'm not talking about the vendors that go to stand= ards bodies :)

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

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. =A0I pe= rsonally wasn't buying that argument much (after all, we're defining a stand= ards-track spec, so we could just do it, and there's enough wiggle room in 3261= 9;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-r= oute in draft-shaken/IMS/etc. model for E.164 AoR's. =A0For example, if the IP-PBX *was* misconfigured and doesn't think it owns an AoR the SSP thi= nks it owns, what happens? =A0The SSP routes it to the IP-PBX. =A0The IP-PBX then routes it to the SSP (in some cases). =A0Nice loop. =A0But 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

=A0

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

--00c09fc2bee7526cb20483b5d94a-- From ietf.hanserik@gmail.com Thu Apr 8 02:08:14 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ECF33A6901 for ; Thu, 8 Apr 2010 02:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCDaO2yQxTa3 for ; Thu, 8 Apr 2010 02:08:12 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 1855A3A6A2B for ; Thu, 8 Apr 2010 02:08:07 -0700 (PDT) Received: by ewy6 with SMTP id 6so595982ewy.32 for ; Thu, 08 Apr 2010 02:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=73VQvCxAMGvfjHnRInQfJ3fJhtAFa1nm3US8l5BL8VA=; b=aMo0xSmFc4hsI8aZKUpGxPBIS57QI2ZUsp2DZ9NjWO+RRC/uwp+/7TeTzNtXi5PKDc ctCLICYFvcTwXS3lwNwjAIA53se/12y/c7Uh5c1i59LDGwMGjpB1fRTfbgY4oS1W3Zc1 pMVMTwJQf0lYqPCNZ3y0wSgpI1d08FUo8lwCA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=v+dhCgoPItX6x5ffZtNjo/2ooHQtAq/AyQpBWmDsHivN9ybICzfrhS0Arib08uY4b2 Uwo6GzJ9OJ4jJlkINtpxo/JmOEV/uaU5CosimQo+N8m2f/6SJNQZze83y7GXZxhLG11n bayfHuaMyEAaAxqlwRsrv6aV/oZJsOHvjc6os= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Thu, 8 Apr 2010 02:08:01 -0700 (PDT) In-Reply-To: <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> References: <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com> <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> Date: Thu, 8 Apr 2010 11:08:01 +0200 Received: by 10.213.47.83 with SMTP id m19mr2686884ebf.92.1270717681551; Thu, 08 Apr 2010 02:08:01 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: jan.van.geel@belgacom.be Content-Type: multipart/alternative; boundary=001485ea7dca04cb6e0483b604c3 Cc: bernard_aboba@hotmail.com, HKaplan@acmepacket.com, martini@ietf.org Subject: Re: [martini] Hitchhiker's Guide to Making Martini (was: The IETF versus reality) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 09:08:14 -0000 --001485ea7dca04cb6e0483b604c3 Content-Type: text/plain; charset=ISO-8859-1 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. 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 shaken solution. I do think this aspect is underspecified in the shaken 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, 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* > IT and Network Development Specialist > Belgacom SDE/SDV/PSE/NST/NCP > Tel: +32 2 202 1035 > Tel: +32 2 207 9032 > Email : jan.van.geel@belgacom.be > www.cyberwezz.tk > > > > *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] *On > Behalf Of *Hans Erik van Elburg > *Sent:* 07 April 2010 15:26 > *To:* Hadriel Kaplan; Spencer Dawkins > > *Cc:* bernard_aboba@hotmail.com; martini@ietf.org > *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: > > > > 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. > > > /Hans Erik van Elburg > > On Wed, Apr 7, 2010 at 5:04 AM, Hadriel Kaplan > 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). > > 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 > > > > **** DISCLAIMER ****http://www.belgacom.be/maildisclaimer > > --001485ea7dca04cb6e0483b604c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree misconfiguration is a pretty weak argument as it can be used to der= ail any solution. Although some solutions are more robust then others in th= e presence of some msiconfigured 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 t= he target." or more general "entering a land where we expect SIP nodes to ignore domain names in the request URI and=20 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.&q= uot;

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 us= ing the shaken solution. I do think this aspect is underspecified in the sh= aken 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 n= odes to ignore [replace] domain names in the request URI and=20 route based on "something else" [configured policy, i own this user all= though i don't own the number (my operator owns it)] from a SIP node th= at was authoritative for the domain to a destination that wasn't authoritative for the domain.&q= uot; text in [] brackets added by me.

Because otherwise we would for= bid certain business models where certain activities (routing to the end us= er) 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, <jan.van.geel@belgacom.be> wrote:

Hi guys= ,

=A0

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

=A0

Kind re= gards

=A0

Jan= Van Geel
IT and Network Develop= ment Specialist
Belgacom SDE/SDV/PSE/N= ST/NCP
Tel: +32 2 202 1035
Tel: +32 2 207 9032
Email : jan.van.geel@belgacom.be
www.cyberwezz.tk

=A0

F= rom: martini-bounces@ietf.org= [mailto:marti= ni-bounces@ietf.org] On Behalf Of Hans Erik van Elburg
Sent: 07 April 2010 15:26
To: Hadriel Kaplan; Spencer Dawkins

Subject: Re: [martini] Hitchhiker's Guide to Making Martin= i (was: The IETF versus reality)

=A0

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 importan= t and the crucial fundamental point where people have different opinions:
<spencer>
=A0 <hadriel>

But in fairness there may well be unintended consequ= ences for doing
loose-route in draft-shaken/IMS/etc. model for E.164 AoR's. =A0For exam= ple,
if the IP-PBX *was* misconfigured and doesn't think it owns an AoR the<= br> SSP thinks it owns, what happens? =A0The SSP routes it to the IP-PBX. =A0The
IP-PBX then routes it to the SSP (in some cases). =A0Nice loop. =A0But 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.

=A0=A0 </hadriel&g= t;

When we actually said this out loud, we realized that we were entering a la= nd where we expect SIP nodes to ignore domain names in the request URI and rou= te 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. M= y 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>

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 5:04 AM, Hadriel Kaplan <<= a href=3D"mailto:HKaplan@acmepacket.com" target=3D"_blank">HKaplan@acmepack= et.com> wrote:


Let me try and cut to the chase, by trying to provide a road map for how we= got here. =A0Some 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. =A0I think that= 9;s also the change that most people are upset about being different from 3gpp. =A0So I'll just cover that.

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

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

We started with loose-route: the SSP just inserts the Registered Contact-UR= I 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? =A0We've seen problems with that in the fie= ld too - some expect a leading "+", some don't; some expect a country-code, some don't; some can handle the visual-separators, some c= an't; some do Tel-URI, some don't. =A0What the SSP gets is any/all forms with= all kinds of number transform rules, but the IP-PBX type we're targeting is= simple. =A0There 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. =A0OK, so now the SSP is modifying the req-uri username, but that&#= 39;s do-able.

Then we hit the second snag: what req-uri host portion does the IP-PBX actu= ally expect/understand? =A0In practice it usually expects its own (its hostname/ip/domain). =A0It's not *actually* in the SSP's domain, af= ter all. =A0But 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. =A0But then we realized that the req-uri the SSP Proxy literally gets (before looking it u= p 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 ho= stname 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 in= stead one of its AoR's, which were really one of the SSP's AoR's. =A0Confusi= ng, 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. =A0And trust me it's virtually NEVER left alon= e, in practice. =A0Think about all the number translations, number manipulations, host replacement rules, etc., the Proxy and SBC vendors have. =A0They'r= e incredibly popular, because they're what make calls actually succeed. = =A0But we're trying to cover that SMB market thing, without unique rules per I= P-PBX vendor/model, and with frankly dumb, cheap, crappy IP-PBX's. (no offens= e to IP-PBX vendors - but I'm not talking about the vendors that go to stand= ards bodies :)

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

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. =A0I pe= rsonally wasn't buying that argument much (after all, we're defining a stand= ards-track spec, so we could just do it, and there's enough wiggle room in 3261= 9;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-r= oute in draft-shaken/IMS/etc. model for E.164 AoR's. =A0For example, if the IP-PBX *was* misconfigured and doesn't think it owns an AoR the SSP thi= nks it owns, what happens? =A0The SSP routes it to the IP-PBX. =A0The IP-PBX then routes it to the SSP (in some cases). =A0Nice loop. =A0But 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

=A0

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

--001485ea7dca04cb6e0483b604c3-- From HKaplan@acmepacket.com Thu Apr 8 02:14:49 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00603A67CF for ; Thu, 8 Apr 2010 02:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.694, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4YlR6ZwGH-t for ; Thu, 8 Apr 2010 02:14:49 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7CFB93A682D for ; Thu, 8 Apr 2010 02:14:48 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 05:14:43 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 05:14:43 -0400 From: Hadriel Kaplan To: "jan.van.geel@belgacom.be" , "ietf.hanserik@gmail.com" , "spencer@wonderhamster.org" Date: Thu, 8 Apr 2010 05:14:43 -0400 Thread-Topic: [martini] Hitchhiker's Guide to Making Martini (was: The IETF versus reality) Thread-Index: AcrWVd002KcI8CRkQ3qea2GTIweSAQAj+LlgAAUwLTA= Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D1D0@mail> References: <9ECCF01B52E7AB408A7EB85352642141014F58BD@ftrdmel0.rd.francetelecom.fr> <4BBB4F38.7050208@nostrum.com> <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com> <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> In-Reply-To: <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] Hitchhiker's Guide to Making Martini (was: The IETF versus reality) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 09:14:49 -0000 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 h= ad changed the routing model of SIP, without intending to change the routin= g model of SIP. :( -hadriel > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f=20 > Of jan.van.geel@belgacom.be > Sent: Thursday, April 08, 2010 2:37 AM > > Hi guys, > To my opinion the network and protocol is not and should not be=20 > responsible for solving (human) errors like misconfiguration ! > Kind regards > Jan Van Geel From HKaplan@acmepacket.com Thu Apr 8 02:33:41 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9143A69EA for ; Thu, 8 Apr 2010 02:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.670, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1txBB6l-4jT for ; Thu, 8 Apr 2010 02:33:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E75453A6407 for ; Thu, 8 Apr 2010 02:33:40 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 05:33:35 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 05:33:35 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg , "jan.van.geel@belgacom.be" , "martini@ietf.org" Date: Thu, 8 Apr 2010 05:33:35 -0400 Thread-Topic: [martini] Hitchhiker's Guide to Making Martini (was: The IETF versus reality) Thread-Index: AcrW+VSNiIjTpCpjTgunILCUtedgjQAAsfPg Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D1D7@mail> References: <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com> <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bernard_aboba@hotmail.com" Subject: Re: [martini] Hitchhiker's Guide to Making Martini (was: The IETF versus reality) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 09:33:41 -0000 Hi Hans Erik, Comments inline... > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: Thursday, April 08, 2010 4:56 AM > > I don't think that this is implied by the use of the Route header for=20 > routing. For some reason people think that this is implied by using the=20 > Route-header-to-PBX solution. I do think this aspect is underspecified in= =20 > the Route-header-to-PBX solution. > > I don't think that it is bad in all cases to "entering a land where we=20 > expect [specific PBX or SSPentities in trunking arrangement] SIP nodes to= =20 > ignore [replace] domain names in the request URI and route based on=20 > "something else" [configured policy, i own this user allthough i don't ow= n=20 > the number (my operator owns it)] from a SIP node that was authoritative= =20 > for the domain to a destination that wasn't authoritative for the domain.= "=20 > text in [] brackets added by me. I'll reply to that in a separate thread. > Because otherwise we would forbid certain business models where certain=20 > activities (routing to the end user) are delegated to another party (PBX)= ,=20 > which can not be the intent of a standard. That is actually what martini= =20 > is trying to achieve. > > The fundamental issue is whether it is allowed to delegate authority to=20 > other parties. My question would be, why should that be forbidden? 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 i= dentifying the intended target, including the domain, is deeply entrenched.= Obviously there is a loose-route model, but when it is used it does not c= hange the intended target. For example, there are dependencies on that dom= ain 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 consens= us in the IETF to go that path, without a lot more worry/work/time. -hadriel From HKaplan@acmepacket.com Thu Apr 8 03:03:27 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACEEF3A6872 for ; Thu, 8 Apr 2010 03:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWATNUqUQJqM for ; Thu, 8 Apr 2010 03:03:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A564F3A683C for ; Thu, 8 Apr 2010 03:03:26 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 06:03:20 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 06:03:20 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg , "martini@ietf.org" Date: Thu, 8 Apr 2010 06:03:19 -0400 Thread-Topic: Changing the domain (was: Hitchhiker's Guide to Making Martini) Thread-Index: AcrW+VSNiIjTpCpjTgunILCUtedgjQAAsfPg Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D1DA@mail> References: <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com> <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [martini] Changing the domain (was: Hitchhiker's Guide to Making Martini) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 10:03:27 -0000 Hi Hans Erik, Comments inline... > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: Thursday, April 08, 2010 4:56 AM > > I don't think that this is implied by the use of the Route header for=20 > routing. For some reason people think that this is implied by using the=20 > Route-header-to-PBX solution. I do think this aspect is underspecified in= =20 > the Route-header-to-PBX solution. > > I don't think that it is bad in all cases to "entering a land where we=20 > expect [specific PBX or SSPentities in trunking arrangement] SIP nodes to= =20 > ignore [replace] domain names in the request URI and route based on=20 > "something else" [configured policy, i own this user allthough i don't ow= n=20 > the number (my operator owns it)] from a SIP node that was authoritative= =20 > for the domain to a destination that wasn't authoritative for the domain.= "=20 > 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 w= as 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 SI= P 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) =20 The only one who could do that (legally) would be the SSP, so I was prepare= d-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 "s= aving" the request-URI parameters. But that just goes right back to the de= bate 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 f= or handling those. :( -hadriel From ietf.hanserik@gmail.com Thu Apr 8 05:10:31 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0DBE3A68DC for ; Thu, 8 Apr 2010 05:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRFIuCRN2kHO for ; Thu, 8 Apr 2010 05:10:30 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 80A033A67FC for ; Thu, 8 Apr 2010 05:10:26 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so185658eyf.51 for ; Thu, 08 Apr 2010 05:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=bxVtLuK8ffSIxTFZDSgTlrnSqQZ3yhCLXzqBs8TjgHM=; b=vys734WAFB4+tDukiFNCCHPHoUA04t8JYMZeoTfIi4CETBiuyfFcNBmK/TUHFHiQmn XfiwZ5X29oyVSk/NU6VFqGJTHzKg4TOyP+gh1oybdpbr5W2z5cZeEdt04+vNLLkecBns NYxC+kuMYvsbu+Unxy5HnzvgakcW8hC6FZJxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HkX6ZQL6Gkvc9dGR2jd6FfKLC1Ahkc3fulSVcAFbzkusTUXAhN5jJja2S+ql2nTgfq kESIlLfa1GgwZ/q8iVUeOd+2fb88gB78bsGrhmOJ3s2vi8CXLxakMxq1yuONcO6ghD9J XDF6JOlaZUXA7qP3XGGBNYl73EsHUbtZ5Ut9U= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Thu, 8 Apr 2010 05:10:20 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D1DA@mail> References: <4BBB7A48.7050801@nostrum.com> <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> <430FC6BDED356B4C8498F634416644A91A79F3D1DA@mail> Date: Thu, 8 Apr 2010 14:10:20 +0200 Received: by 10.213.76.12 with SMTP id a12mr23194ebk.55.1270728620050; Thu, 08 Apr 2010 05:10:20 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=00c09f74895e010a4d0483b8903d Cc: "martini@ietf.org" Subject: Re: [martini] Changing the domain (was: Hitchhiker's Guide to Making Martini) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 12:10:31 -0000 --00c09f74895e010a4d0483b8903d Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > Hi Hans Erik, > Comments inline... > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: Thursday, April 08, 2010 4:56 AM > > > > 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. > > 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 > > --00c09f74895e010a4d0483b8903d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hadriel,

In priciple there is never a problem with changing the n= ame of the domain on numbers (expressed as a SIP URI) as it is not identifi= eing the target user in any way. For numbers the only use of the domain nam= e 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 th= at 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= =20 as well.

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

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 prefe= rs on the SIP trunk.

Note that the ETSI/3GPP solution also still al= lows the use of a third method that is that the contact is placed in the Re= quest-URI and the target in the P-Called-Party-Identity... this however als= o requires special behaviour on the PBX side. BTW I view the History-Info w= ay 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 als= o 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 <HKa= plan@acmepacket.com> wrote:
Hi Hans Erik,
Comments inline...

> -----Original Message-----
> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
> Sent: Thursday, April 08, 2010 4:56 AM
>
> 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 th= e
> 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 allthou= gh i don't own
> the number (my operator owns it)] from a SIP node that was authoritati= ve
> for the domain to a destination that wasn't authoritative for the = domain."
> 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 w= as a distributed proxy system all of the same domain where the proxy in the= Enterprise just handles those AoRs. =A0But that raised red flags of "= but it's NOT the same domain - prove to us there are no interactions wi= th every SIP RFC, because SIP always assumed a proxy within a domain is aut= horitative 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 al= ways 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 prepare= d-for/fine-with the SSP changing the domain to be the IP-PBX. =A0But then i= t occurred to me we're now changing the user portion, and changing the = domain, so what are we NOT changing? =A0The "@" character? ;)

The only thing we would gain, by circumventing rfc3261's rules, would b= e "saving" the request-URI parameters. =A0But that just goes righ= t back to the debate about loose-route vs. Target vs. hist-info, and subver= ting hist-info. =A0And I'm definitely no fan of hist-info, but that'= ;s what we're stuck with for handling those. :(

-hadriel


--00c09f74895e010a4d0483b8903d-- From HKaplan@acmepacket.com Thu Apr 8 06:23:50 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24553A6A6B for ; Thu, 8 Apr 2010 06:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3CuxnzVi658 for ; Thu, 8 Apr 2010 06:23:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7243728C13A for ; Thu, 8 Apr 2010 06:22:45 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 09:22:36 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 09:22:36 -0400 From: Hadriel Kaplan To: "martini@ietf.org" Date: Thu, 8 Apr 2010 09:22:35 -0400 Thread-Topic: Email formats Thread-Index: AcrXHo2lP3xbZBMiT3CEdY2EMD/LQA== Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D214@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [martini] Email formats X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 13:23:50 -0000 Folks, please use plain text emails - I've gotten feedback that some people have p= roblems in their email viewers seeing the html and embedded responses in th= at format.=20 -hadriel From HKaplan@acmepacket.com Thu Apr 8 06:38:58 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1AC63A6893 for ; Thu, 8 Apr 2010 06:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdD4vfPzWqiP for ; Thu, 8 Apr 2010 06:38:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4CA1C3A67EF for ; Thu, 8 Apr 2010 06:38:54 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 09:38:50 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 09:38:50 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Thu, 8 Apr 2010 09:38:48 -0400 Thread-Topic: Changing the domain (was: Hitchhiker's Guide to Making Martini) Thread-Index: AcrXFILEblHv9cdcRDqty20BB63/KAACcrhA Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D222@mail> References: <4BBB7A48.7050801@nostrum.com> <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> <430FC6BDED356B4C8498F634416644A91A79F3D1DA@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Changing the domain (was: Hitchhiker's Guide to Making Martini) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 13:38:58 -0000 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 an= yway) 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 tur= n the page and get closer to the end. :) Other comments inline... > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: Thursday, April 08, 2010 8:10 AM > > For alphanumeric SIP-uri's this is not true but martini just choose to=20 > ignore that case... You can't say on one hand oh oh oh how awful that=20 > approach breaks SIP routing and on the other hand accept a solution that= =20 > breaks ... SIP routing. To use equally strong wording. In both cases this= =20 > strong wording does not apply and non-constructive fights are=20 > preprogrammed. In what way does GIN break SIP routing?? > Did not understand what you ment with that the user part needs changing a= s=20 > well. That was explained in the hitchhiker's guide. :) > It would resolve an issue with existing approaches and at the same time=20 > let the pbx or SSP choose what kind of broken SIP routing flavour it=20 > prefers on the SIP trunk.=20 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. =20 That's the rub, no matter what happens. So now you're saying, "we have mor= e than 2 current mechanisms, let's add 2 more"? And as a side note, though not the main issue: for the GIN draft the REGIST= ER 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 BLINDSAY@nortel.com Thu Apr 8 06:41:36 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99DA63A6A39 for ; Thu, 8 Apr 2010 06:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-V7KNPyl5E9 for ; Thu, 8 Apr 2010 06:41:35 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E239E3A6841 for ; Thu, 8 Apr 2010 06:41:32 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o38DfOf14552; Thu, 8 Apr 2010 13:41:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Apr 2010 09:40:56 -0400 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141D2682CF@zcarhxm1.corp.nortel.com> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D1DA@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Changing the domain (was: Hitchhiker's Guide to MakingMartini) Thread-Index: AcrW+VSNiIjTpCpjTgunILCUtedgjQAAsfPgAAjqNtA= References: <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com><4BBB7A48.7050801@nostrum.com><4BBBAF3E.2080400@nostrum.com><430FC6BDED356B4C8498F634416644A91A79F3CF54@mail><208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> <430FC6BDED356B4C8498F634416644A91A79F3D1DA@mail> From: "Brian Lindsay" To: "Hadriel Kaplan" , "Hans Erik van Elburg" , Subject: Re: [martini] Changing the domain (was: Hitchhiker's Guide to MakingMartini) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 13:41:36 -0000 Hi Hadriel, You've discussed changing the user portion below. Can you clarify why the user portion would change in the Shaken approach?=20 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: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Thursday, April 08, 2010 6:03 AM To: Hans Erik van Elburg; martini@ietf.org Subject: [martini] Changing the domain (was: Hitchhiker's Guide to MakingMartini) Hi Hans Erik, Comments inline... > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Thursday, April 08, 2010 4:56 AM > > I don't think that this is implied by the use of the Route header for=20 > routing. For some reason people think that this is implied by using=20 > the Route-header-to-PBX solution. I do think this aspect is=20 > 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=20 > authoritative for the domain to a destination that wasn't authoritative for the domain." > 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) =20 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 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From ietf.hanserik@gmail.com Thu Apr 8 07:13:02 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B920A3A68C1 for ; Thu, 8 Apr 2010 07:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmTsJzU1u2lk for ; Thu, 8 Apr 2010 07:12:59 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 3B3ED3A690A for ; Thu, 8 Apr 2010 07:12:59 -0700 (PDT) Received: by ewy24 with SMTP id 24so45162ewy.13 for ; Thu, 08 Apr 2010 07:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=bbpt++nt0jjM2RTqQZpeGw+XEMyHUJyZy7a4EPK+oP4=; b=O3D346HiU+uSgomoScp3rN1l6CDyz0rT7zFGuq2JeF5HOc4uID2kkUY9jYzT+Kv8Kg rhiJZwg7QvWEwMl/liCcM6sRUXknw2FEBYyHD5yA1p4VdGwulokAZQO8oZRO1Ul8p/S5 GkSAdZZKHywS9TyCm28k+sNTD6UrCVxqJ0kyc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cMjpYUp+tOxRo63+9NS3CvxzFoIcYBBNxXGu0HsgAde7RNduLQJ+MNUyEfpvt6HNZ7 23Jztq+NtKMCdOWw2mft9HkJfUZg8W2Jd7vT6onXUZe5tWaGxIL6y9kx+St243jk6Q0N DRnwXPx0qsKg+G98nvjio9mUgzyht/27y8WJo= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Thu, 8 Apr 2010 07:12:53 -0700 (PDT) In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141D2682CF@zcarhxm1.corp.nortel.com> References: <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> <430FC6BDED356B4C8498F634416644A91A79F3D1DA@mail> <09B7DBFE70A9E24BBB21689DAD3A06141D2682CF@zcarhxm1.corp.nortel.com> Date: Thu, 8 Apr 2010 16:12:53 +0200 Received: by 10.213.76.12 with SMTP id a12mr112265ebk.55.1270735973055; Thu, 08 Apr 2010 07:12:53 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Brian Lindsay Content-Type: multipart/alternative; boundary=00c09f74895e46fe2c0483ba46db Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] Changing the domain (was: Hitchhiker's Guide to MakingMartini) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:13:02 -0000 --00c09f74895e46fe2c0483ba46db Content-Type: text/plain; charset=ISO-8859-1 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 On Thu, Apr 8, 2010 at 3:40 PM, Brian Lindsay wrote: > 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: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Thursday, April 08, 2010 6:03 AM > To: Hans Erik van Elburg; martini@ietf.org > Subject: [martini] Changing the domain (was: Hitchhiker's Guide to > MakingMartini) > > Hi Hans Erik, > Comments inline... > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: Thursday, April 08, 2010 4:56 AM > > > > 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. > > 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 > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > --00c09f74895e46fe2c0483ba46db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable After rereading the martiniHHguide I think that Hadriel is referring to the= number normalisation/RFC3966 number format error fixing required in curren= t scenarios. Not sure if that is an issue at all that this solution has to = address.

/Hans Erik van Elburg


On Thu, Apr 8, 2010 at 3:40 PM, Brian Li= ndsay <blindsay= @nortel.com> wrote:
Hi Hadriel,

=A0You've discussed changing the user portion below. Can you clarify w= hy
the user portion would change in the Shaken approach?

=A0I had assumed Shaken would go down the path of having the host portion<= br> 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.

=A0Thanks
=A0 =A0 Brian

-----Original Message-----
From: martini-bounces@ietf.org<= /a> [mailto:martini-bounces@iet= f.org] On
Behalf Of Hadriel Kaplan
Sent: Thursday, April 08, 2010 6:03 AM
To: Hans Erik van Elburg; martini@ietf.= org
Subject: [martini] Changing the domain (was: Hitchhiker's Guide to
MakingMartini)

Hi Hans Erik,
Comments inline...

> -----Original Message-----
> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
> Sent: Thursday, April 08, 2010 4:56 AM
>
> 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 allthou= gh 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.

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. =A0But that raised red flags of<= br> "but it's NOT the same domain - prove to us there are no interacti= ons
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? =A0The "@" char= acter? ;)

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

-hadriel

_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini

--00c09f74895e46fe2c0483ba46db-- From HKaplan@acmepacket.com Thu Apr 8 07:47:32 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D003A6A51 for ; Thu, 8 Apr 2010 07:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7SXHbfBhH3S for ; Thu, 8 Apr 2010 07:47:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C28863A6810 for ; Thu, 8 Apr 2010 07:45:16 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 10:45:11 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 10:45:11 -0400 From: Hadriel Kaplan To: Brian Lindsay , Hans Erik van Elburg , "martini@ietf.org" Date: Thu, 8 Apr 2010 10:45:09 -0400 Thread-Topic: [martini] Changing the domain (was: Hitchhiker's Guide to MakingMartini) Thread-Index: AcrW+VSNiIjTpCpjTgunILCUtedgjQAAsfPgAAjqNtAAAmI2wA== Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D26C@mail> References: <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com><4BBB7A48.7050801@nostrum.com><4BBBAF3E.2080400@nostrum.com><430FC6BDED356B4C8498F634416644A91A79F3CF54@mail><208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> <430FC6BDED356B4C8498F634416644A91A79F3D1DA@mail> <09B7DBFE70A9E24BBB21689DAD3A06141D2682CF@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141D2682CF@zcarhxm1.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] Changing the domain (was: Hitchhiker's Guide to MakingMartini) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:47:32 -0000 > -----Original Message----- > From: Brian Lindsay [mailto:blindsay@nortel.com] > Sent: Thursday, April 08, 2010 9:41 AM >=20 > You've discussed changing the user portion below. Can you clarify why > the user portion would change in the Shaken approach? 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, i= mo - so I was going to suggest we add it to draft-shaken, because normalizi= ng the user name isn't that hard and does not require per-name or per-pbx c= onfig. And it is a relatively common interop issue, which I failed to add = to the "problems" draft. -hadriel From ietf.hanserik@gmail.com Thu Apr 8 07:47:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52FEA3A6810 for ; Thu, 8 Apr 2010 07:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taDYBm3SkrP3 for ; Thu, 8 Apr 2010 07:47:41 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 6FA0C3A6A93 for ; Thu, 8 Apr 2010 07:45:38 -0700 (PDT) Received: by ewy24 with SMTP id 24so57803ewy.13 for ; Thu, 08 Apr 2010 07:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=9nnKsSlDzJ7oOrE3atrWdDMryLDXKs4Hr1hgxrkftxs=; b=wggKpP9Ca1gVQpKoAnbUIhmQEol8K8boieYBuvMygWw2ON3n+kJJnYRCaK+/n9ZVa4 YJwsplzUSluFYQa5macEeNo84C7wjh/H8zLUti6VrK0WNgdiDi3RJhGQD2vs+uQbIDIo IaKSsTJnluy09jIUsaE/SvWuO92K7RL1oS8rc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nM4HD0GC5ydoguiClhrWRdeYQ5KHpxqyEgMlW4aFG1W+XvmH7lXQW5hyzO0w4nFWfY Q9YTQn0uALm+YgpjGUTVfHw3ZEZ7hXtfN1zK+NV6rz5OlqZtZVko3Nh6kuMmqzqFnA8d 2MuZELAfG2E+vqxkiOiISBm/CrexGU74btf2U= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Thu, 8 Apr 2010 07:45:30 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D222@mail> References: <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> <430FC6BDED356B4C8498F634416644A91A79F3D1DA@mail> <430FC6BDED356B4C8498F634416644A91A79F3D222@mail> Date: Thu, 8 Apr 2010 16:45:30 +0200 Received: by 10.213.2.79 with SMTP id 15mr194482ebi.59.1270737930503; Thu, 08 Apr 2010 07:45:30 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=001517476818f345c30483baba1e Cc: "martini@ietf.org" Subject: Re: [martini] Changing the domain (was: Hitchhiker's Guide to Making Martini) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:47:42 -0000 --001517476818f345c30483baba1e Content-Type: text/plain; charset=ISO-8859-1 Hi Hadriel, Inline.. /Hans Erik van Elburg On Thu, Apr 8, 2010 at 3:38 PM, Hadriel Kaplan 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. > Other comments inline... > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: Thursday, April 08, 2010 8:10 AM > > > > 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. > > In what way does GIN break SIP routing?? > > 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 ;-) > > > Did not understand what you ment with that the user part needs changing > as > > well. > > That was explained in the hitchhiker's guide. :) OK, but that is not part of the solution is it. > > 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. > > 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. --001517476818f345c30483baba1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Hadriel,

Inline..

/Hans Erik van Elburg


On Thu, Apr 8, 2010 at 3:38 PM, Hadriel = Kaplan <HKap= lan@acmepacket.com> wrote:
Hi Hans Erik,
I think you are getting angry at the wrong person. =A0I was the main advoca= te 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 t= hat.
=A0
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.
=A0
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.
=A0
Other comments inline...

> -----Original Message-----
> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
> Sent: Thursday, April 08, 2010 8:10 AM
>
> For alphanumeric SIP-uri's this is not true but martini just choos= e to
> ignore that case... You can't say on one hand oh oh oh how awful t= hat
> approach breaks SIP routing and on the other hand accept a solution th= at
> breaks ... SIP routing. To use equally strong wording. In both cases t= his
> strong wording does not apply and non-constructive fights are
> preprogrammed.

In what way does GIN break SIP routing??

Try to fire anything else the= n a number on it and it will break the SIP routing of that. Now I always sa= w 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 t= o be interoperable with all the SIP extensions in the world and then propos= e a solution that violates that and don't apply the same criteria. That= is just an unfair comparison. Yeah maybe that makes me angry ;-)
=A0

> Did not understand what you ment with that the user part needs changin= g as
> well.

That was explained in the hitchhiker's guide. :)=A0
<= div>OK, but that is not part of the solution is it.
=A0
> It would resolve an issue with existing approaches and at the same tim= e
> 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.

Agree, but I have always been saying that we need to = mutually align the solutions. Fix the issues in the IMS solution as well. T= he 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 sol= utions.
=A0
That's the rub, no matter what happens. =A0So now you're saying, &q= uot;we have more than 2 current mechanisms, let's add 2 more"?

Ha ha. No, see previous answers.
=A0
And as a side note, though not the main issue: for the GIN draft the REGIST= ER is actually formatted differently from SIP Connect 1.0 and ETSI/3gpp, in= its contact URI. =A0You can't mix these models in the same REGISTER re= quest.

That's not a problem th= at we can't fix. We can do it in the mix.


--001517476818f345c30483baba1e-- From ietf.hanserik@gmail.com Thu Apr 8 07:54:39 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BC583A6909 for ; Thu, 8 Apr 2010 07:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpphotGshdla for ; Thu, 8 Apr 2010 07:54:38 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 3DD953A6903 for ; Thu, 8 Apr 2010 07:54:38 -0700 (PDT) Received: by ewy24 with SMTP id 24so60928ewy.13 for ; Thu, 08 Apr 2010 07:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:cc:content-type; bh=AttWNCWLqPGIgR8BfFJB0Da+7Km86j+RdEEMc47WrV8=; b=aNixyGbJTylWZHmc23GlW4i+gsrq/h8vKPTnXippqdHDldFW9pNCsJtfy4HUhYnDuK XC7lgkeCVgRlDO+VDzqrsb6YyRPq6GUVoNaRMke6QTcX+5TMZh9TQ4y8J6WIGgGhuvXt CXzUYnFNoxKoPWmlZmCJ3puKDJSKpzTDq881U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=KhO4aMbFa5P/UOVs+PSbxgpvp4TtPMn6FleyEd4Mc2+tI7sZX3BFmKzezLWMWLDYJa e3ynkz3K2XRrw5mNAevMCKBKe0RFLf4wwDR4Iu0f81AFbfdTKx4ZMZKAH3tBr4XOaxMD 6TEWmxtXKIXCa8EsSVjX6nDVIXPFvOKgGOqIc= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Thu, 8 Apr 2010 07:54:32 -0700 (PDT) Date: Thu, 8 Apr 2010 16:54:32 +0200 Received: by 10.213.55.74 with SMTP id t10mr188266ebg.78.1270738472284; Thu, 08 Apr 2010 07:54:32 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=001636025ec33e368a0483badbbc Cc: "martini@ietf.org" Subject: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:54:39 -0000 --001636025ec33e368a0483badbbc Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 8, 2010 at 4:45 PM, Hadriel Kaplan wrote: > > > You've discussed changing the user portion below. Can you clarify why > > the user portion would change in the Shaken approach? > > 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. > > Which entity would be responsible for that in your view? /Hans Erik van Elburg --001636025ec33e368a0483badbbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 8, 2010 at 4:45 PM, Hadriel Kaplan <= span dir=3D"ltr"><HKaplan@acme= packet.com> wrote:

> =A0 You've discussed changing the user portion below. Can you clar= ify why
> the user portion would change in the Shaken approach?

I explained it in the hitchhiker's guide. =A0It was not in draft-= shaken, just like it's not in ETSI/3gpp/et-al. =A0But 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. =A0And it is a relatively common interop issue= , which I failed to add to the "problems" draft.


Which entity would be responsible for that in your view?
/Hans Erik van Elburg
=A0
--001636025ec33e368a0483badbbc-- From HKaplan@acmepacket.com Thu Apr 8 07:57:59 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F013A67B4 for ; Thu, 8 Apr 2010 07:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9ykj6dej8EL for ; Thu, 8 Apr 2010 07:57:58 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 545173A67A6 for ; Thu, 8 Apr 2010 07:57:58 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 10:57:54 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 10:57:54 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg , Brian Lindsay Date: Thu, 8 Apr 2010 10:57:53 -0400 Thread-Topic: [martini] Changing the domain (was: Hitchhiker's Guide to MakingMartini) Thread-Index: AcrXJaIyXmbAIP4qRzWuBP0opu9F5gABH6HA Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D277@mail> References: <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> <430FC6BDED356B4C8498F634416644A91A79F3D1DA@mail> <09B7DBFE70A9E24BBB21689DAD3A06141D2682CF@zcarhxm1.corp.nortel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Changing the domain (was: Hitchhiker's Guide to MakingMartini) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 14:57:59 -0000 In my opinion it really is worth it to do that. In fact, I'm ashamed to no= t have realized how critical that piece really is. :( =20 If we had actually gone forward with JDR's loose-route mechanism in the IET= F, 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 - normaliz= ing is relatively straight-forward - it just would have been important to a= ddress/fix.=20 -hadriel ________________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, April 08, 2010 10:13 AM To: Brian Lindsay Cc: Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] Changing the domain (was: Hitchhiker's Guide to Maki= ngMartini) After rereading the martiniHHguide I think that Hadriel is referring to the= number normalisation/RFC3966 number format error fixing required in curren= t scenarios. Not sure if that is an issue at all that this solution has to = address.=20 /Hans Erik van Elburg From dwsauder@dsauder.com Thu Apr 8 08:06:00 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8143A67A6 for ; Thu, 8 Apr 2010 08:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIL2lfKdByHz for ; Thu, 8 Apr 2010 08:05:59 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 81A663A67D1 for ; Thu, 8 Apr 2010 08:05:59 -0700 (PDT) Received: from [10.16.5.34] ([206.132.246.2]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M2t94-1NhXdJ35Fe-00sfvK; Thu, 08 Apr 2010 11:05:51 -0400 Message-ID: <4BBDF0C4.4050800@dsauder.com> Date: Thu, 08 Apr 2010 10:05:40 -0500 From: Doug Sauder User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <14C85D6CCBE92743AF33663BF5D24EBA061F58E0@gaalpa1msgusr7e.ugd.att.com> <4BBB7A48.7050801@nostrum.com> <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> <430FC6BDED356B4C8498F634416644A91A79F3D1D7@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D1D7@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX182zHFBgyP0ezvncPynmiG41jXy7F2ls1D+aVy 5yQJWgQ2EWJisai7LOtlWKyhc+hm+TMer58hq+wrtzd+JO7Y8f dHRBcLYCYoDXjuf60st0qyBB3moHBcu Cc: "bernard_aboba@hotmail.com" , "martini@ietf.org" Subject: Re: [martini] Hitchhiker's Guide to Making Martini X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 15:06:00 -0000 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 Hadriel Kaplan wrote: > Hi Hans Erik, > Comments inline... > > >> -----Original Message----- >> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> Sent: Thursday, April 08, 2010 4:56 AM >> >> 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. >> > > I'll reply to that in a separate thread. > > >> 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? >> > > 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 > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From pkyzivat@cisco.com Thu Apr 8 08:12:57 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4C093A6A97 for ; Thu, 8 Apr 2010 08:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.331 X-Spam-Level: X-Spam-Status: No, score=-10.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBaAtVLCCN+Q for ; Thu, 8 Apr 2010 08:12:57 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E20C93A6AA5 for ; Thu, 8 Apr 2010 08:12:28 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKaPvUtAZnwN/2dsb2JhbACbM3GgapkmhQkE X-IronPort-AV: E=Sophos;i="4.52,170,1270425600"; d="scan'208";a="100064919" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Apr 2010 15:12:25 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o38FCPeL009045; Thu, 8 Apr 2010 15:12:25 GMT Message-ID: <4BBDF257.3050805@cisco.com> Date: Thu, 08 Apr 2010 11:12:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hans Erik van Elburg References: <4BBBAF3E.2080400@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79F3CF54@mail> <208EAE1DFA28FC419529619ABB8622441617E1A960@CMS03.BGC.NET> <430FC6BDED356B4C8498F634416644A91A79F3D1DA@mail> <430FC6BDED356B4C8498F634416644A91A79F3D222@mail> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Changing the domain X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 15:12:57 -0000 Hans Erik van Elburg wrote: > In what way does GIN break SIP routing?? > > 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. 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 From HKaplan@acmepacket.com Thu Apr 8 08:48:56 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235DD3A6972 for ; Thu, 8 Apr 2010 08:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWr3pOG7uYzs for ; Thu, 8 Apr 2010 08:48:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A3B8A3A68D5 for ; Thu, 8 Apr 2010 08:48:52 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 11:48:48 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 11:48:47 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Thu, 8 Apr 2010 11:48:47 -0400 Thread-Topic: number normalization (was Re: [martini] Changing the domain (was: Hitchhiker's Guide to MakingMartini)) Thread-Index: AcrXK2ciEZiTP3UDR96CFJ+2voHxeQAAKRlg Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 15:48:56 -0000 The resolving SSP proxy - i.e., the one that does the location-service look= up using the normalized form as the key. (in IMS language, the S-CSCF) Today I know SBC's do it (a LOT), and I assume other devices do it as well.= If the S-CSCF/Reg-proxy doesn't do it we'd be happy to do it for them. :) But really it should be done there, imho. -hadriel ________________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, April 08, 2010 10:55 AM Which entity would be responsible for that in your view? /Hans Erik van Elburg =A0 From pkyzivat@cisco.com Thu Apr 8 09:08:24 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E17AC3A68B3 for ; Thu, 8 Apr 2010 09:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.339 X-Spam-Level: X-Spam-Status: No, score=-10.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nDC1BrGQDp5 for ; Thu, 8 Apr 2010 09:08:24 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BBFB828C0FF for ; Thu, 8 Apr 2010 09:08:23 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHqcvUtAZnwM/2dsb2JhbACbN3GhDpkshQkE X-IronPort-AV: E=Sophos;i="4.52,171,1270425600"; d="scan'208";a="100082301" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 08 Apr 2010 16:08:18 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o38G8Ilk013476; Thu, 8 Apr 2010 16:08:18 GMT Message-ID: <4BBDFF6B.1020907@cisco.com> Date: Thu, 08 Apr 2010 12:08:11 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 16:08:25 -0000 Hadriel Kaplan wrote: > The resolving SSP proxy - i.e., the one that does the location-service lookup using the normalized form as the key. > (in IMS language, the S-CSCF) > > Today I know SBC's do it (a LOT), and I assume other devices do it as well. If the S-CSCF/Reg-proxy doesn't do it we'd be happy to do it for them. :) > But really it should be done there, imho. I agree with Hadriel. Fundamentally, when a server is responsible for the domain of an incoming R-URI, and is retargeting to a URI in another domain, it needs to be careful to select a valid URI in the target domain. The most straightforward way to do this is to simply select from among URIs it was given. That is what a registrar/location service normally supports. In that case the user portion of the URI is presumed to be valid because it was minted by a server responsible for the domain of that URI. In the gin case the full URI isn't specified. Rather only the domain portion is explicitly specified, while the user portion is *implied* and is defined by some service agreement between the pbx and the SP. But its unlikely (and IMO undesirable) that the service agreement will specify every possible representation variation on the supported numbers that the SP may accept in incoming requests. Hence there will be a need to reformat some incoming numbers. I think we have agreed that the scope is limited to E.164 numbers. Given that, I would expect that the URIs used to reach the pbx will then contain E.164 format. And its probably a good idea to specify further that the E.164 format will not contain any separator characters, thus yielding a single representation for each number. Its important that the syntax be limited, because the pbx may need to use a portion of the username space for other URIs, that must not collide with incoming ones designating registered numbers. Thanks, Paul > -hadriel > > ________________________________________ > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Thursday, April 08, 2010 10:55 AM > > Which entity would be responsible for that in your view? > > /Hans Erik van Elburg > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From ietf.hanserik@gmail.com Thu Apr 8 09:40:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98D63A69C5 for ; Thu, 8 Apr 2010 09:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKZeExDxiYvz for ; Thu, 8 Apr 2010 09:40:25 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 7FDD53A69A2 for ; Thu, 8 Apr 2010 09:40:24 -0700 (PDT) Received: by ewy24 with SMTP id 24so97974ewy.13 for ; Thu, 08 Apr 2010 09:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=HTnZdJfRM+9Jg9bgeXJiyTUe848LDR9j0xuKkB/77Qk=; b=e8JbgchwRNbSA6gLEfwqDQqfxHyhjbQQ/EvdkSUD3R02O+iIoMg7BPdNFhnTcr2+ZU ih2V2KnZpd1u7tlJ9HbuubSEjgFaTjRHVvsHCgfmcC3otQ6v80WE9DStqiB+0EsDJYww BqJXMpNiTtyLoLFoncKClFnpRqyk8Rd1orvKc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Bh9F9dkc7JhaKAaL+xZH4F+DPICe8+1Ns6mhJbHcYxNJymDzqRb9oIZQszwU5A9vFk 6yjedAKfBSA9zBJVdFlUN6vBzE72KfiaGJF6Tn3/MQYPf+dfYgLiy6r81/xJoY5d+xLK aNthqCx5eBhia1x0p+8WZC9poDcWJcUdR5qGM= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Thu, 8 Apr 2010 09:40:17 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> Date: Thu, 8 Apr 2010 18:40:17 +0200 Received: by 10.213.52.19 with SMTP id f19mr262326ebg.87.1270744817963; Thu, 08 Apr 2010 09:40:17 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=00163600d67b7994420483bc5549 Cc: "martini@ietf.org" Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 16:40:25 -0000 --00163600d67b7994420483bc5549 Content-Type: text/plain; charset=ISO-8859-1 If I find a SIP URI that contains a E.164 number i.e. +3124764@example.com;user=phone there is no need to normalize. Do you mean that you also want to be able to handle 24764;phone-context=+ 31@example.com;user=phone and normalise that to the previous form? Or are you thinking: - about local numbers? - about alphanumeric SIP uri's that are to be interpreted as numbers, as they are lacking the user=phone parameter. I would expect martini compliant PBX's to understand SIP numbers URI's in the sense of 3261/3966, i.e. with user=phone and to be 3966 compliant i.e: - to start with a + for international number format - to contain a phone-context for local numbers, without a starting + So martini compliant pbx should not show the same diversity in what it accepts as being a number as that what is currently in the field. /Hans Erik van Elburg On Thu, Apr 8, 2010 at 5:48 PM, Hadriel Kaplan wrote: > > The resolving SSP proxy - i.e., the one that does the location-service > lookup using the normalized form as the key. > (in IMS language, the S-CSCF) > > Today I know SBC's do it (a LOT), and I assume other devices do it as well. > If the S-CSCF/Reg-proxy doesn't do it we'd be happy to do it for them. :) > But really it should be done there, imho. > > -hadriel > > ________________________________________ > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Thursday, April 08, 2010 10:55 AM > > Which entity would be responsible for that in your view? > > /Hans Erik van Elburg > > --00163600d67b7994420483bc5549 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If I find a SIP URI that contains a E.164 number i.e. +3124764@example.com;user=3Dphone there is no need to= normalize.

Do you mean that you also want to be able to handle 2476= 4;phone-context=3D+31@example.com;use= r=3Dphone and normalise that to the previous form?

Or are you thinking:
- about local numbers?
- about alphanumeric = SIP uri's that are to be interpreted as numbers, as they are lacking th= e user=3Dphone parameter.

I would expect martini compliant PBX's= to understand SIP numbers URI's in the sense of 3261/3966, i.e. with u= ser=3Dphone and to be 3966 compliant i.e:
- to start with a + for international number format
- to contain a phone= -context for local numbers, without a starting +

So martini complian= t pbx should not show the same diversity in what it accepts as being a numb= er as that what is currently in the field.

/Hans Erik van Elburg


On Thu, Apr 8, 2010 at 5:48 PM, Hadriel = Kaplan <HKap= lan@acmepacket.com> wrote:

The resolving SSP proxy - i.e., the one that does the location-service look= up using the normalized form as the key.
(in IMS language, the S-CSCF)

Today I know SBC's do it (a LOT), and I assume other devices do it as w= ell. =A0If the S-CSCF/Reg-proxy doesn't do it we'd be happy to do i= t for them. :)
But really it should be done there, imho.

-hadriel

________________________________________
From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Thursday, April 08, 2010 10:55 AM

Which entity would be responsible for that in your view?

/Hans Erik van Elburg
=A0

--00163600d67b7994420483bc5549-- From HKaplan@acmepacket.com Thu Apr 8 10:02:00 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A623A689B for ; Thu, 8 Apr 2010 10:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AkWRkePI3Pk for ; Thu, 8 Apr 2010 10:01:59 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5ED3E3A686A for ; Thu, 8 Apr 2010 10:01:59 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 13:01:51 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 13:01:51 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Thu, 8 Apr 2010 13:01:50 -0400 Thread-Topic: number normalization (was Re: [martini] Changing the domain (was: Hitchhiker's Guide to MakingMartini)) Thread-Index: AcrXOi5+h5lxbIBbT2Swc+1UsvAllwAAYOFA Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 17:02:00 -0000 What I expect and what I see in the field are two different things. :) What I see in the field is that IP-PBX's often do not understand RFC3966 ve= ry well at all. I would assume, however, that if we say "E.164 format" in = whatever spec, that they would do E.164 format. Unfortunately, RFC3966 allows all of the following E.164 user formats: +12125551212 +1(212)555-1212 +1(212)5551212 Etc. And we actually see those, in the field, and they cause interop issues, in = the field. (it was frankly a mistake for RFC3966 to do this, imo, but that'= s another topic for another day) But more importantly, what the Reg-proxy actually *gets* is also often not = E.164 to begin with. It processes received target URIs as E.164 based on l= ocal policy transformation/translation rules, and logically converts them t= o E.164 internally, if not also externally. That's all fine/legal/etc. To= be useful to an IP-PBX which expects E.164, that internal transform has to= actually change the user name in the request-URI itself. Thus *in practic= e*, the reg-proxy often will be changing the request-uri based on local pol= icy rules *anyway*. Ergo, the user name and domain name are both changing. -hadriel ________________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, April 08, 2010 12:40 PM To: Hadriel Kaplan Cc: Brian Lindsay; martini@ietf.org Subject: Re: number normalization (was Re: [martini] Changing the domain (w= as: Hitchhiker's Guide to MakingMartini)) If I find a SIP URI that contains a E.164 number i.e. +3124764@example.com;= user=3Dphone there is no need to normalize. Do you mean that you also want to be able to handle 24764;phone-context=3D+= 31@example.com;user=3Dphone and normalise that to the previous form? Or are you thinking: - about local numbers? - about alphanumeric SIP uri's that are to be interpreted as numbers, as th= ey are lacking the user=3Dphone parameter. I would expect martini compliant PBX's to understand SIP numbers URI's in t= he sense of 3261/3966, i.e. with user=3Dphone and to be 3966 compliant i.e: - to start with a + for international number format - to contain a phone-context for local numbers, without a starting + So martini compliant pbx should not show the same diversity in what it acce= pts as being a number as that what is currently in the field. /Hans Erik van Elburg On Thu, Apr 8, 2010 at 5:48 PM, Hadriel Kaplan wro= te: The resolving SSP proxy - i.e., the one that does the location-service look= up using the normalized form as the key. (in IMS language, the S-CSCF) Today I know SBC's do it (a LOT), and I assume other devices do it as well.= =A0If the S-CSCF/Reg-proxy doesn't do it we'd be happy to do it for them. = :) But really it should be done there, imho. -hadriel ________________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: Thursday, April 08, 2010 10:55 AM Which entity would be responsible for that in your view? /Hans Erik van Elburg =A0 From ietf.hanserik@gmail.com Thu Apr 8 10:02:14 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C2503A695A for ; Thu, 8 Apr 2010 10:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oky4xBfw2KSP for ; Thu, 8 Apr 2010 10:02:13 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 8398D3A6946 for ; Thu, 8 Apr 2010 10:02:12 -0700 (PDT) Received: by ewy24 with SMTP id 24so105166ewy.13 for ; Thu, 08 Apr 2010 10:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=JuAnQYujn4D8yG9JiQiYOuIz9U4M+kVprqbqBpIBHs0=; b=T/XmTeGm2kbpczk5ZmoqcDxFIPBRPAGg7PUW/v3Dixvj9O9eW2mpQad09V8Tq199gY rR7jKFuB2JjISCqVDU3oWPdFuBxijWU0jt2W2JzGbHhlfAqyhE9PzjkCjvSJuOF1/rwz irn0HW/UOkslwYTo5TyV3yxVWXMkS1dS7WrTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=d/Z/BP8cCODwLeVrGenJgKU4QASw5n+VAO/DhU0WeEa2Ld/Ghq+l3bCq7TZrrAnJGF qJMm4ulWcx2o4yjw04SunTXAVvAdYMccGp0UYputVO41PWuU1A4cc/y+IeBbKAcUI6F+ /Dn6ekWNmzoiAnQ/DuGmbGApL/KASODjOuHz8= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Thu, 8 Apr 2010 10:02:05 -0700 (PDT) In-Reply-To: <4BBDFF6B.1020907@cisco.com> References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> <4BBDFF6B.1020907@cisco.com> Date: Thu, 8 Apr 2010 19:02:05 +0200 Received: by 10.213.47.195 with SMTP id o3mr289913ebf.48.1270746125384; Thu, 08 Apr 2010 10:02:05 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Paul Kyzivat Content-Type: multipart/alternative; boundary=0016362570a1673ca30483bca387 Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 17:02:14 -0000 --0016362570a1673ca30483bca387 Content-Type: text/plain; charset=ISO-8859-1 The question remains is what needs to be specified. I am not disagreeing, but it is not entirely clear what to agree with at the moment. The easy part seems to be specify clearly how the PBX shall receive numbers. So that it is clear for PBX vendors what to do. What formats incoming formats the SSP shall accept gets already more fuzzy. Do we need to specify that or does it suffice to say what the martini compliant PBX has to understand? /Hans Erik van Elburg On Thu, Apr 8, 2010 at 6:08 PM, Paul Kyzivat wrote: > > > Hadriel Kaplan wrote: > >> The resolving SSP proxy - i.e., the one that does the location-service >> lookup using the normalized form as the key. >> (in IMS language, the S-CSCF) >> >> Today I know SBC's do it (a LOT), and I assume other devices do it as >> well. If the S-CSCF/Reg-proxy doesn't do it we'd be happy to do it for >> them. :) >> But really it should be done there, imho. >> > > I agree with Hadriel. > > Fundamentally, when a server is responsible for the domain of an incoming > R-URI, and is retargeting to a URI in another domain, it needs to be careful > to select a valid URI in the target domain. The most straightforward way to > do this is to simply select from among URIs it was given. That is what a > registrar/location service normally supports. In that case the user portion > of the URI is presumed to be valid because it was minted by a server > responsible for the domain of that URI. > > In the gin case the full URI isn't specified. Rather only the domain > portion is explicitly specified, while the user portion is *implied* and is > defined by some service agreement between the pbx and the SP. > > But its unlikely (and IMO undesirable) that the service agreement will > specify every possible representation variation on the supported numbers > that the SP may accept in incoming requests. Hence there will be a need to > reformat some incoming numbers. > > I think we have agreed that the scope is limited to E.164 numbers. Given > that, I would expect that the URIs used to reach the pbx will then contain > E.164 format. And its probably a good idea to specify further that the E.164 > format will not contain any separator characters, thus yielding a single > representation for each number. > > Its important that the syntax be limited, because the pbx may need to use a > portion of the username space for other URIs, that must not collide with > incoming ones designating registered numbers. > > Thanks, > Paul > > -hadriel >> >> ________________________________________ >> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: >> Thursday, April 08, 2010 10:55 AM >> >> >> Which entity would be responsible for that in your view? >> >> /Hans Erik van Elburg >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> >> --0016362570a1673ca30483bca387 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The question remains is what needs to be specified. I am not disagreeing, b= ut it is not entirely clear what to agree with at the moment.

The ea= sy part seems to be specify clearly how the PBX shall receive numbers. So t= hat it is clear for PBX vendors what to do.

What formats incoming formats the SSP shall accept gets already more fu= zzy. Do we need to specify that or does it suffice to say what the martini = compliant PBX has to understand?

/Hans Erik van Elburg=


On Thu, Apr 8, 2010 at 6:08 PM, Paul Kyz= ivat <pkyzivat@c= isco.com> wrote:


Hadriel Kaplan wrote:
The resolving SSP proxy - i.e., the one that does the location-service look= up using the normalized form as the key.
(in IMS language, the S-CSCF)

Today I know SBC's do it (a LOT), and I assume other devices do it as w= ell. =A0If the S-CSCF/Reg-proxy doesn't do it we'd be happy to do i= t for them. :)
But really it should be done there, imho.

I agree with Hadriel.

Fundamentally, when a server is responsible for the domain of an incoming R= -URI, and is retargeting to a URI in another domain, it needs to be careful= to select a valid URI in the target domain. The most straightforward way t= o do this is to simply select from among URIs it was given. That is what a = registrar/location service normally supports. In that case the user portion= of the URI is presumed to be valid because it was minted by a server respo= nsible for the domain of that URI.

In the gin case the full URI isn't specified. Rather only the domain po= rtion is explicitly specified, while the user portion is *implied* and is d= efined by some service agreement between the pbx and the SP.

But its unlikely (and IMO undesirable) that the service agreement will spec= ify every possible representation variation on the supported numbers that t= he SP may accept in incoming requests. Hence there will be a need to reform= at some incoming numbers.

I think we have agreed that the scope is limited to E.164 numbers. Given th= at, I would expect that the URIs used to reach the pbx will then contain E.= 164 format. And its probably a good idea to specify further that the E.164 = format will not contain any separator characters, thus yielding a single re= presentation for each number.

Its important that the syntax be limited, because the pbx may need to use a= portion of the username space for other URIs, that must not collide with i= ncoming ones designating registered numbers.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

-hadriel

________________________________________
From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: Thursday, April 08,= 2010 10:55 AM


Which entity would be responsible for that in your view?

/Hans Erik van Elburg
=A0_______________________________________________
martini mailing list
martini@ietf.org<= br> https://www.ietf.org/mailman/listinfo/martini


--0016362570a1673ca30483bca387-- From dean.willis@softarmor.com Thu Apr 8 10:04:51 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2116D3A6800 for ; Thu, 8 Apr 2010 10:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgBiU6gYIRDO for ; Thu, 8 Apr 2010 10:04:50 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 540573A6898 for ; Thu, 8 Apr 2010 10:04:50 -0700 (PDT) Received: from [192.168.2.103] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o38H4iKX031201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 8 Apr 2010 12:04:45 -0500 Message-Id: <1D559E5F-FF45-446B-B2FC-ED2B6C25C62B@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D214@mail> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Apr 2010 12:04:38 -0500 References: <430FC6BDED356B4C8498F634416644A91A79F3D214@mail> X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" Subject: Re: [martini] Email formats X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 17:04:51 -0000 On Apr 8, 2010, at 8:22 AM, Hadriel Kaplan wrote: > Folks, > please use plain text emails - I've gotten feedback that some people > have problems in their email viewers seeing the html and embedded > responses in that format. Learning to cut off the part of an email that you're NOT replying to would be a big help, too. -- dean From ietf.hanserik@gmail.com Thu Apr 8 10:08:12 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E1B3A68DB for ; Thu, 8 Apr 2010 10:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_MEDS=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KZa+yFGkWPF for ; Thu, 8 Apr 2010 10:08:11 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 9CC283A6954 for ; Thu, 8 Apr 2010 10:08:10 -0700 (PDT) Received: by ewy24 with SMTP id 24so106965ewy.13 for ; Thu, 08 Apr 2010 10:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=SOmr0qMqPL+aKvM40yVoNeygTq/+blAYG9u/VA7ps2I=; b=lzw4v5tPTcJJiVk3gsXVtkgtOWNPRsAxSsKEI1VdjBbrZpYxsF9l+8+PYdI8qzxRl0 G/oxgDQb30JPWYiCXhi8+EwI0810m5JcrXM8ZNfEA8FadkBrbANp34m4rgU6U4xeKoTv sytVtJH8j3laxzYLcqCVYim2rmHJANc6wl1QE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ii9wMufXQsh3RcwegVlfRlX2zjabDvTjyUzQZH1WVaTfCvxYVvfyOsfMyIMmhZcTZN PwIamsOAG3ca/xXVwweCiUUFr/zELjrJJ3yfDmTH1sGBddwDsPI4VwUSzxrCCbFXqfYi MVudCb2eHCg/T+EDRu53v3YcsKUHRdvQGOMnA= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Thu, 8 Apr 2010 10:08:02 -0700 (PDT) In-Reply-To: <4BBDFF6B.1020907@cisco.com> References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> <4BBDFF6B.1020907@cisco.com> Date: Thu, 8 Apr 2010 19:08:02 +0200 Received: by 10.213.47.195 with SMTP id o3mr293539ebf.48.1270746482465; Thu, 08 Apr 2010 10:08:02 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Paul Kyzivat Content-Type: multipart/alternative; boundary=0016362570a1afde710483bcb878 Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 17:08:12 -0000 --0016362570a1afde710483bcb878 Content-Type: text/plain; charset=ISO-8859-1 Hi Paul, On Thu, Apr 8, 2010 at 6:08 PM, Paul Kyzivat wrote: > > I think we have agreed that the scope is limited to E.164 numbers. Given > that, I would expect that the URIs used to reach the pbx will then contain > E.164 format. And its probably a good idea to specify further that the E.164 > format will not contain any separator characters, thus yielding a single > representation for each number. > > Did we? Not so sure that we did. > Its important that the syntax be limited, because the pbx may need to use a > portion of the username space for other URIs, that must not collide with > incoming ones designating registered numbers. > > What do you mean? (to advanced for me:-D "the pbx may need to use a portion of the username space for other URIs") /Hans Erik --0016362570a1afde710483bcb878 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Paul,

On Thu, Apr 8,= 2010 at 6:08 PM, Paul Kyzivat <pkyzivat@cisco.com> wrote:

I think we have agreed that the scope is limited to E.164 numbers. Given th= at, I would expect that the URIs used to reach the pbx will then contain E.= 164 format. And its probably a good idea to specify further that the E.164 = format will not contain any separator characters, thus yielding a single re= presentation for each number.

Did we? Not so sure that we did.
=A0
Its important that the syntax be limited, because the pbx may need to use a= portion of the username space for other URIs, that must not collide with i= ncoming ones designating registered numbers.

What do you mean? (to advanced for me:-D "the pb= x may need to use a portion of the username space for other URIs")
=
/Hans Erik
--0016362570a1afde710483bcb878-- From HKaplan@acmepacket.com Thu Apr 8 10:24:00 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7513D28C16C for ; Thu, 8 Apr 2010 10:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtEdbOj9va0D for ; Thu, 8 Apr 2010 10:23:49 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C7C1228C121 for ; Thu, 8 Apr 2010 10:20:59 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 13:20:42 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 13:20:42 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg , Paul Kyzivat Date: Thu, 8 Apr 2010 13:20:40 -0400 Thread-Topic: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) Thread-Index: AcrXPT+nBjUfyn7aRNGl/2TCf9XBIQAAfRsA Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D2E0@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> <4BBDFF6B.1020907@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 17:24:00 -0000 When you say "What formats incoming formats the SSP shall accept" do you me= an accept from the IP-PBX, or you mean in general globally? I don't think there's any point in specifying what the SSP should expect to= get in general globally. (and even if we tried it would never fly) I'm du= bious about doing it for requests from IP-PBX's too. -hadriel ________________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, April 08, 2010 1:02 PM To: Paul Kyzivat Cc: Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] number normalization (was Re: Changing the domain (w= as: Hitchhiker's Guide to MakingMartini)) The question remains is what needs to be specified. I am not disagreeing, b= ut it is not entirely clear what to agree with at the moment. The easy part seems to be specify clearly how the PBX shall receive numbers= . So that it is clear for PBX vendors what to do. What formats incoming formats the SSP shall accept gets already more fuzzy.= Do we need to specify that or does it suffice to say what the martini comp= liant PBX has to understand? /Hans Erik van Elburg From ietf.hanserik@gmail.com Thu Apr 8 10:24:44 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164C03A6937 for ; Thu, 8 Apr 2010 10:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSfBYnonH4TD for ; Thu, 8 Apr 2010 10:24:41 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 53D2B28C14D for ; Thu, 8 Apr 2010 10:21:08 -0700 (PDT) Received: by ewy24 with SMTP id 24so110940ewy.13 for ; Thu, 08 Apr 2010 10:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=ue8QZ+PHOyxTR4KR2Nl0wNiLQpKNCSVnmiBfypvPdbU=; b=uUtdt4ar5R17c7uGim5lSGXCJUJ7H/bCglpLN+/MWFnyVhSFyJV4iavRIrPLTMkizy eClPFE9Bch3etWZ9OHYquNksfiwYrVj/f9Q3tWGyJ+ZJCy1VSkrBhhk3443QdesYrvRh 7XMmb2ih5yhMuZS7a4iARfdiIhsUkxLSJa9KI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jdW7iVhSBq15GeuVs1ltXTTx+8UiuDWMaiik9DgDmy4+r+HAmcDk+g2i43lfI3iWiH 54BxhBXYPjjUvTyzzwIWzNz18wQPlL6f35Zc7D8dM/WnnQPQVYc6BmkrAj9lBbLSUo90 W3mp9JaeaxIQQKYV3sWa+hAlt3N5r5vGGsX1M= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Thu, 8 Apr 2010 10:21:00 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> <430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail> Date: Thu, 8 Apr 2010 19:21:00 +0200 Received: by 10.213.37.71 with SMTP id w7mr240010ebd.61.1270747260750; Thu, 08 Apr 2010 10:21:00 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=00c09fc2bf721396c40483bce77a Cc: "martini@ietf.org" Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 17:24:44 -0000 --00c09fc2bf721396c40483bce77a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 8, 2010 at 7:01 PM, Hadriel Kaplan wrote: > > > Unfortunately, RFC3966 allows all of the following E.164 user formats: > +12125551212 > +1(212)555-1212 > +1(212)5551212 > Etc. > > And we actually see those, in the field, and they cause interop issues, in > the field. (it was frankly a mistake for RFC3966 to do this, imo, but that's > another topic for another day) > This is clear and can be specified. > But more importantly, what the Reg-proxy actually *gets* is also often not > E.164 to begin with. It processes received target URIs as E.164 based on > local policy transformation/translation rules, and logically converts them > to E.164 internally, if not also externally. That's all fine/legal/etc. That is fine but hard to specify. > To be useful to an IP-PBX which expects E.164, that internal transform has > to actually change the user name in the request-URI itself. Thus *in > practice*, the reg-proxy often will be changing the request-uri based on > local policy rules *anyway*. Ergo, the user name and domain name are both > changing. > > QED. --00c09fc2bf721396c40483bce77a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Apr 8, 2010 at 7:01 PM, Hadriel Kaplan <HKaplan@acmepacket.com> w= rote:


Unfortunately, RFC3966 allows all of the following E.164 user formats:
+12125551212
+1(212)555-1212
+1(212)5551212
Etc.

And we actually see those, in the field, and they cause interop issues, in = the field. (it was frankly a mistake for RFC3966 to do this, imo, but that&= #39;s another topic for another day)
This is clear and= can be specified.
=A0
But more importantly, what the Reg-proxy actually *gets* is also often not = E.164 to begin with. =A0It processes received target URIs as E.164 based on= local policy transformation/translation rules, and logically converts them= to E.164 internally, if not also externally. =A0That's all fine/legal/= etc.
That is fine but hard to specify.
=A0
=A0To be useful to an IP-PBX which expect= s E.164, that internal transform has to actually change the user name in th= e request-URI itself. =A0Thus *in practice*, the reg-proxy often will be ch= anging the request-uri based on local policy rules *anyway*. =A0Ergo, the u= ser name and domain name are both changing.

QED.
--00c09fc2bf721396c40483bce77a-- From ietf.hanserik@gmail.com Thu Apr 8 10:29:39 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424EB28C145 for ; Thu, 8 Apr 2010 10:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1bvLFWpnGCy for ; Thu, 8 Apr 2010 10:29:38 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 04E0A3A69F7 for ; Thu, 8 Apr 2010 10:28:17 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so207918eyf.51 for ; Thu, 08 Apr 2010 10:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=6B0bN8vVOcXJnDAeVYMjezqAvRjg51vRTpAdYc5r22w=; b=BiJDOkiwHl5/CXyGFi/kibVf1PwoxNcALMWunhPuH4Pevx5M6PFxFnf+O/34OGq1T2 3khjYIVfgRIkjnHEJzTSMiUcD7druybW8oY0HNIb9vc7/96weyHNdeCpYX3sSwFionGk p+10sta4XRrkf5nLKUnLH7chnZbTNyzeftoSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=W/MlEIcKJh02uZa3cLKMFe9FF2hYSHRZ+xzhj+eFb9durHdynaYoU0KVttGsmD8hje p9UCz64loi5X16kRV2xCfHRuB5L0Q0zVIaOnSiTaVfGWZ2Z6LdMyEScELKswDGrrBHze lnTVEsUncVdVaC/G73hTXDsAgAR7AGVCgyj5I= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Thu, 8 Apr 2010 10:28:10 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D2E0@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> <4BBDFF6B.1020907@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D2E0@mail> Date: Thu, 8 Apr 2010 19:28:10 +0200 Received: by 10.213.47.197 with SMTP id o5mr325226ebf.27.1270747690227; Thu, 08 Apr 2010 10:28:10 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=00c09f8a553eacd94a0483bd0063 Cc: "martini@ietf.org" Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 17:29:39 -0000 --00c09f8a553eacd94a0483bd0063 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 8, 2010 at 7:20 PM, Hadriel Kaplan wrote: > > When you say "What formats incoming formats the SSP shall accept" do you > mean accept from the IP-PBX, or you mean in general globally? > > I ment arriving at the SSP for delivery to the PBX, but you alread answered that in another mail. We havent touched what the SSP accepts from the PBX, but I would expect that what we specify as acceptable format to deliver to the PBX, will also be the format that we expect on calls from the PBX to the SSP. > I don't think there's any point in specifying what the SSP should expect to > get in general globally. (and even if we tried it would never fly) I'm > dubious about doing it for requests from IP-PBX's too. > > I agree, thats why I asked as it was not clear to me to what level you where wanting to take this.But you clarified that in your other mail. > ________________________________________ > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Thursday, April 08, 2010 1:02 PM > To: Paul Kyzivat > Cc: Hadriel Kaplan; martini@ietf.org > Subject: Re: [martini] number normalization (was Re: Changing the domain > (was: Hitchhiker's Guide to MakingMartini)) > > The question remains is what needs to be specified. I am not disagreeing, > but it is not entirely clear what to agree with at the moment. > > The easy part seems to be specify clearly how the PBX shall receive > numbers. So that it is clear for PBX vendors what to do. > > What formats incoming formats the SSP shall accept gets already more fuzzy. > Do we need to specify that or does it suffice to say what the martini > compliant PBX has to understand? > > /Hans Erik van Elburg > > --00c09f8a553eacd94a0483bd0063 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 8, 2010 at 7:2= 0 PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:

When you say "What formats incoming formats the SSP shall accept"= do you mean accept from the IP-PBX, or you mean in general globally?

I ment arriving at the SSP for delivery to the PBX, b= ut you alread answered that in another mail.

We havent touched what = the SSP accepts from the PBX, but I would expect that what we specify as ac= ceptable format to deliver to the PBX, will also be the format that we expe= ct on calls from the PBX to the SSP.
=A0
I don't think there's any point in specifying what the SSP should e= xpect to get in general globally. (and even if we tried it would never fly)= =A0I'm dubious about doing it for requests from IP-PBX's too.

I agree, thats why I asked as= it was not clear to me to what level you where wanting to take this.But yo= u clarified that in your other mail.
=A0


________________________________________
From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Thursday, April 08, 2010 1:02 PM
To: Paul Kyzivat
Cc: Hadriel Kaplan; martini@ietf.org
Subject: Re: [martini] number normalization (was Re: Changing the domain (w= as: Hitchhiker's Guide to MakingMartini))

The question remains is what needs to be specified. I am not disagreeing, b= ut it is not entirely clear what to agree with at the moment.

The easy part seems to be specify clearly how the PBX shall receive numbers= . So that it is clear for PBX vendors what to do.

What formats incoming formats the SSP shall accept gets already more fuzzy.= Do we need to specify that or does it suffice to say what the martini comp= liant PBX has to understand?

/Hans Erik van Elburg


--00c09f8a553eacd94a0483bd0063-- From BLINDSAY@nortel.com Thu Apr 8 10:44:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 158023A6839 for ; Thu, 8 Apr 2010 10:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPCvu2HdMg5G for ; Thu, 8 Apr 2010 10:44:29 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 456363A6936 for ; Thu, 8 Apr 2010 10:44:27 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o38HiIf26973; Thu, 8 Apr 2010 17:44:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Apr 2010 13:44:15 -0400 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141D268559@zcarhxm1.corp.nortel.com> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: number normalization (was Re: [martini] Changing the domain (was: Hitchhiker's Guide to MakingMartini)) Thread-Index: AcrXOi5+h5lxbIBbT2Swc+1UsvAllwAAYOFAAAGBa7A= References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> <430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail> From: "Brian Lindsay" To: "Hadriel Kaplan" , "Hans Erik van Elburg" Cc: martini@ietf.org Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 17:44:30 -0000 Hi, I wonder though if normalizing/canonicalizing/constraining RFC3966 = allowable syntax (for example) is something that MARTINI needs to deal = with, or if it would be better left to something like the SIP Connect = which covers a wide gamut of interconnect recommendations. Regards Brian -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Thursday, April 08, 2010 1:02 PM To: Hans Erik van Elburg Cc: Lindsay, Brian (CAR:AR00); martini@ietf.org Subject: RE: number normalization (was Re: [martini] Changing the domain = (was: Hitchhiker's Guide to MakingMartini)) What I expect and what I see in the field are two different things. :) What I see in the field is that IP-PBX's often do not understand RFC3966 = very well at all. I would assume, however, that if we say "E.164 = format" in whatever spec, that they would do E.164 format. Unfortunately, RFC3966 allows all of the following E.164 user formats: +12125551212 +1(212)555-1212 +1(212)5551212 Etc. And we actually see those, in the field, and they cause interop issues, = in the field. (it was frankly a mistake for RFC3966 to do this, imo, but = that's another topic for another day) But more importantly, what the Reg-proxy actually *gets* is also often = not E.164 to begin with. It processes received target URIs as E.164 = based on local policy transformation/translation rules, and logically = converts them to E.164 internally, if not also externally. That's all = fine/legal/etc. To be useful to an IP-PBX which expects E.164, that = internal transform has to actually change the user name in the = request-URI itself. Thus *in practice*, the reg-proxy often will be = changing the request-uri based on local policy rules *anyway*. Ergo, = the user name and domain name are both changing. -hadriel ________________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: Thursday, April 08, 2010 12:40 PM To: Hadriel Kaplan Cc: Brian Lindsay; martini@ietf.org Subject: Re: number normalization (was Re: [martini] Changing the domain = (was: Hitchhiker's Guide to MakingMartini)) If I find a SIP URI that contains a E.164 number i.e. = +3124764@example.com;user=3Dphone there is no need to normalize. Do you mean that you also want to be able to handle = 24764;phone-context=3D+31@example.com;user=3Dphone and normalise that to = the previous form? Or are you thinking: - about local numbers? - about alphanumeric SIP uri's that are to be interpreted as numbers, as = they are lacking the user=3Dphone parameter. I would expect martini compliant PBX's to understand SIP numbers URI's = in the sense of 3261/3966, i.e. with user=3Dphone and to be 3966 = compliant i.e: - to start with a + for international number format - to contain a phone-context for local numbers, without a starting + So martini compliant pbx should not show the same diversity in what it = accepts as being a number as that what is currently in the field. /Hans Erik van Elburg On Thu, Apr 8, 2010 at 5:48 PM, Hadriel Kaplan = wrote: The resolving SSP proxy - i.e., the one that does the location-service = lookup using the normalized form as the key. (in IMS language, the S-CSCF) Today I know SBC's do it (a LOT), and I assume other devices do it as = well. =A0If the S-CSCF/Reg-proxy doesn't do it we'd be happy to do it = for them. :) But really it should be done there, imho. -hadriel ________________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: Thursday, April 08, 2010 10:55 AM Which entity would be responsible for that in your view? /Hans Erik van Elburg =A0 From HKaplan@acmepacket.com Thu Apr 8 11:02:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CED83A6A87 for ; Thu, 8 Apr 2010 11:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm0Zh2CLONyB for ; Thu, 8 Apr 2010 11:02:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 56F703A68E6 for ; Thu, 8 Apr 2010 11:02:41 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 14:02:32 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 14:02:32 -0400 From: Hadriel Kaplan To: "martini@ietf.org" Date: Thu, 8 Apr 2010 14:02:31 -0400 Thread-Topic: Other AoR's than E.164: draft-kaplan-martini-with-olive-00 Thread-Index: AcrXRahoZd4ezAUpQc6dHIV46fji5A== Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 18:02:42 -0000 Howdy, The discussion about limiting the scope of the current Martini work to E.16= 4's raises an issue that is a bit concerning. We have now heard from sever= al folks that one issue with [draft-gin] is that it does not cover as many = use-cases as other mechanisms. Essentially the question is whether our req= uirements list is correct. While we had consensus that E.164 formats were our scope, because we mostly= see those in daily life, if other mechanisms claim to support more then Ma= rtini, we have a problem. Lots of SSP's and Enterprises (the actual custom= ers!) do not attend the IETF, and do not have time to go through mailing li= st archives, or RFCs, etc. They will pay attention to whatever powerpoint = slides the marketing folks generate, and the perception will be that Martin= i is not as generally useful as something else. It doesn't matter what the technical details are, nor what the Opex cost di= fferences will ultimately be. It's a perception problem. Therefore, if folks are interested, I have submitted an I-D which is part-1= of a two-part draft set to try to address the "other" use cases. Part-1 (draft-olive) linked below is to address any AoR of the registered-t= o SSP's domain. This follows [draft-gin] pretty tightly. =20 Any comments/flames/concerns are appreciated. If people want this type of thing, then we could put the olive in the gin f= or a better martini. -hadriel A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : SIP MARTINI with Other Logical Identifier Values which a= re not E.164 (OLIVE) Author(s) : H. Kaplan Filename : draft-kaplan-martini-with-olive-00.txt Pages : 17 Date : 2010-04-08 The Martini Working Group is defining a mechanism for SIP IP-PBX type devic= es to REGISTER and obtain SIP service for E.164-based Address of Records. = This document defines a means for other, non- E.164 AoRs to be used with Martini-based IP-PBXs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-martini-with-olive-00.txt From john.elwell@siemens-enterprise.com Thu Apr 8 12:25:02 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5F53A6AB8 for ; Thu, 8 Apr 2010 12:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GQLuw107tkW for ; Thu, 8 Apr 2010 12:25:00 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id BFFC53A6ACF for ; Thu, 8 Apr 2010 12:24:39 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1488957; Thu, 8 Apr 2010 21:24:35 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 574AA23F0278; Thu, 8 Apr 2010 21:24:35 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 8 Apr 2010 21:24:35 +0200 From: "Elwell, John" To: Hans Erik van Elburg , Hadriel Kaplan Date: Thu, 8 Apr 2010 21:24:33 +0200 Thread-Topic: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) Thread-Index: AcrXQGHGV6jwuZYnQmCAq+ZgbiEIkwAECcQw Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> <430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 19:25:02 -0000 Yet again having to convert to plain text before replying - sigh! The other form of E.164 number a SSP might need to normalise is one that is= not fully qualified, e.g., a national number, or when with dialled prefix = digits. Also, what is more important to nail down is what an entity must send - on = receipt an entity can be more liberal, but obvious must be able to accept t= he format that the other entity is required to send. John=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Hans Erik van Elburg > Sent: 08 April 2010 18:21 > To: Hadriel Kaplan > Cc: martini@ietf.org > Subject: Re: [martini] number normalization (was Re: Changing=20 > the domain (was: Hitchhiker's Guide to MakingMartini)) >=20 > On Thu, Apr 8, 2010 at 7:01 PM, Hadriel Kaplan=20 > wrote: >=20 >=20 >=20 >=20 > Unfortunately, RFC3966 allows all of the following=20 > E.164 user formats: > +12125551212 > +1(212)555-1212 > +1(212)5551212 > Etc. > =09 > And we actually see those, in the field, and they cause=20 > interop issues, in the field. (it was frankly a mistake for=20 > RFC3966 to do this, imo, but that's another topic for another day) > =09 >=20 > This is clear and can be specified. > =20 >=20 > But more importantly, what the Reg-proxy actually=20 > *gets* is also often not E.164 to begin with. It processes=20 > received target URIs as E.164 based on local policy=20 > transformation/translation rules, and logically converts them=20 > to E.164 internally, if not also externally. That's all=20 > fine/legal/etc.=20 >=20 > That is fine but hard to specify. > =20 >=20 > To be useful to an IP-PBX which expects E.164, that=20 > internal transform has to actually change the user name in=20 > the request-URI itself. Thus *in practice*, the reg-proxy=20 > often will be changing the request-uri based on local policy=20 > rules *anyway*. Ergo, the user name and domain name are both=20 > changing. > =09 >=20 >=20 > QED. >=20 > = From pkyzivat@cisco.com Thu Apr 8 13:09:45 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334433A6A7A for ; Thu, 8 Apr 2010 13:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.355 X-Spam-Level: X-Spam-Status: No, score=-10.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghzHZqj-rKrI for ; Thu, 8 Apr 2010 13:09:44 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2BD0E3A679C for ; Thu, 8 Apr 2010 13:09:44 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALvUvUtAZnwN/2dsb2JhbACbOXGiMJk2gnEBDIILBA X-IronPort-AV: E=Sophos;i="4.52,172,1270425600"; d="scan'208";a="100017806" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Apr 2010 20:09:40 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o38K9eef023776; Thu, 8 Apr 2010 20:09:40 GMT Message-ID: <4BBE380C.7080900@cisco.com> Date: Thu, 08 Apr 2010 16:09:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Elwell, John" References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> <430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:09:45 -0000 Elwell, John wrote: > The other form of E.164 number a SSP might need to normalise is one that is not fully qualified, e.g., a national number, or when with dialled prefix digits. John, while I realize those are used a lot, they aren't E.164 numbers. They *could* be telephone-subscriber format (e.g. sip:2125551234;phone-context=+1@example.com;user=phone) But that form, while valid, isn't E.164 and it explicitly is *not* equivalent to sip:+12125551234@example.com;user=phone. > Also, what is more important to nail down is what an entity must send - on receipt an entity can be more liberal, but obvious must be able to accept the format that the other entity is required to send. I agree. I don't think we need to specify what the SSP must be able to convert *from* - only that it should convert *to* cannonical E.164 (no separators) when retargeting *to* the pbx according to martini. Thanks, Paul > John > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Hans Erik van Elburg >> Sent: 08 April 2010 18:21 >> To: Hadriel Kaplan >> Cc: martini@ietf.org >> Subject: Re: [martini] number normalization (was Re: Changing >> the domain (was: Hitchhiker's Guide to MakingMartini)) >> >> On Thu, Apr 8, 2010 at 7:01 PM, Hadriel Kaplan >> wrote: >> >> >> >> >> Unfortunately, RFC3966 allows all of the following >> E.164 user formats: >> +12125551212 >> +1(212)555-1212 >> +1(212)5551212 >> Etc. >> >> And we actually see those, in the field, and they cause >> interop issues, in the field. (it was frankly a mistake for >> RFC3966 to do this, imo, but that's another topic for another day) >> >> >> This is clear and can be specified. >> >> >> But more importantly, what the Reg-proxy actually >> *gets* is also often not E.164 to begin with. It processes >> received target URIs as E.164 based on local policy >> transformation/translation rules, and logically converts them >> to E.164 internally, if not also externally. That's all >> fine/legal/etc. >> >> That is fine but hard to specify. >> >> >> To be useful to an IP-PBX which expects E.164, that >> internal transform has to actually change the user name in >> the request-URI itself. Thus *in practice*, the reg-proxy >> often will be changing the request-uri based on local policy >> rules *anyway*. Ergo, the user name and domain name are both >> changing. >> >> >> >> QED. >> >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From john.elwell@siemens-enterprise.com Thu Apr 8 13:18:26 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5879F3A694D for ; Thu, 8 Apr 2010 13:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf8aN3-swS1M for ; Thu, 8 Apr 2010 13:18:25 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 198853A6A93 for ; Thu, 8 Apr 2010 13:18:23 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1490258; Thu, 8 Apr 2010 22:18:14 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 47C211EB82AB; Thu, 8 Apr 2010 22:18:14 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 8 Apr 2010 22:18:14 +0200 From: "Elwell, John" To: Paul Kyzivat Date: Thu, 8 Apr 2010 22:18:13 +0200 Thread-Topic: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) Thread-Index: AcrXV3viuREHRP4GSNSZa/VkfsQ84QAAMjvA Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> <430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail> <4BBE380C.7080900@cisco.com> In-Reply-To: <4BBE380C.7080900@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:18:26 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 08 April 2010 21:10 > To: Elwell, John > Cc: Hans Erik van Elburg; Hadriel Kaplan; martini@ietf.org > Subject: Re: [martini] number normalization (was Re: Changing=20 > the domain (was: Hitchhiker's Guide to MakingMartini)) >=20 >=20 >=20 > Elwell, John wrote: >=20 > > The other form of E.164 number a SSP might need to=20 > normalise is one that is not fully qualified, e.g., a=20 > national number, or when with dialled prefix digits. >=20 > John, while I realize those are used a lot, they aren't E.164 numbers. > They *could* be telephone-subscriber format (e.g.=20 > sip:2125551234;phone-context=3D+1@example.com;user=3Dphone) >=20 > But that form, while valid, isn't E.164 and it explicitly is *not*=20 > equivalent to sip:+12125551234@example.com;user=3Dphone. [JRE] Well, whether they are E.164 or not is moot - the fact is an SSP migh= t convert a national number, say into a fully qualified E.164 number for de= livery to the SIP-PBX. >=20 >=20 > > Also, what is more important to nail down is what an entity=20 > must send - on receipt an entity can be more liberal, but=20 > obvious must be able to accept the format that the other=20 > entity is required to send. >=20 > I agree. I don't think we need to specify what the SSP must=20 > be able to=20 > convert *from* - only that it should convert *to* cannonical=20 > E.164 (no=20 > separators) when retargeting *to* the pbx according to martini. [JRE] I was really talking about what the SIP-PBX is able to receive. It cl= early would have to receive a canonical E.164 number from the SSP, but can = of course be more liberal. John >=20 > Thanks, > Paul >=20 > > John=20 > >=20 > >> -----Original Message----- > >> From: martini-bounces@ietf.org=20 > >> [mailto:martini-bounces@ietf.org] On Behalf Of Hans Erik van Elburg > >> Sent: 08 April 2010 18:21 > >> To: Hadriel Kaplan > >> Cc: martini@ietf.org > >> Subject: Re: [martini] number normalization (was Re: Changing=20 > >> the domain (was: Hitchhiker's Guide to MakingMartini)) > >> > >> On Thu, Apr 8, 2010 at 7:01 PM, Hadriel Kaplan=20 > >> wrote: > >> > >> > >> > >> > >> Unfortunately, RFC3966 allows all of the following=20 > >> E.164 user formats: > >> +12125551212 > >> +1(212)555-1212 > >> +1(212)5551212 > >> Etc. > >> =09 > >> And we actually see those, in the field, and they cause=20 > >> interop issues, in the field. (it was frankly a mistake for=20 > >> RFC3966 to do this, imo, but that's another topic for another day) > >> =09 > >> > >> This is clear and can be specified. > >> =20 > >> > >> But more importantly, what the Reg-proxy actually=20 > >> *gets* is also often not E.164 to begin with. It processes=20 > >> received target URIs as E.164 based on local policy=20 > >> transformation/translation rules, and logically converts them=20 > >> to E.164 internally, if not also externally. That's all=20 > >> fine/legal/etc.=20 > >> > >> That is fine but hard to specify. > >> =20 > >> > >> To be useful to an IP-PBX which expects E.164, that=20 > >> internal transform has to actually change the user name in=20 > >> the request-URI itself. Thus *in practice*, the reg-proxy=20 > >> often will be changing the request-uri based on local policy=20 > >> rules *anyway*. Ergo, the user name and domain name are both=20 > >> changing. > >> =09 > >> > >> > >> QED. > >> > >> > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 > = From ietf.hanserik@gmail.com Thu Apr 8 13:38:12 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55FB33A6AD2 for ; Thu, 8 Apr 2010 13:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DipuBMyCdl7L for ; Thu, 8 Apr 2010 13:38:11 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 62F933A69EF for ; Thu, 8 Apr 2010 13:38:11 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so217945eyf.51 for ; Thu, 08 Apr 2010 13:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=mDlCpLVqldnjNiUGjnjYMzRapdyXS20Z+2aKlYM2bfw=; b=E71U5F2sqfU8qgvSXr+p3hXC1ZmiKNHu6bdEQh6DA0dhAThqUlWRuRAVBHjqscLQsm qWrkBhgz0egbp3nd2NApjcJDOPNxSc6C0j55xa2Cax5t0k6+l5jOV7SH/MdLfFd7I83L kGLP/z2pxi02ioT7AxBg7GTxRJC4cWCAhfWPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nzM5Bd7oBzuFE+h2SgbMkKwL0h/HqAV3VuXNQzbR4uDZxYLZM9zRpfWImb9U0sBbty m9+UHB19DL5r1dkS3KgkQevG/rwm+jD8qqjM+EkMJrz5TuZ7nx8e6kl4mORvu69jmmBm z8V4cAYErysQhqF3piiiZXRjeTjmOetO1s0Rg= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Thu, 8 Apr 2010 13:38:04 -0700 (PDT) In-Reply-To: References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> <430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail> <4BBE380C.7080900@cisco.com> Date: Thu, 8 Apr 2010 22:38:04 +0200 Received: by 10.213.44.67 with SMTP id z3mr384324ebe.57.1270759084338; Thu, 08 Apr 2010 13:38:04 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=00c09ffb4f88d12eb60483bfa74e Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:38:12 -0000 --00c09ffb4f88d12eb60483bfa74e Content-Type: text/plain; charset=ISO-8859-1 Being liberal is good in theory. But I still think it would be beneficial if we specify what a PBX is minimally required to handle, so that an SSP can trust that if it uses that format all connected martini pbx's can and will handle it as intended. /Hans Erik van Elburg On Thu, Apr 8, 2010 at 10:18 PM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > [JRE] I was really talking about what the SIP-PBX is able to receive. It > clearly would have to receive a canonical E.164 number from the SSP, but can > of course be more liberal. --00c09ffb4f88d12eb60483bfa74e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Being liberal is good in theory. But I still think it would be beneficial i= f we specify what a PBX is minimally required to handle, so that an SSP can= trust that if it uses that format all connected martini pbx's can and = will handle it as intended.

/Hans Erik van Elburg


On Thu, Apr 8, 2010 at 10:18 PM, Elwell,= John <john.elwell@siemens-enterprise.com> wrote:
[JRE] I was really talking about what the SIP-PBX is able to receive. It cl= early would have to receive a canonical E.164 number from the SSP, but can = of course be more liberal.

--00c09ffb4f88d12eb60483bfa74e-- From spencer@wonderhamster.org Thu Apr 8 14:22:09 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA2B28C0E0 for ; Thu, 8 Apr 2010 14:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MdzGtcpjEl6 for ; Thu, 8 Apr 2010 14:22:07 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 6E11928C114 for ; Thu, 8 Apr 2010 14:22:01 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LuwnZ-1NZxvR3UdF-00zwR7; Thu, 08 Apr 2010 17:21:53 -0400 Message-ID: From: "Spencer Dawkins" To: "Hans Erik van Elburg" , "Elwell, John" References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail><430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail><4BBE380C.7080900@cisco.com> Date: Thu, 8 Apr 2010 16:21:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/MjdmQSReOJ4PNXDhnxnR864gV1YUsvtsPW71 pI5dIHIlx+oQhUB5gDabMEzupYRxuP6MRU4dr79jnv+Lef4uvQ OBjFZfjtMfxmS5sQqOGesLAbnfiuDyslIvS93YjYI0= Cc: Hadriel Kaplan , martini@ietf.org Subject: Re: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 21:22:09 -0000 Exactly. I don't see us prohibiting a PBX from accepting something else :-) but we do need a minimum requirement. Spencer ----- Original Message ----- From: Hans Erik van Elburg To: Elwell, John Cc: martini@ietf.org ; Hadriel Kaplan Sent: Thursday, April 08, 2010 3:38 PM Subject: Re: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) Being liberal is good in theory. But I still think it would be beneficial if we specify what a PBX is minimally required to handle, so that an SSP can trust that if it uses that format all connected martini pbx's can and will handle it as intended. /Hans Erik van Elburg On Thu, Apr 8, 2010 at 10:18 PM, Elwell, John wrote: [JRE] I was really talking about what the SIP-PBX is able to receive. It clearly would have to receive a canonical E.164 number from the SSP, but can of course be more liberal. _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From pkyzivat@cisco.com Thu Apr 8 16:41:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB7533A6852 for ; Thu, 8 Apr 2010 16:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.376 X-Spam-Level: X-Spam-Status: No, score=-10.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnRTSjj3aw7w for ; Thu, 8 Apr 2010 16:41:22 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5AB673A6840 for ; Thu, 8 Apr 2010 16:41:22 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPIFvktAaHte/2dsb2JhbACbO3GiYpkzhQkE X-IronPort-AV: E=Sophos;i="4.52,173,1270425600"; d="scan'208";a="180406757" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 08 Apr 2010 23:41:18 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o38NfGbD023855; Thu, 8 Apr 2010 23:41:17 GMT Message-ID: <4BBE69A0.9010606@cisco.com> Date: Thu, 08 Apr 2010 19:41:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 23:41:24 -0000 Hadriel, You have been busy! I quickly read this, and I think there is a lot to like here, though I definitely need to think about it further. One thing that is definitely bothering me is the removal of the phone-context from local numbers when it matches the ssp's domain. I don't like the resulting number without a phone context for reasons that are to some extent still subliminal. For one, in the degenerate case where there are no other user parameters, this is ambiguous with an "email-style" address that happens to be all numeric. Is there some reason not to leave the ssp domain name in the phone-context in this case? I was also worried about the reg event package, but you already identified that as a potential issue. Nevertheless, I think potentially this direction might bear fruit. Thanks, Paul Hadriel Kaplan wrote: > Howdy, > The discussion about limiting the scope of the current Martini work to E.164's raises an issue that is a bit concerning. We have now heard from several folks that one issue with [draft-gin] is that it does not cover as many use-cases as other mechanisms. Essentially the question is whether our requirements list is correct. > > While we had consensus that E.164 formats were our scope, because we mostly see those in daily life, if other mechanisms claim to support more then Martini, we have a problem. Lots of SSP's and Enterprises (the actual customers!) do not attend the IETF, and do not have time to go through mailing list archives, or RFCs, etc. They will pay attention to whatever powerpoint slides the marketing folks generate, and the perception will be that Martini is not as generally useful as something else. > > It doesn't matter what the technical details are, nor what the Opex cost differences will ultimately be. It's a perception problem. > > Therefore, if folks are interested, I have submitted an I-D which is part-1 of a two-part draft set to try to address the "other" use cases. > > Part-1 (draft-olive) linked below is to address any AoR of the registered-to SSP's domain. This follows [draft-gin] pretty tightly. > > Any comments/flames/concerns are appreciated. > If people want this type of thing, then we could put the olive in the gin for a better martini. > > -hadriel > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > Title : SIP MARTINI with Other Logical Identifier Values which are not E.164 (OLIVE) > Author(s) : H. Kaplan > Filename : draft-kaplan-martini-with-olive-00.txt > Pages : 17 > Date : 2010-04-08 > > The Martini Working Group is defining a mechanism for SIP IP-PBX type devices to REGISTER and obtain SIP service for E.164-based Address of Records. This document defines a means for other, non- > E.164 AoRs to be used with Martini-based IP-PBXs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-martini-with-olive-00.txt > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From HKaplan@acmepacket.com Thu Apr 8 18:40:49 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8093A69E4 for ; Thu, 8 Apr 2010 18:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th9OIBMGlxLe for ; Thu, 8 Apr 2010 18:40:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 49B4A3A659C for ; Thu, 8 Apr 2010 18:40:48 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 21:40:42 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 21:40:41 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Thu, 8 Apr 2010 21:40:40 -0400 Thread-Topic: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 Thread-Index: AcrXdP92uDQ8BcQVRrOxMrRX32l82AADSJrg Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D3DB@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> <4BBE69A0.9010606@cisco.com> In-Reply-To: <4BBE69A0.9010606@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 01:40:50 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, April 08, 2010 7:41 PM > To: Hadriel Kaplan >=20 > One thing that is definitely bothering me is the removal of the > phone-context from local numbers when it matches the ssp's domain. I > don't like the resulting number without a phone context for reasons that > are to some extent still subliminal. > > Is there some reason not to leave the ssp domain name in the > phone-context in this case? Right, so Local-Numbers are rather tricky/ugly in practice, as far as I can= tell. But I'm also not sure how much of what I see in the field is "norma= l" vs. just the error cases my product has to go fix to/from, which could w= ell also be abnormal cases altogether. (so my impression could be way off) Anyway, afaict, when the phone-context is something like ssp.com (which is = not often), then the IP-PBX has no idea about that phone-context, and the U= RI is modified to strip it or change it on its way to the IP-PBX. Because = when it's the SSP's domain it's basically the SSP's private numbers, which = an IP-PBX may just happen to be in the private-dialing plan for (unbeknowns= t to it). I guess the real question is what does the IP-PBX expect to see? > For one, in the degenerate case where there are no other user > parameters, this is ambiguous with an "email-style" address that happens > to be all numeric. Good point.=20 =20 > I was also worried about the reg event package, but you already > identified that as a potential issue. Yeah, but in talking with Adam Roach about this concept earlier today, he t= hought we wouldn't need to have it in reg-event, because ultimately its not= really an AoR you could get meaningful info for (and is private as well) s= o we could just say the Local-Number ones don't apply for reg-event.=20 > Nevertheless, I think potentially this direction might bear fruit. Cool! Also, Adam suggested I put back into the draft how this would work for a ph= one-context of an E.164 (which was in a previous incarnation of the draft).= =20 -hadriel From john.elwell@siemens-enterprise.com Fri Apr 9 00:35:48 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20B728C16C for ; Fri, 9 Apr 2010 00:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4kAI5PtgjWD for ; Fri, 9 Apr 2010 00:35:48 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5120C28C0DC for ; Fri, 9 Apr 2010 00:35:47 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1493968; Fri, 9 Apr 2010 09:35:34 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id D4B7223F0278; Fri, 9 Apr 2010 09:35:34 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 9 Apr 2010 09:35:35 +0200 From: "Elwell, John" To: Spencer Dawkins , Hans Erik van Elburg Date: Fri, 9 Apr 2010 09:35:33 +0200 Thread-Topic: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) Thread-Index: AcrXYYjnE2B4QpFbSr2F1CiLuu9dAgAVZgzw Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail><430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail><4BBE380C.7080900@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 07:35:48 -0000 Yes, of course, and obviously it has to accept what we mandate the other si= de to send, as I thought I made clear in an earlier message. John=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 > Sent: 08 April 2010 22:22 > To: Hans Erik van Elburg; Elwell, John > Cc: martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] number normalization (was Re: Changing=20 > the domain(was: Hitchhiker's Guide to MakingMartini)) >=20 > Exactly. I don't see us prohibiting a PBX from accepting=20 > something else :-)=20 > but we do need a minimum requirement. >=20 > Spencer >=20 > ----- Original Message -----=20 > From: Hans Erik van Elburg > To: Elwell, John > Cc: martini@ietf.org ; Hadriel Kaplan > Sent: Thursday, April 08, 2010 3:38 PM > Subject: Re: [martini] number normalization (was Re: Changing the=20 > domain(was: Hitchhiker's Guide to MakingMartini)) >=20 >=20 > Being liberal is good in theory. But I still think it would=20 > be beneficial if=20 > we specify what a PBX is minimally required to handle, so=20 > that an SSP can=20 > trust that if it uses that format all connected martini pbx's=20 > can and will=20 > handle it as intended. >=20 > /Hans Erik van Elburg >=20 >=20 >=20 > On Thu, Apr 8, 2010 at 10:18 PM, Elwell, John=20 > wrote: >=20 > [JRE] I was really talking about what the SIP-PBX is able to=20 > receive. It=20 > clearly would have to receive a canonical E.164 number from=20 > the SSP, but can=20 > of course be more liberal. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini=20 >=20 > = From john.elwell@siemens-enterprise.com Fri Apr 9 02:53:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A113A6886 for ; Fri, 9 Apr 2010 02:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxmZYkKYnLu5 for ; Fri, 9 Apr 2010 02:53:17 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 7FB873A6817 for ; Fri, 9 Apr 2010 02:53:17 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1494978; Fri, 9 Apr 2010 11:53:12 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id EB0791EB82AB; Fri, 9 Apr 2010 11:53:12 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 9 Apr 2010 11:53:12 +0200 From: "Elwell, John" To: Hadriel Kaplan , "martini@ietf.org" Date: Fri, 9 Apr 2010 11:53:11 +0200 Thread-Topic: Other AoR's than E.164: draft-kaplan-martini-with-olive-00 Thread-Index: AcrXRahoZd4ezAUpQc6dHIV46fji5AAgzRcQ Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 09:53:18 -0000 Hadriel, Thanks for writing this up. I like the direction this is heading, but I am = not sure this really addresses the full population of use cases that we mig= ht like to cover at some stage. One concern is email-style AORs based on the SSP's domain. This might work = for some enterprises. What it means is a lack of portability. For example, = if I agree with ssp1.example.com that I can use sip:bob@ssp1.example.com, i= t is quite likely that if I try to move to ssp2.example.com, bob will not b= e available. I look forward to your planned further draft on the subject of= using the enterprise domain name. Another concern is whether non-E.164 numbers based on phone-context of doma= in name is sufficiently widespread. In fact I don't have much knowledge of = deployments based on non-E.164 numbers (excluding things like national numb= ers, which can be expanded to fully-qualified E.164 numbers). For use in th= e scenarios you describe, do people use domain- or E.164-based phone-contex= ts? I note your intention to give further consideration to E.164-based phon= e-contexts. So basically, I see this as useful material on how gin could be extended in= future to accommodate a broader range of AOR types. I am not sure that we = necessarily need to include these in the initial gin deliverable, but by be= ing aware of such future extensions we could at least ensure that we don't = build anything into gin that rules this out. John =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 08 April 2010 19:03 > To: martini@ietf.org > Subject: [martini] Other AoR's than E.164:=20 > draft-kaplan-martini-with-olive-00 >=20 >=20 > Howdy, > The discussion about limiting the scope of the current=20 > Martini work to E.164's raises an issue that is a bit=20 > concerning. We have now heard from several folks that one=20 > issue with [draft-gin] is that it does not cover as many=20 > use-cases as other mechanisms. Essentially the question is=20 > whether our requirements list is correct. >=20 > While we had consensus that E.164 formats were our scope,=20 > because we mostly see those in daily life, if other=20 > mechanisms claim to support more then Martini, we have a=20 > problem. Lots of SSP's and Enterprises (the actual=20 > customers!) do not attend the IETF, and do not have time to=20 > go through mailing list archives, or RFCs, etc. They will=20 > pay attention to whatever powerpoint slides the marketing=20 > folks generate, and the perception will be that Martini is=20 > not as generally useful as something else. >=20 > It doesn't matter what the technical details are, nor what=20 > the Opex cost differences will ultimately be. It's a=20 > perception problem. >=20 > Therefore, if folks are interested, I have submitted an I-D=20 > which is part-1 of a two-part draft set to try to address the=20 > "other" use cases. >=20 > Part-1 (draft-olive) linked below is to address any AoR of=20 > the registered-to SSP's domain. This follows [draft-gin]=20 > pretty tightly. =20 >=20 > Any comments/flames/concerns are appreciated. > If people want this type of thing, then we could put the=20 > olive in the gin for a better martini. >=20 > -hadriel >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > Title : SIP MARTINI with Other Logical=20 > Identifier Values which are not E.164 (OLIVE) > Author(s) : H. Kaplan > Filename : draft-kaplan-martini-with-olive-00.txt > Pages : 17 > Date : 2010-04-08 >=20 > The Martini Working Group is defining a mechanism for SIP=20 > IP-PBX type devices to REGISTER and obtain SIP service for=20 > E.164-based Address of Records. This document defines a=20 > means for other, non- > E.164 AoRs to be used with Martini-based IP-PBXs. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-martini-with- > olive-00.txt >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From ietf.hanserik@gmail.com Fri Apr 9 03:52:20 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608D03A68EB for ; Fri, 9 Apr 2010 03:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7EUpmX0L15A for ; Fri, 9 Apr 2010 03:52:19 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 6DE783A6407 for ; Fri, 9 Apr 2010 03:52:01 -0700 (PDT) Received: by ewy24 with SMTP id 24so321898ewy.13 for ; Fri, 09 Apr 2010 03:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=s7mMb/gbotHeMaVLgW3ChqB8OpiSOaFYE6W6W28/jG4=; b=QfkzoS+LyZbPUvmx3J98d+p/poEQGVG7UX6wZLklN8LLL2dSwdYg207xvzrv7mztnj KoJrs+wSRsWpr85Xq4Gw7hgMZyH4wFzEhJBAxYYJJTTlQZV7NUoVyINuShYpLl95Pokh ReBiYnSSirJLM+k5oqTpaz6rBAcPiKrSI+M8I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UHvyQ2+BqJ1AFB53GgS0ytNlQzpFssku4DWI88cu1ZuEe/+RA7Tk2RDRzpCRLiAlIp UsDlnNGm+JWUUh8RgbjjODeyvIjQdb7xj/6WGDjl4yvJsifcW6eugV7JuxLI1MI12Rfu xp2NqtM9grt/NRLMS/87x3DOMZyCFGhXUSCNc= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Fri, 9 Apr 2010 03:51:52 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> Date: Fri, 9 Apr 2010 12:51:52 +0200 Received: by 10.213.0.211 with SMTP id 19mr792006ebc.6.1270810312401; Fri, 09 Apr 2010 03:51:52 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=000e0cdfda243f693f0483cb95a8 Cc: "martini@ietf.org" Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 10:52:20 -0000 --000e0cdfda243f693f0483cb95a8 Content-Type: text/plain; charset=ISO-8859-1 Hi Hadriel, I'm impressed by how fast you create drafts ;-) Still have concerns about being forced to do Request-URI replacement and then having to fix things to make it work. An olive unfortunately does not help in preventing a headache the day after. /Hans Erik van Elburg On Thu, Apr 8, 2010 at 8:02 PM, Hadriel Kaplan wrote: > > Howdy, > The discussion about limiting the scope of the current Martini work to > E.164's raises an issue that is a bit concerning. We have now heard from > several folks that one issue with [draft-gin] is that it does not cover as > many use-cases as other mechanisms. Essentially the question is whether our > requirements list is correct. > > While we had consensus that E.164 formats were our scope, because we mostly > see those in daily life, if other mechanisms claim to support more then > Martini, we have a problem. Lots of SSP's and Enterprises (the actual > customers!) do not attend the IETF, and do not have time to go through > mailing list archives, or RFCs, etc. They will pay attention to whatever > powerpoint slides the marketing folks generate, and the perception will be > that Martini is not as generally useful as something else. > > It doesn't matter what the technical details are, nor what the Opex cost > differences will ultimately be. It's a perception problem. > > Therefore, if folks are interested, I have submitted an I-D which is part-1 > of a two-part draft set to try to address the "other" use cases. > > Part-1 (draft-olive) linked below is to address any AoR of the > registered-to SSP's domain. This follows [draft-gin] pretty tightly. > > Any comments/flames/concerns are appreciated. > If people want this type of thing, then we could put the olive in the gin > for a better martini. > > -hadriel > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > Title : SIP MARTINI with Other Logical Identifier Values > which are not E.164 (OLIVE) > Author(s) : H. Kaplan > Filename : draft-kaplan-martini-with-olive-00.txt > Pages : 17 > Date : 2010-04-08 > > The Martini Working Group is defining a mechanism for SIP IP-PBX type > devices to REGISTER and obtain SIP service for E.164-based Address of > Records. This document defines a means for other, non- > E.164 AoRs to be used with Martini-based IP-PBXs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-martini-with-olive-00.txt > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > --000e0cdfda243f693f0483cb95a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hadriel,

I'm impressed by how fast you create drafts ;-)<= br>
Still have concerns about being forced to do Request-URI replacement= and then having to fix things to make it work. An olive unfortunately does= not help in preventing a headache the day after.

/Hans Erik van Elburg


On Thu, Apr 8, 2010 at 8:02 PM, Hadriel = Kaplan <HKap= lan@acmepacket.com> wrote:

Howdy,
The discussion about limiting the scope of the current Martini work to E.16= 4's raises an issue that is a bit concerning. =A0We have now heard from= several folks that one issue with [draft-gin] is that it does not cover as= many use-cases as other mechanisms. =A0Essentially the question is whether= our requirements list is correct.

While we had consensus that E.164 formats were our scope, because we mostly= see those in daily life, if other mechanisms claim to support more then Ma= rtini, we have a problem. =A0Lots of SSP's and Enterprises (the actual = customers!) do not attend the IETF, and do not have time to go through mail= ing list archives, or RFCs, etc. =A0They will pay attention to whatever pow= erpoint slides the marketing folks generate, and the perception will be tha= t Martini is not as generally useful as something else.

It doesn't matter what the technical details are, nor what the Opex cos= t differences will ultimately be. =A0It's a perception problem.

Therefore, if folks are interested, I have submitted an I-D which is part-1= of a two-part draft set to try to address the "other" use cases.=

Part-1 (draft-olive) linked below is to address any AoR of the registered-t= o SSP's domain. =A0This follows [draft-gin] pretty tightly.

Any comments/flames/concerns are appreciated.
If people want this type of thing, then we could put the olive in the gin f= or a better martini.

-hadriel


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : SIP MARTINI with Other Logical = Identifier Values which are not E.164 (OLIVE)
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : H. Kaplan
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-kaplan-martini-with-olive-0= 0.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 17
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-04-08

The Martini Working Group is defining a mechanism for SIP IP-PBX type devic= es to REGISTER and obtain SIP service for E.164-based Address of Records. = =A0This document defines a means for other, non-
E.164 AoRs to be used with Martini-based IP-PBXs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kap= lan-martini-with-olive-00.txt

_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini

--000e0cdfda243f693f0483cb95a8-- From john.elwell@siemens-enterprise.com Fri Apr 9 03:57:38 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9D03A67D2 for ; Fri, 9 Apr 2010 03:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81-MY9NrG9Q0 for ; Fri, 9 Apr 2010 03:57:37 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 1DA023A6407 for ; Fri, 9 Apr 2010 03:57:36 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1495822 for martini@ietf.org; Fri, 9 Apr 2010 12:57:32 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id D6DB023F0278 for ; Fri, 9 Apr 2010 12:57:32 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 9 Apr 2010 12:57:33 +0200 From: "Elwell, John" To: "martini@ietf.org" Date: Fri, 9 Apr 2010 12:57:32 +0200 Thread-Topic: Question on gin and variable number lengths Thread-Index: AcrX03Q2PU9Jjn+GS+WPAAIKg7DLug== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [martini] Question on gin and variable number lengths X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 10:57:38 -0000 Suppose my SSP (or numbering authority) has my allocated to my PBX numbers = beginning +4357008, meaning that I can use that number and any extension of= that number (e.g., +43570080, +4357008555, +435700866666), as long as the = maximum E.164 number length is not exceeded). This is common practice in a = few countries (I am aware of Germany and Austria). As far as I know, the SS= P does not need to be aware of the number lengths I choose to use. For basic gin operation I don't see a problem with this, although clearly t= he SSP's implementation of the location service will need to reflect this p= ossibility (i.e., it cannot have explicit mappings for every conceivable nu= mber). It may have impact on the reg-event package, however, requiring some= sort of short-hand representation of registered contacts. This sounds like= a similar problem to that raised by Hadriel with non-E.164 numbers. John= From ietf.hanserik@gmail.com Fri Apr 9 04:28:04 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A1F3A6A0D for ; Fri, 9 Apr 2010 04:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrZgOHuGGlLN for ; Fri, 9 Apr 2010 04:28:03 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id E25613A6A8F for ; Fri, 9 Apr 2010 04:26:52 -0700 (PDT) Received: by ewy24 with SMTP id 24so330564ewy.13 for ; Fri, 09 Apr 2010 04:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=iBrF6ohTkMC6fY7OCTyuuNdSe/9DVDQfmPJBSOzYFQc=; b=j/egZDcxGAoxzB/QagLZ/sDZzMY4gi2Bl9K1w2zyRUqagz8yd9+E01CtYmrTWilPf7 YRDO5CuittILbRXve49EQVnDpHgd5wpKjtsX4RqjeJokBe0Qi7HL7NN32G78As/bdysU 4x5sZ9ezUChdCUSQ6KAqjGI1I1isq9mRt9438= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Z9pHfWOAFzTWvTY2sVWeyKoFCrpQqQ6Ecf4Vgf0q2HxMFDAhwZdB2qDIKjP3x+MkEA y3nY4FzCGzfiDQhvIUM+5dhJxZhuvPXVPUwSt7c6LAM9xJahQNiX61WAzgQCBEVs8kmT RMlZ/5fWfIlmcbqpq/eui0YNFqH8NSiF+xkTY= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Fri, 9 Apr 2010 04:26:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Apr 2010 13:26:44 +0200 Received: by 10.213.54.144 with SMTP id q16mr802104ebg.68.1270812404444; Fri, 09 Apr 2010 04:26:44 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=00c09ffb5107f16ee90483cc112f Cc: "martini@ietf.org" Subject: Re: [martini] Question on gin and variable number lengths X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 11:28:04 -0000 --00c09ffb5107f16ee90483cc112f Content-Type: text/plain; charset=ISO-8859-1 Hi John, I thought this was covered by the last sentence in the gin recepy: "After the PBX is authenticated, the registrar updates its location service so that each of the phone numbers associated with the PBX creates a unique AOR to Contact mapping. Semantically, each of these mappings will be treated as a unique row in the location service. The actual implementation may, of course, perform internal optimizations to reduce the amount of memory used to store such information." In my mind having a wild-carded entry that matches such a number block, is such an optimization. I do not see the relation with local numbers. /Hans Erik van Elburg On Fri, Apr 9, 2010 at 12:57 PM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Suppose my SSP (or numbering authority) has my allocated to my PBX numbers > beginning +4357008, meaning that I can use that number and any extension of > that number (e.g., +43570080, +4357008555, +435700866666), as long as the > maximum E.164 number length is not exceeded). This is common practice in a > few countries (I am aware of Germany and Austria). As far as I know, the SSP > does not need to be aware of the number lengths I choose to use. > > For basic gin operation I don't see a problem with this, although clearly > the SSP's implementation of the location service will need to reflect this > possibility (i.e., it cannot have explicit mappings for every conceivable > number). It may have impact on the reg-event package, however, requiring > some sort of short-hand representation of registered contacts. This sounds > like a similar problem to that raised by Hadriel with non-E.164 numbers. > > John > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > --00c09ffb5107f16ee90483cc112f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi John,

I thought this was covered by the last sentence in the gin = recepy: "After the PBX is authenticated, the registrar updates its loc= ation service so that each of the phone numbers associated with the PBX cre= ates a unique AOR to Contact mapping. Semantically, each of these mappings= will be treated as a unique row in the location service. The actual imple= mentation may, of course, perform internal optimizations to reduce the amou= nt of=A0 memory used to store such information."

In my mind having a wild-carded entry that matches such a number block,= is such an optimization. I do not see the relation with local numbers.
=
/Hans Erik van Elburg

On Fri, Apr 9, 2010 at 12:57 PM, Elwell, Joh= n <john.elwell@siemens-enterprise.com> wrote:
Suppose my SSP (or numbering authority) has my allocated to my PBX numbers = beginning +4357008, meaning that I can use that number and any extension of= that number (e.g., +43570080, +4357008555, +435700866666), as long as the = maximum E.164 number length is not exceeded). This is common practice in a = few countries (I am aware of Germany and Austria). As far as I know, the SS= P does not need to be aware of the number lengths I choose to use.

For basic gin operation I don't see a problem with this, although clear= ly the SSP's implementation of the location service will need to reflec= t this possibility (i.e., it cannot have explicit mappings for every concei= vable number). It may have impact on the reg-event package, however, requir= ing some sort of short-hand representation of registered contacts. This sou= nds like a similar problem to that raised by Hadriel with non-E.164 numbers= .

John
_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini

--00c09ffb5107f16ee90483cc112f-- From john.elwell@siemens-enterprise.com Fri Apr 9 05:32:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C173A6915 for ; Fri, 9 Apr 2010 05:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogNiID-yjx+l for ; Fri, 9 Apr 2010 05:32:20 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 45C5B3A68A9 for ; Fri, 9 Apr 2010 05:32:19 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1497289; Fri, 9 Apr 2010 14:32:15 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id BCFAA23F0278; Fri, 9 Apr 2010 14:32:15 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 9 Apr 2010 14:32:15 +0200 From: "Elwell, John" To: Hans Erik van Elburg Date: Fri, 9 Apr 2010 14:32:13 +0200 Thread-Topic: [martini] Question on gin and variable number lengths Thread-Index: AcrX14jVeSaAiIziQACZ/Ki7wZlxhgACClRw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Question on gin and variable number lengths X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 12:32:23 -0000 =20 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: 09 April 2010 12:27 > To: Elwell, John > Cc: martini@ietf.org > Subject: Re: [martini] Question on gin and variable number lengths >=20 > Hi John, >=20 > I thought this was covered by the last sentence in the gin=20 > recepy: "After the PBX is authenticated, the registrar=20 > updates its location service so that each of the phone=20 > numbers associated with the PBX creates a unique AOR to=20 > Contact mapping. Semantically, each of these mappings will be=20 > treated as a unique row in the location service. The actual=20 > implementation may, of course, perform internal optimizations=20 > to reduce the amount of memory used to store such information." [JRE] Yes, that was what I was trying to refer to, so I agree there should = not be a problem for basic gin. >=20 > In my mind having a wild-carded entry that matches such a=20 > number block, is such an optimization. I do not see the=20 > relation with local numbers. [JRE] The relationship with local numbers was only in the context of the re= g-event package. Clearly, if the SSP does not know the precise set of numbe= rs used (and if up to 5 extension digits are available, this gives a potent= ial for 11,111 different numbers - 10,000 5 digit numbers plus 1000 4 digit= s numbers, etc.), how would the SSP populate notifications? Listing all pot= ential numbers would result in very large notifications. John >=20 > /Hans Erik van Elburg >=20 >=20 > On Fri, Apr 9, 2010 at 12:57 PM, Elwell, John=20 > wrote: >=20 >=20 > Suppose my SSP (or numbering authority) has my=20 > allocated to my PBX numbers beginning +4357008, meaning that=20 > I can use that number and any extension of that number (e.g.,=20 > +43570080, +4357008555, +435700866666), as long as the=20 > maximum E.164 number length is not exceeded). This is common=20 > practice in a few countries (I am aware of Germany and=20 > Austria). As far as I know, the SSP does not need to be aware=20 > of the number lengths I choose to use. > =09 > For basic gin operation I don't see a problem with=20 > this, although clearly the SSP's implementation of the=20 > location service will need to reflect this possibility (i.e.,=20 > it cannot have explicit mappings for every conceivable=20 > number). It may have impact on the reg-event package,=20 > however, requiring some sort of short-hand representation of=20 > registered contacts. This sounds like a similar problem to=20 > that raised by Hadriel with non-E.164 numbers. > =09 > John > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > =09 >=20 >=20 > = From ietf.hanserik@gmail.com Fri Apr 9 05:49:08 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F153A690B for ; Fri, 9 Apr 2010 05:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CKky7xtJiuq for ; Fri, 9 Apr 2010 05:49:07 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 95F3C3A6A36 for ; Fri, 9 Apr 2010 05:49:04 -0700 (PDT) Received: by ewy24 with SMTP id 24so352358ewy.13 for ; Fri, 09 Apr 2010 05:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=UA2L9kaGsv0okijHNlXxtH/dNzjc2DkLQYcucGGg/m8=; b=vPX9oU6QFF4zlbd1YsRDWV8sS6K/UoshsCi2IFC0YjnDuM2sBSHNvqgMHK2u+RYJu7 yqa+FCk7uTtRkNP/QzEfFAmbuYF2wbcMvXVAOm4Ey3HWSzuwomQaVHUc8mUA/visPWmj sWMPz+85koqtEIFK7/7EuK3QgjkPZk1DHNFpw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QrO3lYerMEvDKRON78HZg7sAXnQ++I8GL8NRQ0kb5oNtmfEGDYcHjPGRHuoltFpXBl FNB0rzzDA37b3V9KYK6wvMFXoV83T1+EiohgQhWwdVzI4FJVRqivhHlgVYqtfdZhnmbZ ytAAuAHYvMxx4bY9ppbxlXIy7jN6w1sEXOazo= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Fri, 9 Apr 2010 05:48:56 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Apr 2010 14:48:56 +0200 Received: by 10.213.68.203 with SMTP id w11mr389389ebi.43.1270817336742; Fri, 09 Apr 2010 05:48:56 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=001636137597ee55c30483cd370d Cc: "martini@ietf.org" Subject: Re: [martini] Question on gin and variable number lengths X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 12:49:08 -0000 --001636137597ee55c30483cd370d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 9, 2010 at 2:32 PM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > > > > > In my mind having a wild-carded entry that matches such a > > number block, is such an optimization. I do not see the > > relation with local numbers. > [JRE] The relationship with local numbers was only in the context of the > reg-event package. Clearly, if the SSP does not know the precise set of > numbers used (and if up to 5 extension digits are available, this gives a > potential for 11,111 different numbers - 10,000 5 digit numbers plus 1000 4 > digits numbers, etc.), how would the SSP populate notifications? Listing all > potential numbers would result in very large notifications. > > In that case having a wildcard representation also in regevent packages sounds like a good idea. /Hans Erik van Elburg --001636137597ee55c30483cd370d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 9, 2010 at 2:32 PM, Elwell, John <jo= hn.elwell@siemens-enterprise.com> wrote:

>
> In my mind having a wild-carded entry that matches such a
> number block, is such an optimization. I do not see the
> relation with local numbers.
[JRE] The relationship with local numbers was only in the context of = the reg-event package. Clearly, if the SSP does not know the precise set of= numbers used (and if up to 5 extension digits are available, this gives a = potential for 11,111 different numbers - 10,000 5 digit numbers plus 1000 4= digits numbers, etc.), how would the SSP populate notifications? Listing a= ll potential numbers would result in very large notifications.

In that case having a = wildcard representation also=A0 in regevent packages sounds like a good idea.

/Hans Erik van Elburg
--001636137597ee55c30483cd370d-- From pkyzivat@cisco.com Fri Apr 9 06:13:45 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB0D3A6A5D for ; Fri, 9 Apr 2010 06:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgvVgUDy04M0 for ; Fri, 9 Apr 2010 06:13:44 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0C20628C112 for ; Fri, 9 Apr 2010 06:13:17 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPfEvktAZnwN/2dsb2JhbACbO3GhMpkyhQkE X-IronPort-AV: E=Sophos;i="4.52,177,1270425600"; d="scan'208";a="100227947" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2010 13:13:13 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o39DDDxk018622; Fri, 9 Apr 2010 13:13:13 GMT Message-ID: <4BBF27F8.2090704@cisco.com> Date: Fri, 09 Apr 2010 09:13:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> <4BBE69A0.9010606@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D3DB@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D3DB@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 13:13:45 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, April 08, 2010 7:41 PM >> To: Hadriel Kaplan >> >> One thing that is definitely bothering me is the removal of the >> phone-context from local numbers when it matches the ssp's domain. I >> don't like the resulting number without a phone context for reasons that >> are to some extent still subliminal. >> >> Is there some reason not to leave the ssp domain name in the >> phone-context in this case? > > Right, so Local-Numbers are rather tricky/ugly in practice, as far as I can tell. But I'm also not sure how much of what I see in the field is "normal" vs. just the error cases my product has to go fix to/from, which could well also be abnormal cases altogether. (so my impression could be way off) > > Anyway, afaict, when the phone-context is something like ssp.com (which is not often), then the IP-PBX has no idea about that phone-context, and the URI is modified to strip it or change it on its way to the IP-PBX. Because when it's the SSP's domain it's basically the SSP's private numbers, which an IP-PBX may just happen to be in the private-dialing plan for (unbeknownst to it). > > I guess the real question is what does the IP-PBX expect to see? I get your point about the pbx not understanding the ssp's phone context. Since the context "belongs to" the ssp (and the URI does too because of the domain), the ssp is free to translate to anything it wants. The trick is to have a clear understanding between it and the pbx of what that will be. The simple, answer is that it can be anything that the service agreement between the pbx and the ssp says it will be. But that's not a very good path to consistent interoperability. I don't have a great answer here for the moment. Of course for local numbers to be useful, they will have to work in both directions. We have been avoiding that discussion, but maybe we need to have it. That might also also tie in with how to represent certain non E.164 numbers that have to go from the pbx to the ssp, such as service numbers. (0, 411, 911, etc.) IMO there are only a couple of rational choices for those: user=dialstring or local number syntax. (E.g. 911;phone-context=+1) Perhaps that suggests doing something more specific about certain local number forms. And then maybe that would help in addressing the more general local number issues. >> For one, in the degenerate case where there are no other user >> parameters, this is ambiguous with an "email-style" address that happens >> to be all numeric. > > Good point. > > >> I was also worried about the reg event package, but you already >> identified that as a potential issue. > > Yeah, but in talking with Adam Roach about this concept earlier today, he thought we wouldn't need to have it in reg-event, because ultimately its not really an AoR you could get meaningful info for (and is private as well) so we could just say the Local-Number ones don't apply for reg-event. When we are talking about the reg event package as "the" way of determining what your implicit registration actually yielded, I consider it a problem if the reg event package can't report on some of the numbers that have been enabled by the registration. > Nevertheless, I think potentially this direction might bear fruit. > > Cool! > Also, Adam suggested I put back into the draft how this would work for a phone-context of an E.164 (which was in a previous incarnation of the draft). Since I don't know what it said, I won't comment on whether I want you to put it back. :-) But I agree it could be worth saying *something* about it (as I alluded above) as long as we find the *right* thing to say. Thanks, Paul From spencer@wonderhamster.org Fri Apr 9 06:21:41 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594B83A6935 for ; Fri, 9 Apr 2010 06:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q55vQ0FYRTzy for ; Fri, 9 Apr 2010 06:21:40 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 094D728C0F5 for ; Fri, 9 Apr 2010 06:21:03 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MIcD2-1Ny1DJ3yDA-0030cA; Fri, 09 Apr 2010 09:20:41 -0400 Message-ID: <38C8E0333CD84FDB908C277D09F0F4E1@china.huawei.com> From: "Spencer Dawkins" To: "Hans Erik van Elburg" , "Elwell, John" References: Date: Fri, 9 Apr 2010 08:20:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+K2dpMCNZeEdGga0ChIAWmHWHcYzwU4t+x7pZ JKNHlBvNNYBkoblb4KH/fSwNF1oO32qwbynjbAgbBMXxZT6aML G631U5OQ4YJccoiPn2dEecJqnvf6zKZnLLDPZXHgE4= Cc: martini@ietf.org Subject: Re: [martini] Question on gin and variable number lengths X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 13:21:41 -0000 Speaking as individual, my impression was that we didn't have a lot of objection to support for wildcarding - the concern (focused around the PUBLISH-based UP proposal, if that helps locate threads), most consistently stated by Rich Shockey, was that we couldn't count on wildcarding to guarantee that the size of the wildcarded expression would fit in request/response size limitations for UDP operation, whether due to number range fragmentation or simply because a bunch of unrelated numbers were involved. Again, speaking as individual, if it's helpful for us to define a wildcarding syntax, it would be more helpful if we do that soon, so that we don't have deployed implementations that don't understand that syntax when we DO define it... Thanks, Spencer ----- Original Message ----- From: Hans Erik van Elburg > In my mind having a wild-carded entry that matches such a > number block, is such an optimization. I do not see the > relation with local numbers. [JRE] The relationship with local numbers was only in the context of the reg-event package. Clearly, if the SSP does not know the precise set of numbers used (and if up to 5 extension digits are available, this gives a potential for 11,111 different numbers - 10,000 5 digit numbers plus 1000 4 digits numbers, etc.), how would the SSP populate notifications? Listing all potential numbers would result in very large notifications. In that case having a wildcard representation also in regevent packages sounds like a good idea. /Hans Erik van Elburg From adam@nostrum.com Fri Apr 9 07:05:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF2343A6803 for ; Fri, 9 Apr 2010 07:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAr5uFLAANo5 for ; Fri, 9 Apr 2010 07:05:17 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id DFD963A63EB for ; Fri, 9 Apr 2010 07:05:14 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o39E57b7059977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Apr 2010 09:05:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBF3413.9080408@nostrum.com> Date: Fri, 09 Apr 2010 09:05:07 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hans Erik van Elburg References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040405040600070206020300" Cc: "martini@ietf.org" Subject: Re: [martini] Question on gin and variable number lengths X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 14:05:18 -0000 This is a multi-part message in MIME format. --------------040405040600070206020300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/9/10 7:48 AM, Hans Erik van Elburg wrote: > On Fri, Apr 9, 2010 at 2:32 PM, Elwell, John > > wrote: > > > > > > In my mind having a wild-carded entry that matches such a > > number block, is such an optimization. I do not see the > > relation with local numbers. > [JRE] The relationship with local numbers was only in the context > of the reg-event package. Clearly, if the SSP does not know the > precise set of numbers used (and if up to 5 extension digits are > available, this gives a potential for 11,111 different numbers - > 10,000 5 digit numbers plus 1000 4 digits numbers, etc.), how > would the SSP populate notifications? Listing all potential > numbers would result in very large notifications. > > In that case having a wildcard representation also in regevent > packages sounds like a good idea. The problem is that the entity receiving the reg event bodies isn't a party to the initial REGISTER transaction. This means that it isn't part of the negotiation of the use of the bulk-number-registration feature. As a consequence, when he attempts to subscribe to the reg event for the PBX, he'll get back a modified syntax. A syntax based on a protocol extension. A protocol extension he did not indicate support for, and he does not understand. And that's an interop problem. As we discussed in Anaheim, I plan to put together a draft that talks about an _optional_ explicit indication of extensions at registration time. Use of such an indication completely solves the "variable length extensions" problem. /a --------------040405040600070206020300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 4/9/10 7:48 AM, Hans Erik van Elburg wrote:
On Fri, Apr 9, 2010 at 2:32 PM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:

>
> In my mind having a wild-carded entry that matches such a
> number block, is such an optimization. I do not see the
> relation with local numbers.
[JRE] The relationship with local numbers was only in the context of the reg-event package. Clearly, if the SSP does not know the precise set of numbers used (and if up to 5 extension digits are available, this gives a potential for 11,111 different numbers - 10,000 5 digit numbers plus 1000 4 digits numbers, etc.), how would the SSP populate notifications? Listing all potential numbers would result in very large notifications.

In that case having a wildcard representation also  in regevent packages sounds like a good idea.

The problem is that the entity receiving the reg event bodies isn't a party to the initial REGISTER transaction. This means that it isn't part of the negotiation of the use of the bulk-number-registration feature.

As a consequence, when he attempts to subscribe to the reg event for the PBX, he'll get back a modified syntax. A syntax based on a protocol extension. A protocol extension he did not indicate support for, and he does not understand.

And that's an interop problem.

As we discussed in Anaheim, I plan to put together a draft that talks about an _optional_ explicit indication of extensions at registration time. Use of such an indication completely solves the "variable length extensions" problem.

/a

--------------040405040600070206020300-- From HKaplan@acmepacket.com Fri Apr 9 07:14:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5003A68E5 for ; Fri, 9 Apr 2010 07:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sh+0Sia8mkuM for ; Fri, 9 Apr 2010 07:14:45 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CA4F23A68A0 for ; Fri, 9 Apr 2010 07:14:43 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 9 Apr 2010 10:14:38 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 9 Apr 2010 10:14:36 -0400 From: Hadriel Kaplan To: "Elwell, John" , "martini@ietf.org" Date: Fri, 9 Apr 2010 10:14:29 -0400 Thread-Topic: Other AoR's than E.164: draft-kaplan-martini-with-olive-00 Thread-Index: AcrXRahoZd4ezAUpQc6dHIV46fji5AAgzRcQAAk9HsA= Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D48C@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 14:14:46 -0000 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Friday, April 09, 2010 5:53 AM >=20 > Thanks for writing this up. I like the direction this is heading, but I a= m > not sure this really addresses the full population of use cases that we > might like to cover at some stage. That's coming in another draft (Part-2), which I wanted to separate from Ol= ive becaue I thought it would be more contentious and it will use a differe= nt mechanism. > Another concern is whether non-E.164 numbers based on phone-context of > domain name is sufficiently widespread. In fact I don't have much > knowledge of deployments based on non-E.164 numbers (excluding things lik= e > national numbers, which can be expanded to fully-qualified E.164 numbers)= . > For use in the scenarios you describe, do people use domain- or E.164- > based phone-contexts? I note your intention to give further consideration > to E.164-based phone-contexts. I had E.164-based local-numbers in an earlier private rev of the draft, but= pulled it at the last minute because it (1) had problems with reg-event, a= nd (2) it seemed like a similar problem as user@domain where the domain isn= 't under the SSP's authority, because the E.164 phone-context effectively m= akes its scope/knowledge/authority to be the E.164 not the SSP. But I'm putting it back in in the next rev of the Olive draft. =20 > So basically, I see this as useful material on how gin could be extended > in future to accommodate a broader range of AOR types. I am not sure that > we necessarily need to include these in the initial gin deliverable, but > by being aware of such future extensions we could at least ensure that we > don't build anything into gin that rules this out. The big question of whether it belongs in GIN or separate, in my mind, is: = assume draft-gin by itself gets published, and at some later date Olive is = published; would Olive require another option-tag, or can it simply use the= draft-gin as is? If it requires another option-tag again, or updates GIN = in some way, then I'd say let's just stick it in GIN; if can stand alone as= an informational then I'd say keep it separate. -hadriel From john.elwell@siemens-enterprise.com Fri Apr 9 07:20:57 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B827D3A686D for ; Fri, 9 Apr 2010 07:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQO3bBtIvLt7 for ; Fri, 9 Apr 2010 07:20:55 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 67D993A68A0 for ; Fri, 9 Apr 2010 07:20:52 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1499257; Fri, 9 Apr 2010 16:20:47 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id ACDF61EB82AB; Fri, 9 Apr 2010 16:20:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 9 Apr 2010 16:20:47 +0200 From: "Elwell, John" To: Spencer Dawkins , Hans Erik van Elburg Date: Fri, 9 Apr 2010 16:20:46 +0200 Thread-Topic: [martini] Question on gin and variable number lengths Thread-Index: AcrX55Daq8zgRDZ4RH+uNB4jML2+ZQACCu8A Message-ID: References: <38C8E0333CD84FDB908C277D09F0F4E1@china.huawei.com> In-Reply-To: <38C8E0333CD84FDB908C277D09F0F4E1@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Question on gin and variable number lengths X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 14:20:57 -0000 Spencer, The point is, it would only need to apply to the reg-event package, and tha= t need not be part of the initial MARTINI deliverables. John=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 > Sent: 09 April 2010 14:21 > To: Hans Erik van Elburg; Elwell, John > Cc: martini@ietf.org > Subject: Re: [martini] Question on gin and variable number lengths >=20 > Speaking as individual, my impression was that we didn't have=20 > a lot of=20 > objection to support for wildcarding - the concern (focused=20 > around the=20 > PUBLISH-based UP proposal, if that helps locate threads),=20 > most consistently=20 > stated by Rich Shockey, was that we couldn't count on wildcarding to=20 > guarantee that the size of the wildcarded expression would fit in=20 > request/response size limitations for UDP operation, whether=20 > due to number=20 > range fragmentation or simply because a bunch of unrelated=20 > numbers were=20 > involved. >=20 > Again, speaking as individual, if it's helpful for us to define a=20 > wildcarding syntax, it would be more helpful if we do that=20 > soon, so that we=20 > don't have deployed implementations that don't understand=20 > that syntax when=20 > we DO define it... >=20 > Thanks, >=20 > Spencer >=20 > ----- Original Message -----=20 > From: Hans Erik van Elburg >=20 > > In my mind having a wild-carded entry that matches such a > > number block, is such an optimization. I do not see the > > relation with local numbers. >=20 > [JRE] The relationship with local numbers was only in the=20 > context of the=20 > reg-event package. Clearly, if the SSP does not know the=20 > precise set of=20 > numbers used (and if up to 5 extension digits are available,=20 > this gives a=20 > potential for 11,111 different numbers - 10,000 5 digit=20 > numbers plus 1000 4=20 > digits numbers, etc.), how would the SSP populate=20 > notifications? Listing all=20 > potential numbers would result in very large notifications. >=20 >=20 > In that case having a wildcard representation also in=20 > regevent packages=20 > sounds like a good idea. >=20 > /Hans Erik van Elburg=20 >=20 > = From spencer@wonderhamster.org Fri Apr 9 07:23:04 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03E33A68C0 for ; Fri, 9 Apr 2010 07:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heo+ntt0IInl for ; Fri, 9 Apr 2010 07:22:57 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id CD1D53A688A for ; Fri, 9 Apr 2010 07:22:48 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Lu77W-1NYND715K2-010iYy; Fri, 09 Apr 2010 10:22:42 -0400 Message-ID: <551B2F8F28374DC3A791737B7A516BE0@china.huawei.com> From: "Spencer Dawkins" To: "Elwell, John" , "Hans Erik van Elburg" References: <38C8E0333CD84FDB908C277D09F0F4E1@china.huawei.com> Date: Fri, 9 Apr 2010 09:22:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+57/KJoUfnxfNMKu55oIAlOdIPYSPPRJdhoNz 41WPcjVAZV6kMJAPQmbOJq0VB7TJLuziUrOajuyCz8+PtniTZA nmb2ZWGRubFjR1NnHPSik3kA/vVjIJtZnzTi/B2QY0= Cc: martini@ietf.org Subject: Re: [martini] Question on gin and variable number lengths X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 14:23:04 -0000 Hi, John, That is a lovely answer. Spencer, speaking as co-chair ----- Original Message ----- From: "Elwell, John" To: "Spencer Dawkins" ; "Hans Erik van Elburg" Cc: Sent: Friday, April 09, 2010 9:20 AM Subject: RE: [martini] Question on gin and variable number lengths Spencer, The point is, it would only need to apply to the reg-event package, and that need not be part of the initial MARTINI deliverables. John > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: 09 April 2010 14:21 > To: Hans Erik van Elburg; Elwell, John > Cc: martini@ietf.org > Subject: Re: [martini] Question on gin and variable number lengths > > Speaking as individual, my impression was that we didn't have > a lot of > objection to support for wildcarding - the concern (focused > around the > PUBLISH-based UP proposal, if that helps locate threads), > most consistently > stated by Rich Shockey, was that we couldn't count on wildcarding to > guarantee that the size of the wildcarded expression would fit in > request/response size limitations for UDP operation, whether > due to number > range fragmentation or simply because a bunch of unrelated > numbers were > involved. > > Again, speaking as individual, if it's helpful for us to define a > wildcarding syntax, it would be more helpful if we do that > soon, so that we > don't have deployed implementations that don't understand > that syntax when > we DO define it... > > Thanks, > > Spencer > > ----- Original Message ----- > From: Hans Erik van Elburg > > > In my mind having a wild-carded entry that matches such a > > number block, is such an optimization. I do not see the > > relation with local numbers. > > [JRE] The relationship with local numbers was only in the > context of the > reg-event package. Clearly, if the SSP does not know the > precise set of > numbers used (and if up to 5 extension digits are available, > this gives a > potential for 11,111 different numbers - 10,000 5 digit > numbers plus 1000 4 > digits numbers, etc.), how would the SSP populate > notifications? Listing all > potential numbers would result in very large notifications. > > > In that case having a wildcard representation also in > regevent packages > sounds like a good idea. > > /Hans Erik van Elburg > > = From adam@nostrum.com Fri Apr 9 08:29:19 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0FFE3A68E2 for ; Fri, 9 Apr 2010 08:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3Qj9MF800KL for ; Fri, 9 Apr 2010 08:29:16 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 1E05F3A6920 for ; Fri, 9 Apr 2010 08:29:08 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o39FSoYd066422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Apr 2010 10:28:57 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BBF47AF.3070303@nostrum.com> Date: Fri, 09 Apr 2010 10:28:47 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Spencer Dawkins References: <38C8E0333CD84FDB908C277D09F0F4E1@china.huawei.com> <551B2F8F28374DC3A791737B7A516BE0@china.huawei.com> In-Reply-To: <551B2F8F28374DC3A791737B7A516BE0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: martini@ietf.org Subject: Re: [martini] Question on gin and variable number lengths X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 15:29:20 -0000 I also think it's highly flawed, as an answer. See my earlier mail about foisting a protocol extension syntax on a reg event subscriber who does not understand the protocol extension. /a On 4/9/10 9:22 AM, Spencer Dawkins wrote: > Hi, John, > > That is a lovely answer. > > Spencer, speaking as co-chair > > ----- Original Message ----- From: "Elwell, John" > > To: "Spencer Dawkins" ; "Hans Erik van > Elburg" > Cc: > Sent: Friday, April 09, 2010 9:20 AM > Subject: RE: [martini] Question on gin and variable number lengths > > > Spencer, > > The point is, it would only need to apply to the reg-event package, > and that need not be part of the initial MARTINI deliverables. > > John > >> -----Original Message----- >> From: Spencer Dawkins [mailto:spencer@wonderhamster.org] >> Sent: 09 April 2010 14:21 >> To: Hans Erik van Elburg; Elwell, John >> Cc: martini@ietf.org >> Subject: Re: [martini] Question on gin and variable number lengths >> >> Speaking as individual, my impression was that we didn't have >> a lot of >> objection to support for wildcarding - the concern (focused >> around the >> PUBLISH-based UP proposal, if that helps locate threads), >> most consistently >> stated by Rich Shockey, was that we couldn't count on wildcarding to >> guarantee that the size of the wildcarded expression would fit in >> request/response size limitations for UDP operation, whether >> due to number >> range fragmentation or simply because a bunch of unrelated >> numbers were >> involved. >> >> Again, speaking as individual, if it's helpful for us to define a >> wildcarding syntax, it would be more helpful if we do that >> soon, so that we >> don't have deployed implementations that don't understand >> that syntax when >> we DO define it... >> >> Thanks, >> >> Spencer >> >> ----- Original Message ----- From: Hans Erik van Elburg >> >> > In my mind having a wild-carded entry that matches such a >> > number block, is such an optimization. I do not see the >> > relation with local numbers. >> >> [JRE] The relationship with local numbers was only in the >> context of the >> reg-event package. Clearly, if the SSP does not know the >> precise set of >> numbers used (and if up to 5 extension digits are available, >> this gives a >> potential for 11,111 different numbers - 10,000 5 digit >> numbers plus 1000 4 >> digits numbers, etc.), how would the SSP populate >> notifications? Listing all >> potential numbers would result in very large notifications. >> >> >> In that case having a wildcard representation also in >> regevent packages >> sounds like a good idea. >> >> /Hans Erik van Elburg >> >> = > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From pkyzivat@cisco.com Fri Apr 9 09:37:57 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760AA3A6941 for ; Fri, 9 Apr 2010 09:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.41 X-Spam-Level: X-Spam-Status: No, score=-10.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2u4ZedDGKvN for ; Fri, 9 Apr 2010 09:37:56 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 210FB3A6988 for ; Fri, 9 Apr 2010 09:37:31 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAL1vktAZnwM/2dsb2JhbACbPHGiRJkhhQkE X-IronPort-AV: E=Sophos;i="4.52,178,1270425600"; d="scan'208";a="100284286" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Apr 2010 16:37:23 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o39GbNqc027668; Fri, 9 Apr 2010 16:37:23 GMT Message-ID: <4BBF57C5.3060400@cisco.com> Date: Fri, 09 Apr 2010 12:37:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: <38C8E0333CD84FDB908C277D09F0F4E1@china.huawei.com> <551B2F8F28374DC3A791737B7A516BE0@china.huawei.com> <4BBF47AF.3070303@nostrum.com> In-Reply-To: <4BBF47AF.3070303@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: martini@ietf.org Subject: Re: [martini] Question on gin and variable number lengths X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 16:37:57 -0000 Adam, We could consider making the wildcarded data an extension to the application/reginfo+xml syntax from rfc 3680, just as rfc 5628 extended it. E.g., another element within to describe the wildcard. There is already provision for extension elements, so this would be backward compatible. To make this work it would only be necessary to specify how the basic syntax of the contact would be denoted. I think we could simply use the uri without user part for this. Thanks, Paul Adam Roach wrote: > I also think it's highly flawed, as an answer. See my earlier mail about > foisting a protocol extension syntax on a reg event subscriber who does > not understand the protocol extension. > > /a > > On 4/9/10 9:22 AM, Spencer Dawkins wrote: >> Hi, John, >> >> That is a lovely answer. >> >> Spencer, speaking as co-chair >> >> ----- Original Message ----- From: "Elwell, John" >> >> To: "Spencer Dawkins" ; "Hans Erik van >> Elburg" >> Cc: >> Sent: Friday, April 09, 2010 9:20 AM >> Subject: RE: [martini] Question on gin and variable number lengths >> >> >> Spencer, >> >> The point is, it would only need to apply to the reg-event package, >> and that need not be part of the initial MARTINI deliverables. >> >> John >> >>> -----Original Message----- >>> From: Spencer Dawkins [mailto:spencer@wonderhamster.org] >>> Sent: 09 April 2010 14:21 >>> To: Hans Erik van Elburg; Elwell, John >>> Cc: martini@ietf.org >>> Subject: Re: [martini] Question on gin and variable number lengths >>> >>> Speaking as individual, my impression was that we didn't have >>> a lot of >>> objection to support for wildcarding - the concern (focused >>> around the >>> PUBLISH-based UP proposal, if that helps locate threads), >>> most consistently >>> stated by Rich Shockey, was that we couldn't count on wildcarding to >>> guarantee that the size of the wildcarded expression would fit in >>> request/response size limitations for UDP operation, whether >>> due to number >>> range fragmentation or simply because a bunch of unrelated >>> numbers were >>> involved. >>> >>> Again, speaking as individual, if it's helpful for us to define a >>> wildcarding syntax, it would be more helpful if we do that >>> soon, so that we >>> don't have deployed implementations that don't understand >>> that syntax when >>> we DO define it... >>> >>> Thanks, >>> >>> Spencer >>> >>> ----- Original Message ----- From: Hans Erik van Elburg >>> >>> > In my mind having a wild-carded entry that matches such a >>> > number block, is such an optimization. I do not see the >>> > relation with local numbers. >>> >>> [JRE] The relationship with local numbers was only in the >>> context of the >>> reg-event package. Clearly, if the SSP does not know the >>> precise set of >>> numbers used (and if up to 5 extension digits are available, >>> this gives a >>> potential for 11,111 different numbers - 10,000 5 digit >>> numbers plus 1000 4 >>> digits numbers, etc.), how would the SSP populate >>> notifications? Listing all >>> potential numbers would result in very large notifications. >>> >>> >>> In that case having a wildcard representation also in >>> regevent packages >>> sounds like a good idea. >>> >>> /Hans Erik van Elburg >>> >>> = >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From ietf.hanserik@gmail.com Fri Apr 9 21:42:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832B13A6802 for ; Fri, 9 Apr 2010 21:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPocu1cdCWvt for ; Fri, 9 Apr 2010 21:42:45 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 5C5EC3A67C1 for ; Fri, 9 Apr 2010 21:42:45 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so290877eyf.51 for ; Fri, 09 Apr 2010 21:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=BZCCYr0LJXckT3AwSoV0ufqEdsFtCr/sDhgPp/k25P4=; b=O+bKgWW81R5iYRpZOPwvCVTPE3LFxGM/dQXHnQXWqSu14lIIe3F/+9IusSdnd2s5ay GkrPW+XSz04+duqyzNUKN1zZFT5H8YVWt7ALJ7nupzqT31OIk1xn4YBCxKAhlU12UXLO doVTSpuSS8YJ+xzdkf4Dr4DlVpRdJpspnIi8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MwSl7uL7mqlO4LEOnO6RKRsdsqfNBISYCANAvMOBc6y1ZONC59dJAVie7nLaJmxgGj CLxJFK+UMakI4u4faAzHjnhKfWbwrVLkJdhDU99WRCxH2TQJaMf3ty4aCEv26EdvLihe ZZoHkqUgILng+/VSylI3tzoGAzht+3rom1J/w= MIME-Version: 1.0 Received: by 10.213.2.129 with HTTP; Fri, 9 Apr 2010 21:42:36 -0700 (PDT) In-Reply-To: <4BBF57C5.3060400@cisco.com> References: <38C8E0333CD84FDB908C277D09F0F4E1@china.huawei.com> <551B2F8F28374DC3A791737B7A516BE0@china.huawei.com> <4BBF47AF.3070303@nostrum.com> <4BBF57C5.3060400@cisco.com> Date: Sat, 10 Apr 2010 06:42:36 +0200 Received: by 10.213.80.140 with SMTP id t12mr893540ebk.7.1270874556641; Fri, 09 Apr 2010 21:42:36 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Paul Kyzivat Content-Type: multipart/alternative; boundary=00163613751f80d1e10483da8a55 Cc: martini@ietf.org Subject: Re: [martini] Question on gin and variable number lengths X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 04:42:46 -0000 --00163613751f80d1e10483da8a55 Content-Type: text/plain; charset=ISO-8859-1 Yes, without having checked the details of reginfo this seems to be the way to go. It is perfectly OK to expect that nodes that are interested in this information understand the extension. /Hans Erik van Elburg On Fri, Apr 9, 2010 at 6:37 PM, Paul Kyzivat wrote: > Adam, > > We could consider making the wildcarded data an extension to the > application/reginfo+xml syntax from rfc 3680, just as rfc 5628 extended it. > E.g., another element within to describe the wildcard. > > There is already provision for extension elements, so this would be > backward compatible. > > To make this work it would only be necessary to specify how the basic > syntax of the contact would be denoted. I think we could simply use the uri > without user part for this. > > Thanks, > Paul > > > --00163613751f80d1e10483da8a55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, without having checked the details of reginfo this seems to be the way= to go.

It is perfectly OK to expect that nodes that are interested = in this information understand the extension.

/Hans Er= ik van Elburg


On Fri, Apr 9, 2010 at 6:37 PM, Paul Kyz= ivat <pkyzivat@c= isco.com> wrote:
Adam,

We could consider making the wildcarded data an extension to the applicatio= n/reginfo+xml syntax from rfc 3680, just as rfc 5628 extended it. E.g., ano= ther element within <contact> to describe the wildcard.

There is already provision for extension elements, so this would be backwar= d compatible.

To make this work it would only be necessary to specify how the basic synta= x of the contact would be denoted. I think we could simply use the uri with= out user part for this.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul


--00163613751f80d1e10483da8a55-- From HKaplan@acmepacket.com Sat Apr 10 07:14:06 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C913A67DB for ; Sat, 10 Apr 2010 07:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHP9ay80MFvA for ; Sat, 10 Apr 2010 07:14:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9061B3A672F for ; Sat, 10 Apr 2010 07:14:05 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 10 Apr 2010 10:14:00 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 10 Apr 2010 10:14:00 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Adam Roach Date: Sat, 10 Apr 2010 10:14:00 -0400 Thread-Topic: [martini] Question on gin and variable number lengths Thread-Index: AcrYAySEX+AThRNjS7aHg3JsCV1QUAAsgThQ Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D639@mail> References: <38C8E0333CD84FDB908C277D09F0F4E1@china.huawei.com> <551B2F8F28374DC3A791737B7A516BE0@china.huawei.com> <4BBF47AF.3070303@nostrum.com> <4BBF57C5.3060400@cisco.com> In-Reply-To: <4BBF57C5.3060400@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Question on gin and variable number lengths X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 14:14:06 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Paul Kyzivat > Sent: Friday, April 09, 2010 12:37 PM >=20 > There is already provision for extension elements, so this would be > backward compatible. Yeah I don't see a _general_ issue with backwards-compatibility - an rfc368= 0 UA subscribing and getting an unknown namespace extension XML element is = supposed to ignore it. But see below for what I think is the specific issu= e. =20 > To make this work it would only be necessary to specify how the basic > syntax of the contact would be denoted. I think we could simply use the > uri without user part for this. Just to be clear, it's not a contact URI we're talking about, right? This = is a variable-length AoR. So the rub is: can you use a "registration" XML = element for it, in a backwards-compatible way?=20 It also raises a corner-case issue: imagine if the SSP allocates a variable= length number of prefix 12345, but also does know and handle the specific = AoR number 12345678. This can happen in a private numbering plan for examp= le, where the SSP may have centrex service for some specific numbers in a b= lock, but the rest of the block is handled by the PBX at the Enterprise. S= o we'd have to handle that somehow, and handle it in a way that lets the sp= ecific number 12345678 be registered from multiple contacts, including poss= ibly the PBX itself. -hadriel From HKaplan@acmepacket.com Sat Apr 10 09:02:44 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261083A692C for ; Sat, 10 Apr 2010 09:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JJ-flJw9tG8 for ; Sat, 10 Apr 2010 09:02:42 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B7AAE3A6903 for ; Sat, 10 Apr 2010 09:02:42 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 10 Apr 2010 12:02:38 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 10 Apr 2010 12:02:37 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Sat, 10 Apr 2010 12:02:37 -0400 Thread-Topic: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 Thread-Index: AcrX5nVRqanLswgATX2aNFvUo7fDVgA3XhIg Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D643@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> <4BBE69A0.9010606@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D3DB@mail> <4BBF27F8.2090704@cisco.com> In-Reply-To: <4BBF27F8.2090704@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 16:02:44 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, April 09, 2010 9:13 AM >=20 > I get your point about the pbx not understanding the ssp's phone context. >=20 > Since the context "belongs to" the ssp (and the URI does too because of > the domain), the ssp is free to translate to anything it wants. The > trick is to have a clear understanding between it and the pbx of what > that will be. The simple, answer is that it can be anything that the > service agreement between the pbx and the ssp says it will be. But > that's not a very good path to consistent interoperability. I don't have > a great answer here for the moment. Right, when the phone-context is the SSP's domain, it effectively means it'= s a local-number to the SSP, which is only meaningful to it, and only it ha= s knowledge of how to handle. In my simple caveman brain, draft-gin is effectively just a bulk registrati= on mechanism, as if the PBX had really registered for each AoR separately. = So what AoR would the PBX register to for the local-number "12345;ext=3D67= 8;phone-context=3Dssp.com"? I *think* the actual answer is it would have registered for "sip: 12345;ext= =3D678;phone-context=3Dssp.com@ssp.com". If that's true, draft-olive is cu= rrently wrong. It should set the contact to "sip: 12345;ext=3D678;phone-co= ntext=3Dssp.com@pbx.com". -hadriel From HKaplan@acmepacket.com Sat Apr 10 09:30:09 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51ADA3A67CC for ; Sat, 10 Apr 2010 09:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 572OnsTUKqtz for ; Sat, 10 Apr 2010 09:30:08 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 45D6B3A67F4 for ; Sat, 10 Apr 2010 09:30:04 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 10 Apr 2010 12:29:59 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 10 Apr 2010 12:29:59 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Sat, 10 Apr 2010 12:29:59 -0400 Thread-Topic: Local-numbers (was Other AoR's than E.164: draft-kaplan-martini-with-olive-00) Thread-Index: AcrX5nVRqanLswgATX2aNFvUo7fDVgA4MkBA Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D647@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> <4BBE69A0.9010606@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D3DB@mail> <4BBF27F8.2090704@cisco.com> In-Reply-To: <4BBF27F8.2090704@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: [martini] Local-numbers (was Other AoR's than E.164: draft-kaplan-martini-with-olive-00) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 16:30:09 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, April 09, 2010 9:13 AM >=20 > Of course for local numbers to be useful, they will have to work in both > directions. We have been avoiding that discussion, but maybe we need to > have it.=20 There be dragons. :) One of the problems with local-numbers is the device which actually knows w= hat context it's in is sometimes not the PBX, and sometimes is the PBX. In practice I know there are times when the ingress proxy of the SSP is the= one which does it, but I think that from a spec and architectural model th= e PBX should be the one which inserts a phone-context. > That might also also tie in with how to represent certain non > E.164 numbers that have to go from the pbx to the ssp, such as service > numbers. (0, 411, 911, etc.) IMO there are only a couple of rational > choices for those: user=3Ddialstring or local number syntax. (E.g. > 911;phone-context=3D+1) Perhaps that suggests doing something more > specific about certain local number forms.=20 In practice it seems to me that the user=3Ddialstring param isn't used much= . If the request-uri is "sip:411@ssp.com", it's handled as a dialed phone = number of "411" regardless of a user=3Ddialstring. SSP's just don't alloca= te "411" as a username to some random SIP subscriber. I would argue that's= true for all service numbers, including "911" - you can send a sos URN or = a user=3Ddialstring param, but it's not like they're going to give the AoR = of "sip:911@ssp.com" to some random subscriber anyway, so it's not ambiguou= s in practice. There's no real interop problem to solve, afaict. If we *were* to specify a dialstring, then it would need a phone-context an= yway (per rfc4967), and in my opinion that phone-context should be "ssp.com= ", ironically. -hadriel From trac@tools.ietf.org Sat Apr 10 12:50:24 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27FDE3A68ED for ; Sat, 10 Apr 2010 12:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k2ksLac0P2A for ; Sat, 10 Apr 2010 12:50:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8EC6B3A68E4 for ; Sat, 10 Apr 2010 12:50:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0gh6-0002qw-3X; Sat, 10 Apr 2010 12:50:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: martini Date: Sat, 10 Apr 2010 19:50:16 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/28 Message-ID: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> X-Trac-Ticket-ID: 28 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 19:50:24 -0000 #28: GIN: user=phone in the Contact ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: gin | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- The current example in section 8 and elsewhere in the draft uses a "user=phone" URI param in the Contact of the REGISTER. Since the URI does not actually have a user portion, it does not follow the format of telephone-suscriber and should not have this param. For example, when expanded and used for routing to the IP-PBX, the user portion of the resultant req-uri is not in fact a phone number but rather just a URI (though it sure will look like a phone number ;) As another example, depending on how the temp-gruu concept ends up, it may be incompatible with a temp-gruu mechanism, since a request to the IP-PBX with its temp-gruu would not have a phone user. Likewise, there should be text stipulating a user=dialstring is not appropriate for the Registered Contact. -- Ticket URL: martini From trac@tools.ietf.org Sat Apr 10 13:07:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856AA3A6919 for ; Sat, 10 Apr 2010 13:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUCBQ0ua7RxE for ; Sat, 10 Apr 2010 13:07:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C199A3A690D for ; Sat, 10 Apr 2010 13:07:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0gxh-0003QL-Pk; Sat, 10 Apr 2010 13:07:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: martini Date: Sat, 10 Apr 2010 20:07:25 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/29 Message-ID: <064.ee2915cc34068edb5fe6157b1cd193ad@tools.ietf.org> X-Trac-Ticket-ID: 29 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #29: GIN: inappropriate introductory text X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 20:07:30 -0000 #29: GIN: inappropriate introductory text ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Now that the GIN draft is a WG doc, the language used in the Introduction section needs to be less subjective. :) In particular, the following paragraph should be removed: Because this problem has certain similarities with the REGISTER operation, several non-standard, ad hoc extensions to REGISTER have been developed to address this desire. And the current text of the last paragraph of the Introduction, which starts with "In recognition of the momentum..." should be changed to: In recognition of the momentum that a REGISTER-based approach has seen in deployments, this document defines a REGISTER-based approach that is tailored to E.164-addressed extensions in a SIP PBX environment. It does not address SIP URIs in which the user portion is not an E.164 number. -- Ticket URL: martini From trac@tools.ietf.org Sat Apr 10 13:35:08 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02EBB3A67E7 for ; Sat, 10 Apr 2010 13:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7XGlX1nFKQz for ; Sat, 10 Apr 2010 13:35:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 14A383A677D for ; Sat, 10 Apr 2010 13:35:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0hOQ-0005Hj-P9; Sat, 10 Apr 2010 13:35:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: martini Date: Sat, 10 Apr 2010 20:35:02 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/30 Message-ID: <064.d7efde8f2663b068aaab0de8469262ae@tools.ietf.org> X-Trac-Ticket-ID: 30 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #30: GIN: change 'bulknumbercontact' to 'bnc' or some such X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 20:35:08 -0000 #30: GIN: change 'bulknumbercontact' to 'bnc' or some such ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- I know this is a nit, but is there some reason the option-tag needs to be so long? Why can't we just use the same string as the Contact URI param: 'bnc'? Or make it 'gin' for all I care. It could be an acronym for 'Generate Implicit Numbers', for example. -- Ticket URL: martini From trac@tools.ietf.org Sat Apr 10 20:41:26 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5C643A6781 for ; Sat, 10 Apr 2010 20:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-eg2SsdLgmP for ; Sat, 10 Apr 2010 20:41:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BDEAF3A67F7 for ; Sat, 10 Apr 2010 20:41:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0o2z-0004CI-Gp; Sat, 10 Apr 2010 20:41:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: martini Date: Sun, 11 Apr 2010 03:41:21 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/31 Message-ID: <064.da47dcd1c0e82864cfd0f4f8eec80169@tools.ietf.org> X-Trac-Ticket-ID: 31 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #31: GIN: add text requiring Path X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 03:41:26 -0000 #31: GIN: add text requiring Path ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- I have heard no objections to requiring RFC 3327 Path in GIN. I therefore ask for section 8 example messages to be updated with the 'path' option- tag in the Supported header field, and for something like the following text to be added after the third paragraph of Section 5: The PBX MUST also support the Path mechanism in [RFC3327], and MUST include a 'path' option-tag in the Supported header field of the REGISTER request, although it MAY ignore the Path header fields returned in the REGISTER response. This is necessary because Proxies between the PBX and the Registrar may need to insert Path header field values in the REGISTER request for this document's mechanism to function properly, and per [RFC3327] they can only do so if the UAC inserted the option-tag in the Supported header field. A Registrar compliant with this document MUST support the Path mechanism defined in [RFC3327]. -- Ticket URL: martini From bernard_aboba@hotmail.com Sun Apr 11 01:46:39 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7CF63A6885 for ; Sun, 11 Apr 2010 01:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6OPXtt4Wg+e for ; Sun, 11 Apr 2010 01:46:38 -0700 (PDT) Received: from blu0-omc2-s33.blu0.hotmail.com (blu0-omc2-s33.blu0.hotmail.com [65.55.111.108]) by core3.amsl.com (Postfix) with ESMTP id 9F2F63A67EA for ; Sun, 11 Apr 2010 01:46:38 -0700 (PDT) Received: from BLU137-DS5 ([65.55.111.71]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 11 Apr 2010 01:46:34 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Sun, 11 Apr 2010 01:46:33 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CAD918.D0D47EF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrZU3zOLXSlZiJfRMeK/a0ortmPaQ== Content-Language: en-us X-OriginalArrivalTime: 11 Apr 2010 08:46:34.0467 (UTC) FILETIME=[7D821330:01CAD953] Subject: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 08:46:39 -0000 ------=_NextPart_000_000D_01CAD918.D0D47EF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Section 3.2.1 One of the initial benefits cited for only supporting E.164 is that an E.164 user name is globally unique by itself, and thus changing the host portion of the Request-URI does not impact the identity of the intended target of the Request. [BA] Is the issue really the global uniqueness of the AOR or the global uniqueness of the user portion? Using single AOR registration, it's possible to cause a Request-URI of "bob@ssp.example.net" to be mapped to a contact of "bob@pbx.example.com". To make sure this is ok, it's not enough just to authenticate the REGISTER; the SSP also needs to check that the mapping is authorized (e.g. the PBX sending the registration really is authorized to utilize pbx.example.com as a contact domain). In the case of multiple AOR registration, presumably the SSP has pre-provisioned a list of AORs that may be implicitly registered, and the same authorization checks would apply to the contact domain. So while multiple AOR registration may not make this usage case more problematic, using a globally unique user portion (e.g. E.164 number) makes the authorization check less necessary. Section 3.2.2 For example, if the IP-PBX has multiple SSPs it Registers into, it can't just receive a request to "sip:bob@pbx.enterprise.com", because it won't know if that's to "sip:bob@ssp1.example.net" or "sip:bob@ssp2.example.net", which may be different users. [BA] Presumably, this paragraph is describing the problem created by having multiple SSPs map different Request-URIs (e.g. bob@ssp1.example.net, bob@ssp2.example.net) to the same registered contact (bob@pbx.enterprise.com), right? While I understand the potential issues raised by this, a question that this (and other examples) raise for me, is the extent to which the issues are unique to multiple AOR registration. For example, it's possible to use multiple single AOR registrations to bind multiple AORs to the same contact, causing the same problem. Given that, is this issue really intrinsic to multiple AOR registration? Or is it speaking to the problems created by having a single contact (created implicitly or explicitly) map to multiple Request-URIs? ------=_NextPart_000_000D_01CAD918.D0D47EF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3.2.1

 

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

 

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

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

"bob@ssp.example.net" to be mapped to a = contact of "bob@pbx.example.com".   

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

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

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

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

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

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

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

necessary. 

 

Section 3.2.2

 

   For example, if the IP-PBX has multiple SSPs it =
Registers
   into, it can't just receive =
a request to
   =
"sip:bob@pbx.enterprise.com", because it won't know if that's =
to
   =
"sip:bob@ssp1.example.net" or =
"sip:bob@ssp2.example.net", which =
may
   be different =
users.
 
[BA] Presumably, =
this paragraph is describing the problem created by having =

multiple SSPs map different Request-URIs (e.g. =
bob@ssp1.example.net, 
bob@ssp2.example.net) to the =
same registered contact =
(bob@pbx.enterprise.com),
right?
 
While I understand the potential issues =
raised by this, a question that this 
(and other =
examples) raise for me, is the extent to which the issues are unique =

to multiple AOR registration.  For example, =
it's possible to use multiple
single AOR =
registrations to bind multiple AORs to the same contact, =
causing
the same problem.  Given that, is this =
issue really intrinsic to multiple
AOR =
registration?  Or is it speaking to the problems created by having =
a single
contact (created implicitly or explicitly) =
map to multiple =
Request-URIs?
 
 =
;
 
 
 
------=_NextPart_000_000D_01CAD918.D0D47EF0-- From bernard_aboba@hotmail.com Sun Apr 11 08:52:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928113A67FA for ; Sun, 11 Apr 2010 08:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.19 X-Spam-Level: X-Spam-Status: No, score=0.19 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzYQmnpnTB9Y for ; Sun, 11 Apr 2010 08:52:29 -0700 (PDT) Received: from blu0-omc2-s22.blu0.hotmail.com (blu0-omc2-s22.blu0.hotmail.com [65.55.111.97]) by core3.amsl.com (Postfix) with ESMTP id 94C463A63EB for ; Sun, 11 Apr 2010 08:52:29 -0700 (PDT) Received: from BLU137-W33 ([65.55.111.71]) by blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 11 Apr 2010 08:52:25 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a2a18518-95c8-4832-a2a8-7a858b41e95a_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Sun, 11 Apr 2010 08:52:25 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 11 Apr 2010 15:52:25.0227 (UTC) FILETIME=[FAF2A5B0:01CAD98E] Subject: [martini] Martini Virtual Interim IV: April 29, 2010 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 15:52:30 -0000 --_a2a18518-95c8-4832-a2a8-7a858b41e95a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Based on the Doodle Poll=2C MARTINI Virtual Interim IV will take place on T= hursday=2C April 29=2C 2010 from 11 AM - 1 PM Pacific Time.=20 Details to follow.=20 If you have Agenda items=2C please send them to Spencer and myself.=20 = --_a2a18518-95c8-4832-a2a8-7a858b41e95a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Based on the Doodle Poll=2C MARTINI Virtual Interim IV will take place on T= hursday=2C April 29=2C 2010 from 11 AM - 1 PM Pacific Time.

Details= to follow.

If you have Agenda items=2C please send them to Spencer= and myself.
=
<= a href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGo= od" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decorati= on: none=3B">
= --_a2a18518-95c8-4832-a2a8-7a858b41e95a_-- From HKaplan@acmepacket.com Sun Apr 11 08:57:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63C1E3A688F for ; Sun, 11 Apr 2010 08:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYFPnlp4+pLL for ; Sun, 11 Apr 2010 08:57:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A44BD3A67FB for ; Sun, 11 Apr 2010 08:57:10 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 11 Apr 2010 11:57:02 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 11 Apr 2010 11:57:01 -0400 From: Hadriel Kaplan To: Bernard Aboba , "martini@ietf.org" Date: Sun, 11 Apr 2010 11:57:01 -0400 Thread-Topic: [martini] Questions about draft-kaplan-martini-with-olive Thread-Index: AcrZU3zOLXSlZiJfRMeK/a0ortmPaQAOFdfA Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D673@mail> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A79F3D673mail_" MIME-Version: 1.0 Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 15:57:18 -0000 --_000_430FC6BDED356B4C8498F634416644A91A79F3D673mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Bernard, Comments inline... ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Bernard Aboba Sent: Sunday, April 11, 2010 4:47 AM To: martini@ietf.org Subject: [martini] Questions about draft-kaplan-martini-with-olive Section 3.2.1 One of the initial benefits cited for only supporting E.164 is that an E.164 user name is globally unique by itself, and thus changing the host portion of the Request-URI does not impact the identity of the intended target of the Request. [BA] Is the issue really the global uniqueness of the AOR or the global uni= queness of the user portion? Using single AOR registration, it's possible to cause a Req= uest-URI of "bob@ssp.example.net" to be mapped to a contact of "bob@pbx.example.com". To make sure this is ok, it's not enough just to authenticate the REGISTER;= the SSP also needs to check that the mapping is authorized (e.g. the PBX sending the registration really is authorized to utilize pbx.example.com as= a contact domain). [hsk] As far as I know, there is no authorization checking for single Regis= trations which does not also occur in, or apply to, [draft-gin] bulk Regist= rations. [BA] In the case of multiple AOR registration, presumably the SSP has pre-p= rovisioned a list of AORs that may be implicitly registered, and the same authorization checks would = apply to the contact domain. So while multiple AOR registration may not make this usage case = more problematic, using a globally unique user portion (e.g. E.164 number) makes the authoriz= ation check less necessary. [hsk] How is it any less necessary? We were ok with E.164 because the SSP = was as authoritative as could be for that identity - well who's more author= itative for the AoR "sip:bob@ssp.com" than ssp.com?? [hsk] The point of draft-olive is to say: instead of Registering separately= for "bob@ssp.com" and "charlie@ssp.com", use the [draft-gin] bulk registra= tion to do it in one Registration. Those AoR's are both of ssp.com, and it= is wholly authoritative for them. Whatever policy decisions the SSP makes= about the individual Registrations would necessarily be the same that it m= akes for the bulk Registration. Section 3.2.2 For example, if the IP-PBX has multiple SSPs it Registers into, it can't just receive a request to "sip:bob@pbx.enterprise.com", because it won't know if that's to "sip:bob@ssp1.example.net" or "sip:bob@ssp2.example.net", which may be different users. [BA] Presumably, this paragraph is describing the problem created by having multiple SSPs map different Request-URIs (e.g. bob@ssp1.example.net, bob@ssp2.example.net) to the same registered contact (bob@pbx.enterprise.co= m), right? [hsk] yup. While I understand the potential issues raised by this, a question that thi= s (and other examples) raise for me, is the extent to which the issues are un= ique to multiple AOR registration. For example, it's possible to use multiple single AOR registrations to bind multiple AORs to the same contact, causing the same problem. Given that, is this issue really intrinsic to multiple AOR registration? Or is it speaking to the problems created by having a si= ngle contact (created implicitly or explicitly) map to multiple Request-URIs? [hsk] The same issue arises for single AoR Registrations, but it was raised= as an issue for bulk Registrations previously. I believe the concern was = that with single Registrations the Registered Contact URI usually has a use= r portion, and it's often unique per single Registration, so people were th= inking that without a user portion they couldn't make it unique. So I put = this discussion into the draft to point out that (1) it's a property of the= Contact that needs to be unique, not the AoR, and (2) we can still have th= e Contact be unique because the PBX can just put in a unique Contact URI pa= ram per bulk REGISTER. --_000_430FC6BDED356B4C8498F634416644A91A79F3D673mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey Bernard,<= /p>

Comments inline…

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Sunday, April 11, 2010= 4:47 AM
To: martini@ietf.org
Subject: [martini] Questions= about draft-kaplan-martini-with-olive=

 

Section 3.2.1

 

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

 

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

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

"bob@ssp.example.net" to be mapped to a contact of "bob@pbx.example.com".   <= o:p>

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

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

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

 

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

 

[BA] In the case of multiple AOR registrat= ion, presumably the SSP has pre-provisioned a list of AORs

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

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

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

necessary. 

 

[hsk] How is it any less necessary? &n= bsp;We were ok with E.164 because the SSP was as authoritative as could be for tha= t identity – well who’s more authoritative for the AoR “sip:bob@ssp.= com” than ssp.com??

 

[hsk] The point of draft-olive is to s= ay: instead of Registering separately for “bob@ssp.com” and “charlie@= ssp.com”, use the [draft-gin] bulk registration to do it in one Registration.  T= hose AoR’s are both of ssp.com, and it is wholly authoritative for them. &= nbsp;Whatever policy decisions the SSP makes about the individual Registrations would nec= essarily be the same that it makes for the bulk Registration.

 

Section 3.2.2

 

&=
nbsp;  For example, if the IP-PBX has multiple SSPs it Registers<=
/o:p>
  =
 into, it can't just receive a request to
  = "sip:bob@pbx.enterprise.com", because it won't know if that's to= 
  =
 "sip:bob@ssp1.example.net" or "sip:bob@ssp2.example.net&quo=
t;, which may
  =
 be different users.
 <=
/o:p>
[BA] Presuma=
bly, this paragraph is describing the problem created by having =

multiple SSP=
s map different Request-URIs (e.g. bob@ssp1.example.net, =

bob@ssp2.exa=
mple.net) to the same registered contact (bob@pbx.enterprise.com),
right?<=
/o:p>
 
[hsk] yup.
 
While I understand th=
e potential issues raised by this, a question that this <=
/font>
(and other e=
xamples) raise for me, is the extent to which the issues are unique 
to multiple =
AOR registration.  For example, it's possible to use multiple
single AOR r=
egistrations to bind multiple AORs to the same contact, causing<=
/span>
the same pro=
blem.  Given that, is this issue really intrinsic to multiple
AOR registra=
tion?  Or is it speaking to the problems created by having a single
contact (cre=
ated implicitly or explicitly) map to multiple Request-URIs?
 <=
/o:p>
[hsk] The same issue arises for single AoR Registrations, but i=
t was raised as an issue for bulk Registrations previously.  I believe=
 the concern was that with single Registrations the Registered Contact URI =
usually has a user portion, and it’s often unique per single Registra=
tion, so people were thinking that without a user portion they couldn’=
;t make it unique.  So I put this discussion into the draft to point o=
ut that (1) it’s a property of the Contact that needs to be unique, n=
ot the AoR, and (2) we can still have the Contact be unique because the PBX=
 can just put in a unique Contact URI param per bulk REGISTER.
 <=
/o:p>
 <=
/o:p>
--_000_430FC6BDED356B4C8498F634416644A91A79F3D673mail_-- From HKaplan@acmepacket.com Sun Apr 11 10:24:49 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF2F3A6914 for ; Sun, 11 Apr 2010 10:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJXlpEV8KLh9 for ; Sun, 11 Apr 2010 10:24:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E37E83A683A for ; Sun, 11 Apr 2010 10:24:40 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 11 Apr 2010 13:24:35 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 11 Apr 2010 13:24:33 -0400 From: Hadriel Kaplan To: "martini@ietf.org" Date: Sun, 11 Apr 2010 13:24:33 -0400 Thread-Topic: [martini] Questions about draft-kaplan-martini-with-olive Thread-Index: AcrZU3zOLXSlZiJfRMeK/a0ortmPaQAOFdfAAAPeSxA= Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D679@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D673@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D673@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 17:24:49 -0000 BTW, I sent this in HTML format because my email client (made by some big c= ompany near Seattle) can't cleanly convert from HTML to plain text with the= ">" indentation thing if the original email started as HTML, and I got tir= ed of doing it by hand. It does the below instead. -hadriel ________________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Hadriel Kaplan Sent: Sunday, April 11, 2010 11:57 AM To: Bernard Aboba; martini@ietf.org Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive Hey Bernard, Comments inline. ________________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Bernard Aboba Sent: Sunday, April 11, 2010 4:47 AM To: martini@ietf.org Subject: [martini] Questions about draft-kaplan-martini-with-olive Section 3.2.1 =A0=A0 One of the initial benefits cited for only supporting E.164 is that =A0=A0 an E.164 user name is globally unique by itself, and thus changing =A0=A0 the host portion of the Request-URI does not impact the identity of =A0=A0 the intended target of the Request. [BA] Is the issue really the global uniqueness of the AOR or the global uni= queness of the user portion?=A0 =A0Using single AOR registration, it's possible to cause a= Request-URI of=20 "bob@ssp.example.net" to be mapped to a contact of "bob@pbx.example.com". = =A0=A0 To make sure this is ok, it's not enough just to authenticate the REGISTER;= =A0 the=20 SSP also needs to check that the mapping is authorized (e.g. the PBX=20 sending the registration really is authorized to utilize pbx.example.com as= a contact domain). =A0 [hsk] As far as I know, there is no authorization checking for single Regis= trations which does not also occur in, or apply to, [draft-gin] bulk Regist= rations. [BA] In the case of multiple AOR registration, presumably the SSP has pre-p= rovisioned a list of AORs=20 that may be implicitly registered, and the same authorization checks would = apply to the contact=20 domain.=A0 =A0=A0So while multiple AOR registration may not make this usage= case more problematic, using a globally unique user portion (e.g. E.164 number) makes the authoriz= ation check less necessary.=A0=20 [hsk] How is it any less necessary? =A0We were ok with E.164 because the SS= P was as authoritative as could be for that identity - well who's more auth= oritative for the AoR "sip:bob@ssp.com" than ssp.com?? [hsk] The point of draft-olive is to say: instead of Registering separately= for "bob@ssp.com" and "charlie@ssp.com", use the [draft-gin] bulk registra= tion to do it in one Registration.=A0 Those AoR's are both of ssp.com, and = it is wholly authoritative for them. =A0Whatever policy decisions the SSP m= akes about the individual Registrations would necessarily be the same that = it makes for the bulk Registration. Section 3.2.2 =A0=A0 For example, if the IP-PBX has multiple SSPs it Registers =A0=A0 into, it can't just receive a request to =A0=A0 "sip:bob@pbx.enterprise.com", because it won't know if that's to =A0=A0 "sip:bob@ssp1.example.net" or "sip:bob@ssp2.example.net", which may =A0=A0 be different users. [BA] Presumably, this paragraph is describing the problem created by having= =20 multiple SSPs map different Request-URIs (e.g. bob@ssp1.example.net,=20 bob@ssp2.example.net) to the same registered contact (bob@pbx.enterprise.co= m), right? [hsk] yup. While I understand the potential issues raised by this, a question that thi= s=20 (and other examples) raise for me, is the extent to which the issues are un= ique=20 to multiple AOR registration.=A0 For example, it's possible to use multiple single AOR registrations to bind multiple AORs to the same contact, causing the same problem.=A0 Given that, is this issue really intrinsic to multiple AOR registration?=A0 Or is it speaking to the problems created by having a = single contact (created implicitly or explicitly) map to multiple Request-URIs? [hsk] The same issue arises for single AoR Registrations, but it was raised= as an issue for bulk Registrations previously.=A0 I believe the concern wa= s that with single Registrations the Registered Contact URI usually has a u= ser portion, and it's often unique per single Registration, so people were = thinking that without a user portion they couldn't make it unique.=A0 So I = put this discussion into the draft to point out that (1) it's a property of= the Contact that needs to be unique, not the AoR, and (2) we can still hav= e the Contact be unique because the PBX can just put in a unique Contact UR= I param per bulk REGISTER. From jan.van.geel@belgacom.be Mon Apr 12 00:55:39 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2555F3A6972 for ; Mon, 12 Apr 2010 00:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyIYYBowZGR7 for ; Mon, 12 Apr 2010 00:55:38 -0700 (PDT) Received: from mx23.belgacom.be (mx23.belgacom.be [213.181.45.233]) by core3.amsl.com (Postfix) with ESMTP id 134903A69F0 for ; Mon, 12 Apr 2010 00:55:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,189,1270418400"; d="scan'208";a="280328" Received: from unknown (HELO A03005.BGC.NET) ([10.120.129.161]) by mx23.belgacom.be with ESMTP; 12 Apr 2010 09:55:22 +0200 X-TM-IMSS-Message-ID: <02edab29000054fa@belgacom.be> Received: from AE7111.BGC.NET ([45.219.2.50]) by belgacom.be ([10.120.129.161]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 02edab29000054fa ; Mon, 12 Apr 2010 09:54:49 +0200 Received: from CMS03.BGC.NET ([10.120.128.133]) by AE7111.BGC.NET ([45.219.2.50]) with mapi; Mon, 12 Apr 2010 09:54:49 +0200 From: To: , , Date: Mon, 12 Apr 2010 09:54:48 +0200 Thread-Topic: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) Thread-Index: AcrXYY6Q8/kwonW+QjiWHoB+QP6FHgCs6TCQ Message-ID: <208EAE1DFA28FC419529619ABB8622441617EF2A1A@CMS03.BGC.NET> References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail><430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail><4BBE380C.7080900@cisco.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB x-tm-as-product-ver: SMEX-8.0.0.1285-6.000.1038-17314.005 x-tm-as-result: No--45.890200-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: martini@ietf.org, HKaplan@acmepacket.com Subject: Re: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 07:55:39 -0000 Hi, Just=20for=20my=20clarification,=20when=20talking=20about=20what=20a=20ma= rtini=20PBX=20should=20be=20able=20to=20receive,=20which=20headers=20are= =20we=20talking=20about=20? The=20"format"=20to=20be=20received=20might=20be=20different=20in=20Reque= st-URI=20and=20FROM=20header=20for=20example. Kind=20regards Jan=20Van=20Geel=20 IT=20and=20Network=20Development=20Specialist=20 Belgacom=20SDE/SDV/PSE/NST/NCP=20 Tel:=20+32=202=20202=201035=20 Tel:=20+32=202=20207=209032=20 Email=20:=20jan.van.geel@belgacom.be=20 www.cyberwezz.tk=20 -----Original=20Message----- From:=20martini-bounces@ietf.org=20[mailto:martini-bounces@ietf.org]=20On= =20Behalf=20Of=20Spencer=20Dawkins Sent:=2008=20April=202010=2023:22 To:=20Hans=20Erik=20van=20Elburg;=20Elwell,=20John Cc:=20Hadriel=20Kaplan;=20martini@ietf.org Subject:=20Re:=20[martini]=20number=20normalization=20(was=20Re:=20Changi= ng=20the=20domain(was:=20Hitchhiker's=20Guide=20to=20MakingMartini)) Exactly.=20I=20don't=20see=20us=20prohibiting=20a=20PBX=20from=20acceptin= g=20something=20else=20:-)=20 but=20we=20do=20need=20a=20minimum=20requirement. Spencer -----=20Original=20Message=20-----=20 From:=20Hans=20Erik=20van=20Elburg To:=20Elwell,=20John Cc:=20martini@ietf.org=20;=20Hadriel=20Kaplan Sent:=20Thursday,=20April=2008,=202010=203:38=20PM Subject:=20Re:=20[martini]=20number=20normalization=20(was=20Re:=20Changi= ng=20the=20 domain(was:=20Hitchhiker's=20Guide=20to=20MakingMartini)) Being=20liberal=20is=20good=20in=20theory.=20But=20I=20still=20think=20it= =20would=20be=20beneficial=20if=20 we=20specify=20what=20a=20PBX=20is=20minimally=20required=20to=20handle,= =20so=20that=20an=20SSP=20can=20 trust=20that=20if=20it=20uses=20that=20format=20all=20connected=20martini= =20pbx's=20can=20and=20will=20 handle=20it=20as=20intended. /Hans=20Erik=20van=20Elburg On=20Thu,=20Apr=208,=202010=20at=2010:18=20PM,=20Elwell,=20John=20 =20wrote: [JRE]=20I=20was=20really=20talking=20about=20what=20the=20SIP-PBX=20is=20= able=20to=20receive.=20It=20 clearly=20would=20have=20to=20receive=20a=20canonical=20E.164=20number=20= from=20the=20SSP,=20but=20can=20 of=20course=20be=20more=20liberal. _______________________________________________ martini=20mailing=20list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini=20 _______________________________________________ martini=20mailing=20list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini ****=20DISCLAIMER=20**** http://www.belgacom.be/maildisclaimer From ietf.hanserik@gmail.com Mon Apr 12 01:18:53 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3469128C0EF for ; Mon, 12 Apr 2010 01:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mitaPsBOCMjp for ; Mon, 12 Apr 2010 01:18:45 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 9B6E33A6A03 for ; Mon, 12 Apr 2010 01:18:43 -0700 (PDT) Received: by ewy24 with SMTP id 24so914871ewy.13 for ; Mon, 12 Apr 2010 01:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=g3jOrD5/piqmu++CYICv9kr1TDtjIiSWKV+fby/WEaY=; b=ql7j/ua1sHVBjVb1Q5DeVo3i1oni7hj2w5nY4d/+eHmDDOMfG6RDogaOOv5aOmOOdv QhmXVTqLrIjiPQ7DQOGuHcUFd8DW4un6iK/viAshxox2LU8tN08Qvij/Qiwukb+4IY8i 5HIN0/HfYNwoLUEbRkLMXdUihvua3N6zAcX7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Pi5ehKNcOV0SpRTwGMuOpOgRYTuqtUOsps4Ft+II8PTHEqRqn59IUxtai8SHUIa1Oi hIQtaweKJ7CNHlw27WepAw6koMIW8gqr2mXk+VwADTkXMKp1Ei2cAui43flohlyJhpEW 6U8CGIrx5DeKqMi063gWmzwNumu8lvdTMnAiE= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Mon, 12 Apr 2010 01:18:34 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D639@mail> References: <38C8E0333CD84FDB908C277D09F0F4E1@china.huawei.com> <551B2F8F28374DC3A791737B7A516BE0@china.huawei.com> <4BBF47AF.3070303@nostrum.com> <4BBF57C5.3060400@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D639@mail> Date: Mon, 12 Apr 2010 10:18:34 +0200 Received: by 10.213.55.211 with SMTP id v19mr1855260ebg.86.1271060314755; Mon, 12 Apr 2010 01:18:34 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=00163600cdd18c920b048405caf7 Cc: "martini@ietf.org" Subject: Re: [martini] Question on gin and variable number lengths X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 08:18:53 -0000 --00163600cdd18c920b048405caf7 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 10, 2010 at 4:14 PM, Hadriel Kaplan wrote: > > It also raises a corner-case issue: imagine if the SSP allocates a variable > length number of prefix 12345, but also does know and handle the specific > AoR number 12345678. This can happen in a private numbering plan for > example, where the SSP may have centrex service for some specific numbers in > a block, but the rest of the block is handled by the PBX at the Enterprise. > So we'd have to handle that somehow, and handle it in a way that lets the > specific number 12345678 be registered from multiple contacts, including > possibly the PBX itself. > > It is not totally clear where you see the problem, but if it is the matching bit then specifying that the best match wins will resolve this. In the sense that 12345 matches better with the record with name 12345 then with the record with wildcarded id 12345*. /Hans Erik van Elburg --00163600cdd18c920b048405caf7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 10, 2010 at 4:14 PM, Hadriel Kaplan = <HKaplan@acm= epacket.com> wrote:

It also raises a corner-case issue: imagine if the SSP allocates a variable= length number of prefix 12345, but also does know and handle the specific = AoR number 12345678. =A0This can happen in a private numbering plan for exa= mple, where the SSP may have centrex service for some specific numbers in a= block, but the rest of the block is handled by the PBX at the Enterprise. = =A0So we'd have to handle that somehow, and handle it in a way that let= s the specific number 12345678 be registered from multiple contacts, includ= ing possibly the PBX itself.

It is not totally clea= r where you see the problem, but if it is the matching bit then specifying = that the best match wins will resolve this. In the sense that 12345 matches= better with the record with name 12345 then with the record with wildcarde= d id 12345*.

/Hans Erik van Elburg
--00163600cdd18c920b048405caf7-- From ietf.hanserik@gmail.com Mon Apr 12 02:38:10 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A383A68A5 for ; Mon, 12 Apr 2010 02:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8q-G1TaNMYW for ; Mon, 12 Apr 2010 02:38:08 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 4A3923A6407 for ; Mon, 12 Apr 2010 02:38:07 -0700 (PDT) Received: by ewy24 with SMTP id 24so941027ewy.13 for ; Mon, 12 Apr 2010 02:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=VcIvr7andIM9TZBEdtLKsqKWlhAztAZejJv5nWUQcRM=; b=Ko9VhHX3YvUif4eSFGbQvfE0JXlVdKVHXvNWqKF/hbhHIcYdMBUfrQoP9UUV2yEQGn Ce+fkeTjzvb2mWua4M/klYrPcdkj5IruN0onwVNQMWGihzDyJh7c3kMIW3QrfPCwyUf3 xJAUOLzYTlV+c8WHSMZzfH+N1Qo1nwnLIOkWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QFnSNrfFhQ2+XwN3BqOdeSzjo8K6xaeNaiIxXaqVXyWcyzdakvWBDhV1RqVJYiPmXN FXZHcYKKV7UV6pv0p+ITTENJmvtElVM5X3c6y4hwx+Wgxt6/zS7el/pi2nQElFZrc9fD RxTMoX2Kkuz3ikzn1HqpQPlLf3d25FRuwV+PE= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Mon, 12 Apr 2010 02:37:59 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D643@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> <4BBE69A0.9010606@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D3DB@mail> <4BBF27F8.2090704@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D643@mail> Date: Mon, 12 Apr 2010 11:37:59 +0200 Received: by 10.213.90.139 with SMTP id i11mr2162454ebm.95.1271065079382; Mon, 12 Apr 2010 02:37:59 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=00c09f7f9e5f8b048c048406e686 Cc: "martini@ietf.org" Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 09:38:10 -0000 --00c09f7f9e5f8b048c048406e686 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 10, 2010 at 6:02 PM, Hadriel Kaplan wrote: > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Friday, April 09, 2010 9:13 AM > > > In my simple caveman brain, draft-gin is effectively just a bulk > registration mechanism, as if the PBX had really registered for each AoR > separately. So what AoR would the PBX register to for the local-number > "12345;ext=678;phone-context=ssp.com"? > > I *think* the actual answer is it would have registered for "sip: > 12345;ext=678;phone-context=ssp.com@ssp.com". If that's true, draft-olive > is currently wrong. It should set the contact to "sip: > 12345;ext=678;phone-context=ssp.com@pbx.com". > > Is it me being a Neanderthaler, or is this just a strange example? The more natural case would be where "12345;ext=678;phone-context= martini-enterprise.com" is passed unmodified to the pbx handling this number and which belongs to martini-enterprise. /Hans Erik --00c09f7f9e5f8b048c048406e686 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 10, 2010 at 6:02 P= M, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzi= vat@cisco.com]
> Sent: Friday, April 09, 2010 9:13 AM
>
In my simple caveman brain, draft-gin is effectively just a bulk regi= stration mechanism, as if the PBX had really registered for each AoR separa= tely. =A0So what AoR would the PBX register to for the local-number "1= 2345;ext=3D678;phone-context=3Dssp.com"?

I *think* the actual answer is it would have registered for "sip: 1234= 5;ext=3D678;phone-context=3Dss= p.com@ssp.com". = =A0If that's true, draft-olive is currently wrong. =A0It should set the= contact to "sip: 12345;ext=3D678;phone-context=3Dssp.com@pbx.com".

Is it me being a Neand= erthaler, or is this just a strange example?

The more natural case w= ould be where "12345;ext=3D678;phone-context=3Dmartini-enterprise.com" is passed unmodified to= the pbx handling this number and which belongs to martini-enterprise.

/Hans Erik
--00c09f7f9e5f8b048c048406e686-- From john.elwell@siemens-enterprise.com Mon Apr 12 02:55:28 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F5B03A6977 for ; Mon, 12 Apr 2010 02:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxkr0QAzDwTi for ; Mon, 12 Apr 2010 02:55:27 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id B11613A62C1 for ; Mon, 12 Apr 2010 02:55:26 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1514625; Mon, 12 Apr 2010 11:55:18 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 3E5D71EB82AB; Mon, 12 Apr 2010 11:55:18 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 12 Apr 2010 11:55:18 +0200 From: "Elwell, John" To: "jan.van.geel@belgacom.be" , "spencer@wonderhamster.org" , "ietf.hanserik@gmail.com" Date: Mon, 12 Apr 2010 11:55:17 +0200 Thread-Topic: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) Thread-Index: AcrXYY6Q8/kwonW+QjiWHoB+QP6FHgCs6TCQAAQ893A= Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail><430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail><4BBE380C.7080900@cisco.com> <208EAE1DFA28FC419529619ABB8622441617EF2A1A@CMS03.BGC.NET> In-Reply-To: <208EAE1DFA28FC419529619ABB8622441617EF2A1A@CMS03.BGC.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" , "HKaplan@acmepacket.com" Subject: Re: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 09:55:28 -0000 Jan, I think we are only talking about the Request-URI here. John=20 > -----Original Message----- > From: jan.van.geel@belgacom.be [mailto:jan.van.geel@belgacom.be]=20 > Sent: 12 April 2010 08:55 > To: spencer@wonderhamster.org; ietf.hanserik@gmail.com; Elwell, John > Cc: HKaplan@acmepacket.com; martini@ietf.org > Subject: RE: [martini] number normalization (was Re: Changing=20 > the domain(was: Hitchhiker's Guide to MakingMartini)) >=20 > Hi, >=20 > Just for my clarification, when talking about what a martini=20 > PBX should be able to receive, which headers are we talking about ? > The "format" to be received might be different in Request-URI=20 > and FROM header for example. >=20 > Kind regards >=20 >=20 > Jan Van Geel=20 > IT and Network Development Specialist=20 > Belgacom SDE/SDV/PSE/NST/NCP=20 > Tel: +32 2 202 1035=20 > Tel: +32 2 207 9032=20 > Email : jan.van.geel@belgacom.be=20 > www.cyberwezz.tk=20 >=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > Sent: 08 April 2010 23:22 > To: Hans Erik van Elburg; Elwell, John > Cc: Hadriel Kaplan; martini@ietf.org > Subject: Re: [martini] number normalization (was Re: Changing=20 > the domain(was: Hitchhiker's Guide to MakingMartini)) >=20 > Exactly. I don't see us prohibiting a PBX from accepting=20 > something else :-)=20 > but we do need a minimum requirement. >=20 > Spencer >=20 > ----- Original Message -----=20 > From: Hans Erik van Elburg > To: Elwell, John > Cc: martini@ietf.org ; Hadriel Kaplan > Sent: Thursday, April 08, 2010 3:38 PM > Subject: Re: [martini] number normalization (was Re: Changing the=20 > domain(was: Hitchhiker's Guide to MakingMartini)) >=20 >=20 > Being liberal is good in theory. But I still think it would=20 > be beneficial if=20 > we specify what a PBX is minimally required to handle, so=20 > that an SSP can=20 > trust that if it uses that format all connected martini pbx's=20 > can and will=20 > handle it as intended. >=20 > /Hans Erik van Elburg >=20 >=20 >=20 > On Thu, Apr 8, 2010 at 10:18 PM, Elwell, John=20 > wrote: >=20 > [JRE] I was really talking about what the SIP-PBX is able to=20 > receive. It=20 > clearly would have to receive a canonical E.164 number from=20 > the SSP, but can=20 > of course be more liberal. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 > **** DISCLAIMER **** > http://www.belgacom.be/maildisclaimer > = From keith.drage@alcatel-lucent.com Mon Apr 12 03:20:45 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8ED3A67B3 for ; Mon, 12 Apr 2010 03:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.233 X-Spam-Level: X-Spam-Status: No, score=-5.233 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MP6UpFpegei4 for ; Mon, 12 Apr 2010 03:20:39 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id B659A3A62C1 for ; Mon, 12 Apr 2010 03:20:37 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o3CADsN6013385 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Apr 2010 12:20:25 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 12 Apr 2010 12:20:05 +0200 From: "DRAGE, Keith (Keith)" To: Hadriel Kaplan , Hans Erik van Elburg Date: Mon, 12 Apr 2010 12:20:04 +0200 Thread-Topic: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) Thread-Index: AcrXOi5+h5lxbIBbT2Swc+1UsvAllwAAYOFAALtpUWA= Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> <430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "martini@ietf.org" Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 10:20:45 -0000 I think this thread is heading here into over specification. > +12125551212 > +1(212)555-1212 > +1(212)5551212 > Etc. All the examples given by Hadriel are syntactically valid forms of RFC 3966= and the PBX should be able to handle them. If we think there are interoper= ability problems with that, then someone should update RFC 3966, rather tha= n fiddle with it in Martini.=20 However I suspect there is no interoperability problem except a tendency to= sloppy implementation. We might just as well specify that abbreviated form= s of header field names should not be used, as they are a second way of spe= cifying the same thing. regards Keith > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: Thursday, April 08, 2010 6:02 PM > To: Hans Erik van Elburg > Cc: martini@ietf.org > Subject: Re: [martini] number normalization (was Re: Changing=20 > the domain (was: Hitchhiker's Guide to MakingMartini)) >=20 >=20 > What I expect and what I see in the field are two different things. :) >=20 > What I see in the field is that IP-PBX's often do not=20 > understand RFC3966 very well at all. I would assume,=20 > however, that if we say "E.164 format" in whatever spec, that=20 > they would do E.164 format. >=20 > Unfortunately, RFC3966 allows all of the following E.164 user formats: > +12125551212 > +1(212)555-1212 > +1(212)5551212 > Etc. >=20 > And we actually see those, in the field, and they cause=20 > interop issues, in the field. (it was frankly a mistake for=20 > RFC3966 to do this, imo, but that's another topic for another day) >=20 > But more importantly, what the Reg-proxy actually *gets* is=20 > also often not E.164 to begin with. It processes received=20 > target URIs as E.164 based on local policy=20 > transformation/translation rules, and logically converts them=20 > to E.164 internally, if not also externally. That's all=20 > fine/legal/etc. To be useful to an IP-PBX which expects=20 > E.164, that internal transform has to actually change the=20 > user name in the request-URI itself. Thus *in practice*, the=20 > reg-proxy often will be changing the request-uri based on=20 > local policy rules *anyway*. Ergo, the user name and domain=20 > name are both changing. >=20 > -hadriel >=20 > ________________________________________ > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Thursday, April 08, 2010 12:40 PM > To: Hadriel Kaplan > Cc: Brian Lindsay; martini@ietf.org > Subject: Re: number normalization (was Re: [martini] Changing=20 > the domain (was: Hitchhiker's Guide to MakingMartini)) >=20 > If I find a SIP URI that contains a E.164 number i.e.=20 > +3124764@example.com;user=3Dphone there is no need to normalize. >=20 > Do you mean that you also want to be able to handle=20 > 24764;phone-context=3D+31@example.com;user=3Dphone and normalise=20 > that to the previous form? >=20 > Or are you thinking: > - about local numbers? > - about alphanumeric SIP uri's that are to be interpreted as=20 > numbers, as they are lacking the user=3Dphone parameter. >=20 > I would expect martini compliant PBX's to understand SIP=20 > numbers URI's in the sense of 3261/3966, i.e. with user=3Dphone=20 > and to be 3966 compliant i.e: > - to start with a + for international number format > - to contain a phone-context for local numbers, without a starting + >=20 > So martini compliant pbx should not show the same diversity=20 > in what it accepts as being a number as that what is=20 > currently in the field. >=20 > /Hans Erik van Elburg >=20 > On Thu, Apr 8, 2010 at 5:48 PM, Hadriel Kaplan=20 > wrote: >=20 > The resolving SSP proxy - i.e., the one that does the=20 > location-service lookup using the normalized form as the key. > (in IMS language, the S-CSCF) >=20 > Today I know SBC's do it (a LOT), and I assume other devices=20 > do it as well. =A0If the S-CSCF/Reg-proxy doesn't do it we'd be=20 > happy to do it for them. :) But really it should be done there, imho. >=20 > -hadriel >=20 > ________________________________________ > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Thursday, April 08, 2010 10:55 AM >=20 > Which entity would be responsible for that in your view? >=20 > /Hans Erik van Elburg > =A0 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From keith.drage@alcatel-lucent.com Mon Apr 12 03:22:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6D13A67B3 for ; Mon, 12 Apr 2010 03:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.563 X-Spam-Level: X-Spam-Status: No, score=-5.563 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFvtes2CdXKl for ; Mon, 12 Apr 2010 03:22:26 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id AD34A3A698E for ; Mon, 12 Apr 2010 03:21:58 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o3CAAkgY011475 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Apr 2010 12:21:48 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 12 Apr 2010 12:21:30 +0200 From: "DRAGE, Keith (Keith)" To: "Elwell, John" , Hadriel Kaplan , "martini@ietf.org" Date: Mon, 12 Apr 2010 12:21:29 +0200 Thread-Topic: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 Thread-Index: AcrXRahoZd4ezAUpQc6dHIV46fji5AAgzRcQAAQbQ4A= Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 10:22:30 -0000 We need to be careful here that we are not running before we can walk. Yes I want to handle different numbers, more specifically private network n= umbers, but we do need to understand how they will be used in the SSP befor= e we start writing protocol requirements. The ETSI/3GPP model for this work was that the SSP could undertake to provi= de various logical entities within it's own equipment to support the enterp= rise. So where Centrex is provided (or hosted enterprise services in the ET= SI terminology) essentially a logical PBX is hosted by the SSP. Nominally t= he enterprise is responsible for this logical entity, and the SSP manages i= t on behalf of the enteprise. It is part of the enterprise, and therefore i= t should be able to handle anything a physically provided IP-PBX can handle= , including the numbering / addressing plans of the enterprise. If I want to connect two IP-PBX together in the same enterprise, then I can= the option of establishing a direct IP connection between them, with all t= he QoS and numbering / addressing handling of the enterprise handled provid= ed over this, in the same way as in the PSTN I can buy a tie line, or I can= use the SSP to provide public network services to connect the two, in whic= h case I am tied to the QoS and other capabilities provided by the SSP, inc= luding the numbering and addressing plans supported by the SSP (and which m= ust be globally unique within the SSP). In particular, as an inheritance of what has been done with the use of numb= ers in the past, a separate numbering plan probably exists in the enterpris= e, such that 777 1234 is a valid number within the enterprise, but would of= course be meaningless outside the context of that enteprise. While some di= gits may correspond to an equivalent E.l64 number, e.g. +1 555 999 1234, th= at is not a fixed requirement. So what happens if I want to connect two Centrex installations together. Ye= s I can always use the services of the SSP in which it is resident to conne= ct the two together, in which case we are still tied to the QoS and other c= apabilities provided by the SSP, including the numbering and addressing pla= ns supported by the SSP (and which must be globally unique within the SSP).= Or I can negotiate a deal with the SSP that essentially for signalling pur= poses requires them to simulate what I would get from that direct IP connec= tion (with all the QoS and numbering / addressing handling of the enterpris= e handled provided over this). The ETSI / 3GPP model provides for this, and= the work in: https://datatracker.ietf.org/doc/draft-vanelburg-dispatch-private-network-i= nd/ provides a tag for implementing identifying such traffic, such that it is h= andled according to the rules of the enterprise (which have of course been = agreed with the SSP), rather than the rules of the SSP directly. It is with= in this context that the numbering / addressing plan of the enterprise can = be used. Thus within IMS tel:1234;phone-context=3Denterprise.com can have m= eaning when it appears in a SIP message that contains the header field P-Pr= ivate-Network-Indication:enterprise.com, but would probably not have meanin= g when such a header field is missing. There is no need for this tag where it is known that the traffic is 100% be= longing to the enterprise. So a UA registering with a registrar function wi= thin the Centrex environment, and sending and receiving traffic between the= UA and outbound proxies / registrars within that Centrex environment, do n= ot need this tag. So that deals with two logical PBXs, i.e. Centrex connected. What happens i= f one is Centrex and one is a physically provided IP-PBX. Yes we should sti= ll be able to do the things we have been doing. The PBX needs to "register" its private network numbers in the SSP location= server. In the IMS model, this is performed implicitly, so there are no do= main name issues here. Incoming calls with the P-Private-Network-Indication: enterprise.com can as= sume the numbering / addressing plan of the enterprise, which would normall= y have a phone-context of enterprise.com, or some subdomain of that. So where does this lead in terms of what I would like to do. 1) I am less worried about being able to handle local number forms of E.164= numbers, although it probably drops out automatically from being able to h= andle private network numbers. 2) I do want to handle numbers where phone-context is enterprise.com or som= e subdomain of that. These will only appear in incoming requests with an eq= uivalent P-Private-Network-Indication, and handling such an indication invo= lves more that just applying a special numbering plan (rather a full set of= operational agreements with the enterprise operator). regards Keith =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Friday, April 09, 2010 10:53 AM > To: Hadriel Kaplan; martini@ietf.org > Subject: Re: [martini] Other AoR's than E.164:=20 > draft-kaplan-martini-with-olive-00 >=20 > Hadriel, >=20 > Thanks for writing this up. I like the direction this is=20 > heading, but I am not sure this really addresses the full=20 > population of use cases that we might like to cover at some stage. >=20 > One concern is email-style AORs based on the SSP's domain.=20 > This might work for some enterprises. What it means is a lack=20 > of portability. For example, if I agree with ssp1.example.com=20 > that I can use sip:bob@ssp1.example.com, it is quite likely=20 > that if I try to move to ssp2.example.com, bob will not be=20 > available. I look forward to your planned further draft on=20 > the subject of using the enterprise domain name. >=20 > Another concern is whether non-E.164 numbers based on=20 > phone-context of domain name is sufficiently widespread. In=20 > fact I don't have much knowledge of deployments based on=20 > non-E.164 numbers (excluding things like national numbers,=20 > which can be expanded to fully-qualified E.164 numbers). For=20 > use in the scenarios you describe, do people use domain- or=20 > E.164-based phone-contexts? I note your intention to give=20 > further consideration to E.164-based phone-contexts. >=20 > So basically, I see this as useful material on how gin could=20 > be extended in future to accommodate a broader range of AOR=20 > types. I am not sure that we necessarily need to include=20 > these in the initial gin deliverable, but by being aware of=20 > such future extensions we could at least ensure that we don't=20 > build anything into gin that rules this out. >=20 > John > =20 >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Hadriel Kaplan > > Sent: 08 April 2010 19:03 > > To: martini@ietf.org > > Subject: [martini] Other AoR's than E.164:=20 > > draft-kaplan-martini-with-olive-00 > >=20 > >=20 > > Howdy, > > The discussion about limiting the scope of the current=20 > Martini work to=20 > > E.164's raises an issue that is a bit concerning. We have=20 > now heard=20 > > from several folks that one issue with [draft-gin] is that=20 > it does not=20 > > cover as many use-cases as other mechanisms. Essentially=20 > the question=20 > > is whether our requirements list is correct. > >=20 > > While we had consensus that E.164 formats were our scope,=20 > because we=20 > > mostly see those in daily life, if other mechanisms claim=20 > to support=20 > > more then Martini, we have a problem. Lots of SSP's and=20 > Enterprises=20 > > (the actual > > customers!) do not attend the IETF, and do not have time to=20 > go through=20 > > mailing list archives, or RFCs, etc. They will pay attention to=20 > > whatever powerpoint slides the marketing folks generate, and the=20 > > perception will be that Martini is not as generally useful as=20 > > something else. > >=20 > > It doesn't matter what the technical details are, nor what the Opex=20 > > cost differences will ultimately be. It's a perception problem. > >=20 > > Therefore, if folks are interested, I have submitted an I-D=20 > which is=20 > > part-1 of a two-part draft set to try to address the "other" use=20 > > cases. > >=20 > > Part-1 (draft-olive) linked below is to address any AoR of the=20 > > registered-to SSP's domain. This follows [draft-gin]=20 > pretty tightly. > >=20 > > Any comments/flames/concerns are appreciated. > > If people want this type of thing, then we could put the=20 > olive in the=20 > > gin for a better martini. > >=20 > > -hadriel > >=20 > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > Title : SIP MARTINI with Other Logical=20 > > Identifier Values which are not E.164 (OLIVE) > > Author(s) : H. Kaplan > > Filename : draft-kaplan-martini-with-olive-00.txt > > Pages : 17 > > Date : 2010-04-08 > >=20 > > The Martini Working Group is defining a mechanism for SIP=20 > IP-PBX type=20 > > devices to REGISTER and obtain SIP service for E.164-based=20 > Address of=20 > > Records. This document defines a means for other, non- > > E.164 AoRs to be used with Martini-based IP-PBXs. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-kaplan-martini-with- > > olive-00.txt > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From john.elwell@siemens-enterprise.com Mon Apr 12 04:04:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28143A6944 for ; Mon, 12 Apr 2010 04:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0UjT2kRygwx for ; Mon, 12 Apr 2010 04:04:40 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8B4F83A6783 for ; Mon, 12 Apr 2010 04:04:39 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1515653; Mon, 12 Apr 2010 13:04:33 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 874081EB82AB; Mon, 12 Apr 2010 13:04:33 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 12 Apr 2010 13:04:33 +0200 From: "Elwell, John" To: "DRAGE, Keith (Keith)" , Hadriel Kaplan , "martini@ietf.org" Date: Mon, 12 Apr 2010 13:04:31 +0200 Thread-Topic: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 Thread-Index: AcrXRahoZd4ezAUpQc6dHIV46fji5AAgzRcQAAQbQ4AAlZlaYA== Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 11:04:42 -0000 Agreed we should not try to run before we can walk, and extending gin to co= ver these "private network traffic" situations can wait until later. It is = useful to start the discussion now, however, to help ensure that we leave t= he door open to future extensibility of gin. John=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 > Sent: 12 April 2010 11:21 > To: Elwell, John; Hadriel Kaplan; martini@ietf.org > Subject: RE: [martini] Other AoR's than E.164:=20 > draft-kaplan-martini-with-olive-00 >=20 > We need to be careful here that we are not running before we can walk. >=20 > Yes I want to handle different numbers, more specifically=20 > private network numbers, but we do need to understand how=20 > they will be used in the SSP before we start writing protocol=20 > requirements. >=20 > The ETSI/3GPP model for this work was that the SSP could=20 > undertake to provide various logical entities within it's own=20 > equipment to support the enterprise. So where Centrex is=20 > provided (or hosted enterprise services in the ETSI=20 > terminology) essentially a logical PBX is hosted by the SSP.=20 > Nominally the enterprise is responsible for this logical=20 > entity, and the SSP manages it on behalf of the enteprise. It=20 > is part of the enterprise, and therefore it should be able to=20 > handle anything a physically provided IP-PBX can handle,=20 > including the numbering / addressing plans of the enterprise. >=20 > If I want to connect two IP-PBX together in the same=20 > enterprise, then I can the option of establishing a direct IP=20 > connection between them, with all the QoS and numbering /=20 > addressing handling of the enterprise handled provided over=20 > this, in the same way as in the PSTN I can buy a tie line, or=20 > I can use the SSP to provide public network services to=20 > connect the two, in which case I am tied to the QoS and other=20 > capabilities provided by the SSP, including the numbering and=20 > addressing plans supported by the SSP (and which must be=20 > globally unique within the SSP). >=20 > In particular, as an inheritance of what has been done with=20 > the use of numbers in the past, a separate numbering plan=20 > probably exists in the enterprise, such that 777 1234 is a=20 > valid number within the enterprise, but would of course be=20 > meaningless outside the context of that enteprise. While some=20 > digits may correspond to an equivalent E.l64 number, e.g. +1=20 > 555 999 1234, that is not a fixed requirement. >=20 > So what happens if I want to connect two Centrex=20 > installations together. Yes I can always use the services of=20 > the SSP in which it is resident to connect the two together,=20 > in which case we are still tied to the QoS and other=20 > capabilities provided by the SSP, including the numbering and=20 > addressing plans supported by the SSP (and which must be=20 > globally unique within the SSP). Or I can negotiate a deal=20 > with the SSP that essentially for signalling purposes=20 > requires them to simulate what I would get from that direct=20 > IP connection (with all the QoS and numbering / addressing=20 > handling of the enterprise handled provided over this). The=20 > ETSI / 3GPP model provides for this, and the work in: >=20 > https://datatracker.ietf.org/doc/draft-vanelburg-dispatch-priv > ate-network-ind/ >=20 > provides a tag for implementing identifying such traffic,=20 > such that it is handled according to the rules of the=20 > enterprise (which have of course been agreed with the SSP),=20 > rather than the rules of the SSP directly. It is within this=20 > context that the numbering / addressing plan of the=20 > enterprise can be used. Thus within IMS=20 > tel:1234;phone-context=3Denterprise.com can have meaning when=20 > it appears in a SIP message that contains the header field=20 > P-Private-Network-Indication:enterprise.com, but would=20 > probably not have meaning when such a header field is missing. >=20 > There is no need for this tag where it is known that the=20 > traffic is 100% belonging to the enterprise. So a UA=20 > registering with a registrar function within the Centrex=20 > environment, and sending and receiving traffic between the UA=20 > and outbound proxies / registrars within that Centrex=20 > environment, do not need this tag. >=20 > So that deals with two logical PBXs, i.e. Centrex connected.=20 > What happens if one is Centrex and one is a physically=20 > provided IP-PBX. Yes we should still be able to do the things=20 > we have been doing. >=20 > The PBX needs to "register" its private network numbers in=20 > the SSP location server. In the IMS model, this is performed=20 > implicitly, so there are no domain name issues here. >=20 > Incoming calls with the P-Private-Network-Indication:=20 > enterprise.com can assume the numbering / addressing plan of=20 > the enterprise, which would normally have a phone-context of=20 > enterprise.com, or some subdomain of that. >=20 >=20 > So where does this lead in terms of what I would like to do. >=20 > 1) I am less worried about being able to handle local=20 > number forms of E.164 numbers, although it probably drops out=20 > automatically from being able to handle private network numbers. >=20 > 2) I do want to handle numbers where phone-context is=20 > enterprise.com or some subdomain of that. These will only=20 > appear in incoming requests with an equivalent=20 > P-Private-Network-Indication, and handling such an indication=20 > involves more that just applying a special numbering plan=20 > (rather a full set of operational agreements with the=20 > enterprise operator). >=20 >=20 > regards >=20 > Keith >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org=20 > > [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Friday, April 09, 2010 10:53 AM > > To: Hadriel Kaplan; martini@ietf.org > > Subject: Re: [martini] Other AoR's than E.164:=20 > > draft-kaplan-martini-with-olive-00 > >=20 > > Hadriel, > >=20 > > Thanks for writing this up. I like the direction this is=20 > > heading, but I am not sure this really addresses the full=20 > > population of use cases that we might like to cover at some stage. > >=20 > > One concern is email-style AORs based on the SSP's domain.=20 > > This might work for some enterprises. What it means is a lack=20 > > of portability. For example, if I agree with ssp1.example.com=20 > > that I can use sip:bob@ssp1.example.com, it is quite likely=20 > > that if I try to move to ssp2.example.com, bob will not be=20 > > available. I look forward to your planned further draft on=20 > > the subject of using the enterprise domain name. > >=20 > > Another concern is whether non-E.164 numbers based on=20 > > phone-context of domain name is sufficiently widespread. In=20 > > fact I don't have much knowledge of deployments based on=20 > > non-E.164 numbers (excluding things like national numbers,=20 > > which can be expanded to fully-qualified E.164 numbers). For=20 > > use in the scenarios you describe, do people use domain- or=20 > > E.164-based phone-contexts? I note your intention to give=20 > > further consideration to E.164-based phone-contexts. > >=20 > > So basically, I see this as useful material on how gin could=20 > > be extended in future to accommodate a broader range of AOR=20 > > types. I am not sure that we necessarily need to include=20 > > these in the initial gin deliverable, but by being aware of=20 > > such future extensions we could at least ensure that we don't=20 > > build anything into gin that rules this out. > >=20 > > John > > =20 > >=20 > > > -----Original Message----- > > > From: martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] On Behalf Of Hadriel Kaplan > > > Sent: 08 April 2010 19:03 > > > To: martini@ietf.org > > > Subject: [martini] Other AoR's than E.164:=20 > > > draft-kaplan-martini-with-olive-00 > > >=20 > > >=20 > > > Howdy, > > > The discussion about limiting the scope of the current=20 > > Martini work to=20 > > > E.164's raises an issue that is a bit concerning. We have=20 > > now heard=20 > > > from several folks that one issue with [draft-gin] is that=20 > > it does not=20 > > > cover as many use-cases as other mechanisms. Essentially=20 > > the question=20 > > > is whether our requirements list is correct. > > >=20 > > > While we had consensus that E.164 formats were our scope,=20 > > because we=20 > > > mostly see those in daily life, if other mechanisms claim=20 > > to support=20 > > > more then Martini, we have a problem. Lots of SSP's and=20 > > Enterprises=20 > > > (the actual > > > customers!) do not attend the IETF, and do not have time to=20 > > go through=20 > > > mailing list archives, or RFCs, etc. They will pay attention to=20 > > > whatever powerpoint slides the marketing folks generate, and the=20 > > > perception will be that Martini is not as generally useful as=20 > > > something else. > > >=20 > > > It doesn't matter what the technical details are, nor=20 > what the Opex=20 > > > cost differences will ultimately be. It's a perception problem. > > >=20 > > > Therefore, if folks are interested, I have submitted an I-D=20 > > which is=20 > > > part-1 of a two-part draft set to try to address the "other" use=20 > > > cases. > > >=20 > > > Part-1 (draft-olive) linked below is to address any AoR of the=20 > > > registered-to SSP's domain. This follows [draft-gin]=20 > > pretty tightly. > > >=20 > > > Any comments/flames/concerns are appreciated. > > > If people want this type of thing, then we could put the=20 > > olive in the=20 > > > gin for a better martini. > > >=20 > > > -hadriel > > >=20 > > >=20 > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > > > directories. > > > Title : SIP MARTINI with Other Logical=20 > > > Identifier Values which are not E.164 (OLIVE) > > > Author(s) : H. Kaplan > > > Filename : draft-kaplan-martini-with-olive-00.txt > > > Pages : 17 > > > Date : 2010-04-08 > > >=20 > > > The Martini Working Group is defining a mechanism for SIP=20 > > IP-PBX type=20 > > > devices to REGISTER and obtain SIP service for E.164-based=20 > > Address of=20 > > > Records. This document defines a means for other, non- > > > E.164 AoRs to be used with Martini-based IP-PBXs. > > >=20 > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-kaplan-martini-with- > > > olive-00.txt > > >=20 > > > _______________________________________________ > > > martini mailing list > > > martini@ietf.org > > > https://www.ietf.org/mailman/listinfo/martini > > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > = From pkyzivat@cisco.com Mon Apr 12 06:06:39 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A08393A6903 for ; Mon, 12 Apr 2010 06:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.415 X-Spam-Level: X-Spam-Status: No, score=-10.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz52UHHEKwCH for ; Mon, 12 Apr 2010 06:06:38 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4570B3A68D7 for ; Mon, 12 Apr 2010 06:06:34 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB+3wktAZnwM/2dsb2JhbACbMnGhVJhEhQwE X-IronPort-AV: E=Sophos;i="4.52,190,1270425600"; d="scan'208";a="100982441" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 12 Apr 2010 13:06:29 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3CD6Smf027272; Mon, 12 Apr 2010 13:06:28 GMT Message-ID: <4BC31AD4.4060004@cisco.com> Date: Mon, 12 Apr 2010 09:06:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <38C8E0333CD84FDB908C277D09F0F4E1@china.huawei.com> <551B2F8F28374DC3A791737B7A516BE0@china.huawei.com> <4BBF47AF.3070303@nostrum.com> <4BBF57C5.3060400@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D639@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D639@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] Question on gin and variable number lengths X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 13:06:39 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Friday, April 09, 2010 12:37 PM >> >> There is already provision for extension elements, so this would be >> backward compatible. > > Yeah I don't see a _general_ issue with backwards-compatibility - an rfc3680 UA subscribing and getting an unknown namespace extension XML element is supposed to ignore it. But see below for what I think is the specific issue. > > >> To make this work it would only be necessary to specify how the basic >> syntax of the contact would be denoted. I think we could simply use the >> uri without user part for this. > > Just to be clear, it's not a contact URI we're talking about, right? This is a variable-length AoR. So the rub is: can you use a "registration" XML element for it, in a backwards-compatible way? Duh, that's true. It can still be done compatibly with the existing schema, but using a different extensibility hook. The top level contains a sequence of followed by an optional sequence of other stuff. To do this entirely cleanly we might have to define a new variant on where the aor= is replaced by something else that allows for wildcards or ranges or .... (My knowledge of xml is insufficient to specify in detail the best way to accomplish this.) There is some serious work to do here. Thanks, Paul > It also raises a corner-case issue: imagine if the SSP allocates a variable length number of prefix 12345, but also does know and handle the specific AoR number 12345678. This can happen in a private numbering plan for example, where the SSP may have centrex service for some specific numbers in a block, but the rest of the block is handled by the PBX at the Enterprise. So we'd have to handle that somehow, and handle it in a way that lets the specific number 12345678 be registered from multiple contacts, including possibly the PBX itself. > > -hadriel > From pkyzivat@cisco.com Mon Apr 12 06:29:58 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD7E3A6A41 for ; Mon, 12 Apr 2010 06:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9+U1s90yBNT for ; Mon, 12 Apr 2010 06:29:53 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BE40E3A6A3B for ; Mon, 12 Apr 2010 06:29:52 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPu8wktAZnwM/2dsb2JhbACbMnGiDJhKgmwIghgE X-IronPort-AV: E=Sophos;i="4.52,190,1270425600"; d="scan'208";a="100988304" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 12 Apr 2010 13:29:47 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3CDTluZ003567; Mon, 12 Apr 2010 13:29:47 GMT Message-ID: <4BC3204B.9090508@cisco.com> Date: Mon, 12 Apr 2010 09:29:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hans Erik van Elburg References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> <4BBE69A0.9010606@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D3DB@mail> <4BBF27F8.2090704@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D643@mail> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 13:29:58 -0000 Hans Erik van Elburg wrote: > > On Sat, Apr 10, 2010 at 6:02 PM, Hadriel Kaplan > wrote: > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com > ] > > Sent: Friday, April 09, 2010 9:13 AM > > > In my simple caveman brain, draft-gin is effectively just a bulk > registration mechanism, as if the PBX had really registered for each > AoR separately. So what AoR would the PBX register to for the > local-number "12345;ext=678;phone-context=ssp.com "? > > I *think* the actual answer is it would have registered for "sip: > 12345;ext=678;phone-context=ssp.com @ssp.com > ". If that's true, draft-olive is currently wrong. > It should set the contact to "sip: > 12345;ext=678;phone-context=ssp.com @pbx.com > ". > > Is it me being a Neanderthaler, or is this just a strange example? > > The more natural case would be where > "12345;ext=678;phone-context=martini-enterprise.com > " is passed unmodified to the pbx > handling this number and which belongs to martini-enterprise. I gather you are suggesting that the original registration would have been (implicitly) to aor sip:12345;ext=678;phone-context=martini-enterprise.com@ssp.com That is certainly a possibility. But it raises again the ugly issue of domain name assignments for pbxes, and the notion of responsibility for domains. I don't recall exactly what are the *semantics* of using a domain name in the phone-context. But I think it *ought* to have some notion of responsibility for the domain name. Specifically, if Cisco asked ssp.com to use acmepacket.com as the phone context for its local numbers, and then later on acmepacket got an account with ssp.com, I suspect things would get pretty ugly. So that kind of usage ought not be permitted. So I don't think using pbx-specific domain-name style phone-context will work for pbxes that don't already have domain names. Thanks, Paul From pkyzivat@cisco.com Mon Apr 12 06:38:08 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55FBC3A6A3E for ; Mon, 12 Apr 2010 06:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.423 X-Spam-Level: X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wjp3Pr6vl5JM for ; Mon, 12 Apr 2010 06:38:07 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D8FA23A6A3C for ; Mon, 12 Apr 2010 06:38:06 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFO/wktAZnwM/2dsb2JhbACbMnGiNphLhQwE X-IronPort-AV: E=Sophos;i="4.52,190,1270425600"; d="scan'208";a="100990448" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 12 Apr 2010 13:38:01 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3CDc14s006010; Mon, 12 Apr 2010 13:38:01 GMT Message-ID: <4BC32238.9090503@cisco.com> Date: Mon, 12 Apr 2010 09:38:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> <4BBE69A0.9010606@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D3DB@mail> <4BBF27F8.2090704@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D647@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D647@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] Local-numbers (was Other AoR's than E.164: draft-kaplan-martini-with-olive-00) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 13:38:08 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, April 09, 2010 9:13 AM >> >> Of course for local numbers to be useful, they will have to work in both >> directions. We have been avoiding that discussion, but maybe we need to >> have it. > > There be dragons. :) > One of the problems with local-numbers is the device which actually knows what context it's in is sometimes not the PBX, and sometimes is the PBX. > In practice I know there are times when the ingress proxy of the SSP is the one which does it, but I think that from a spec and architectural model the PBX should be the one which inserts a phone-context. I think I agree with both your solution and your warning about dragons. :-) >> That might also also tie in with how to represent certain non >> E.164 numbers that have to go from the pbx to the ssp, such as service >> numbers. (0, 411, 911, etc.) IMO there are only a couple of rational >> choices for those: user=dialstring or local number syntax. (E.g. >> 911;phone-context=+1) Perhaps that suggests doing something more >> specific about certain local number forms. > > In practice it seems to me that the user=dialstring param isn't used much. If the request-uri is "sip:411@ssp.com", it's handled as a dialed phone number of "411" regardless of a user=dialstring. SSP's just don't allocate "411" as a username to some random SIP subscriber. I would argue that's true for all service numbers, including "911" - you can send a sos URN or a user=dialstring param, but it's not like they're going to give the AoR of "sip:911@ssp.com" to some random subscriber anyway, so it's not ambiguous in practice. There's no real interop problem to solve, afaict. While I understand the practicality of what you say, I would find it difficult to write that down in a standard. So I think it would be useful to have *some* standard, even if many SSPs accept other things as well. But we don't have to solve that as part of *this* effort. > If we *were* to specify a dialstring, then it would need a phone-context anyway (per rfc4967), and in my opinion that phone-context should be "ssp.com", ironically. There I disagree. The phone context in a dialstring needs to correlate directly to the dial plan for the phone that is dialing. Having it be ssp.com would mean that all the pbxes supported by that ssp would have the same dial plan. That obviously wouldn't work. Instead, it again requires coming up with some unique phone-context for the pbx, or maybe even for each dial plan used by the pbx if it might have more than one. Thanks, Paul From spencer@wonderhamster.org Mon Apr 12 06:42:15 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F1603A6A3C for ; Mon, 12 Apr 2010 06:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCCiScFfuGNR for ; Mon, 12 Apr 2010 06:42:08 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 032533A6A3A for ; Mon, 12 Apr 2010 06:42:08 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Mg3NV-1Np2Eg21UT-00NRnJ; Mon, 12 Apr 2010 09:41:48 -0400 Message-ID: <6E4501A3405D42BD8CE60E8244BD09E7@china.huawei.com> From: "Spencer Dawkins" To: References: <430FC6BDED356B4C8498F634416644A91A79F3D673@mail> <430FC6BDED356B4C8498F634416644A91A79F3D679@mail> Date: Mon, 12 Apr 2010 08:41:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+ygnn/IZ1VO5UZoCKZ7pmfpSD35Zq5D6FOF0Y ejrYk480iTyvpZdXTo9nJC0WeaiIN7T8afnbRydx99cFKrsJ/H uEP81nYSvi3NbHm3PGeA2rCMr9fW0/jy4LMzr2PdEw= Subject: [martini] Please don't send HTML to the mailing list X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 13:42:15 -0000 Just to follow along with Hadriel's note below... All of the mail readers I use (Outlook and Outlook Express) allow you to set "send plain text only" for each userid in the address book, so you can (and I do) normally send HTML, but have your mailer do the check and prompt you to convert if you forget to "format as plain text" something that's going to an IETF mailing list. We have a strong preference for plain text in the IETF (when I started attending, some area directors did not accept e-mail that wasn't plaintext), and my own preference (as working group chair) is that it's a lot easier to make sure I'm following a thread if I can easily find the text that's not prefixed, rather than trying to figure out which color is who, where the "[SD]" blocks actually end, etc. Please set martini@ietf.org up for plain text in your address books - it will make losing your valuable comments less likely! Thank you, Spencer, as co-chair ----- Original Message ----- From: "Hadriel Kaplan" To: Sent: Sunday, April 11, 2010 12:24 PM Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive BTW, I sent this in HTML format because my email client (made by some big company near Seattle) can't cleanly convert from HTML to plain text with the ">" indentation thing if the original email started as HTML, and I got tired of doing it by hand. It does the below instead. -hadriel From pkyzivat@cisco.com Mon Apr 12 07:37:20 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1293A68C5 for ; Mon, 12 Apr 2010 07:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.433 X-Spam-Level: X-Spam-Status: No, score=-10.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1cOgvqgKBwj for ; Mon, 12 Apr 2010 07:37:19 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E511828C103 for ; Mon, 12 Apr 2010 07:37:10 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGPNwktAZnwN/2dsb2JhbACbMnGibJhfgnQKgg4E X-IronPort-AV: E=Sophos;i="4.52,190,1270425600"; d="scan'208";a="101008576" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Apr 2010 14:37:04 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3CEb3vY006053; Mon, 12 Apr 2010 14:37:03 GMT Message-ID: <4BC33012.6070302@cisco.com> Date: Mon, 12 Apr 2010 10:37:06 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Spencer Dawkins References: <430FC6BDED356B4C8498F634416644A91A79F3D673@mail> <430FC6BDED356B4C8498F634416644A91A79F3D679@mail> <6E4501A3405D42BD8CE60E8244BD09E7@china.huawei.com> In-Reply-To: <6E4501A3405D42BD8CE60E8244BD09E7@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: martini@ietf.org Subject: Re: [martini] Please don't send HTML to the mailing list X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 14:37:20 -0000 I think I'm the source of the original complaint on this. I use Thunderbird for mail. It can do both HTML and plain text mail and convert between them. I read all the html mail in html format, but have set up to always reply in text format. I don't fully understand what it is that results in some html mail being nicely readable while some other html mail is difficult to follow. In the nice cases there is color coding but also bars in the margin corresponding to the "> " indenting of replies in friendly text mail. But in some other cases there is no indenting, no bars, just color coding and people's initials run into the text. And sometimes not even initials - just the color coding. While I find the text that has initials hard to read after a few replies, I never complain about it because it is a personal preference item and I can live with it. Where I complained was when the only distinction I could see was between black text and blue text (that doesn't look very much different than black to me.) My main concern is that replies be formatted in such a way that its reasonably feasible to figure out who said what in response to what after there have been multiple replies. If that can be achieved with html mail, then fine. But I think I will continue to reply in plaintext until I see a better alternative. Sorry to have been a pain, Paul Spencer Dawkins wrote: > Just to follow along with Hadriel's note below... > > All of the mail readers I use (Outlook and Outlook Express) allow you to > set "send plain text only" for each userid in the address book, so you > can (and I do) normally send HTML, but have your mailer do the check and > prompt you to convert if you forget to "format as plain text" something > that's going to an IETF mailing list. > > We have a strong preference for plain text in the IETF (when I started > attending, some area directors did not accept e-mail that wasn't > plaintext), and my own preference (as working group chair) is that it's > a lot easier to make sure I'm following a thread if I can easily find > the text that's not prefixed, rather than trying to figure out which > color is who, where the "[SD]" blocks actually end, etc. > > Please set martini@ietf.org up for plain text in your address books - it > will make losing your valuable comments less likely! > > Thank you, > > Spencer, as co-chair > > ----- Original Message ----- From: "Hadriel Kaplan" > > To: > Sent: Sunday, April 11, 2010 12:24 PM > Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive > > > > BTW, I sent this in HTML format because my email client (made by some > big company near Seattle) can't cleanly convert from HTML to plain text > with the ">" indentation thing if the original email started as HTML, > and I got tired of doing it by hand. It does the below instead. > > -hadriel > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From pkyzivat@cisco.com Mon Apr 12 07:43:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E553A6A1C for ; Mon, 12 Apr 2010 07:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.437 X-Spam-Level: X-Spam-Status: No, score=-10.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVG9fYRg2ovc for ; Mon, 12 Apr 2010 07:43:23 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AC2A83A699E for ; Mon, 12 Apr 2010 07:43:21 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogSAMvOwktAZnwN/2dsb2JhbACIOgGSeHGid5higleCNQQ X-IronPort-AV: E=Sophos;i="4.52,190,1270425600"; d="scan'208";a="100870509" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Apr 2010 14:43:16 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3CEhFrn007723; Mon, 12 Apr 2010 14:43:16 GMT Message-ID: <4BC33183.6070201@cisco.com> Date: Mon, 12 Apr 2010 10:43:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Elwell, John" References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail><430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail><4BBE380C.7080900@cisco.com> <208EAE1DFA28FC419529619ABB8622441617EF2A1A@CMS03.BGC.NET> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" , "HKaplan@acmepacket.com" Subject: Re: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 14:43:25 -0000 Elwell, John wrote: > Jan, > > I think we are only talking about the Request-URI here. Well, that may be the first order of business. But there are issues with others also. For instance, whatever the callee uses to identify the caller (From or P-Asserted-ID) could also be problematic unless it is normalized by somebody. Thanks, Paul > John > >> -----Original Message----- >> From: jan.van.geel@belgacom.be [mailto:jan.van.geel@belgacom.be] >> Sent: 12 April 2010 08:55 >> To: spencer@wonderhamster.org; ietf.hanserik@gmail.com; Elwell, John >> Cc: HKaplan@acmepacket.com; martini@ietf.org >> Subject: RE: [martini] number normalization (was Re: Changing >> the domain(was: Hitchhiker's Guide to MakingMartini)) >> >> Hi, >> >> Just for my clarification, when talking about what a martini >> PBX should be able to receive, which headers are we talking about ? >> The "format" to be received might be different in Request-URI >> and FROM header for example. >> >> 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 : jan.van.geel@belgacom.be >> www.cyberwezz.tk >> >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins >> Sent: 08 April 2010 23:22 >> To: Hans Erik van Elburg; Elwell, John >> Cc: Hadriel Kaplan; martini@ietf.org >> Subject: Re: [martini] number normalization (was Re: Changing >> the domain(was: Hitchhiker's Guide to MakingMartini)) >> >> Exactly. I don't see us prohibiting a PBX from accepting >> something else :-) >> but we do need a minimum requirement. >> >> Spencer >> >> ----- Original Message ----- >> From: Hans Erik van Elburg >> To: Elwell, John >> Cc: martini@ietf.org ; Hadriel Kaplan >> Sent: Thursday, April 08, 2010 3:38 PM >> Subject: Re: [martini] number normalization (was Re: Changing the >> domain(was: Hitchhiker's Guide to MakingMartini)) >> >> >> Being liberal is good in theory. But I still think it would >> be beneficial if >> we specify what a PBX is minimally required to handle, so >> that an SSP can >> trust that if it uses that format all connected martini pbx's >> can and will >> handle it as intended. >> >> /Hans Erik van Elburg >> >> >> >> On Thu, Apr 8, 2010 at 10:18 PM, Elwell, John >> wrote: >> >> [JRE] I was really talking about what the SIP-PBX is able to >> receive. It >> clearly would have to receive a canonical E.164 number from >> the SSP, but can >> of course be more liberal. >> >> >> >> >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> >> **** DISCLAIMER **** >> http://www.belgacom.be/maildisclaimer >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From adam@nostrum.com Mon Apr 12 07:50:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C373A67FC for ; Mon, 12 Apr 2010 07:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKAb9HshuP1C for ; Mon, 12 Apr 2010 07:50:44 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 103C53A68C3 for ; Mon, 12 Apr 2010 07:50:43 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3CEoTVn078659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Apr 2010 09:50:29 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BC33335.9060000@nostrum.com> Date: Mon, 12 Apr 2010 09:50:29 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Kyzivat References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail><430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail><4BBE380C.7080900@cisco.com> <208EAE1DFA28FC419529619ABB8622441617EF2A1A@CMS03.BGC.NET> <4BC33183.6070201@cisco.com> In-Reply-To: <4BC33183.6070201@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "HKaplan@acmepacket.com" , "martini@ietf.org" Subject: Re: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 14:50:46 -0000 On 4/12/10 9:43 AM, Paul Kyzivat wrote: > > > Elwell, John wrote: >> >> I think we are only talking about the Request-URI here. > > Well, that may be the first order of business. > But there are issues with others also. For instance, whatever the > callee uses to identify the caller (From or P-Asserted-ID) could also > be problematic unless it is normalized by somebody. Maybe, but I don't think that's in MARTINI's scope. But it's a pretty weak "maybe" anyway. Keep in mind that "From" can't be changed after the caller creates it. Any "normalization" would need to take place at the UAC, so we're kind of limited in what we can do here anyway. Also recall that "From" is meaningless as an identifier unless you're also using RFC 4474. There's a well-known and completely different can of worms that arises from the interaction between 4474 and E.164 numbers. And MARTINI is emphatically not the place to address that issue. /a From ietf.hanserik@gmail.com Mon Apr 12 07:54:03 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A765228C10D for ; Mon, 12 Apr 2010 07:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fm6zSiKRvcFd for ; Mon, 12 Apr 2010 07:54:02 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id E2EB228C107 for ; Mon, 12 Apr 2010 07:54:01 -0700 (PDT) Received: by ewy24 with SMTP id 24so1112257ewy.13 for ; Mon, 12 Apr 2010 07:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=i7auP81Nf7uizKw0PXN88nAYb2CUJzL/G4AGIHEKFSY=; b=BcC2NUGPWX7Cp4U2Shcle3bHHkolYbPsID0t3e2D5z6MX/XVYssGKRc1mP9Vbjmdbm ZVA6MfAmK1RQ2NpryrXWGruWdPKxJDnNT/M4Vl5qecxl1u/6aT5k0jAAg0Sh1mdwkXjc RHcH8E9D9qRYkkLLztz2NsAOAzVS/nqb3XaMo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=v+OS0w6vdQjYjCDciWls7vy6vG/KJC01o0EUAZ4HvDnWUBN4F874TeykMbOk/KZI3Y 6rOOyI+xVgLFtPn98n1vNLbTpPzSe4+hJn01iH7nmk5Z5R33pfLzO7WmVE66AZ7MBmjX 3trBZmVNUFRSGcU6RpYJNnLs9l+KY0OgZi/F4= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Mon, 12 Apr 2010 07:53:52 -0700 (PDT) In-Reply-To: <4BC3204B.9090508@cisco.com> References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> <4BBE69A0.9010606@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D3DB@mail> <4BBF27F8.2090704@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D643@mail> <4BC3204B.9090508@cisco.com> Date: Mon, 12 Apr 2010 16:53:52 +0200 Received: by 10.213.52.141 with SMTP id i13mr2488345ebg.62.1271084032845; Mon, 12 Apr 2010 07:53:52 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Paul Kyzivat Content-Type: multipart/alternative; boundary=0014852c4ef041eadc04840b506c Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 14:54:03 -0000 --0014852c4ef041eadc04840b506c Content-Type: text/plain; charset=ISO-8859-1 When that happened the phonecontexts that it wishes to use below that domainname for our_number_plan.company.com is completely under control of that company. This is in fact the internet model. I do not see what is ugly about that, it just makes perfect sense. (for once ;-) This is not a pbx assignement, but just a unique name that identifies the context (i.e. numberplan) within which this local number has meaning. In principle there is no relation with the domain name used for routing and the phone-context, but in practice I expect that the phone context is a subdomain of the companies already registered DNS domain name. Because that is just very practical. /Hans Erik van Elburg On Mon, Apr 12, 2010 at 3:29 PM, Paul Kyzivat wrote: > > > The more natural case would be where "12345;ext=678;phone-context= >> martini-enterprise.com " is passed >> unmodified to the pbx handling this number and which belongs to >> martini-enterprise. >> > > I gather you are suggesting that the original registration would have been > (implicitly) to aor sip:12345;ext=678;phone-context=martini-enterprise.com > @ssp.com > > That is certainly a possibility. But it raises again the ugly issue of > domain name assignments for pbxes, and the notion of responsibility for > domains. > > I don't recall exactly what are the *semantics* of using a domain name in > the phone-context. But I think it *ought* to have some notion of > responsibility for the domain name. Specifically, if Cisco asked ssp.comto use > acmepacket.com as the phone context for its local numbers, and then later > on acmepacket got an account with ssp.com, I suspect things would get > pretty ugly. So that kind of usage ought not be permitted. > > So I don't think using pbx-specific domain-name style phone-context will > work for pbxes that don't already have domain names. > I would believe and hope that any company has a DNS domain name, or at > least is in the possibility of easily obtaining one that it owns. > --0014852c4ef041eadc04840b506c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable When that happened the phonecontexts that it wishes to use below that=20 domainname for our_number_pl= an.company.com is completely under control=20 of that company. This is in fact the internet model. I do not see what=20 is ugly about that, it just makes perfect sense. (for once ;-)

This is not a pbx assignement, but just a unique name that identifies the=20 context (i.e. numberplan) within which this local number has meaning.

In principle there is no relation with the domain name used for routing=20 and the phone-context, but in practice I expect that the phone context=20 is a subdomain of the companies already registered DNS domain name.=20 Because that is just very practical.

/Hans Erik van=20 Elburg


On Mon, Apr 12, 2010 at 3:29 PM, Paul Ky= zivat <pkyzivat@= cisco.com> wrote:


The more natural case would be where "12345;ext=3D678;phone-context=3D= martini-enterpr= ise.com <http://martini-enterprise.com>" is passed unmodified to the pb= x handling this number and which belongs to martini-enterprise.

I gather you are suggesting that the original registration would have been = (implicitly) to aor sip:12345;ext=3D678;phone-context=3Dmartini-enterprise.com@ssp.com

That is certainly a possibility. But it raises again the ugly issue of doma= in name assignments for pbxes, and the notion of responsibility for domains= .

I don't recall exactly what are the *semantics* of using a domain name = in the phone-context. But I think it *ought* to have some notion of respons= ibility for the domain name. Specifically, if Cisco asked ssp.com to use acmepacket.com as the phone context for its loc= al numbers, and then later on acmepacket got an account with ssp.com, I suspect things would get pret= ty ugly. So that kind of usage ought not be permitted.

So I don't think using pbx-specific domain-name style phone-context wil= l work for pbxes that don't already have domain names.
I would believe and hope that any company has a DNS domain name, or at=20 least is in the possibility of easily obtaining one that it owns.
=A0

--0014852c4ef041eadc04840b506c-- From pkyzivat@cisco.com Mon Apr 12 08:10:08 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129B83A6A6F for ; Mon, 12 Apr 2010 08:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.44 X-Spam-Level: X-Spam-Status: No, score=-10.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB+cTXsFTki2 for ; Mon, 12 Apr 2010 08:10:06 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C80BB28C117 for ; Mon, 12 Apr 2010 08:08:40 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKfUwktAZnwM/2dsb2JhbACbNHGiWJhigmwIghgE X-IronPort-AV: E=Sophos;i="4.52,190,1270425600"; d="scan'208";a="100878648" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 12 Apr 2010 15:08:35 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3CF8ZLZ007076; Mon, 12 Apr 2010 15:08:35 GMT Message-ID: <4BC33775.5000504@cisco.com> Date: Mon, 12 Apr 2010 11:08:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hans Erik van Elburg References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> <4BBE69A0.9010606@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D3DB@mail> <4BBF27F8.2090704@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D643@mail> <4BC3204B.9090508@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 15:10:08 -0000 Hans Erik van Elburg wrote: > When that happened the phonecontexts that it wishes to use below that > domainname for our_number_plan.company.com > is completely under control of that > company. This is in fact the internet model. I do not see what is ugly > about that, it just makes perfect sense. (for once ;-) > > This is not a pbx assignement, but just a unique name that identifies > the context (i.e. numberplan) within which this local number has meaning. > > In principle there is no relation with the domain name used for routing > and the phone-context, but in practice I expect that the phone context > is a subdomain of the companies already registered DNS domain name. > Because that is just very practical. 3966 says: > The domain name does not have to resolve to any actual host but MUST > be under the administrative control of the entity managing the local > phone context. That is all fine *if* the company with the pbx actually has a domain name under its administrative control. But IIUC we are considering cases where that may not be true. Thanks, Paul > /Hans Erik van Elburg > > > On Mon, Apr 12, 2010 at 3:29 PM, Paul Kyzivat > wrote: > > > > The more natural case would be where > "12345;ext=678;phone-context=martini-enterprise.com > " > is passed unmodified to the pbx handling this number and which > belongs to martini-enterprise. > > > I gather you are suggesting that the original registration would > have been (implicitly) to aor > sip:12345;ext=678;phone-context=martini-enterprise.com > @ssp.com > > That is certainly a possibility. But it raises again the ugly issue > of domain name assignments for pbxes, and the notion of > responsibility for domains. > > I don't recall exactly what are the *semantics* of using a domain > name in the phone-context. But I think it *ought* to have some > notion of responsibility for the domain name. Specifically, if Cisco > asked ssp.com to use acmepacket.com > as the phone context for its local numbers, > and then later on acmepacket got an account with ssp.com > , I suspect things would get pretty ugly. So that > kind of usage ought not be permitted. > > So I don't think using pbx-specific domain-name style phone-context > will work for pbxes that don't already have domain names. > I would believe and hope that any company has a DNS domain name, or > at least is in the possibility of easily obtaining one that it owns. > > > From pkyzivat@cisco.com Mon Apr 12 08:18:14 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D123A68F3 for ; Mon, 12 Apr 2010 08:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.446 X-Spam-Level: X-Spam-Status: No, score=-10.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ePsuLHhPSGz for ; Mon, 12 Apr 2010 08:18:10 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6FE273A6895 for ; Mon, 12 Apr 2010 08:18:03 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMLWwktAZnwN/2dsb2JhbACbNHGiUZhlgleCNQQ X-IronPort-AV: E=Sophos;i="4.52,191,1270425600"; d="scan'208";a="101021531" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Apr 2010 15:17:58 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3CFHvai020263; Mon, 12 Apr 2010 15:17:57 GMT Message-ID: <4BC339A7.2020008@cisco.com> Date: Mon, 12 Apr 2010 11:17:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail><430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail><4BBE380C.7080900@cisco.com> <208EAE1DFA28FC419529619ABB8622441617EF2A1A@CMS03.BGC.NET> <4BC33183.6070201@cisco.com> <4BC33335.9060000@nostrum.com> In-Reply-To: <4BC33335.9060000@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "HKaplan@acmepacket.com" , "martini@ietf.org" Subject: Re: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 15:18:14 -0000 yeah, ok, I agree its not a martini thing. Thanks, Paul Adam Roach wrote: > On 4/12/10 9:43 AM, Paul Kyzivat wrote: >> >> >> Elwell, John wrote: >>> >>> I think we are only talking about the Request-URI here. >> >> Well, that may be the first order of business. >> But there are issues with others also. For instance, whatever the >> callee uses to identify the caller (From or P-Asserted-ID) could also >> be problematic unless it is normalized by somebody. > > Maybe, but I don't think that's in MARTINI's scope. > > But it's a pretty weak "maybe" anyway. Keep in mind that "From" can't be > changed after the caller creates it. Any "normalization" would need to > take place at the UAC, so we're kind of limited in what we can do here > anyway. > > Also recall that "From" is meaningless as an identifier unless you're > also using RFC 4474. There's a well-known and completely different can > of worms that arises from the interaction between 4474 and E.164 > numbers. And MARTINI is emphatically not the place to address that issue. > > /a > From victor.pascual.avila@gmail.com Mon Apr 12 08:26:13 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97E653A6894 for ; Mon, 12 Apr 2010 08:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqzQ2vwoWYwH for ; Mon, 12 Apr 2010 08:26:12 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id 7FE133A67EB for ; Mon, 12 Apr 2010 08:26:12 -0700 (PDT) Received: by bwz9 with SMTP id 9so4693686bwz.29 for ; Mon, 12 Apr 2010 08:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pjz/L1RGjNlz1GVSRfJvE1VY6XfquFi1fKtszSVVV28=; b=qzJZgGr3Aa9TO3y2T7AI58wJerZfvKSCT2F+uOyW5f/W+ZkxNJYz5RtiSEcOq+uo3l lK+r09RD845F9hcUsVtE7GbS1k/gRTC7piV77A07twLyKzNG/b+XBDqmT54wRe1F/rik /4SuiAwNCI0wuh5GgLkE1OFphk/34eI6b9yYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iYachPSDoQfpiCeo4NR7o0MR0uWV151+ZSla6/VFmS34JgbkYu8PnVwN5Pae9jWOXI L+lgqv+SUbZqAlZpgqpnlDekwszcF5MqJqeWgiZ9Uf9NWd/BO4vI54Nzk50WDlI9JVjD 8BZXS9Rd6MFlhzv1FRoPa9JFgS5xiVijubPQA= MIME-Version: 1.0 Received: by 10.204.66.73 with HTTP; Mon, 12 Apr 2010 08:26:03 -0700 (PDT) In-Reply-To: <4BC33335.9060000@nostrum.com> References: <4BBE380C.7080900@cisco.com> <208EAE1DFA28FC419529619ABB8622441617EF2A1A@CMS03.BGC.NET> <4BC33183.6070201@cisco.com> <4BC33335.9060000@nostrum.com> Date: Mon, 12 Apr 2010 17:26:03 +0200 Received: by 10.204.21.17 with SMTP id h17mr2614539bkb.197.1271085963493; Mon, 12 Apr 2010 08:26:03 -0700 (PDT) Message-ID: From: Victor Pascual Avila To: Adam Roach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "martini@ietf.org" , "HKaplan@acmepacket.com" Subject: Re: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 15:26:13 -0000 On Mon, Apr 12, 2010 at 4:50 PM, Adam Roach wrote: > Also recall that "From" is meaningless as an identifier unless you're als= o > using RFC 4474. There's a well-known and completely different can of worm= s > that arises from the interaction between 4474 and E.164 numbers. And MART= INI > is emphatically not the place to address that issue. +1 Martini is not the place for such a discussion. Cheers, --=20 Victor Pascual =C3=81vila From ietf.hanserik@gmail.com Mon Apr 12 08:33:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD133A6899 for ; Mon, 12 Apr 2010 08:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-9Mvgew1xdh for ; Mon, 12 Apr 2010 08:33:17 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 761873A6894 for ; Mon, 12 Apr 2010 08:33:17 -0700 (PDT) Received: by ewy24 with SMTP id 24so1146040ewy.13 for ; Mon, 12 Apr 2010 08:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=ki3yCvWuZrGIwGu9r63IoivzT3zru4KNw17Op4iH3HA=; b=pBG2DcW0/eVl8SziAAAmQgeJg0d4NJigyuIQDXFG8jaJ35kW91GCaPhylrXWHcA7wO G2NtU0+xn7STMXaH3nDBQcfn8kw/dw8tYwiu9IGuJuZH8WVf9ON5tD41I15OARwFyvB0 HPIMwbQRRjnamLQXUwqY85xcaKMMtLHWU2R3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Gc6COAKWvWT8s6BkvgwWIcQXtdQtIu8foEYNvQvrHSFIj7FupV5M9vvWDnu75JSk5a aynaOLWXC/v222KYHH8ho0xZi+Vz9HZQqNBhtO02ikWZ+/S7dobCIYvgLSwmONawNMTt QqcyqVE5nTfSaphlsw+NpXP99zm1HdAFaRgz4= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Mon, 12 Apr 2010 08:33:09 -0700 (PDT) In-Reply-To: <4BC33775.5000504@cisco.com> References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> <4BBE69A0.9010606@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D3DB@mail> <4BBF27F8.2090704@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D643@mail> <4BC3204B.9090508@cisco.com> <4BC33775.5000504@cisco.com> Date: Mon, 12 Apr 2010 17:33:09 +0200 Received: by 10.213.55.148 with SMTP id u20mr2527098ebg.85.1271086389116; Mon, 12 Apr 2010 08:33:09 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Paul Kyzivat Content-Type: multipart/alternative; boundary=0014853260d8b3bffe04840bdced Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 15:33:18 -0000 --0014853260d8b3bffe04840bdced Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 12, 2010 at 5:08 PM, Paul Kyzivat wrote: > That is all fine *if* the company with the pbx actually has a domain name > under its administrative control. But IIUC we are considering cases where > that may not be true. > > There are several possibilities to tackle those: - The SSP providing the enterprise with the trunking service can give out dedicated subdomains solely for the purpose to serve as a phone context of its domain as a service to its customers. This makes sense as company might not want tto bother about this, they want it to just work. - A specialised company could do this. After all people earn money by selling desert sand. BUT in all honesty any company that is big enough to consider a private numberplan already for sure has webpresence and hence owns a domain name. And if that is not the case, it can obtain such domain name easily. BR, /Hans Erik --0014853260d8b3bffe04840bdced Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 12, 2010 at 5:08 PM, Paul Kyziva= t <pkyzivat@cisc= o.com> wrote:
That is all fine *if* the company with the pbx actually has a domain name u= nder its administrative control. But IIUC we are considering cases where th= at may not be true.

=A0There are several possibil= ities to tackle those:
- The SSP providing the enterprise with the trunk= ing service can give out dedicated subdomains solely for the purpose to ser= ve as a phone context of its domain as a service to its customers. This mak= es sense as company might not want tto bother about this, they want it to j= ust work.
- A specialised company could do this. After all people earn money by selli= ng desert sand.

BUT in all honesty any company that is big enough to= consider a private numberplan already for sure has webpresence and hence o= wns a domain name. And if that is not the case, it can obtain such domain n= ame easily.

BR,
/Hans Erik
--0014853260d8b3bffe04840bdced-- From HKaplan@acmepacket.com Mon Apr 12 09:23:50 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7067E3A67EB for ; Mon, 12 Apr 2010 09:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hojSom6axNBx for ; Mon, 12 Apr 2010 09:23:49 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 551AB28C0FF for ; Mon, 12 Apr 2010 09:17:33 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 12 Apr 2010 12:17:27 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 12 Apr 2010 12:17:27 -0400 From: Hadriel Kaplan To: "jan.van.geel@belgacom.be" , "spencer@wonderhamster.org" , "ietf.hanserik@gmail.com" , "john.elwell@siemens-enterprise.com" Date: Mon, 12 Apr 2010 12:17:15 -0400 Thread-Topic: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) Thread-Index: AcrXYY6Q8/kwonW+QjiWHoB+QP6FHgCs6TCQABFHHqA= Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D7CD@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail><430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail><4BBE380C.7080900@cisco.com> <208EAE1DFA28FC419529619ABB8622441617EF2A1A@CMS03.BGC.NET> In-Reply-To: <208EAE1DFA28FC419529619ABB8622441617EF2A1A@CMS03.BGC.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 16:23:50 -0000 Hi Jan, Just the Request-URI. I know people have problems with From (and To, and P= AI, and Diversion/Hist-Info, etc.) but there's no way to change a From/To i= n a Proxy. I'm just trying to address as much as we can legally address. = And the first order of priority is making sure the IP-PBX at least knows wh= at the target of the request is. :) Maybe what we should do is put in language in the draft to remind folks tha= t the To/From/PAI/etc. can be of various flavors/formats, and hope for the = best? -hadriel > -----Original Message----- > From: jan.van.geel@belgacom.be [mailto:jan.van.geel@belgacom.be] > Sent: Monday, April 12, 2010 3:55 AM >=20 > Just for my clarification, when talking about what a martini PBX should b= e > able to receive, which headers are we talking about ? > The "format" to be received might be different in Request-URI and FROM > header for example. From HKaplan@acmepacket.com Mon Apr 12 09:36:40 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77E9A28B23E for ; Mon, 12 Apr 2010 09:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJabK7ktWZaL for ; Mon, 12 Apr 2010 09:36:39 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BEA2C28C14D for ; Mon, 12 Apr 2010 09:33:51 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 12 Apr 2010 12:33:46 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 12 Apr 2010 12:33:45 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Mon, 12 Apr 2010 12:33:45 -0400 Thread-Topic: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 Thread-Index: AcraI9nJvk6UBtHYTyCiko5iN+AmvAAOLL3Q Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D7D9@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> <4BBE69A0.9010606@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D3DB@mail> <4BBF27F8.2090704@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D643@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 16:36:40 -0000 No you're not being a Neanderthal - we're only discussing a very narrow use= -case, essentially for completeness. What you describe is the more common = example (or arguably an E.164 is the more common example), but the example = you cite is purposefully not covered by draft-olive. BTW, I'm not claiming draft-olive is very *useful* - it only covers the cas= e for certain local-numbers and email-style AoRs *of the SSP's domain*. It= only does those, because those are similar conceptually to [draft-gin] and= thus follow the same solution, which is basically: "follow rfc3261 as if t= hey had individually registered". -hadriel ________________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Monday, April 12, 2010 5:38 AM Is it me being a Neanderthaler, or is this just a strange example? The more natural case would be where "12345;ext=3D678;phone-context=3Dmarti= ni-enterprise.com" is passed unmodified to the pbx handling this number and= which belongs to martini-enterprise. /Hans Erik From HKaplan@acmepacket.com Mon Apr 12 10:10:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295833A6A89 for ; Mon, 12 Apr 2010 10:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cLD6AwKf2cv for ; Mon, 12 Apr 2010 10:10:40 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0403728C16B for ; Mon, 12 Apr 2010 10:08:27 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 12 Apr 2010 13:08:21 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 12 Apr 2010 13:08:21 -0400 From: Hadriel Kaplan To: "DRAGE, Keith (Keith)" , "Hans Erik van Elburg" Date: Mon, 12 Apr 2010 13:08:20 -0400 Thread-Topic: [martini] number normalization Thread-Index: AcrXOi5+h5lxbIBbT2Swc+1UsvAllwAAYOFAALtpUWAADSy6MA== Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D7F4@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> <430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] number normalization X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 17:10:42 -0000 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Monday, April 12, 2010 6:20 AM >=20 > I think this thread is heading here into over specification. >=20 > > +12125551212 > > +1(212)555-1212 > > +1(212)5551212 > > Etc. >=20 > All the examples given by Hadriel are syntactically valid forms of RFC > 3966 and the PBX should be able to handle them. If we think there are > interoperability problems with that, then someone should update RFC 3966, > rather than fiddle with it in Martini. We're NOT fiddling with it - we're bypassing it altogether. [draft-gin] is= n't specifying a specific 3966 translation rule to get rid of visual-separa= tors or whatever in req-uri phone numbers, it's just saying "do what rfc326= 1 does and replace the req-uri with the contact-uri". =20 As a matter of fact, the IP-PBX doesn't have to support RFC 3966 to begin w= ith! How do you even know the IP-PBX supports rfc3966 when you send it the= request? =20 =20 > However I suspect there is no interoperability problem except a tendency > to sloppy implementation. We might just as well specify that abbreviated > forms of header field names should not be used, as they are a second way > of specifying the same thing. No that's not analogous. =20 For one thing, there's a level of interop problems beyond which it's no lon= ger "sloppy implementation", but bad protocol design/spec. Honestly, rfc39= 66 fits in the latter (well really rfc2806). Allowing human-display visual= -separators to be mixed into a resource address used by machines for identi= fication and routing is simply mind-boggling. Secondly, GOOD protocol specs use a model of "strict on send, liberal on re= ceipt". Just because the receiver *should* support Foo, doesn't mean the s= ender should assume it if it can avoid doing so. For some things (many thi= ngs) the assumption can't be avoided. But we have the opportunity to avoid= it here.=20 And let's be honest - it's not like the SSP's Proxy isn't going to be chang= ing the req-uri user name a lot *anyway*. Unless you really believe every = request it receives has a full E.164 in the user portion. That's not the r= eal world, afaict. People don't type full E.164's into their phone a lot. = They type something which needs to be translated anyway, because they type= a dial-string for all intents and purposes. -hadriel From ietf.hanserik@gmail.com Mon Apr 12 10:47:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA5D28C11B for ; Mon, 12 Apr 2010 10:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOaxgUopZHGh for ; Mon, 12 Apr 2010 10:47:51 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 389873A6A81 for ; Mon, 12 Apr 2010 10:47:28 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so419406eyf.51 for ; Mon, 12 Apr 2010 10:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=jvpyWBaUrmhL4QjI8+al5y7n3CWeTZslkFdLeTAJYms=; b=GYQO6MEnMrefBduS5ubf6f47hRh7RuZTSA0L2jtG1BHS3sb0oMr3+oE+X3LoPHSz87 egPZTEOuZwo+XjqvLvakf2OL0kL6+7jieFjH2lztFS/ys7eU/t7fkvojvUlCl8hpE+b7 e4b5goTyn95iUygcC3mRjeNlD5LIxhaz/pzTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=md8m8Wisdyz966kttqqXOPgDVHgL1rlVES/lgNdxg202z1c7bb1Td2CHrcxqb2Zqej GmIC4661ZwjsW3v1YkSwlInZvgdVNJweKKAnkzej4P0Nzvy865cA8BOfOdl4nSNvgEqb w34ixyblRWmtWXQrtEgdTTP5mn5QD6BRFSfCw= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Mon, 12 Apr 2010 10:47:16 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D7F4@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail> <430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail> <430FC6BDED356B4C8498F634416644A91A79F3D7F4@mail> Date: Mon, 12 Apr 2010 19:47:16 +0200 Received: by 10.213.73.65 with SMTP id p1mr2244392ebj.65.1271094436944; Mon, 12 Apr 2010 10:47:16 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=00c09f79ece663db9204840dbc5f Cc: "DRAGE, Keith \(Keith\)" , "martini@ietf.org" Subject: Re: [martini] number normalization X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 17:47:52 -0000 --00c09f79ece663db9204840dbc5f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 12, 2010 at 7:08 PM, Hadriel Kaplan wrote: > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > > Sent: Monday, April 12, 2010 6:20 AM > > > > I think this thread is heading here into over specification. > > > > > +12125551212 > > > +1(212)555-1212 > > > +1(212)5551212 > > > Etc. > > > > All the examples given by Hadriel are syntactically valid forms of RFC > > 3966 and the PBX should be able to handle them. If we think there are > > interoperability problems with that, then someone should update RFC 3966, > > rather than fiddle with it in Martini. > > We're NOT fiddling with it - we're bypassing it altogether. [draft-gin] > isn't specifying a specific 3966 translation rule to get rid of > visual-separators or whatever in req-uri phone numbers, it's just saying "do > what rfc3261 does and replace the req-uri with the contact-uri". > > As a matter of fact, the IP-PBX doesn't have to support RFC 3966 to begin > with! How do you even know the IP-PBX supports rfc3966 when you send it the > request? > > Why not isn't that part of it saying hey I am martini compliant??? > > However I suspect there is no interoperability problem except a tendency > > to sloppy implementation. We might just as well specify that abbreviated > > forms of header field names should not be used, as they are a second way > > of specifying the same thing. > > No that's not analogous. > > For one thing, there's a level of interop problems beyond which it's no > longer "sloppy implementation", but bad protocol design/spec. Honestly, > rfc3966 fits in the latter (well really rfc2806). Allowing human-display > visual-separators to be mixed into a resource address used by machines for > identification and routing is simply mind-boggling. > Agree. > Secondly, GOOD protocol specs use a model of "strict on send, liberal on > receipt". Just because the receiver *should* support Foo, doesn't mean the > sender should assume it if it can avoid doing so. For some things (many > things) the assumption can't be avoided. But we have the opportunity to > avoid it here. > Agree, but the sender is not the SSP. The sender is the originating UA, these devices are not martini compliant. > And let's be honest - it's not like the SSP's Proxy isn't going to be > changing the req-uri user name a lot *anyway*. Unless you really believe > every request it receives has a full E.164 in the user portion. That's not > the real world, afaict. People don't type full E.164's into their phone a > lot. They type something which needs to be translated anyway, because they > type a dial-string for all intents and purposes. > That is problematic. If the originating domain would just comply with RFC3966, in the sense of "strict on send, liberal on receipt". Then there was no need on the SSP serving the terminating party to fix things. In fact having the terminating SSP fix things makes the unknow of what has to be fixed a lot larger as it could mean that you need to fix whatever device there exists in the universe is sending at a PBX served by that SSP. I have nothing against filtering human-display-visual-separators, as they dont carry any useful information. And if they create more succesful calls why not? The question is of course if we need to specify that as part of a trunking solution. This makes me believe that Keith has a point. If we believe RFC3966 has an issue we should start create RFC3966bis and refer that from the martini specification. Or just live with RFC3966 and demand that martini compliant PBX implement it correctly. /Hans Erik van Elburg --00c09f79ece663db9204840dbc5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 12, 2010 at 7:08 PM, Hadriel Kap= lan <HKaplan= @acmepacket.com> wrote:
> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]
> Sent: Monday, April 12, 2010 6:20 AM
>
> I think this thread is heading here into over specification.
>
> > +12125551212
> > +1(212)555-1212
> > +1(212)5551212
> > Etc.
>
> All the examples given by Hadriel are syntactically valid forms of RFC=
> 3966 and the PBX should be able to handle them. If we think there are<= br> > interoperability problems with that, then someone should update RFC 39= 66,
> rather than fiddle with it in Martini.

We're NOT fiddling with it - we're bypassing it altogether. =A0[dra= ft-gin] isn't specifying a specific 3966 translation rule to get rid of= visual-separators or whatever in req-uri phone numbers, it's just sayi= ng "do what rfc3261 does and replace the req-uri with the contact-uri&= quot;.

As a matter of fact, the IP-PBX doesn't have to support RFC 3966 to beg= in with! =A0How do you even know the IP-PBX supports rfc3966 when you send = it the request?

Why not isn't that part of it saying hey I am mar= tini compliant???

=A0
> However I suspect there is no interoperability problem except a tenden= cy
> to sloppy implementation. We might just as well specify that abbreviat= ed
> forms of header field names should not be used, as they are a second w= ay
> of specifying the same thing.

No that's not analogous.

For one thing, there's a level of interop problems beyond which it'= s no longer "sloppy implementation", but bad protocol design/spec= . =A0Honestly, rfc3966 fits in the latter (well really rfc2806). =A0Allowin= g human-display visual-separators to be mixed into a resource address used = by machines for identification and routing is simply mind-boggling.
Agree.
=A0
Secondly, GOOD protocol specs use a model of "strict on send, liberal = on receipt". =A0Just because the receiver *should* support Foo, doesn&= #39;t mean the sender should assume it if it can avoid doing so. =A0For som= e things (many things) the assumption can't be avoided. =A0But we have = the opportunity to avoid it here.
Agree, but the sender is not the SSP. The sender is the o= riginating UA, these devices are not martini compliant.
=A0
And let's be honest - it's not like the SSP's Proxy isn't g= oing to be changing the req-uri user name a lot *anyway*. =A0Unless you rea= lly believe every request it receives has a full E.164 in the user portion.= =A0That's not the real world, afaict. =A0People don't type full E.= 164's into their phone a lot. =A0They type something which needs to be = translated anyway, because they type a dial-string for all intents and purp= oses.
That is problematic. If the originating domain would just= comply with RFC3966, in the sense of "strict on send, liberal on rece= ipt". Then there was no need on the SSP serving the terminating party = to fix things. In fact having the terminating SSP fix things makes the unkn= ow of what has to be fixed a lot larger as it could mean that you need to f= ix whatever device there exists in the universe is sending at a PBX served = by that SSP.

I have nothing against filtering human-display-visual-separators, as th= ey dont carry any useful information. And if they create more succesful cal= ls why not? The question is of course if we need to specify that as part of= a trunking solution.

This makes me believe that Keith has a point. If we believe RFC3966 has= an issue we should start create RFC3966bis and refer that from the martini= specification. Or just live with RFC3966 and demand that martini compliant= PBX implement it correctly.

/Hans Erik van Elburg

--00c09f79ece663db9204840dbc5f-- From spencer@wonderhamster.org Mon Apr 12 12:21:32 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273803A68DE for ; Mon, 12 Apr 2010 12:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOiKP+HTju-D for ; Mon, 12 Apr 2010 12:21:30 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id B7B5628C1A1 for ; Mon, 12 Apr 2010 12:21:03 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MaHgW-1Nlwjv1Pey-00KUp2; Mon, 12 Apr 2010 15:20:57 -0400 Message-ID: <7738997058B143BABC2F87CC2E6C7E14@china.huawei.com> From: "Spencer Dawkins" To: "Paul Kyzivat" References: <430FC6BDED356B4C8498F634416644A91A79F3D673@mail> <430FC6BDED356B4C8498F634416644A91A79F3D679@mail> <6E4501A3405D42BD8CE60E8244BD09E7@china.huawei.com> <4BC33012.6070302@cisco.com> Date: Mon, 12 Apr 2010 14:20:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX18fZoQ/tlw7FjxpM0+1oq3NLGV1UZruyFrCQSs GBOxqHcajo8A3xmWBUPxQuGTT6BV2whesvQbmxYZr9WS/mR+yC 6d14rczlaFNeCGD6K9aAR+5zZ+IHkx0n45HD1qnwHg= Cc: martini@ietf.org Subject: Re: [martini] Please don't send HTML to the mailing list X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 19:21:32 -0000 Hi, Paul, I didn't mean to pick on a particular person - only to ask people to keep an eye on this. Thanks for your help with major technical topics AND with with administrivia like mail formats! Spencer >I think I'm the source of the original complaint on this. > I use Thunderbird for mail. It can do both HTML and plain text mail and > convert between them. I read all the html mail in html format, but have > set up to always reply in text format. > > I don't fully understand what it is that results in some html mail being > nicely readable while some other html mail is difficult to follow. In the > nice cases there is color coding but also bars in the margin corresponding > to the "> " indenting of replies in friendly text mail. > > But in some other cases there is no indenting, no bars, just color coding > and people's initials run into the text. And sometimes not even initials - > just the color coding. > > While I find the text that has initials hard to read after a few replies, > I never complain about it because it is a personal preference item and I > can live with it. > > Where I complained was when the only distinction I could see was between > black text and blue text (that doesn't look very much different than black > to me.) > > My main concern is that replies be formatted in such a way that its > reasonably feasible to figure out who said what in response to what after > there have been multiple replies. If that can be achieved with html mail, > then fine. But I think I will continue to reply in plaintext until I see a > better alternative. > > Sorry to have been a pain, > Paul > > Spencer Dawkins wrote: >> Just to follow along with Hadriel's note below... >> >> All of the mail readers I use (Outlook and Outlook Express) allow you to >> set "send plain text only" for each userid in the address book, so you >> can (and I do) normally send HTML, but have your mailer do the check and >> prompt you to convert if you forget to "format as plain text" something >> that's going to an IETF mailing list. >> >> We have a strong preference for plain text in the IETF (when I started >> attending, some area directors did not accept e-mail that wasn't >> plaintext), and my own preference (as working group chair) is that it's a >> lot easier to make sure I'm following a thread if I can easily find the >> text that's not prefixed, rather than trying to figure out which color is >> who, where the "[SD]" blocks actually end, etc. >> >> Please set martini@ietf.org up for plain text in your address books - it >> will make losing your valuable comments less likely! >> >> Thank you, >> >> Spencer, as co-chair >> >> ----- Original Message ----- From: "Hadriel Kaplan" >> >> To: >> Sent: Sunday, April 11, 2010 12:24 PM >> Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive >> >> >> >> BTW, I sent this in HTML format because my email client (made by some big >> company near Seattle) can't cleanly convert from HTML to plain text with >> the ">" indentation thing if the original email started as HTML, and I >> got tired of doing it by hand. It does the below instead. >> >> -hadriel >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> From ietf.hanserik@gmail.com Mon Apr 12 15:14:51 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D94F3A6AD5 for ; Mon, 12 Apr 2010 15:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yX1ByVbHshI for ; Mon, 12 Apr 2010 15:14:48 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 66F393A6931 for ; Mon, 12 Apr 2010 15:14:01 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so441417eyf.51 for ; Mon, 12 Apr 2010 15:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=zeUTOP0awZY8Psg3AC+6i9HUf4rnyqftlfHyLZTbnqk=; b=aedT2Z0pKnv8V5Rpd8Iavz0PgJo06+EElxOmzDMWKw+CshRbsDvShA7aRhPd1+SCBS bmfmjqUIZfe0sYV6saBWwuCFApfdwLIFhdhBU16EDRNDGHVBXocP2fcynJp5vGArhjRo 5DxbU1luB9O53i8CxrvDHfETX8izkB2Lhpy+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Cgb+6GMW1llOosSwqfA4or0kQREelGO98zgdpVpOMb2FWYzrj7QDremPfIeLVI4mah RggIPV7qqM2ibtlMOmV7Xijfpbj3pzLZ3DDN32vIq4CoZj5AIzsgIL03HcK/970wa4pW /MrGvE0GhDPe07OF8ZVWteKdiIZOc3o6LlS38= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Mon, 12 Apr 2010 15:13:52 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Apr 2010 00:13:52 +0200 Received: by 10.213.79.11 with SMTP id n11mr2761524ebk.28.1271110432892; Mon, 12 Apr 2010 15:13:52 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Bernard Aboba Content-Type: multipart/alternative; boundary=001485e29a10d2a84a048411756b Cc: martini@ietf.org Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 22:14:51 -0000 --001485e29a10d2a84a048411756b Content-Type: text/plain; charset=ISO-8859-1 On Sun, Apr 11, 2010 at 10:46 AM, Bernard Aboba wrote: > For example, if the IP-PBX has multiple SSPs it Registers > > into, it can't just receive a request to > > "sip:bob@pbx.enterprise.com ", because it won't know if that's to > > "sip:bob@ssp1.example.net " or "sip:bob@ssp2.example.net ", which may > > be different users. > > > > [BA] Presumably, this paragraph is describing the problem created by having > > multiple SSPs map different Request-URIs (e.g. bob@ssp1.example.net, > > bob@ssp2.example.net) to the same registered contact (bob@pbx.enterprise.com), > > right? > > > > While I understand the potential issues raised by this, a question that this > > (and other examples) raise for me, is the extent to which the issues are unique > > to multiple AOR registration. For example, it's possible to use multiple > > single AOR registrations to bind multiple AORs to the same contact, causing > > the same problem. Given that, is this issue really intrinsic to multiple > > AOR registration? Or is it speaking to the problems created by having a single > > contact (created implicitly or explicitly) map to multiple Request-URIs? > > > [HE] Yes it is the same and no it is not the same. A UE like a phone that can receive calls for different AOR's of the same user can get the target delivered in the P-Called-Party-Identity like is done in IMS or it could use the History-Info as described in the 4244bis. This target info is merely used for presentation purposes. A PBX on the other hand that uses bulkregistration is not the last entity, but has to deliver the incoming call to the end user device. This enduser device's user may also deliver calls for multiple AOR's of the same user. P-Called-Party-Identity does not work there anymore as it will be either overwritten with a contact address or there will be two P-Called-Party-Identy values, if the PBX also implements that mechanism. (not sure if this case is defined at all) Also here the History-Info from 4244bis could be used, but it requires traversal of some more History-Info entries to find the target information. One of the observation of the ua-loose-route/target-uri discussion was that it is actually a design flaw in SIP that Request-URI is rewritten for routing. There are means to alleviate the consequences when it happens on the last hop. But it is certainly not a good idea to start introducing a mechanism that forces such behaviour on intermediary hops (between the SSP and the PBX). This discussion is a symptom of forcing Request-URI rewrites to be used for routing over the SIP trunk. /Hans Erik --001485e29a10d2a84a048411756b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Apr 11, 2010 at 10:46 AM, Bernard Ab= oba <bern= ard_aboba@hotmail.com> wrote:
=A0=A0 For example, if the IP-PBX has multiple SSPs it Registers
=A0=A0=
 into, it can't just receive a request to
=A0=A0 "sip:bob@pbx.ent=
erprise.com", because it won't know if that's to
=A0=A0 "sip:bob@ssp1.example.net" or "sip:bob@ssp2.example.net",=
 which may
=A0=A0 be different users.
=A0
[BA] Presumably, th=
is paragraph is describing the problem created by having 
multipl=
e SSPs map different Request-URIs (e.g. bob@ssp1.example.net, 
bob@ssp2.exa=
mple.net) to the same registered contact (bob@pbx.enterprise.com),
right=
?
=A0
While I understand the potential issues raised by this, =
a question that this 
(and other examples) raise for me, is the e=
xtent to which the issues are unique 
to multiple AOR registratio=
n.=A0 For example, it's possible to use multiple
single AOR registrations to bind multiple AORs to the same contact, ca=
using
the same problem.=A0 Given that, is this issue really intri=
nsic to multiple
AOR registration?=A0 Or is it speaking to the pr=
oblems created by having a single
contact (created implicitly or explicitly) map to multiple Request-URI=
s?


[HE] Yes it is the same and n= o it is not the same.
A UE like a phone that can receive calls for=A0 di= fferent AOR's of the same user can get the target delivered in the P-Ca= lled-Party-Identity like is done in IMS or it could use the History-Info as= described in the 4244bis. This target info is merely used for presentation= purposes.

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

One of the observation of the ua-loose-route/target-uri discussion was = that it is actually a design flaw in SIP that Request-URI is rewritten for = routing. There are means to alleviate the consequences when it happens on t= he last hop. But it is certainly not a good idea to start introducing a mec= hanism that forces such behaviour on intermediary hops (between the SSP and= the PBX). This discussion is a symptom of forcing Request-URI rewrites to = be used for routing over the SIP trunk.
=A0
/Hans Erik
--001485e29a10d2a84a048411756b-- From HKaplan@acmepacket.com Mon Apr 12 15:18:49 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CED53A6ACA for ; Mon, 12 Apr 2010 15:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB4Hnxzd7vYw for ; Mon, 12 Apr 2010 15:18:21 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6DF093A67B7 for ; Mon, 12 Apr 2010 15:15:24 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 12 Apr 2010 18:15:11 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 12 Apr 2010 18:15:11 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Mon, 12 Apr 2010 18:15:09 -0400 Thread-Topic: Local-numbers (was Other AoR's than E.164: draft-kaplan-martini-with-olive-00) Thread-Index: AcraRWxqchJWxk6pTs2C7jeCRVcldgAR9MBg Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D93A@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> <4BBE69A0.9010606@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D3DB@mail> <4BBF27F8.2090704@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D647@mail> <4BC32238.9090503@cisco.com> In-Reply-To: <4BC32238.9090503@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Local-numbers (was Other AoR's than E.164: draft-kaplan-martini-with-olive-00) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 22:18:50 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, April 12, 2010 9:38 AM >=20 > Hadriel Kaplan wrote: > > In practice it seems to me that the user=3Ddialstring param isn't used > > much. If the request-uri is "sip:411@ssp.com", it's handled as a diale= d > > phone number of "411" regardless of a user=3Ddialstring. SSP's just do= n't > > allocate "411" as a username to some random SIP subscriber. I would ar= gue > > that's true for all service numbers, including "911" - you can send a s= os > > URN or a user=3Ddialstring param, but it's not like they're going to gi= ve > > the AoR of "sip:911@ssp.com" to some random subscriber anyway, so it's = not > > ambiguous in practice. There's no real interop problem to solve, afaic= t. >=20 > While I understand the practicality of what you say, I would find it > difficult to write that down in a standard. So I think it would be > useful to have *some* standard, even if many SSPs accept other things as > well. But we don't have to solve that as part of *this* effort. >=20 > > If we *were* to specify a dialstring, then it would need a phone-contex= t > > anyway (per rfc4967), and in my opinion that phone-context should be > > "ssp.com", ironically. >=20 > There I disagree. The phone context in a dialstring needs to correlate > directly to the dial plan for the phone that is dialing. Having it be > ssp.com would mean that all the pbxes supported by that ssp would have > the same dial plan. That obviously wouldn't work. >=20 > Instead, it again requires coming up with some unique phone-context for > the pbx, or maybe even for each dial plan used by the pbx if it might > have more than one. Umm, we were talking about numbers like "411" and "911" and such, no? The = SSP *is* the "PBX" for those numbers. It's the SSP's logical "dial-plan" y= ou're hitting first. Of course the SSP may retarget the request to a priva= te numbering plan, or to an E.164, or to an emergency number. But the "con= text" of the digits you pressed on a UA is the SSP initially, because it's = the one making a decision for what the digits mean. =20 -hadriel From ietf.hanserik@gmail.com Mon Apr 12 15:24:24 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E65C3A6923 for ; Mon, 12 Apr 2010 15:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJH8Z1yJce1X for ; Mon, 12 Apr 2010 15:24:23 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id A10A53A695E for ; Mon, 12 Apr 2010 15:20:42 -0700 (PDT) Received: by ewy24 with SMTP id 24so1367491ewy.13 for ; Mon, 12 Apr 2010 15:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:cc:content-type; bh=k0ARecQSK9gNSJy1XWcxSisBugzKIpZsyrar45fll+8=; b=hVA9QrRwCQOi5c3lR/5ml7xXjp6Rgga8eF9FJC+PBaHBsSZ1dtkrTQHbbHyC50ZDzp 7J4Lu65rgh2Dzj1NcQDLpQecv1N0xvDf0FoRC6V+k5Q6woiKAr4ehet0uDzuLHgaJgh7 VLrPxouVwL4OxqKnmgXRmmKv0HVpSF8hcD9uw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; b=otfEAjXP/5BaJdE10ZBB48rMVy5MRjpDIQjNoXXCa4sRtUUr1qaUnUp2rrf99W0Wns a2rMxX02zpmTJRLuUb8S561JavjG0YPlh2JC4KtcCOdWiQ7CMYq67NtKlHM41nKmn9Vm +mU5T7blPTfGRdk1GYKAn7vu5YDpCVZ9CMjjE= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Mon, 12 Apr 2010 15:20:33 -0700 (PDT) In-Reply-To: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> Date: Tue, 13 Apr 2010 00:20:33 +0200 Received: by 10.213.55.148 with SMTP id u20mt3804669ebg.85.1271110833214; Mon, 12 Apr 2010 15:20:33 -0700 (PDT) Message-ID: From: Hans Erik van Elburg Content-Type: multipart/alternative; boundary=0014853260d8af9c490484118d0c Cc: martini@ietf.org Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 22:24:24 -0000 --0014853260d8af9c490484118d0c Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 10, 2010 at 9:50 PM, martini issue tracker wrote: > #28: GIN: user=phone in the Contact > > For example, when expanded and used for routing to the IP-PBX, the user > portion of the resultant req-uri is not in fact a phone number but rather > just a URI (though it sure will look like a phone number ;) > > ?? Is it a number or not ?? An incoming INVITE carrying a SIP version of a number needs to carry user=phone, otherwise it is not a number. Period. /Hans Erik --0014853260d8af9c490484118d0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 10, 2010 at 9:50 PM, martini iss= ue tracker <tra= c@tools.ietf.org> wrote:
#28: GIN: user=3Dphone in the Contact

=A0For example, when expanded and used for routing to the IP-PBX, the user<= br> =A0portion of the resultant req-uri is not in fact a phone number but rathe= r
=A0just a URI (though it sure will look like a phone number ;)

?? Is it a number or not ??

An incoming INVITE= carrying a SIP version of a number needs to carry user=3Dphone, otherwise = it is not a number. Period.
=A0
/Hans Erik
--0014853260d8af9c490484118d0c-- From HKaplan@acmepacket.com Mon Apr 12 15:42:51 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 969D23A6868 for ; Mon, 12 Apr 2010 15:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbk8Z29vC9Uc for ; Mon, 12 Apr 2010 15:42:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A105B3A684D for ; Mon, 12 Apr 2010 15:42:49 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 12 Apr 2010 18:42:43 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 12 Apr 2010 18:42:43 -0400 From: Hadriel Kaplan To: "DRAGE, Keith (Keith)" , "Elwell, John" , "martini@ietf.org" Date: Mon, 12 Apr 2010 18:42:42 -0400 Thread-Topic: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 Thread-Index: AcrXRahoZd4ezAUpQc6dHIV46fji5AAgzRcQAAQbQ4AArTkQAA== Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D943@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] Other AoR's than E.164: draft-kaplan-martini-with-olive-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 22:42:51 -0000 Right, I'm with you on all that. I was just avoiding the domain name case = because of the concerns folks had raised over draft-shaken/stirred, one of = which was on the alt-root issue. And just to be clear - nothing Martini does can possibly remove or restrict= configured local policies from doing what they need to. All we're trying = to do is define enough to get the REGISTER-based model to work for basic ca= lls, avoid the basic/simple known interop issues, and not change SIP's curr= ent sipcore specs. There was feedback that supporting just E.164 isn't suf= ficient, so I'm just trying to provide a strawman for how to handle the res= t (although draft-olive only handles the easy half). Although given the nature of local-numbers I'm tempted to just change draft= -olive to say "any string user portion of the SSP domain", and leave it at = that. It would be local (provisioned) policy for how to handle whether a s= pecific username of a phone-context is an AoR or not, whether it gets chang= ed or not, etc. -hadriel > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Monday, April 12, 2010 6:21 AM > To: Elwell, John; Hadriel Kaplan; martini@ietf.org > Subject: RE: [martini] Other AoR's than E.164: draft-kaplan-martini-with- > olive-00 >=20 > We need to be careful here that we are not running before we can walk. >=20 > Yes I want to handle different numbers, more specifically private network > numbers, but we do need to understand how they will be used in the SSP > before we start writing protocol requirements. >=20 > The ETSI/3GPP model for this work was that the SSP could undertake to > provide various logical entities within it's own equipment to support the > enterprise. So where Centrex is provided (or hosted enterprise services i= n > the ETSI terminology) essentially a logical PBX is hosted by the SSP. > Nominally the enterprise is responsible for this logical entity, and the > SSP manages it on behalf of the enteprise. It is part of the enterprise, > and therefore it should be able to handle anything a physically provided > IP-PBX can handle, including the numbering / addressing plans of the > enterprise. >=20 > If I want to connect two IP-PBX together in the same enterprise, then I > can the option of establishing a direct IP connection between them, with > all the QoS and numbering / addressing handling of the enterprise handled > provided over this, in the same way as in the PSTN I can buy a tie line, > or I can use the SSP to provide public network services to connect the tw= o, > in which case I am tied to the QoS and other capabilities provided by the > SSP, including the numbering and addressing plans supported by the SSP > (and which must be globally unique within the SSP). >=20 > In particular, as an inheritance of what has been done with the use of > numbers in the past, a separate numbering plan probably exists in the > enterprise, such that 777 1234 is a valid number within the enterprise, > but would of course be meaningless outside the context of that enteprise. > While some digits may correspond to an equivalent E.l64 number, e.g. +1 > 555 999 1234, that is not a fixed requirement. >=20 > So what happens if I want to connect two Centrex installations together. > Yes I can always use the services of the SSP in which it is resident to > connect the two together, in which case we are still tied to the QoS and > other capabilities provided by the SSP, including the numbering and > addressing plans supported by the SSP (and which must be globally unique > within the SSP). Or I can negotiate a deal with the SSP that essentially > for signalling purposes requires them to simulate what I would get from > that direct IP connection (with all the QoS and numbering / addressing > handling of the enterprise handled provided over this). The ETSI / 3GPP > model provides for this, and the work in: >=20 > https://datatracker.ietf.org/doc/draft-vanelburg-dispatch-private-network= - > ind/ >=20 > provides a tag for implementing identifying such traffic, such that it is > handled according to the rules of the enterprise (which have of course > been agreed with the SSP), rather than the rules of the SSP directly. It > is within this context that the numbering / addressing plan of the > enterprise can be used. Thus within IMS tel:1234;phone- > context=3Denterprise.com can have meaning when it appears in a SIP messag= e > that contains the header field P-Private-Network-Indication:enterprise.co= m, > but would probably not have meaning when such a header field is missing. >=20 > There is no need for this tag where it is known that the traffic is 100% > belonging to the enterprise. So a UA registering with a registrar functio= n > within the Centrex environment, and sending and receiving traffic between > the UA and outbound proxies / registrars within that Centrex environment, > do not need this tag. >=20 > So that deals with two logical PBXs, i.e. Centrex connected. What happens > if one is Centrex and one is a physically provided IP-PBX. Yes we should > still be able to do the things we have been doing. >=20 > The PBX needs to "register" its private network numbers in the SSP > location server. In the IMS model, this is performed implicitly, so there > are no domain name issues here. >=20 > Incoming calls with the P-Private-Network-Indication: enterprise.com can > assume the numbering / addressing plan of the enterprise, which would > normally have a phone-context of enterprise.com, or some subdomain of tha= t. >=20 >=20 > So where does this lead in terms of what I would like to do. >=20 > 1) I am less worried about being able to handle local number forms of > E.164 numbers, although it probably drops out automatically from being > able to handle private network numbers. >=20 > 2) I do want to handle numbers where phone-context is enterprise.com or > some subdomain of that. These will only appear in incoming requests with > an equivalent P-Private-Network-Indication, and handling such an > indication involves more that just applying a special numbering plan > (rather a full set of operational agreements with the enterprise operator= ). >=20 >=20 > regards >=20 > Keith >=20 >=20 From HKaplan@acmepacket.com Mon Apr 12 16:08:05 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81FBA3A6932 for ; Mon, 12 Apr 2010 16:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiL4dVessaGc for ; Mon, 12 Apr 2010 16:08:04 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DFA773A68C7 for ; Mon, 12 Apr 2010 16:07:57 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 12 Apr 2010 19:07:52 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 12 Apr 2010 19:07:51 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Mon, 12 Apr 2010 19:07:50 -0400 Thread-Topic: [martini] #28: GIN: user=phone in the Contact Thread-Index: Acrajmv0qdg8Lv3ER8aZktGDEb14CgAAxO5Q Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D949@mail> References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 23:08:05 -0000 The gin-draft doesn't say, but IMO it's not a "phone number". It's a regis= tered contact URI. Since the URI's host portion is the IP-PBX's, the IP-PB= X can do what it wants with it, including treating it as a phone number of = course. (which is undoubtedly what it should and will do with it) Let me put it a different way: if a UA registers normally today, and thus d= oes NOT use a "user=3Dphone" in its Registered Contact-URI, what happens? = Answer: the SSP's proxy gets a Request for the E.164, and replaces the Req-= uri with the Registered contact. What breaks? It's true that this means "sip:+123456789@ssp.com;user=3Dphone" and "sip:+1= 23456789@ssp.com", and probably "sip:123456789@ssp.com", would all have to = resolve to the same registered user. Is that a problem? -hadriel ________________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Monday, April 12, 2010 6:21 PM On Sat, Apr 10, 2010 at 9:50 PM, martini issue tracker wrote: #28: GIN: user=3Dphone in the Contact =A0For example, when expanded and used for routing to the IP-PBX, the user =A0portion of the resultant req-uri is not in fact a phone number but rathe= r =A0just a URI (though it sure will look like a phone number ;) ?? Is it a number or not ?? An incoming INVITE carrying a SIP version of a number needs to carry user= =3Dphone, otherwise it is not a number. Period. =A0 /Hans Erik From pkyzivat@cisco.com Mon Apr 12 16:33:59 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431FB3A6ACE for ; Mon, 12 Apr 2010 16:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbnqjtCZZUn2 for ; Mon, 12 Apr 2010 16:33:56 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5828A3A6929 for ; Mon, 12 Apr 2010 16:33:56 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI1Kw0tAZnwN/2dsb2JhbACbQnGjNpkrhQwE X-IronPort-AV: E=Sophos;i="4.52,193,1270425600"; d="scan'208";a="101015855" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Apr 2010 23:33:50 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3CNXos5000119; Mon, 12 Apr 2010 23:33:50 GMT Message-ID: <4BC3ADCF.7070000@cisco.com> Date: Mon, 12 Apr 2010 19:33:35 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91A79F3D2FA@mail> <4BBE69A0.9010606@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D3DB@mail> <4BBF27F8.2090704@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D647@mail> <4BC32238.9090503@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D93A@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D93A@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] Local-numbers (was Other AoR's than E.164: draft-kaplan-martini-with-olive-00) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 23:33:59 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, April 12, 2010 9:38 AM >> >> Hadriel Kaplan wrote: >>> In practice it seems to me that the user=dialstring param isn't used >>> much. If the request-uri is "sip:411@ssp.com", it's handled as a dialed >>> phone number of "411" regardless of a user=dialstring. SSP's just don't >>> allocate "411" as a username to some random SIP subscriber. I would argue >>> that's true for all service numbers, including "911" - you can send a sos >>> URN or a user=dialstring param, but it's not like they're going to give >>> the AoR of "sip:911@ssp.com" to some random subscriber anyway, so it's not >>> ambiguous in practice. There's no real interop problem to solve, afaict. >> While I understand the practicality of what you say, I would find it >> difficult to write that down in a standard. So I think it would be >> useful to have *some* standard, even if many SSPs accept other things as >> well. But we don't have to solve that as part of *this* effort. >> >>> If we *were* to specify a dialstring, then it would need a phone-context >>> anyway (per rfc4967), and in my opinion that phone-context should be >>> "ssp.com", ironically. >> There I disagree. The phone context in a dialstring needs to correlate >> directly to the dial plan for the phone that is dialing. Having it be >> ssp.com would mean that all the pbxes supported by that ssp would have >> the same dial plan. That obviously wouldn't work. >> >> Instead, it again requires coming up with some unique phone-context for >> the pbx, or maybe even for each dial plan used by the pbx if it might >> have more than one. > > Umm, we were talking about numbers like "411" and "911" and such, no? The SSP *is* the "PBX" for those numbers. It's the SSP's logical "dial-plan" you're hitting first. Of course the SSP may retarget the request to a private numbering plan, or to an E.164, or to an emergency number. But the "context" of the digits you pressed on a UA is the SSP initially, because it's the one making a decision for what the digits mean. Well, maybe we are talking in circles. I was talking about what to use *in general* as phone-context with user=dialstring, assuming it might contain anything the user might dial. And that might be at issue here. For instance, I might have to dial 9411 to get outside information. (Hopefully I don't have to dial 9911 for an emergency, but I have seen that happen too.) If the calling phone, or the pbx, is generally processing the dial plan and converting to user=phone syntax in most cases, then I *suppose* you could use user=dialstring between the pbx and the SSP for certain cases where there is no other convenient representation. But that would then not be a *true* dialstring unless it is a matter of leaving the actual dialstring in selected cases. For it to be the same value across multiple pbx clients of the ssp, then I think it is just an artiface, and it would be better to choose some other one, such as service:sos or at least a local number with user=phone and some agreed upon phone-context for that purpose. Thanks, Paul From pkyzivat@cisco.com Mon Apr 12 16:49:34 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53B623A6919 for ; Mon, 12 Apr 2010 16:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.141 X-Spam-Level: X-Spam-Status: No, score=-10.141 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRugHpdRQhdI for ; Mon, 12 Apr 2010 16:49:33 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0F2163A694C for ; Mon, 12 Apr 2010 16:49:32 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEpOw0tAZnwN/2dsb2JhbACbQnGjH5kthQwE X-IronPort-AV: E=Sophos;i="4.52,193,1270425600"; d="scan'208";a="101018312" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Apr 2010 23:49:27 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3CNnRUj003359; Mon, 12 Apr 2010 23:49:27 GMT Message-ID: <4BC3B175.3020504@cisco.com> Date: Mon, 12 Apr 2010 19:49:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hans Erik van Elburg References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: martini@ietf.org Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 23:49:34 -0000 Hans Erik van Elburg wrote: > > On Sat, Apr 10, 2010 at 9:50 PM, martini issue tracker > > wrote: > > #28: GIN: user=phone in the Contact > > For example, when expanded and used for routing to the IP-PBX, the user > portion of the resultant req-uri is not in fact a phone number but > rather > just a URI (though it sure will look like a phone number ;) > > ?? Is it a number or not ?? > > An incoming INVITE carrying a SIP version of a number needs to carry > user=phone, otherwise it is not a number. Period. The user=phone thing is really very ugly - confusing and inadequate definition. If you look at 3261, the logic for updating the location service during a REGISTER uses only the user part to select the entry, ignoring all the parameters. So while it might be possible for the server to route incoming requests differently based on the presence/absence of user=phone, you can't really have two unique entries in your location service for those cases. However, you could have a policy that incoming requests to be routed are treated differently if user=phone is present. For instance, in that case the user part might be canonicalized - stripping out separator characters - before a location service dip is made. It might even reject values where the user part matches telephone-subscriber syntax but user=phone is not present. But these are policies. Its not something that MUST be done. (Unless it is made mandatory for martini.) Thanks, Paul From pkyzivat@cisco.com Mon Apr 12 16:55:33 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B87C3A694C for ; Mon, 12 Apr 2010 16:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.138 X-Spam-Level: X-Spam-Status: No, score=-10.138 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIJ7IJjSYo5I for ; Mon, 12 Apr 2010 16:55:32 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5A7AA3A67A1 for ; Mon, 12 Apr 2010 16:55:29 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALNPw0tAZnwN/2dsb2JhbACbQnGjE5kuhQwE X-IronPort-AV: E=Sophos;i="4.52,193,1270425600"; d="scan'208";a="101019303" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Apr 2010 23:55:23 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3CNtNSe004485; Mon, 12 Apr 2010 23:55:23 GMT Message-ID: <4BC3B2D9.4060302@cisco.com> Date: Mon, 12 Apr 2010 19:55:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> <430FC6BDED356B4C8498F634416644A91A79F3D949@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D949@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 23:55:33 -0000 Hadriel Kaplan wrote: > The gin-draft doesn't say, but IMO it's not a "phone number". It's a registered contact URI. Since the URI's host portion is the IP-PBX's, the IP-PBX can do what it wants with it, including treating it as a phone number of course. (which is undoubtedly what it should and will do with it) > > Let me put it a different way: if a UA registers normally today, and thus does NOT use a "user=phone" in its Registered Contact-URI, what happens? Answer: the SSP's proxy gets a Request for the E.164, and replaces the Req-uri with the Registered contact. What breaks? > > It's true that this means "sip:+123456789@ssp.com;user=phone" and "sip:+123456789@ssp.com", and probably "sip:123456789@ssp.com", would all have to resolve to the same registered user. Is that a problem? I just posted something on this subject. The server will have to go out of its way to make the first two of those behave differently. But to make the third resolve the same is going to require some configuration or policy algorithm to map it to the other form. No regular location service lookup is going to make that fall out by default. Thanks, Paul From HKaplan@acmepacket.com Mon Apr 12 19:27:01 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30893A6AD3 for ; Mon, 12 Apr 2010 19:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LvQJxqHWtfI for ; Mon, 12 Apr 2010 19:27:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0CB6B3A69BC for ; Mon, 12 Apr 2010 19:27:00 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 12 Apr 2010 22:26:55 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 12 Apr 2010 22:26:55 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Hans Erik van Elburg Date: Mon, 12 Apr 2010 22:26:54 -0400 Thread-Topic: [martini] #28: GIN: user=phone in the Contact Thread-Index: AcramtkGy+Pc9XLNQgW2Sf6TmitFXwAFJB6w Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D991@mail> References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> <4BC3B175.3020504@cisco.com> In-Reply-To: <4BC3B175.3020504@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 02:27:02 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Paul Kyzivat >=20 > Hans Erik van Elburg wrote: > > An incoming INVITE carrying a SIP version of a number needs to carry > > user=3Dphone, otherwise it is not a number. Period. > > The user=3Dphone thing is really very ugly - confusing and inadequate > definition. Totally. A hack, really. =20 > If you look at 3261, the logic for updating the location service during > a REGISTER uses only the user part to select the entry, ignoring all the > parameters. So while it might be possible for the server to route > incoming requests differently based on the presence/absence of > user=3Dphone, you can't really have two unique entries in your location > service for those cases. Right, it would break in a heart-beat. =20 > However, you could have a policy that incoming requests to be routed are > treated differently if user=3Dphone is present. For instance, in that cas= e > the user part might be canonicalized - stripping out separator > characters - before a location service dip is made. It might even reject > values where the user part matches telephone-subscriber syntax but > user=3Dphone is not present. >=20 > But these are policies. Its not something that MUST be done. (Unless it > is made mandatory for martini.) Actually, it was my impression that since RFC 3966 said the visual-separato= rs aren't used for URI comparison, that the Registrar processing of the REG= ISTER for a user=3Dphone would remove them as part of the canonicalization = step, and proxies would too as part of the location service lookup. But clearly it's too brittle all around, and the reality is you have to tre= at "sip:+123456789@foo.com" the same as "sip:+123456789@foo.com;user=3Dphon= e" unless you want things to break left and right. =20 -hadriel From HKaplan@acmepacket.com Mon Apr 12 19:33:49 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4DF3A69BD for ; Mon, 12 Apr 2010 19:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrnZJZza8-IP for ; Mon, 12 Apr 2010 19:33:49 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id EB86C3A67B5 for ; Mon, 12 Apr 2010 19:33:48 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 12 Apr 2010 22:33:42 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 12 Apr 2010 22:33:42 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Mon, 12 Apr 2010 22:33:09 -0400 Thread-Topic: [martini] #28: GIN: user=phone in the Contact Thread-Index: Acram56YHh14mRntS6m/lwdzOOVNqAAFUDDw Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D992@mail> References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> <430FC6BDED356B4C8498F634416644A91A79F3D949@mail> <4BC3B2D9.4060302@cisco.com> In-Reply-To: <4BC3B2D9.4060302@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 02:33:49 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, April 12, 2010 7:55 PM >=20 > Hadriel Kaplan wrote: > > > > Let me put it a different way: if a UA registers normally today, and > thus does NOT use a "user=3Dphone" in its Registered Contact-URI, what > happens? Answer: the SSP's proxy gets a Request for the E.164, and > replaces the Req-uri with the Registered contact. What breaks? > > > > It's true that this means "sip:+123456789@ssp.com;user=3Dphone" and > "sip:+123456789@ssp.com", and probably "sip:123456789@ssp.com", would all > have to resolve to the same registered user. Is that a problem? >=20 > I just posted something on this subject. >=20 > The server will have to go out of its way to make the first two of those > behave differently. > But to make the third resolve the same is going to require some > configuration or policy algorithm to map it to the other form. No > regular location service lookup is going to make that fall out by default= . You're right - just the first two then. -hadriel From dean.willis@softarmor.com Mon Apr 12 19:54:41 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F5C73A683F for ; Mon, 12 Apr 2010 19:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE3IJYZa75yp for ; Mon, 12 Apr 2010 19:54:40 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 95DE53A67FA for ; Mon, 12 Apr 2010 19:54:40 -0700 (PDT) Received: from localhost.localdomain (mobile-032-161-047-049.mycingular.net [32.161.47.49] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3D2sOWj008246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Apr 2010 21:54:31 -0500 X-User-Agent: K-9 Mail for Android In-Reply-To: References: =?US-ASCII?Q?=3CAcrZU3zOLXSlZiJfRMeK/a0ortmPaQ=3D=3D=3E=0D?= =?US-ASCII?Q?=0A=09=3CBLU137-DS5226F43E3AFFEBC8D381D9313?= =?US-ASCII?Q?0=40phx=2Egbl=3E_=3Cp2x9ae56b1e1004121513u59?= =?US-ASCII?Q?6213d6v9ee0f747f8545611=40mail=2Egmail=2Ecom=3E?= Content-Type: multipart/mixed; boundary="----L2N1RHLBYOUVJ1C042IOW6M6VLAB46" MIME-Version: 1.0 From: Dean Willis Date: Mon, 12 Apr 2010 22:54:13 -0400 To: Hans Erik van Elburg , Bernard Aboba Message-ID: Cc: martini@ietf.org Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 02:54:41 -0000 ------L2N1RHLBYOUVJ1C042IOW6M6VLAB46 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiJIYW5zIEVyaWsgdmFuIEVsYnVyZyIgPGlldGYuaGFuc2VyaWtAZ21haWwuY29tPiB3cm90ZToK Pk9uZSBvZiB0aGUgb2JzZXJ2YXRpb24gb2YgdGhlIHVhLWxvb3NlLXJvdXRlL3RhcmdldC11cmkg ZGlzY3Vzc2lvbiB3YXMgdGhhdAo+aXQgaXMgYWN0dWFsbHkgYSBkZXNpZ24gZmxhdyBpbiBTSVAg dGhhdCBSZXF1ZXN0LVVSSSBpcyByZXdyaXR0ZW4gZm9yCj5yb3V0aW5nLiBUaGVyZSBhcmUgbWVh bnMgdG8gYWxsZXZpYXRlIHRoZSBjb25zZXF1ZW5jZXMgd2hlbiBpdCBoYXBwZW5zIG9uCj50aGUg bGFzdCBob3AuIEJ1dCBpdCBpcyBjZXJ0YWlubHkgbm90IGEgZ29vZCBpZGVhIHRvIHN0YXJ0IGlu dHJvZHVjaW5nIGEKPm1lY2hhbmlzbSB0aGF0IGZvcmNlcyBzdWNoIGJlaGF2aW91ciBvbiBpbnRl cm1lZGlhcnkgaG9wcyAoYmV0d2VlbiB0aGUgU1NQCj5hbmQgdGhlIFBCWCkuIFRoaXMgZGlzY3Vz c2lvbiBpcyBhIHN5bXB0b20gb2YgZm9yY2luZyBSZXF1ZXN0LVVSSSByZXdyaXRlcwo+dG8gYmUg dXNlZCBmb3Igcm91dGluZyBvdmVyIHRoZSBTSVAgCgpWZXJ5IHRydWUuIEJ1dCB0aGlzIHBhcnRp Y3VsYXJseSBhYmhvcnJlbnQgZWxlbWVudCBvZiBTSVAgaXMgZW5jb2RlZCBkaXJlY3RseSBpbiB0 aGUgRE5BIG9mIHRoZSBSRUdJU1RFUiBtZXRob2QuIEZpeGluZyBpdCByaWdodCByZXF1aXJlcyBl aXRoZXIgcmVzZXF1ZW5jaW5nIHNhaWQgRE5BIGludG8gU0lQIDMuMCBvciB1c2luZyBhIHJlcXVl c3QtbWV0aG9kIHRoYXQgaXMgbm90IFJFR0lTVEVSLiAKClBpY2sgb25lLgoKCi0tIApEZWFuIFdp bGxpcwo= ------L2N1RHLBYOUVJ1C042IOW6M6VLAB46-- From HKaplan@acmepacket.com Mon Apr 12 19:56:21 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 072203A67FA for ; Mon, 12 Apr 2010 19:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKcay02wgs6d for ; Mon, 12 Apr 2010 19:56:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2C6993A67AE for ; Mon, 12 Apr 2010 19:56:20 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 12 Apr 2010 22:56:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 12 Apr 2010 22:56:11 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Mon, 12 Apr 2010 22:56:09 -0400 Thread-Topic: [martini] Question on gin and variable number lengths Thread-Index: AcraGMyzGcA8fwk1SOW/3roDSz+nGgASmpug Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D994@mail> References: <38C8E0333CD84FDB908C277D09F0F4E1@china.huawei.com> <551B2F8F28374DC3A791737B7A516BE0@china.huawei.com> <4BBF47AF.3070303@nostrum.com> <4BBF57C5.3060400@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D639@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Question on gin and variable number lengths X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 02:56:21 -0000 I think we'd just need to agree on what the "rule" is, basically. And cons= ider/document what it means when a more-specific match exists. For example, if it's a longest-prefix-match rule as you describe, then does= that mean the shorter prefix one does or does not also include the longer = AoR? (i.e., is the longer AoR registered twice, or is the longer entry's ra= nge effectively removed from the shorter prefix one) And if try to subscribe for the prefix, am I also subscribing for the longe= r one? How would I know if a longer one exists if it's not auto-included? = Etc. -hadriel ________________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Monday, April 12, 2010 4:19 AM To: Hadriel Kaplan It is not totally clear where you see the problem, but if it is the matchin= g bit then specifying that the best match wins will resolve this. In the se= nse that 12345 matches better with the record with name 12345 then with the= record with wildcarded id 12345*. /Hans Erik van Elburg From HKaplan@acmepacket.com Mon Apr 12 20:37:08 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557E728C0E8 for ; Mon, 12 Apr 2010 20:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynn0+4tPi6wV for ; Mon, 12 Apr 2010 20:37:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7363D3A6851 for ; Mon, 12 Apr 2010 20:37:07 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 12 Apr 2010 23:37:00 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 12 Apr 2010 23:37:00 -0400 From: Hadriel Kaplan To: Dean Willis Date: Mon, 12 Apr 2010 23:36:59 -0400 Thread-Topic: [martini] Questions about draft-kaplan-martini-with-olive Thread-Index: AcratLFdh8fMLkbTT7aWFKd28OJzwAAAFGhA Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D99B@mail> References: =?US-ASCII?Q?=3CAcrZU3zOLXSlZiJfRMeK/a0ortmPaQ=3D=3D=3E=0D?= =?US-ASCII?Q?=0A=09=3CBLU137-DS5226F43E3AFFEBC8D381D9313?= =?US-ASCII?Q?0=40phx=2Egbl=3E_=3Cp2x9ae56b1e1004121513u59?= =?US-ASCII?Q?6213d6v9ee0f747f8545611=40mail=2Egmail=2Ecom=3E?= In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 03:37:08 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Dean Willis >=20 > "Hans Erik van Elburg" wrote: > >One of the observation of the ua-loose-route/target-uri discussion was > that > >it is actually a design flaw in SIP that Request-URI is rewritten for > >routing. There are means to alleviate the consequences when it happens o= n > >the last hop. But it is certainly not a good idea to start introducing a > >mechanism that forces such behaviour on intermediary hops (between the > SSP > >and the PBX). This discussion is a symptom of forcing Request-URI > rewrites > >to be used for routing over the SIP >=20 > Very true. But this particularly abhorrent element of SIP is encoded > directly in the DNA of the REGISTER method. Fixing it right requires > either resequencing said DNA into SIP 3.0 or using a request-method that > is not REGISTER. > Pick one. I don't buy that. It doesn't matter if the request was named REGISTER or P= UBLISH or FOOBAR. The language for routing in 3261 is loose enough to driv= e a Mac truck through, and any extension can extend/apply-to any method inc= luding REGISTER. Heck, we could have defined a mime body for REGISTER if w= e wanted to.=20 But you're not going to get me to go back in time to rehash those arguments= again... no really you won't... :) -hadriel From dean.willis@softarmor.com Mon Apr 12 21:08:45 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38D273A67E1 for ; Mon, 12 Apr 2010 21:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCGfegakyMf6 for ; Mon, 12 Apr 2010 21:08:44 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id ADE5E3A687C for ; Mon, 12 Apr 2010 21:08:39 -0700 (PDT) Received: from localhost.localdomain (mobile-032-161-047-049.mycingular.net [32.161.47.49] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3D48PTn008718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Apr 2010 23:08:31 -0500 X-User-Agent: K-9 Mail for Android In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D99B@mail> References: =?US-ASCII?Q?=3D=3FUS-ASCII=3FQ=3F=3D3CAcrZU3zOLXSlZiJfRMeK/a0ort?= =?US-ASCII?Q?mPaQ=3D3D=3D3D=3D3E=3D0D=3F=3D=0D=0A=09?= =?US-ASCII?Q?=3D=3FUS-ASCII=3FQ=3F=3D0A=3D09=3D3CBL?= =?US-ASCII?Q?U137-DS5226F43E3AFFEBC8D381D9313=3F=3D=0D=0A=09=3D=3FUS-AS?= =?US-ASCII?Q?CII=3FQ=3F0=3D40phx=3D2Egbl=3D3E=5F=3D3Cp2x9ae56b1e100412151?= =?US-ASCII?Q?3u59=3F=3D=0D=0A=09=3D=3FUS-ASCII=3F?= =?US-ASCII?Q?Q=3F6213d6v9ee0f747f85456?= =?US-ASCII?Q?11=3D40mail=3D2Egmail=3D2Eco?= =?US-ASCII?Q?m=3D3E=3F=3D=0D=0A_=3Cf7f530b8-131b-?= =?US-ASCII?Q?4692-bf68-3ee88c7ca71e=40email=2Eandroid=2Ecom=3E_=3C4?= =?US-ASCII?Q?30FC6BDED356B4C8498F634416644A91A79F3D99B=40mail=3E?= Content-Type: multipart/mixed; boundary="----XOS2WIG3FTY5UVEV33FL24ENYVWATY" MIME-Version: 1.0 From: Dean Willis Date: Tue, 13 Apr 2010 00:08:16 -0400 To: Hadriel Kaplan Message-ID: <639fa5f8-699f-4816-bf8a-8dc31b0762bf@email.android.com> Cc: "martini@ietf.org" Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 04:08:45 -0000 ------XOS2WIG3FTY5UVEV33FL24ENYVWATY Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiJIYWRyaWVsIEthcGxhbiIgPEhLYXBsYW5AYWNtZXBhY2tldC5jb20+IHdyb3RlOgo+QnV0IHlv dSdyZSBub3QgeWdvaW5nIHRvIGdldCBtZSB0byBnbyBiYWNrIGluIHRpbWUgdG8gcmVoYXNoIHRo b3NlIGFyZ3VtZW50cyBhZ2Fpbi4uLiBubyByZWFsbHkgeW91IHdvbid0Li4uCj46KQoKCk5vLCBI YWRyaWVsLiBZb3UgY2Fubm90IGJvcnJvdyB0aGUgRGVMb3JlYW4gdG9uaWdodC4gIEkgYW0gdXNp bmcgaXQgdG8gcmV2aXNpdCBteSBiZWZvcmUtU0lQIDMwJ3MuIEJhY2sgd2hlbiBJIGFjdHVhbGx5 IHRob3VnaHQgSSBrbmV3IHNvbWV0aGluZyBpbXBvcnRhbnQuCgoKLS0gCkRlYW4gV2lsbGlz ------XOS2WIG3FTY5UVEV33FL24ENYVWATY-- From HKaplan@acmepacket.com Mon Apr 12 21:16:43 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDFB03A6AEC for ; Mon, 12 Apr 2010 21:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk+r0jPaeK0f for ; Mon, 12 Apr 2010 21:16:42 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 123E63A67B2 for ; Mon, 12 Apr 2010 21:16:42 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 13 Apr 2010 00:16:35 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 13 Apr 2010 00:16:35 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg , Bernard Aboba Date: Tue, 13 Apr 2010 00:16:11 -0400 Thread-Topic: [martini] Questions about draft-kaplan-martini-with-olive Thread-Index: AcrajZq4KOaIMqSlTxOBKLLdCY5hYgALSgyA Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 04:16:44 -0000 I'm not so sure that request-URI re-writing is actually a design flaw for t= his case. Ultimately, there really is a problem with leaving the Request-URI "alone" = when it goes from one authoritative domain to another. =20 Think about it - how could we really expect that the original full URI for = domain foo.com has any meaning to domain bar.com? Just re-writing the dom= ain portion doesn't suddenly make it understandable to bar.com. Simple thi= ngs like URI user-params may (and in fact do in practice) mean different th= ings to foo.com than they do to bar.com. For example, the "rn", "cic", and "tgrp" TEL URI params (SIP URI user param= s) are quite popular. These are essentially only understandable to the SSP= (s) - that's completely legitimate, because the URI is of the SSP. Would y= ou *really* expect to pass those on untouched in the Request-URI to a SIP U= A, or IP-PBX? -hadriel ________________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Hans Erik van Elburg Sent: Monday, April 12, 2010 6:14 PM One of the observation of the ua-loose-route/target-uri discussion was that= it is actually a design flaw in SIP that Request-URI is rewritten for rout= ing. There are means to alleviate the consequences when it happens on the l= ast hop. But it is certainly not a good idea to start introducing a mechani= sm that forces such behaviour on intermediary hops (between the SSP and the= PBX). This discussion is a symptom of forcing Request-URI rewrites to be u= sed for routing over the SIP trunk. =A0 /Hans Erik From trac@tools.ietf.org Mon Apr 12 21:42:04 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F267F3A68A7 for ; Mon, 12 Apr 2010 21:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQDU9QGEwXYk for ; Mon, 12 Apr 2010 21:42:03 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 36A3F3A67B1 for ; Mon, 12 Apr 2010 21:42:03 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O1Xwj-00033N-Ic; Mon, 12 Apr 2010 21:41:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: martini Date: Tue, 13 Apr 2010 04:41:57 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/32 Message-ID: <064.feeb3a5a70015c5019da8d1e3378776a@tools.ietf.org> X-Trac-Ticket-ID: 32 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #32: GIN: need to specify the exact AoR format being registered X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 04:42:04 -0000 #32: GIN: need to specify the exact AoR format being registered ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Since the REGISTER is in bulk and does not identify each exact AoR being registered, we need to be normatively succint on the exact format of AoR that is being implicitly Registered, because it (1) may affect reg-event processing, (2) may affect authentication and Identity, and (3) may cause interop issues. The current text in section 5 says: For each of these unique rows, the AOR will be in the format that the SSP expects to receive from external parties (e.g. "sip:+12145550102@ssp.example.com"),... An "example" isn't normative. Also, we need to decide if the Registered AoR has a "user=phone" URI param or not - i.e., whether the implicit REGISTER's virtual To-URI had one. In practice they rarely do, and whether it should or not hopefully doesn't matter, but it'd be better to be clear one way or the other (or even just explain why it doesn't matter). -- Ticket URL: martini From jan.van.geel@belgacom.be Tue Apr 13 00:18:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B12A3A69D1 for ; Tue, 13 Apr 2010 00:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zR4dEHHuhtAE for ; Tue, 13 Apr 2010 00:18:49 -0700 (PDT) Received: from mx13.belgacom.be (mx13.belgacom.be [195.13.15.233]) by core3.amsl.com (Postfix) with ESMTP id 363D73A69D6 for ; Tue, 13 Apr 2010 00:17:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,196,1270418400"; d="scan'208";a="396708" Received: from unknown (HELO A03005.BGC.NET) ([10.120.129.161]) by mx13.belgacom.be with ESMTP; 13 Apr 2010 09:17:45 +0200 X-TM-IMSS-Message-ID: <02cb30de000043f8@belgacom.be> Received: from A03167.BGC.NET ([45.223.1.34]) by belgacom.be ([10.120.129.161]) with ESMTP (TREND IMSS SMTP Service 7.0; TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 02cb30de000043f8 ; Tue, 13 Apr 2010 09:17:14 +0200 Received: from CMS03.BGC.NET ([10.120.128.133]) by A03167.BGC.NET ([45.223.1.34]) with mapi; Tue, 13 Apr 2010 09:17:14 +0200 From: To: , , , Date: Tue, 13 Apr 2010 09:17:13 +0200 Thread-Topic: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) Thread-Index: AcrXYY6Q8/kwonW+QjiWHoB+QP6FHgCs6TCQABFHHqAAH6uhcA== Message-ID: <208EAE1DFA28FC419529619ABB8622441617F432D6@CMS03.BGC.NET> References: <430FC6BDED356B4C8498F634416644A91A79F3D2A2@mail><430FC6BDED356B4C8498F634416644A91A79F3D2D3@mail><4BBE380C.7080900@cisco.com> <208EAE1DFA28FC419529619ABB8622441617EF2A1A@CMS03.BGC.NET> <430FC6BDED356B4C8498F634416644A91A79F3D7CD@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D7CD@mail> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: martini@ietf.org Subject: Re: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini)) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 07:18:52 -0000 Well,=20in=20my=20simple=20mind=20I=20assume=20the=20IP-PB=20expects=20th= e=20Request-URI=20to=20match=20what=20he=20used=20to=20REGISTER,=20right= =20? So,=20whatever=20you=20decide=20on=20what=20the=20"network"=20should=20se= nd=20to=20the=20IP-PBX,=20the=20"network"=20will=20also=20receive=20this= =20in=20REGISTER=20messages=20(unless=20we=20talk=20about=20registrationl= ess=20operation) Jan=20Van=20Geel=20 IT=20and=20Network=20Development=20Specialist=20 Belgacom=20SDE/SDV/PSE/NST/NCP=20 Tel:=20+32=202=20202=201035=20 Tel:=20+32=202=20207=209032=20 Email=20:=20jan.van.geel@belgacom.be=20 www.cyberwezz.tk=20 -----Original=20Message----- From:=20Hadriel=20Kaplan=20[mailto:HKaplan@acmepacket.com]=20 Sent:=2012=20April=202010=2018:17 To:=20VAN=20GEEL=20Jan=20(ITN/NIS);=20spencer@wonderhamster.org;=20ietf.h= anserik@gmail.com;=20john.elwell@siemens-enterprise.com Cc:=20martini@ietf.org Subject:=20RE:=20[martini]=20number=20normalization=20(was=20Re:=20Changi= ng=20the=20domain(was:=20Hitchhiker's=20Guide=20to=20MakingMartini)) Hi=20Jan, Just=20the=20Request-URI.=20=20I=20know=20people=20have=20problems=20with= =20From=20(and=20To,=20and=20PAI,=20and=20Diversion/Hist-Info,=20etc.)=20= but=20there's=20no=20way=20to=20change=20a=20From/To=20in=20a=20Proxy.=20= =20I'm=20just=20trying=20to=20address=20as=20much=20as=20we=20can=20legal= ly=20address.=20=20And=20the=20first=20order=20of=20priority=20is=20makin= g=20sure=20the=20IP-PBX=20at=20least=20knows=20what=20the=20target=20of= =20the=20request=20is.=20:) Maybe=20what=20we=20should=20do=20is=20put=20in=20language=20in=20the=20d= raft=20to=20remind=20folks=20that=20the=20To/From/PAI/etc.=20can=20be=20o= f=20various=20flavors/formats,=20and=20hope=20for=20the=20best? -hadriel >=20-----Original=20Message----- >=20From:=20jan.van.geel@belgacom.be=20[mailto:jan.van.geel@belgacom.be] >=20Sent:=20Monday,=20April=2012,=202010=203:55=20AM >=20 >=20Just=20for=20my=20clarification,=20when=20talking=20about=20what=20a= =20martini=20PBX=20should=20be >=20able=20to=20receive,=20which=20headers=20are=20we=20talking=20about= =20? >=20The=20"format"=20to=20be=20received=20might=20be=20different=20in=20R= equest-URI=20and=20FROM >=20header=20for=20example. ****=20DISCLAIMER=20**** http://www.belgacom.be/maildisclaimer From ietf.hanserik@gmail.com Tue Apr 13 00:34:05 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A823A6976 for ; Tue, 13 Apr 2010 00:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0ALRNwvPW+E for ; Tue, 13 Apr 2010 00:34:05 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id BDBD43A68CC for ; Tue, 13 Apr 2010 00:33:47 -0700 (PDT) Received: by ewy24 with SMTP id 24so1441536ewy.13 for ; Tue, 13 Apr 2010 00:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=H4QV+/K+uk+jfU9KQGlHAAL4zgfuZ9rEm4JNk9U6Gzo=; b=jNLlchoSAdBxcxGuUsisXPTplV97ztci1NPCiih11w11nOkR+ZYns/aSp9Y3dXPZMW J6cP9f3oNAuv0OA4DaYTiXSR9F6ablqaWj7FELyEuUC3nZwa2YObPp6z1FMFUeP04mnD gaH73Firyy+lhW2Bn6n6A8MV3UksW1C1AQlEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MC7U6XGkU/ajPmlIi5bqFOotxWFo/bi8pS23iICKUmy/e2Ra8zqvApSbDg9LSzI/01 6jn55TiX1TcgdW0n0JhRMpbXy1dWOobjjvaAWqftPKurb1LRNPrHgr84uHNx9JOPoz6o KRaWKSV6ahPLF7Y5gF8jKufy3cgCXjORNctzI= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Tue, 13 Apr 2010 00:33:37 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Apr 2010 09:33:37 +0200 Received: by 10.213.2.79 with SMTP id 15mr2646504ebi.96.1271144017579; Tue, 13 Apr 2010 00:33:37 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Dean Willis Content-Type: text/plain; charset=ISO-8859-1 Cc: Bernard Aboba , martini@ietf.org Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 07:34:05 -0000 REGISTER with bnc option tag did not exist before. We are actually defining that mechanism... /Hans Erik van Elburg On Tue, Apr 13, 2010 at 4:54 AM, Dean Willis wrote: > > "Hans Erik van Elburg" wrote: >>One of the observation of the ua-loose-route/target-uri discussion was that >>it is actually a design flaw in SIP that Request-URI is rewritten for >>routing. There are means to alleviate the consequences when it happens on >>the last hop. But it is certainly not a good idea to start introducing a >>mechanism that forces such behaviour on intermediary hops (between the SSP >>and the PBX). This discussion is a symptom of forcing Request-URI rewrites >>to be used for routing over the SIP > > Very true. But this particularly abhorrent element of SIP is encoded directly in the DNA of the REGISTER method. Fixing it right requires either resequencing said DNA into SIP 3.0 or using a request-method that is not REGISTER. > > Pick one. > > > -- > Dean Willis > From ietf.hanserik@gmail.com Tue Apr 13 00:38:07 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3135C3A69D7 for ; Tue, 13 Apr 2010 00:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRplyfsdcYA7 for ; Tue, 13 Apr 2010 00:38:06 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 71E023A695B for ; Tue, 13 Apr 2010 00:38:01 -0700 (PDT) Received: by ewy24 with SMTP id 24so1442520ewy.13 for ; Tue, 13 Apr 2010 00:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kcZUIVeUJU9fGIFCuWNPYhI7l0kJvwC/IXzzLxrRE2w=; b=o5vpnq3k3q/Rqu5UgVwhTh2S8w4LW0MJWVYAqPcsOGbCWAcpPd9+MRuOStp7bZi+Rl 9pyCHu7kGYU15DmO++Zu6Q/f15HMck8EULqGawDbQTjxD/sOf4ccfXT0J4MCgtf9ulQT I1d/umgNMAFkZ15IANI18UyTVaxBFY9wHWaD8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GY5X8v+hfg9vbDm8BFd0BdRSS7H97MHwd1sxOZQr9R7TRzknUjeAvnpHFp/+AqSjl4 v0wxq3GFTE7jd8SIRShkP/ej1BFwgMLaFtVQA69wGPaQQODnep5FIuKWE+H1D+3cYtKu HSceSfX5VFEXBEIeWD6BhfEEFGZMgBy1fi1Bs= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Tue, 13 Apr 2010 00:37:53 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> Date: Tue, 13 Apr 2010 09:37:53 +0200 Received: by 10.213.37.133 with SMTP id x5mr2929826ebd.24.1271144273240; Tue, 13 Apr 2010 00:37:53 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 07:38:07 -0000 On Tue, Apr 13, 2010 at 6:16 AM, Hadriel Kaplan wr= ote: > > I'm not so sure that request-URI re-writing is actually a design flaw for= this case. > Ultimately, there really is a problem with leaving the Request-URI "alone= " when it goes from one authoritative domain to another. [HE] Agree. But that is something else then choosing a mechanims that forces you in ALL case to do such rewrite. > For example, the "rn", "cic", and "tgrp" TEL URI params (SIP URI user par= ams) are quite popular. =A0These are essentially only understandable to the= SSP(s) - that's completely legitimate, because the URI is of the SSP. =A0W= ould you *really* expect to pass those on untouched in the Request-URI to a= SIP UA, or IP-PBX? [HE] Yeah, but we are not specifying a solution based on those or? I agree you want might want to strip them of. That is still something else then choosing a solution that forces you in ALL situations to perform rewrites. From john.elwell@siemens-enterprise.com Tue Apr 13 03:33:19 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299943A692F for ; Tue, 13 Apr 2010 03:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+-3YR-knvm2 for ; Tue, 13 Apr 2010 03:33:18 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E57AA3A6821 for ; Tue, 13 Apr 2010 03:33:17 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1529504; Tue, 13 Apr 2010 12:33:10 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 878721EB82AB; Tue, 13 Apr 2010 12:33:10 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 13 Apr 2010 12:33:10 +0200 From: "Elwell, John" To: Hans Erik van Elburg , Bernard Aboba Date: Tue, 13 Apr 2010 12:33:08 +0200 Thread-Topic: [martini] Questions about draft-kaplan-martini-with-olive Thread-Index: AcrajZg8awvcK4dLQEuDjtPWyfl7JwAZfKeA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 10:33:19 -0000 =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Hans Erik van Elburg > Sent: 12 April 2010 23:14 > To: Bernard Aboba > Cc: martini@ietf.org > Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive >=20 >=20 > On Sun, Apr 11, 2010 at 10:46 AM, Bernard Aboba=20 > wrote: >=20 >=20 > For example, if the IP-PBX has multiple SSPs it Registers > into, it can't just receive a request to > "sip:bob@pbx.enterprise.com=20 > ", because it won't=20 > know if that's to > "sip:bob@ssp1.example.net=20 > " or=20 > "sip:bob@ssp2.example.net =20 > ", which may > be different users. > =20 > [BA] Presumably, this paragraph is describing the=20 > problem created by having=20 > multiple SSPs map different Request-URIs (e.g.=20 > bob@ssp1.example.net,=20 > bob@ssp2.example.net) to the same registered contact=20 > (bob@pbx.enterprise.com), > right? > =20 > While I understand the potential issues raised by this,=20 > a question that this=20 > (and other examples) raise for me, is the extent to=20 > which the issues are unique=20 > to multiple AOR registration. For example, it's=20 > possible to use multiple > single AOR registrations to bind multiple AORs to the=20 > same contact, causing > the same problem. Given that, is this issue really=20 > intrinsic to multiple > AOR registration? Or is it speaking to the problems=20 > created by having a single > contact (created implicitly or explicitly) map to=20 > multiple Request-URIs? >=20 >=20 >=20 > [HE] Yes it is the same and no it is not the same. > A UE like a phone that can receive calls for different AOR's=20 > of the same user can get the target delivered in the=20 > P-Called-Party-Identity like is done in IMS or it could use=20 > the History-Info as described in the 4244bis. This target=20 > info is merely used for presentation purposes. [JRE] In my experience, a UA behind a PBX is far more likely to register ea= ch AOR separately, with a separate contact URI for each, so there is no amb= iguity when an inbound request arrives (no need for P-Called-Party-ID, no n= eed for History-Info). >=20 > A PBX on the other hand that uses bulkregistration is not the=20 > last entity, but has to deliver the incoming call to the end=20 > user device. This enduser device's user may also deliver=20 > calls for multiple AOR's of the same user.=20 > P-Called-Party-Identity does not work there anymore as it=20 > will be either overwritten with a contact address or there=20 > will be two P-Called-Party-Identy values, if the PBX also=20 > implements that mechanism. (not sure if this case is defined=20 > at all) Also here the History-Info from 4244bis could be=20 > used, but it requires traversal of some more History-Info=20 > entries to find the target information.=20 [JRE] I don't see the problem. As part of bulk registration according to gi= n, the PBX will register all AORs on all its UAs with the SSP, registering = separate contact URIs for each. Therefore, when an inbound request arrives,= the PBX knows what AOR is targeted. It can then go to its own location ser= vice and find the appropriate contact URI for routing to the UA. It all see= ms to work just fine, and very much in line with current practice. John From ietf.hanserik@gmail.com Tue Apr 13 03:47:41 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0453A6A24 for ; Tue, 13 Apr 2010 03:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12tPrzwxpz1T for ; Tue, 13 Apr 2010 03:47:40 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 7C82B3A6A41 for ; Tue, 13 Apr 2010 03:47:24 -0700 (PDT) Received: by ewy24 with SMTP id 24so1503523ewy.13 for ; Tue, 13 Apr 2010 03:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3T4RMNnColOwe5cF/dse7lMTtz/VXNBheXn6aVkbZ3Q=; b=et62E43B1COT9Qfj88QYrC24YCyAlXMrGpKNngPsUTTepqteYMdQLTRYQr8VPBSJGW 8ila8rAypVbdokRc1VKme4AXF9vHw2PSAJr4WVs3fLK6VOBKIjgj+GkPv5LDP5Ecs4u5 doYV5czQLy6VTNhWWjnEmXroYT0FgQH17KK4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=n0k3xaIf6vmIMKwdeBazk9TnapvPWO77eY+OneZtuFUQOfYUm8MNXcwNBtWMVPSx4h H5eoiCC78XNu7qckWlzI0RGCS/DsA+t3hKdUKNeNuhQe5GfUr2wns2g61gB5iJHzgK0E OiM94EuO4uWY4MEfwQZcyouyPt6AjgNnU037I= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Tue, 13 Apr 2010 03:47:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Apr 2010 12:47:14 +0200 Received: by 10.213.68.77 with SMTP id u13mr3158394ebi.9.1271155634776; Tue, 13 Apr 2010 03:47:14 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 10:47:41 -0000 On Tue, Apr 13, 2010 at 12:33 PM, Elwell, John wrote: >> [HE] Yes it is the same and no it is not the same. >> A UE like a phone that can receive calls for =A0different AOR's >> of the same user can get the target delivered in the >> P-Called-Party-Identity like is done in IMS or it could use >> the History-Info as described in the 4244bis. This target >> info is merely used for presentation purposes. > [JRE] In my experience, a UA behind a PBX is far more likely to register = each AOR separately, with a separate contact URI for each, so there is no a= mbiguity when an inbound request arrives (no need for P-Called-Party-ID, no= need for History-Info). [HE] Yes likely, but not guaranteed. Especially if a PBX supports its own variant of implicit registration. We can't base a specification on likely behavior. >> A PBX on the other hand that uses bulkregistration is not the >> last entity, but has to deliver the incoming call to the end >> user device. This enduser device's user may also deliver >> calls for multiple AOR's of the same user. >> P-Called-Party-Identity does not work there anymore as it >> will be either overwritten with a contact address or there >> will be two P-Called-Party-Identy values, if the PBX also >> implements that mechanism. (not sure if this case is defined >> at all) Also here the History-Info from 4244bis could be >> used, but it requires traversal of some more History-Info >> entries to find the target information. > [JRE] I don't see the problem. As part of bulk registration according to = gin, the PBX will register all AORs on all its UAs with the SSP, registerin= g separate contact URIs for each. [HE] You can not conclude that, that would enforce a company to make all its numbers used internally externally exposed DIDs. [JRE] Therefore, when an inbound request arrives, the PBX knows what AOR is targeted. It can then go to its own location service and find the appropriate contact URI for routing to the UA. It all seems to work just fine, and very much in line with current practice. [HE] Which current practice?? There is no uniform current practice, otherwise there would not be this frenzy martini discussion. From john.elwell@siemens-enterprise.com Tue Apr 13 04:07:32 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC26728C183 for ; Tue, 13 Apr 2010 04:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hisjF4axKjlN for ; Tue, 13 Apr 2010 04:07:32 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 9F2C028C0FC for ; Tue, 13 Apr 2010 04:07:31 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1531035; Tue, 13 Apr 2010 13:07:25 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 1B2FA1EB82AB; Tue, 13 Apr 2010 13:07:25 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 13 Apr 2010 13:07:25 +0200 From: "Elwell, John" To: Hans Erik van Elburg Date: Tue, 13 Apr 2010 13:07:23 +0200 Thread-Topic: [martini] Questions about draft-kaplan-martini-with-olive Thread-Index: Acra9q5bSxdHVQk2T0mOnNcn+fXiSwAAYcbA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 11:07:33 -0000 =20 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: 13 April 2010 11:47 > To: Elwell, John > Cc: Bernard Aboba; martini@ietf.org > Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive >=20 > On Tue, Apr 13, 2010 at 12:33 PM, Elwell, John > wrote: >=20 > >> [HE] Yes it is the same and no it is not the same. > >> A UE like a phone that can receive calls for =A0different AOR's > >> of the same user can get the target delivered in the > >> P-Called-Party-Identity like is done in IMS or it could use > >> the History-Info as described in the 4244bis. This target > >> info is merely used for presentation purposes. > > [JRE] In my experience, a UA behind a PBX is far more=20 > likely to register each AOR separately, with a separate=20 > contact URI for each, so there is no ambiguity when an=20 > inbound request arrives (no need for P-Called-Party-ID, no=20 > need for History-Info). > [HE] Yes likely, but not guaranteed. Especially if a PBX supports its > own variant of implicit registration. We can't base a specification on > likely behavior. JRE] In any case, that is an issue for the PBX to solve, not MARTINI. I am = just stating what, in my limited experience, is common practice. >=20 >=20 > >> A PBX on the other hand that uses bulkregistration is not the > >> last entity, but has to deliver the incoming call to the end > >> user device. This enduser device's user may also deliver > >> calls for multiple AOR's of the same user. > >> P-Called-Party-Identity does not work there anymore as it > >> will be either overwritten with a contact address or there > >> will be two P-Called-Party-Identy values, if the PBX also > >> implements that mechanism. (not sure if this case is defined > >> at all) Also here the History-Info from 4244bis could be > >> used, but it requires traversal of some more History-Info > >> entries to find the target information. > > [JRE] I don't see the problem. As part of bulk registration=20 > according to gin, the PBX will register all AORs on all its=20 > UAs with the SSP, registering separate contact URIs for each. > [HE] You can not conclude that, that would enforce a company to make > all its numbers used internally externally exposed DIDs. [JRE] You are correct that there might be some AORs that are not DIDs, so a= re not directly reachable from an SSP (only via some sort of human or autom= ated attendant service), but this is outside the scope of MARTINI, surely? >=20 > [JRE] Therefore, when an inbound request arrives, the PBX knows what > AOR is targeted. It can then go to its own location service and find > the appropriate contact URI for routing to the UA. It all seems to > work just fine, and very much in line with current practice. > [HE] Which current practice?? There is no uniform current practice, > otherwise there would not be this frenzy martini discussion. [JRE] Current practice certainly varies in detail - that is the reason for = MARTINI. But the principles are the same - information in the inbound reque= st to the PBX identifies the target AOR somehow, and that is used by the PB= X to query its location service for onward routing to a UA. John From ietf.hanserik@gmail.com Tue Apr 13 04:16:43 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8553C3A6A09 for ; Tue, 13 Apr 2010 04:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFavAnWcOFus for ; Tue, 13 Apr 2010 04:16:42 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 68FA13A699D for ; Tue, 13 Apr 2010 04:16:42 -0700 (PDT) Received: by ewy24 with SMTP id 24so1522320ewy.13 for ; Tue, 13 Apr 2010 04:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+rdY5xpJEJcNwfo6u8F9jH0slpUurxLBEd1Z/sxQRx4=; b=J/2nDMSo47Vt1EfCNel4Awfp5RU1GWXn2ojpvwrthDBGgArLE656kEDqggxRbOOwbp G6Tnr2oqKkuCOzt1gbapGyfFNjibZ0z/qn+vHFntQlWQSdS8r0o+Qd81DyugxrisA067 Moa1D4DP3r9obZ7N5F9yu9Lb8SYaZLbz/iaGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AOqSvDv/220ElZK4anxk0YNWCj5CCT0Io67nrjmlD5rM+kUOyf38LmBdSMFKRwXDB6 56kYD/dIDgFbb7MfGRFIIXNng/1RvYhJ9+zdTozac3IeHGhT59tPY5ZtnCoPFk5oQ9n9 zpCPRhEHTuiYfgWACXhiVlWojfs8m8tU0dKOg= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Tue, 13 Apr 2010 04:16:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Apr 2010 13:16:36 +0200 Received: by 10.213.37.133 with SMTP id x5mr3042084ebd.24.1271157396358; Tue, 13 Apr 2010 04:16:36 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 11:16:43 -0000 On Tue, Apr 13, 2010 at 1:07 PM, Elwell, John wrote: >> > [JRE] In my experience, a UA behind a PBX is far more >> likely to register each AOR separately, with a separate >> contact URI for each, so there is no ambiguity when an >> inbound request arrives (no need for P-Called-Party-ID, no >> need for History-Info). >> [HE] Yes likely, but not guaranteed. Especially if a PBX supports its >> own variant of implicit registration. We can't base a specification on >> likely behavior. > JRE] In any case, that is an issue for the PBX to solve, not MARTINI. I a= m just stating what, in my limited experience, is common practice. [HE] Disagree. Your making unjustified assumptions. >> >> A PBX on the other hand that uses bulkregistration is not the >> >> last entity, but has to deliver the incoming call to the end >> >> user device. This enduser device's user may also deliver >> >> calls for multiple AOR's of the same user. >> >> P-Called-Party-Identity does not work there anymore as it >> >> will be either overwritten with a contact address or there >> >> will be two P-Called-Party-Identy values, if the PBX also >> >> implements that mechanism. (not sure if this case is defined >> >> at all) Also here the History-Info from 4244bis could be >> >> used, but it requires traversal of some more History-Info >> >> entries to find the target information. >> > [JRE] I don't see the problem. As part of bulk registration >> according to gin, the PBX will register all AORs on all its >> UAs with the SSP, registering separate contact URIs for each. >> [HE] You can not conclude that, that would enforce a company to make >> all its numbers used internally externally exposed DIDs. > [JRE] You are correct that there might be some AORs that are not DIDs, so= are not directly reachable from an SSP (only via some sort of human or aut= omated attendant service), but this is outside the scope of MARTINI, surely= ? [HE] It is in so far relevant if the mechanism chosen by martini, will have impact on such deployments. > [JRE] Current practice certainly varies in detail - that is the reason fo= r MARTINI. But the principles are the same - information in the inbound req= uest to the PBX identifies the target AOR somehow, and that is used by the = PBX to query its location service for onward routing to a UA. [HE] Somehow ;-) From john.elwell@siemens-enterprise.com Tue Apr 13 05:42:54 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277C13A6B0A for ; Tue, 13 Apr 2010 05:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJuCvBzw-ETX for ; Tue, 13 Apr 2010 05:42:52 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D07F73A6A1D for ; Tue, 13 Apr 2010 05:42:51 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1533507; Tue, 13 Apr 2010 14:42:45 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 1F4C01EB82B0; Tue, 13 Apr 2010 14:42:45 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 13 Apr 2010 14:42:45 +0200 From: "Elwell, John" To: Hans Erik van Elburg Date: Tue, 13 Apr 2010 14:42:44 +0200 Thread-Topic: [martini] Questions about draft-kaplan-martini-with-olive Thread-Index: Acra+shWRCglpuXGQN235eqlKPnycAACpzrw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 12:42:54 -0000 =20 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: 13 April 2010 12:17 > To: Elwell, John > Cc: Bernard Aboba; martini@ietf.org > Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive >=20 > On Tue, Apr 13, 2010 at 1:07 PM, Elwell, John > wrote: >=20 > >> > [JRE] In my experience, a UA behind a PBX is far more > >> likely to register each AOR separately, with a separate > >> contact URI for each, so there is no ambiguity when an > >> inbound request arrives (no need for P-Called-Party-ID, no > >> need for History-Info). > >> [HE] Yes likely, but not guaranteed. Especially if a PBX=20 > supports its > >> own variant of implicit registration. We can't base a=20 > specification on > >> likely behavior. > > JRE] In any case, that is an issue for the PBX to solve,=20 > not MARTINI. I am just stating what, in my limited=20 > experience, is common practice. > [HE] Disagree. Your making unjustified assumptions. [JRE] I fail to understand why, provided MARTINI delivers information that = allows the PBX to identify the target AOR, onward handling of this within t= he PBX should be an issue for MARTINI. >=20 > >> >> A PBX on the other hand that uses bulkregistration is not the > >> >> last entity, but has to deliver the incoming call to the end > >> >> user device. This enduser device's user may also deliver > >> >> calls for multiple AOR's of the same user. > >> >> P-Called-Party-Identity does not work there anymore as it > >> >> will be either overwritten with a contact address or there > >> >> will be two P-Called-Party-Identy values, if the PBX also > >> >> implements that mechanism. (not sure if this case is defined > >> >> at all) Also here the History-Info from 4244bis could be > >> >> used, but it requires traversal of some more History-Info > >> >> entries to find the target information. > >> > [JRE] I don't see the problem. As part of bulk registration > >> according to gin, the PBX will register all AORs on all its > >> UAs with the SSP, registering separate contact URIs for each. > >> [HE] You can not conclude that, that would enforce a=20 > company to make > >> all its numbers used internally externally exposed DIDs. > > [JRE] You are correct that there might be some AORs that=20 > are not DIDs, so are not directly reachable from an SSP (only=20 > via some sort of human or automated attendant service), but=20 > this is outside the scope of MARTINI, surely? > [HE] It is in so far relevant if the mechanism chosen by martini, will > have impact on such deployments. [JRE] Again, provided MARTINI delivers information that allows the PBX to i= dentify the target AOR, which in this case would be that of an attendant fu= nction, what else does it need to do? Delivery of additional information fo= r identifying the target beyond the attendant function has to be conducted = by some other means that is unrelated to the method by which MARTINI delive= rs the request to the attendant function, e.g., it might be done in the med= ia stream, by an INFO application, by something along the lines of draft-jo= hnston-dispatch-sip-cc-uui, etc.. Outside scope of MARTINI. >=20 > > [JRE] Current practice certainly varies in detail - that is=20 > the reason for MARTINI. But the principles are the same -=20 > information in the inbound request to the PBX identifies the=20 > target AOR somehow, and that is used by the PBX to query its=20 > location service for onward routing to a UA. > [HE] Somehow ;-) [JRE] Yes - the gin draft is one suitable mechanism. John From pkyzivat@cisco.com Tue Apr 13 06:15:02 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7025B3A68E7 for ; Tue, 13 Apr 2010 06:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.838 X-Spam-Level: X-Spam-Status: No, score=-9.838 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNQxgxooreYD for ; Tue, 13 Apr 2010 06:15:01 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4B9723A6B18 for ; Tue, 13 Apr 2010 06:14:53 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPcKxEtAZnwN/2dsb2JhbACbSHGiCJoNhQ0E X-IronPort-AV: E=Sophos;i="4.52,197,1270425600"; d="scan'208";a="101313397" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2010 13:14:47 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3DDElte008607; Tue, 13 Apr 2010 13:14:47 GMT Message-ID: <4BC46E42.2000206@cisco.com> Date: Tue, 13 Apr 2010 09:14:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> <4BC3B175.3020504@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D991@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3D991@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 13:15:02 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> >> Hans Erik van Elburg wrote: >>> An incoming INVITE carrying a SIP version of a number needs to carry >>> user=phone, otherwise it is not a number. Period. >> The user=phone thing is really very ugly - confusing and inadequate >> definition. > > Totally. A hack, really. > >> If you look at 3261, the logic for updating the location service during >> a REGISTER uses only the user part to select the entry, ignoring all the >> parameters. So while it might be possible for the server to route >> incoming requests differently based on the presence/absence of >> user=phone, you can't really have two unique entries in your location >> service for those cases. > > Right, it would break in a heart-beat. > >> However, you could have a policy that incoming requests to be routed are >> treated differently if user=phone is present. For instance, in that case >> the user part might be canonicalized - stripping out separator >> characters - before a location service dip is made. It might even reject >> values where the user part matches telephone-subscriber syntax but >> user=phone is not present. >> >> But these are policies. Its not something that MUST be done. (Unless it >> is made mandatory for martini.) > > Actually, it was my impression that since RFC 3966 said the visual-separators aren't used for URI comparison, that the Registrar processing of the REGISTER for a user=phone would remove them as part of the canonicalization step, and proxies would too as part of the location service lookup. Well, I can find nothing in 3261 section 19.1.4 (URI Comparison) that would suggest you should. Nor do I see anything in registration procedures that would suggest doing this. I'm not even certain if you would be compliant if you did so. (I expect us spec-lawyers could argue over that for a long time.) The place with the most latitude is retargeting, where you can do pretty much as you wish. > But clearly it's too brittle all around, and the reality is you have to treat "sip:+123456789@foo.com" the same as "sip:+123456789@foo.com;user=phone" unless you want things to break left and right. Yup. Once upon a time I thought you could in effect have two namespaces within your domain - one for user=phone, and another for user=ip. But I eventually realized that isn't possible. Thanks, Paul From HKaplan@acmepacket.com Tue Apr 13 09:27:11 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02A743A697D for ; Tue, 13 Apr 2010 09:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPW8Bcoeo6JY for ; Tue, 13 Apr 2010 09:27:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id F200E3A694C for ; Tue, 13 Apr 2010 09:27:09 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 13 Apr 2010 12:27:03 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 13 Apr 2010 12:27:03 -0400 From: Hadriel Kaplan To: "martini@ietf.org" Date: Tue, 13 Apr 2010 12:27:01 -0400 Thread-Topic: The Problem we're trying to solve (was Questions about draft-kaplan-martini-with-olive) Thread-Index: Acra3EsJtu/izjlhTR+Pbf5g+fVYyAAMbl9g Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [martini] The Problem we're trying to solve (was Questions about draft-kaplan-martini-with-olive) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 16:27:11 -0000 I think there's confusion about what the problem is, because people keep ra= ising issues which do not appear to be germane to the problem [draft-gin] a= ddresses. The goal of SIP-Forum's SIP-Connect 1.1 which instigated this was to suppor= t IP-PBX's in the SMB market. That market has some rather strict demands i= n terms of interoperability out-of-the-box, without separate/unique per-PBX= "rules" in the SSP, without a lot of config on the PBX itself, and with a = high expectation of things working without operator NOC/install folks havin= g to handle each new IP-PBX customer with the same level of attention/effor= t as they would a big customer or peering partner. Say what you will about 3GPP, ETSI, or IETF models - but at the end of the = day most peering and IP-PBX deployments today in any/all of those models re= quire a high degree of per-PBX configuration and customization to deploy. = That may be fine for those situations, because it's cost-justified, but for= SMB deployments it's not. So [draft-gin] is meant to address that, by specifying what a PBX sending a= REGISTER using the option-tags will minimally expect and accept. It does NOT restrict you from doing other things. All [draft-gin] does is = provide a guarantee that if the PBX sent the options-tag, that it is doing = a bulk Register and will accept requests for the AoR's of the bulk Register= to the expanded contacts. Of course the PBX may accept requests for other= URI's, but we can't possibly specify the form of all its possible URI's, n= or how they would be transformed from the SSP's URI in a programmatic/consi= stent fashion in every possible case. NOTHING else is made "illegal" by [draft-gin] - it just isn't covered by [d= raft-gin], and relies on local policy instead, and thus goes back to per-PB= X config/customization/rules. And it does NOT mean you can't use a [draft-= gin] REGISTER to do other things. It just isn't covered by the draft, so t= here's no guarantee the PBX will accept or understand your request. The question is really: does [draft-gin] cover the 95% use-case, or not?=20 -hadriel From keith.drage@alcatel-lucent.com Tue Apr 13 09:34:06 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71F1B3A690B for ; Tue, 13 Apr 2010 09:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.567 X-Spam-Level: X-Spam-Status: No, score=-5.567 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1c4BSP3sNHT for ; Tue, 13 Apr 2010 09:34:05 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 174923A688B for ; Tue, 13 Apr 2010 09:34:04 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o3DGXsjQ010589 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Apr 2010 18:33:54 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 13 Apr 2010 18:33:54 +0200 From: "DRAGE, Keith (Keith)" To: Hadriel Kaplan , "martini@ietf.org" Date: Tue, 13 Apr 2010 18:29:37 +0200 Thread-Topic: [martini] The Problem we're trying to solve (was Questions about draft-kaplan-martini-with-olive) Thread-Index: Acra3EsJtu/izjlhTR+Pbf5g+fVYyAAMbl9gAAYalwA= Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> <430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [martini] The Problem we're trying to solve (was Questions about draft-kaplan-martini-with-olive) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 16:34:06 -0000 If we are only doing this work for the "SIP-Forum" market place, then I sha= ll make an immediate request to close the working group down. Keith=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: Tuesday, April 13, 2010 5:27 PM > To: martini@ietf.org > Subject: [martini] The Problem we're trying to solve (was=20 > Questions about draft-kaplan-martini-with-olive) >=20 >=20 > I think there's confusion about what the problem is, because=20 > people keep raising issues which do not appear to be germane=20 > to the problem [draft-gin] addresses. >=20 > The goal of SIP-Forum's SIP-Connect 1.1 which instigated this=20 > was to support IP-PBX's in the SMB market. That market has=20 > some rather strict demands in terms of interoperability=20 > out-of-the-box, without separate/unique per-PBX "rules" in=20 > the SSP, without a lot of config on the PBX itself, and with=20 > a high expectation of things working without operator=20 > NOC/install folks having to handle each new IP-PBX customer=20 > with the same level of attention/effort as they would a big=20 > customer or peering partner. >=20 > Say what you will about 3GPP, ETSI, or IETF models - but at=20 > the end of the day most peering and IP-PBX deployments today=20 > in any/all of those models require a high degree of per-PBX=20 > configuration and customization to deploy. That may be fine=20 > for those situations, because it's cost-justified, but for=20 > SMB deployments it's not. >=20 > So [draft-gin] is meant to address that, by specifying what a=20 > PBX sending a REGISTER using the option-tags will minimally=20 > expect and accept. >=20 > It does NOT restrict you from doing other things. All=20 > [draft-gin] does is provide a guarantee that if the PBX sent=20 > the options-tag, that it is doing a bulk Register and will=20 > accept requests for the AoR's of the bulk Register to the=20 > expanded contacts. Of course the PBX may accept requests for=20 > other URI's, but we can't possibly specify the form of all=20 > its possible URI's, nor how they would be transformed from=20 > the SSP's URI in a programmatic/consistent fashion in every=20 > possible case. >=20 > NOTHING else is made "illegal" by [draft-gin] - it just isn't=20 > covered by [draft-gin], and relies on local policy instead,=20 > and thus goes back to per-PBX config/customization/rules. =20 > And it does NOT mean you can't use a [draft-gin] REGISTER to=20 > do other things. It just isn't covered by the draft, so=20 > there's no guarantee the PBX will accept or understand your request. >=20 > The question is really: does [draft-gin] cover the 95%=20 > use-case, or not?=20 >=20 > -hadriel >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From bruno.chatras@orange-ftgroup.com Tue Apr 13 09:36:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37AD3A68DC for ; Tue, 13 Apr 2010 09:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzX5jVD1OcYK for ; Tue, 13 Apr 2010 09:36:17 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 806433A688B for ; Tue, 13 Apr 2010 09:36:17 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0F0438B800A; Tue, 13 Apr 2010 18:35:57 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 210648B800D; Tue, 13 Apr 2010 18:35:54 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Apr 2010 18:35:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Apr 2010 18:35:28 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214101558AB5@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] The Problem we're trying to solve (was Questions about draft-kaplan-martini-with-olive) Thread-Index: Acra3EsJtu/izjlhTR+Pbf5g+fVYyAAMbl9gAAY45vA= References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> <430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail> From: To: , X-OriginalArrivalTime: 13 Apr 2010 16:35:29.0141 (UTC) FILETIME=[53E82250:01CADB27] Subject: Re: [martini] The Problem we're trying to solve (was Questions about draft-kaplan-martini-with-olive) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 16:36:18 -0000 =20 > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Hadriel Kaplan > Envoy=E9 : mardi 13 avril 2010 18:27 > =C0 : martini@ietf.org > Objet : [martini] The Problem we're trying to solve (was=20 > Questions about draft-kaplan-martini-with-olive) >=20 >=20 > I think there's confusion about what the problem is, because=20 > people keep raising issues which do not appear to be germane=20 > to the problem [draft-gin] addresses. >=20 > The goal of SIP-Forum's SIP-Connect 1.1 which instigated this=20 > was to support IP-PBX's in the SMB market. That market has=20 > some rather strict demands in terms of interoperability=20 > out-of-the-box, without separate/unique per-PBX "rules" in=20 > the SSP, without a lot of config on the PBX itself, and with=20 > a high expectation of things working without operator=20 > NOC/install folks having to handle each new IP-PBX customer=20 > with the same level of attention/effort as they would a big=20 > customer or peering partner. >=20 > Say what you will about 3GPP, ETSI, or IETF models - but at=20 > the end of the day most peering and IP-PBX deployments today=20 > in any/all of those models require a high degree of per-PBX=20 > configuration and customization to deploy. That may be fine=20 > for those situations, because it's cost-justified, but for=20 > SMB deployments it's not. >=20 > So [draft-gin] is meant to address that, by specifying what a=20 > PBX sending a REGISTER using the option-tags will minimally=20 > expect and accept. >=20 > It does NOT restrict you from doing other things. All=20 > [draft-gin] does is provide a guarantee that if the PBX sent=20 > the options-tag, that it is doing a bulk Register and will=20 > accept requests for the AoR's of the bulk Register to the=20 > expanded contacts. Of course the PBX may accept requests for=20 > other URI's, but we can't possibly specify the form of all=20 > its possible URI's, nor how they would be transformed from=20 > the SSP's URI in a programmatic/consistent fashion in every=20 > possible case. >=20 > NOTHING else is made "illegal" by [draft-gin] - it just isn't=20 > covered by [draft-gin], and relies on local policy instead,=20 > and thus goes back to per-PBX config/customization/rules. =20 > And it does NOT mean you can't use a [draft-gin] REGISTER to=20 > do other things. It just isn't covered by the draft, so=20 > there's no guarantee the PBX will accept or understand your request. >=20 > The question is really: does [draft-gin] cover the 95%=20 > use-case, or not?=20 =3D=3DBC: If you think that 95% of the use cases will not be IMS-based = and will use E.164 numbers only, the answer is probably yes. But I don't = share the same view. >=20 > -hadriel >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 From md3135@att.com Tue Apr 13 09:40:48 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42503A6993 for ; Tue, 13 Apr 2010 09:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.341 X-Spam-Level: X-Spam-Status: No, score=-106.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eATx40yONzO for ; Tue, 13 Apr 2010 09:40:47 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 974553A694C for ; Tue, 13 Apr 2010 09:40:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-11.tower-129.messagelabs.com!1271176840!12710215!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 31257 invoked from network); 13 Apr 2010 16:40:41 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Apr 2010 16:40:41 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3DGeQSg026837 for ; Tue, 13 Apr 2010 12:40:26 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3DGeOl3026793 for ; Tue, 13 Apr 2010 12:40:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Apr 2010 12:40:37 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0638A5D6@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214101558AB5@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] The Problem we're trying to solve (was Questionsabout draft-kaplan-martini-with-olive) Thread-Index: Acra3EsJtu/izjlhTR+Pbf5g+fVYyAAMbl9gAAY45vAAADB6sA== References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail><430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail> <9ECCF01B52E7AB408A7EB8535264214101558AB5@ftrdmel0.rd.francetelecom.fr> From: "DOLLY, MARTIN C (ATTLABS)" To: , , Subject: Re: [martini] The Problem we're trying to solve (was Questionsabout draft-kaplan-martini-with-olive) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 16:40:49 -0000 I support Bruno's point of view, in that the % of IMS-based deployments = would be higher. > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Hadriel Kaplan > Envoy=E9 : mardi 13 avril 2010 18:27 > =C0 : martini@ietf.org > Objet : [martini] The Problem we're trying to solve (was=20 > Questions about draft-kaplan-martini-with-olive) >=20 >=20 > I think there's confusion about what the problem is, because=20 > people keep raising issues which do not appear to be germane=20 > to the problem [draft-gin] addresses. >=20 > The goal of SIP-Forum's SIP-Connect 1.1 which instigated this=20 > was to support IP-PBX's in the SMB market. That market has=20 > some rather strict demands in terms of interoperability=20 > out-of-the-box, without separate/unique per-PBX "rules" in=20 > the SSP, without a lot of config on the PBX itself, and with=20 > a high expectation of things working without operator=20 > NOC/install folks having to handle each new IP-PBX customer=20 > with the same level of attention/effort as they would a big=20 > customer or peering partner. >=20 > Say what you will about 3GPP, ETSI, or IETF models - but at=20 > the end of the day most peering and IP-PBX deployments today=20 > in any/all of those models require a high degree of per-PBX=20 > configuration and customization to deploy. That may be fine=20 > for those situations, because it's cost-justified, but for=20 > SMB deployments it's not. >=20 > So [draft-gin] is meant to address that, by specifying what a=20 > PBX sending a REGISTER using the option-tags will minimally=20 > expect and accept. >=20 > It does NOT restrict you from doing other things. All=20 > [draft-gin] does is provide a guarantee that if the PBX sent=20 > the options-tag, that it is doing a bulk Register and will=20 > accept requests for the AoR's of the bulk Register to the=20 > expanded contacts. Of course the PBX may accept requests for=20 > other URI's, but we can't possibly specify the form of all=20 > its possible URI's, nor how they would be transformed from=20 > the SSP's URI in a programmatic/consistent fashion in every=20 > possible case. >=20 > NOTHING else is made "illegal" by [draft-gin] - it just isn't=20 > covered by [draft-gin], and relies on local policy instead,=20 > and thus goes back to per-PBX config/customization/rules. =20 > And it does NOT mean you can't use a [draft-gin] REGISTER to=20 > do other things. It just isn't covered by the draft, so=20 > there's no guarantee the PBX will accept or understand your request. >=20 > The question is really: does [draft-gin] cover the 95%=20 > use-case, or not?=20 =3D=3DBC: If you think that 95% of the use cases will not be IMS-based = and will use E.164 numbers only, the answer is probably yes. But I don't = share the same view. >=20 > -hadriel >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From HKaplan@acmepacket.com Tue Apr 13 09:53:47 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE7A3A6A04 for ; Tue, 13 Apr 2010 09:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9bNu4Dyw-S1 for ; Tue, 13 Apr 2010 09:53:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7103F3A6903 for ; Tue, 13 Apr 2010 09:53:46 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 13 Apr 2010 12:53:40 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 13 Apr 2010 12:53:40 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Tue, 13 Apr 2010 12:53:34 -0400 Thread-Topic: [martini] Questions about draft-kaplan-martini-with-olive Thread-Index: Acra3EsJtu/izjlhTR+Pbf5g+fVYyAASeaEA Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3DAD0@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 16:53:47 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Hans Erik van Elburg > Sent: Tuesday, April 13, 2010 3:38 AM >=20 > On Tue, Apr 13, 2010 at 6:16 AM, Hadriel Kaplan > wrote: > > > > I'm not so sure that request-URI re-writing is actually a design flaw > for this case. > > Ultimately, there really is a problem with leaving the Request-URI > "alone" when it goes from one authoritative domain to another. > [HE] Agree. But that is something else then choosing a mechanims that > forces you in ALL case to do such rewrite. It does NOT "force you in all cases to do a rewrite". It can't force you t= o, because you can simply ignore it. And I don't just mean you can ignore = the draft - I mean RFC 3261 allows you to do whatever you want, in section = 16.5: ... this implies that the element is responsible for the domain in the Request-URI, and the element MAY use whatever mechanism it desires to determine where to send the request. Any of these mechanisms can be modeled as accessing an abstract Location Service. This may consist of obtaining information from a location service created by a SIP Registrar, reading a database, consulting a presence server, utilizing other protocols, or simply performing an algorithmic substitution on the Request-URI. =20 So let's say you received a request for "sip:123456;foo=3Dyes@ssp.com;bar= =3Dno" and decided that you needed to send to the IP-PBX a URI of: "sip:123456;foo=3Dyes@pbx.com;bar=3Dno", but you wanted to use the Path inf= o and Contact URI learned from the [draft-gin] REGISTER. You can do that. = The original AoR URI is the SSP's, and thus it can do whatever it wants to= it. You can, for example, simply claim to have a static local policy to d= o it, which by *sheer coincidence* happens to have pre-loaded Route headers= matching the same URI's of the REGISTER Paths and Contact. As a side note, from a logical perspective you are NOT "just changing the d= omain portion", you are actually retargeting the request to a new URI, whic= h you just happened to have constructed based on an algorithm of the origin= al URI. Will it work?? Well that's the rub. How do you know the PBX knows what th= e "foo" and "bar" params mean, or what their values mean? You need to kno= w what URI syntax and semantics the PBX expects to get - essentially you ne= ed to agree on the "algorithm". Today, that "algorithm" is done by per-tru= nk configuration on both sides. That's fine for big trunks. Not so good f= or 5-line pizza shops. -hadriel From HKaplan@acmepacket.com Tue Apr 13 10:00:19 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA2B3A6944 for ; Tue, 13 Apr 2010 10:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuYERpPvpoVb for ; Tue, 13 Apr 2010 10:00:18 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1F5BD3A66B4 for ; Tue, 13 Apr 2010 10:00:18 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 13 Apr 2010 13:00:11 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 13 Apr 2010 13:00:10 -0400 From: Hadriel Kaplan To: "DOLLY, MARTIN C (ATTLABS)" , "bruno.chatras@orange-ftgroup.com" , "martini@ietf.org" Date: Tue, 13 Apr 2010 13:00:03 -0400 Thread-Topic: [martini] The Problem we're trying to solve (was Questionsabout draft-kaplan-martini-with-olive) Thread-Index: Acra3EsJtu/izjlhTR+Pbf5g+fVYyAAMbl9gAAY45vAAADB6sAAAj4dQ Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3DAD7@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail><430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail> <9ECCF01B52E7AB408A7EB8535264214101558AB5@ftrdmel0.rd.francetelecom.fr> <14C85D6CCBE92743AF33663BF5D24EBA0638A5D6@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0638A5D6@gaalpa1msgusr7e.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] The Problem we're trying to solve (was Questionsabout draft-kaplan-martini-with-olive) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 17:00:19 -0000 Of course, and so do I. I meant more that "does handling E.164 cover 95% o= f the use-cases?" My hope is that 3GPP will consider Martini's output and adopt it as well. = It already supports 2 modes for PBX trunking today: loose-route and req-uri= -replacement. This would be a third, but the nice thing is this third mode= is really just what you do for basic subscribers, and really similar to th= e req-uri-replacement mode you already support now. -hadriel > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of DOLLY, MARTIN C (ATTLABS) > Sent: Tuesday, April 13, 2010 12:41 PM >=20 > I support Bruno's point of view, in that the % of IMS-based deployments > would be higher. >=20 > > -----Message d'origine----- > > De : martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] De la part de Hadriel Kaplan > > Envoy=E9 : mardi 13 avril 2010 18:27 > > =C0 : martini@ietf.org >=20 > =3D=3DBC: If you think that 95% of the use cases will not be IMS-based an= d > will use E.164 numbers only, the answer is probably yes. But I don't shar= e > the same view. > > From HKaplan@acmepacket.com Tue Apr 13 10:03:12 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9B83A694A for ; Tue, 13 Apr 2010 10:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hfo1M+4fLffp for ; Tue, 13 Apr 2010 10:03:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1666628C115 for ; Tue, 13 Apr 2010 10:03:08 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 13 Apr 2010 13:03:02 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 13 Apr 2010 13:03:01 -0400 From: Hadriel Kaplan To: "DRAGE, Keith (Keith)" , "martini@ietf.org" Date: Tue, 13 Apr 2010 13:02:32 -0400 Thread-Topic: [martini] The Problem we're trying to solve (was Questions about draft-kaplan-martini-with-olive) Thread-Index: Acra3EsJtu/izjlhTR+Pbf5g+fVYyAAMbl9gAAYalwAAAR9JoA== Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3DAD8@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> <430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] The Problem we're trying to solve (was Questions about draft-kaplan-martini-with-olive) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 17:03:12 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of DRAGE, Keith (Keith) > Sent: Tuesday, April 13, 2010 12:30 PM > To: Hadriel Kaplan; martini@ietf.org >=20 > If we are only doing this work for the "SIP-Forum" market place, then I > shall make an immediate request to close the working group down. =20 No, you know that's not what I meant. =20 -hadriel From ietf.hanserik@gmail.com Tue Apr 13 11:29:03 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B944F3A6A87 for ; Tue, 13 Apr 2010 11:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyL0q4xfoRDn for ; Tue, 13 Apr 2010 11:29:02 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 8D9E73A6A7A for ; Tue, 13 Apr 2010 11:29:02 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so283407eyd.5 for ; Tue, 13 Apr 2010 11:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GYxd8gPITS/Vm4vfKtmsetRz0hP1P/ACoBbSvLvAoTY=; b=flcIu9+hQZb8Pv5+YZleHiSo+si8Goq7IykR8fMnG+D5fMsl9Z4hNF76h4XHa8dJFk oG5QyavkADLxYIXFlELf1siSrfYyrrNMXFj1W/I41qTOUrWKRLGag7mUUXbiWa+m3pvd h+SXyOCdKbe30MEG88B+gYA3Q0O7A8HMze1wY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fKaGPdHyIzOowtT0f2hxu4D0WKS4f9m+K7NlDcLFYXjzPmmTIW15LPKsofPWA71t5w A5jz1niv15eOBu6dvz4uk1oY+FgHo1pJHG+SzT7+eEaouQPdxAd6rLBYcSKeMtqgVLb1 E1wuBaYbhP9spT5C57ABxMxNpukVZKQMweqqU= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Tue, 13 Apr 2010 11:28:53 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3DAD0@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> <430FC6BDED356B4C8498F634416644A91A79F3DAD0@mail> Date: Tue, 13 Apr 2010 20:28:53 +0200 Received: by 10.213.44.67 with SMTP id z3mr3072809ebe.57.1271183333494; Tue, 13 Apr 2010 11:28:53 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 18:29:03 -0000 How does it help that I can ignore it? It would require the PBX to be able to signal that it wants the Registrar (location service) to return a no-op and at the same time have its Contact address added to the Route. (Utilizing 16.6 step 2 and step 6). /Hans Erik van Elburg On Tue, Apr 13, 2010 at 6:53 PM, Hadriel Kaplan wr= ote: > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Beha= lf >> Of Hans Erik van Elburg >> Sent: Tuesday, April 13, 2010 3:38 AM >> >> On Tue, Apr 13, 2010 at 6:16 AM, Hadriel Kaplan >> wrote: >> > >> > I'm not so sure that request-URI re-writing is actually a design flaw >> for this case. >> > Ultimately, there really is a problem with leaving the Request-URI >> "alone" when it goes from one authoritative domain to another. >> [HE] Agree. But that is something else then choosing a mechanims that >> forces you in ALL case to do such rewrite. > > It does NOT "force you in all cases to do a rewrite". =A0It can't force y= ou to, because you can simply ignore it. =A0And I don't just mean you can i= gnore the draft - I mean RFC 3261 allows you to do whatever you want, in se= ction 16.5: > =A0 ... this implies that the element is responsible for the > =A0 domain in the Request-URI, and the element MAY use whatever mechanism > =A0 it desires to determine where to send the request. =A0Any of these > =A0 mechanisms can be modeled as accessing an abstract Location Service. > =A0 This may consist of obtaining information from a location service > =A0 created by a SIP Registrar, reading a database, consulting a presence > =A0 server, utilizing other protocols, or simply performing an > =A0 algorithmic substitution on the Request-URI. > > So let's say you received a request for "sip:123456;foo=3Dyes@ssp.com;bar= =3Dno" and decided that you needed to send to the IP-PBX a URI of: > "sip:123456;foo=3Dyes@pbx.com;bar=3Dno", but you wanted to use the Path i= nfo and Contact URI learned from the [draft-gin] REGISTER. =A0You can do th= at. =A0The original AoR URI is the SSP's, and thus it can do whatever it wa= nts to it. =A0You can, for example, simply claim to have a static local pol= icy to do it, which by *sheer coincidence* happens to have pre-loaded Route= headers matching the same URI's of the REGISTER Paths and Contact. > > As a side note, from a logical perspective you are NOT "just changing the= domain portion", you are actually retargeting the request to a new URI, wh= ich you just happened to have constructed based on an algorithm of the orig= inal URI. > > Will it work?? =A0Well that's the rub. =A0How do you know the PBX knows w= hat the "foo" and "bar" params mean, or what their values mean? =A0 You nee= d to know what URI syntax and semantics the PBX expects to get - essentiall= y you need to agree on the "algorithm". =A0Today, that "algorithm" is done = by per-trunk configuration on both sides. =A0That's fine for big trunks. = =A0Not so good for 5-line pizza shops. > > -hadriel > From ietf.hanserik@gmail.com Tue Apr 13 11:38:54 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 915EB3A69F7 for ; Tue, 13 Apr 2010 11:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YOcyLdaEcYO for ; Tue, 13 Apr 2010 11:38:53 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 2F57F3A67EB for ; Tue, 13 Apr 2010 11:38:52 -0700 (PDT) Received: by ewy24 with SMTP id 24so1838209ewy.13 for ; Tue, 13 Apr 2010 11:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8xjDxCcVmDBJ32xg3H18N5U8gguvzJ2QGxNJQ82SJNc=; b=DcJywJbI+lBtkuEG1aYB8pe6yxHmtEBv9XGTGuAfbUCZdzoO8pfUURqlkSA9kCEDRT ULjvFi4D9byFSj3X5RQK04UnbQUVvjX8s8zosN4PzEkZsNlcp9Nkl/w7VrejpB1Fupcz 8IeHWxIngIUUZ2IhyKwEYQWGJ4uly1MKdhQiM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=r9TuXeMYthi/sEzX/Ax1xTcOZzstthL5a2+pb2+g+C8sAV/RrxPQli9kembJN/uA9s hZwKjklkNg3FVpoyulmkmcFinZXpWVna0CXbV7yiY9D9BEVo0UQe5P/kpJVDbet9ufhV RMYaBOQTNOU22YVhyazl+mj2H19r7JkVfBUzg= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Tue, 13 Apr 2010 11:38:42 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> <430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail> Date: Tue, 13 Apr 2010 20:38:42 +0200 Received: by 10.213.44.206 with SMTP id b14mr3526485ebf.45.1271183922924; Tue, 13 Apr 2010 11:38:42 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "martini@ietf.org" Subject: Re: [martini] The Problem we're trying to solve (was Questions about draft-kaplan-martini-with-olive) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 18:38:54 -0000 On Tue, Apr 13, 2010 at 6:27 PM, Hadriel Kaplan wr= ote: > > I think there's confusion about what the problem is, because people keep = raising issues which do not appear to be germane to the problem [draft-gin]= addresses. Don't think there is confusion really, there is disagreement ;-) > Say what you will about 3GPP, ETSI, or IETF models - but at the end of th= e day most peering and IP-PBX deployments today in any/all of those models = require a high degree of per-PBX configuration and customization to deploy.= =A0That may be fine for those situations, because it's cost-justified, but= for SMB deployments it's not. That is not fine for those situations. Subscription based business trunking is exactly targeting that segment. Similar motivations as are listed in martini for using registration etc. /Hans Erik From ietf.hanserik@gmail.com Tue Apr 13 11:39:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3DF428C12E for ; Tue, 13 Apr 2010 11:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9N1D2fipUYW for ; Tue, 13 Apr 2010 11:39:22 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 7966028C0D6 for ; Tue, 13 Apr 2010 11:39:22 -0700 (PDT) Received: by mail-ew0-f224.google.com with SMTP id 24so1838209ewy.13 for ; Tue, 13 Apr 2010 11:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=W16+kvbU8j7AklXdi1UVC0PSmqLqaNawQ7tNo4lCOHY=; b=tkfzVez/YxzzBhn8lTJK0gcMY8vR5ISnhnjdoGJj5yX2WLUpqRH7sFEQjTiW1b4pqb jKlTnUySS9phSwEllGV/OQ1JY68qr99WGdQXOVcXTEx97XxVIGlx++G1dJ9LKO/F/ZDF pwcoBI2/hlJqQSLZegn0E9k/VMF5/Ronb6Sg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=waysgFEwxZeN75iME2ItTehSRonSWd1GEw3SmR1ClL046tl/0ORH5pBCrSXozfTNVu 1nk8gjES8QPKUTf9GajURH6RjKcgRF211iDE0nSGP7WgM5AFDiLs7Tg7kgwPRqUpLh6v 8PIOXap2ouMKzgxLCNr9HMeNiBb+/2CiCrpGw= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Tue, 13 Apr 2010 11:39:16 -0700 (PDT) In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0638A5D6@gaalpa1msgusr7e.ugd.att.com> References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> <430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail> <9ECCF01B52E7AB408A7EB8535264214101558AB5@ftrdmel0.rd.francetelecom.fr> <14C85D6CCBE92743AF33663BF5D24EBA0638A5D6@gaalpa1msgusr7e.ugd.att.com> Date: Tue, 13 Apr 2010 20:39:16 +0200 Received: by 10.213.46.13 with SMTP id h13mr3483836ebf.83.1271183956844; Tue, 13 Apr 2010 11:39:16 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: "DOLLY, MARTIN C (ATTLABS)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: martini@ietf.org, HKaplan@acmepacket.com Subject: Re: [martini] The Problem we're trying to solve (was Questionsabout draft-kaplan-martini-with-olive) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 18:39:23 -0000 +1 /Hans Erik van Elburg On Tue, Apr 13, 2010 at 6:40 PM, DOLLY, MARTIN C (ATTLABS) wrote: > I support Bruno's point of view, in that the % of IMS-based deployments w= ould be higher. > >> -----Message d'origine----- >> De : martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] De la part de Hadriel Kaplan >> Envoy=E9 : mardi 13 avril 2010 18:27 >> =C0 : martini@ietf.org >> Objet : [martini] The Problem we're trying to solve (was >> Questions about draft-kaplan-martini-with-olive) >> >> >> I think there's confusion about what the problem is, because >> people keep raising issues which do not appear to be germane >> to the problem [draft-gin] addresses. >> >> The goal of SIP-Forum's SIP-Connect 1.1 which instigated this >> was to support IP-PBX's in the SMB market. =A0That market has >> some rather strict demands in terms of interoperability >> out-of-the-box, without separate/unique per-PBX "rules" in >> the SSP, without a lot of config on the PBX itself, and with >> a high expectation of things working without operator >> NOC/install folks having to handle each new IP-PBX customer >> with the same level of attention/effort as they would a big >> customer or peering partner. >> >> Say what you will about 3GPP, ETSI, or IETF models - but at >> the end of the day most peering and IP-PBX deployments today >> in any/all of those models require a high degree of per-PBX >> configuration and customization to deploy. =A0That may be fine >> for those situations, because it's cost-justified, but for >> SMB deployments it's not. >> >> So [draft-gin] is meant to address that, by specifying what a >> PBX sending a REGISTER using the option-tags will minimally >> expect and accept. >> >> It does NOT restrict you from doing other things. =A0All >> [draft-gin] does is provide a guarantee that if the PBX sent >> the options-tag, that it is doing a bulk Register and will >> accept requests for the AoR's of the bulk Register to the >> expanded contacts. =A0Of course the PBX may accept requests for >> other URI's, but we can't possibly specify the form of all >> its possible URI's, nor how they would be transformed from >> the SSP's URI in a programmatic/consistent fashion in every >> possible case. >> >> NOTHING else is made "illegal" by [draft-gin] - it just isn't >> covered by [draft-gin], and relies on local policy instead, >> and thus goes back to per-PBX config/customization/rules. >> And it does NOT mean you can't use a [draft-gin] REGISTER to >> do other things. =A0It just isn't covered by the draft, so >> there's no guarantee the PBX will accept or understand your request. >> >> The question is really: does [draft-gin] cover the 95% >> use-case, or not? > > =3D=3DBC: If you think that 95% of the use cases will not be IMS-based an= d will use E.164 numbers only, the answer is probably yes. But I don't shar= e the same view. >> >> -hadriel >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From richard@shockey.us Tue Apr 13 13:32:33 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F3528C125 for ; Tue, 13 Apr 2010 13:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxoHTsOGsCUy for ; Tue, 13 Apr 2010 13:32:32 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 77BAD28C157 for ; Tue, 13 Apr 2010 13:32:22 -0700 (PDT) Received: (qmail 9910 invoked by uid 0); 13 Apr 2010 20:32:17 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 13 Apr 2010 20:32:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=Sbefi0PNezg8XRqJrTgNjD60bqXhEnDkAM7LjUDDpP0Zjiz/gBltE2qjSVrdWEqOfbqV/lHxUPNDWZ8kDiZi9KtP2DrPO3ZUrsoR4MU0s3J1d8dGrG+EZx5LGo9CkdtB; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O1mmO-00078Z-AO; Tue, 13 Apr 2010 14:32:16 -0600 From: "Richard Shockey" To: "'DRAGE, Keith \(Keith\)'" , "'Hadriel Kaplan'" , References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> <430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail> In-Reply-To: Date: Tue, 13 Apr 2010 16:32:11 -0400 Message-ID: <008a01cadb48$65d84140$3188c3c0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acra3EsJtu/izjlhTR+Pbf5g+fVYyAAMbl9gAAYalwAACBh0IA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Subject: Re: [martini] The Problem we're trying to solve (was Questions about draft-kaplan-martini-with-olive) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 20:32:33 -0000 OK Keith please. I deeply respect your opinion here and am very concerned about the local number issues since it represents a profound difference in how some jurisdictions deal with E.164 number allocations. North America is increasingly DID numbering centric. But there are clear operational support issues and OPEX issues for SSP's supporting large enterprises vs SMB and the proposed MARTINI framework is trying to recognize this. It is also trying desperately address short term problems in the field while understand there may be long term solutions here. If we could bifurcate the option tag to if you see this do "foo" if you see that do "bar" we'd be a lot closer to consensus here. The lack of a clear option tag is endemic to the issues with the IMS solution vs what the SIP Forum has proposed. What some of us are convinced of there is not a "one size fits all solution". -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Tuesday, April 13, 2010 12:30 PM To: Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] The Problem we're trying to solve (was Questions about draft-kaplan-martini-with-olive) If we are only doing this work for the "SIP-Forum" market place, then I shall make an immediate request to close the working group down. Keith > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: Tuesday, April 13, 2010 5:27 PM > To: martini@ietf.org > Subject: [martini] The Problem we're trying to solve (was > Questions about draft-kaplan-martini-with-olive) > > > I think there's confusion about what the problem is, because > people keep raising issues which do not appear to be germane > to the problem [draft-gin] addresses. > > The goal of SIP-Forum's SIP-Connect 1.1 which instigated this > was to support IP-PBX's in the SMB market. That market has > some rather strict demands in terms of interoperability > out-of-the-box, without separate/unique per-PBX "rules" in > the SSP, without a lot of config on the PBX itself, and with > a high expectation of things working without operator > NOC/install folks having to handle each new IP-PBX customer > with the same level of attention/effort as they would a big > customer or peering partner. > > Say what you will about 3GPP, ETSI, or IETF models - but at > the end of the day most peering and IP-PBX deployments today > in any/all of those models require a high degree of per-PBX > configuration and customization to deploy. That may be fine > for those situations, because it's cost-justified, but for > SMB deployments it's not. > > So [draft-gin] is meant to address that, by specifying what a > PBX sending a REGISTER using the option-tags will minimally > expect and accept. > > It does NOT restrict you from doing other things. All > [draft-gin] does is provide a guarantee that if the PBX sent > the options-tag, that it is doing a bulk Register and will > accept requests for the AoR's of the bulk Register to the > expanded contacts. Of course the PBX may accept requests for > other URI's, but we can't possibly specify the form of all > its possible URI's, nor how they would be transformed from > the SSP's URI in a programmatic/consistent fashion in every > possible case. > > NOTHING else is made "illegal" by [draft-gin] - it just isn't > covered by [draft-gin], and relies on local policy instead, > and thus goes back to per-PBX config/customization/rules. > And it does NOT mean you can't use a [draft-gin] REGISTER to > do other things. It just isn't covered by the draft, so > there's no guarantee the PBX will accept or understand your request. > > The question is really: does [draft-gin] cover the 95% > use-case, or not? > > -hadriel > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From richard@shockey.us Tue Apr 13 13:47:13 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59ED03A6AB4 for ; Tue, 13 Apr 2010 13:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=-0.917, BAYES_20=-0.74, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-tmokbJJNh6 for ; Tue, 13 Apr 2010 13:47:12 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 9CFB628C172 for ; Tue, 13 Apr 2010 13:46:43 -0700 (PDT) Received: (qmail 26617 invoked by uid 0); 13 Apr 2010 20:46:38 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 13 Apr 2010 20:46:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=RPMMf7tC/J37YgVCr3YnTwCeXaJgV+cX1GWN4vxTpuDTgbqL0/BplccUDkW7eOsVntVpLBxYznlX1+SFlTbw6y0LIxIsoor1lZmRTUme1G9SCwdy99MUueBdxruFD3lK; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1O1n0H-0006Oa-GP; Tue, 13 Apr 2010 14:46:37 -0600 From: "Richard Shockey" To: "'Hans Erik van Elburg'" , "'Hadriel Kaplan'" References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> <430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail> In-Reply-To: Date: Tue, 13 Apr 2010 16:46:32 -0400 Message-ID: <009801cadb4a$671d8090$355881b0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrbOI/Cs86Ru5QBTtWfoAa+X01LagAEF70g Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: martini@ietf.org Subject: Re: [martini] The Problem we're trying to solve (was Questions about draft-kaplan-martini-with-olive) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 20:47:13 -0000 Hadriel is right here ..the whole justification for the SIP Connect investigation of this problem was to simplify the process of registering PBX's in the SMB market which IMHO is the fastest growing segment of the = SIP trunking business. We saw the problem we knew a option tag was = necessary. All of the participants in the SIP Connect process are full paid up = members of the RAI club.=20 Look guys we have to start thinking about making SIP simpler to deploy. Whether its PBX's or CUA's for the residential markets etc it needs to = work better than our current SIP architecture is designed for. Maybe a = little duct tape and bailing wire is necessary in the short term. But truth be = told ..if we don=92t start addressing simplicity in operational deployment of = SIP our common friends at Skype and Google are just going to pick us all off = at the economic margins.=20 Turning this into a SIP Forum vs IMS/ETSI cage match is not helping. = Skype will be laughing all the way to a very profitable IPO.=20 Yes this was targeted as a E.164 centric solution since DUH that=92s = what people use. Yes gin will address at least 90% of the issues noted in the field. =20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of Hans Erik van Elburg Sent: Tuesday, April 13, 2010 2:39 PM To: Hadriel Kaplan Cc: martini@ietf.org Subject: Re: [martini] The Problem we're trying to solve (was Questions about draft-kaplan-martini-with-olive) On Tue, Apr 13, 2010 at 6:27 PM, Hadriel Kaplan wrote: > > I think there's confusion about what the problem is, because people = keep raising issues which do not appear to be germane to the problem = [draft-gin] addresses. Don't think there is confusion really, there is disagreement ;-) > Say what you will about 3GPP, ETSI, or IETF models - but at the end of = the day most peering and IP-PBX deployments today in any/all of those models require a high degree of per-PBX configuration and customization to = deploy. =A0That may be fine for those situations, because it's cost-justified, = but for SMB deployments it's not. That is not fine for those situations. Subscription based business trunking is exactly targeting that segment. Similar motivations as are listed in martini for using registration etc. /Hans Erik _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From ietf.hanserik@gmail.com Tue Apr 13 14:20:41 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F314E3A6877 for ; Tue, 13 Apr 2010 14:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy4zb4ZgvIwZ for ; Tue, 13 Apr 2010 14:20:39 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id EF09528C1DC for ; Tue, 13 Apr 2010 14:19:08 -0700 (PDT) Received: by ewy24 with SMTP id 24so1947244ewy.13 for ; Tue, 13 Apr 2010 14:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=dYfc64lfvGgeESzOUd2gac39FgbjpBOo3h18IaPgd2g=; b=hGyBmVVIoKo2zFsvLjZqyi+39JQgpJZYxm1JBNyMupPRkcDg3fPHhmyb/BPFzrapn2 AJgDfheIQpzaqHvbVMth4G3eOaRwpX+emIsFCJcS/EtspCP5TETwVx2Jwj0NPkreG5r9 a8l9RxOQT2C5wqJJJGMnfE/HIzXStdbflPRrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qs7tMrQK7Dy7vTJu/4/cF+OSr5hDP6h47oUox+Vs7RRtCJ7P9uXzSFko3LLuYl928l 6oj0sIX7Kzl8hEohFtp1gSyL8lNIdzEAfbLSRs9bOIDk0U3toq2rui8pFnXJBcGV/SMi NOXpg+6Q6Q5HFTDbkvk0vP+YlZpo5bTLUskXg= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Tue, 13 Apr 2010 14:18:59 -0700 (PDT) In-Reply-To: <009801cadb4a$671d8090$355881b0$@us> References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> <430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail> <009801cadb4a$671d8090$355881b0$@us> Date: Tue, 13 Apr 2010 23:18:59 +0200 Received: by 10.213.55.2 with SMTP id s2mr3674638ebg.14.1271193539795; Tue, 13 Apr 2010 14:18:59 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Richard Shockey Content-Type: text/plain; charset=ISO-8859-1 Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] The Problem we're trying to solve (was Questions about draft-kaplan-martini-with-olive) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 21:20:41 -0000 On Tue, Apr 13, 2010 at 10:46 PM, Richard Shockey wrote: > Turning this into a SIP Forum vs IMS/ETSI cage match is not helping. > Agree very much with that, so lets cooperate and create clarity in the market. /Hans Erik From spencer@wonderhamster.org Tue Apr 13 14:45:35 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7435A3A6AB3 for ; Tue, 13 Apr 2010 14:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id So1j42e9hCBb for ; Tue, 13 Apr 2010 14:45:34 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id B9CA43A67F3 for ; Tue, 13 Apr 2010 14:45:34 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MPlgA-1O6lzq1U2c-004xLN; Tue, 13 Apr 2010 17:45:28 -0400 Message-ID: <9E2FFCE7758D44A887644A796D170573@china.huawei.com> From: "Spencer Dawkins" To: "Hans Erik van Elburg" , "Richard Shockey" References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail><430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail><009801cadb4a$671d8090$355881b0$@us> Date: Tue, 13 Apr 2010 16:45:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX18+iwq9+sPhlZR1DaJjLTLh1Ge4Dra7iEHjC8d XP24DKxDMo90qLljqUa4FpjFqKuA2obYxpruE0ZAvM4NxCgKNe /ZEEFMAyTh9UhBvrkIlpnraGqjhz02ei3p4Y7aEhf4= Cc: Hadriel Kaplan , martini@ietf.org Subject: Re: [martini] The Problem we're trying to solve (was Questionsabout draft-kaplan-martini-with-olive) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 21:45:35 -0000 Speaking as chair, >> Turning this into a SIP Forum vs IMS/ETSI cage match is not helping. >> > Agree very much with that, so lets cooperate and create clarity in the > market. That would be awesome :D Thanks, Spencer, as chair From HKaplan@acmepacket.com Tue Apr 13 18:56:17 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E46D3A6839 for ; Tue, 13 Apr 2010 18:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNqeMG8LCWyq for ; Tue, 13 Apr 2010 18:56:16 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 273273A63EC for ; Tue, 13 Apr 2010 18:56:16 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 13 Apr 2010 21:56:09 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 13 Apr 2010 21:56:09 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Tue, 13 Apr 2010 21:56:08 -0400 Thread-Topic: [martini] Questions about draft-kaplan-martini-with-olive Thread-Index: AcrbNy6KioLi5ps7SHOWdDkDvlG5SAAJMRoA Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCE9E9@mail> References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> <430FC6BDED356B4C8498F634416644A91A79F3DAD0@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Questions about draft-kaplan-martini-with-olive X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 01:56:17 -0000 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Tuesday, April 13, 2010 2:29 PM >=20 > How does it help that I can ignore it? It would require the PBX to be > able to signal that it wants the Registrar (location service) to > return a no-op and at the same time have its Contact address added to > the Route. (Utilizing 16.6 step 2 and step 6). Can I ask why do you need to? By that I mean why do you need to leave the = req-uri alone and insert a Contact as a Route header? What's the problem y= ou are solving that [draft-gin] doesn't solve for you? 'Cause I think the = answer to that may change the answer to your question. I can think of several reasons, but none for simple SMB IP-PBX's. But it c= ould easily be I'm missing something that seems obvious to you.=20 -hadriel From christer.holmberg@ericsson.com Tue Apr 13 22:30:34 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3CE828C256 for ; Tue, 13 Apr 2010 22:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C71PKupAEzXv for ; Tue, 13 Apr 2010 22:30:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 98AA828C24D for ; Tue, 13 Apr 2010 22:28:10 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-94-4bc55251473e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id DA.80.23740.15255CB4; Wed, 14 Apr 2010 07:27:46 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 14 Apr 2010 07:27:45 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Wed, 14 Apr 2010 07:27:45 +0200 From: Christer Holmberg To: Hans Erik van Elburg , "DOLLY, MARTIN C (ATTLABS)" Date: Wed, 14 Apr 2010 07:27:43 +0200 Thread-Topic: [martini] The Problem we're trying to solve (was Questionsabout draft-kaplan-martini-with-olive) Thread-Index: AcrbOKJqnpHwRsYAR1S8ifR9i4IY1gAWo3bw Message-ID: References: <430FC6BDED356B4C8498F634416644A91A79F3D99E@mail> <430FC6BDED356B4C8498F634416644A91A79F3DAB8@mail> <9ECCF01B52E7AB408A7EB8535264214101558AB5@ftrdmel0.rd.francetelecom.fr> <14C85D6CCBE92743AF33663BF5D24EBA0638A5D6@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "HKaplan@acmepacket.com" , "martini@ietf.org" Subject: Re: [martini] The Problem we're trying to solve (was Questionsabout draft-kaplan-martini-with-olive) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 05:30:34 -0000 +1 Regards, Christer=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Hans Erik van Elburg > Sent: 13. huhtikuuta 2010 21:39 > To: DOLLY, MARTIN C (ATTLABS) > Cc: martini@ietf.org; HKaplan@acmepacket.com > Subject: Re: [martini] The Problem we're trying to solve (was=20 > Questionsabout draft-kaplan-martini-with-olive) >=20 > +1 >=20 > /Hans Erik van Elburg >=20 >=20 >=20 > On Tue, Apr 13, 2010 at 6:40 PM, DOLLY, MARTIN C (ATTLABS)=20 > wrote: > > I support Bruno's point of view, in that the % of IMS-based=20 > deployments would be higher. > > > >> -----Message d'origine----- > >> De : martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] De la part de Hadriel=20 > Kaplan Envoy=E9=20 > >> : mardi 13 avril 2010 18:27 =C0 : martini@ietf.org Objet : [martini]=20 > >> The Problem we're trying to solve (was Questions about=20 > >> draft-kaplan-martini-with-olive) > >> > >> > >> I think there's confusion about what the problem is,=20 > because people=20 > >> keep raising issues which do not appear to be germane to=20 > the problem=20 > >> [draft-gin] addresses. > >> > >> The goal of SIP-Forum's SIP-Connect 1.1 which instigated=20 > this was to=20 > >> support IP-PBX's in the SMB market. =A0That market has some rather=20 > >> strict demands in terms of interoperability=20 > out-of-the-box, without=20 > >> separate/unique per-PBX "rules" in the SSP, without a lot=20 > of config=20 > >> on the PBX itself, and with a high expectation of things working=20 > >> without operator NOC/install folks having to handle each=20 > new IP-PBX=20 > >> customer with the same level of attention/effort as they=20 > would a big=20 > >> customer or peering partner. > >> > >> Say what you will about 3GPP, ETSI, or IETF models - but=20 > at the end=20 > >> of the day most peering and IP-PBX deployments today in any/all of=20 > >> those models require a high degree of per-PBX configuration and=20 > >> customization to deploy. =A0That may be fine for those situations,=20 > >> because it's cost-justified, but for SMB deployments it's not. > >> > >> So [draft-gin] is meant to address that, by specifying what a PBX=20 > >> sending a REGISTER using the option-tags will minimally expect and=20 > >> accept. > >> > >> It does NOT restrict you from doing other things. =A0All [draft-gin]=20 > >> does is provide a guarantee that if the PBX sent the options-tag,=20 > >> that it is doing a bulk Register and will accept requests for the=20 > >> AoR's of the bulk Register to the expanded contacts. =A0Of=20 > course the=20 > >> PBX may accept requests for other URI's, but we can't possibly=20 > >> specify the form of all its possible URI's, nor how they would be=20 > >> transformed from the SSP's URI in a=20 > programmatic/consistent fashion=20 > >> in every possible case. > >> > >> NOTHING else is made "illegal" by [draft-gin] - it just=20 > isn't covered=20 > >> by [draft-gin], and relies on local policy instead, and thus goes=20 > >> back to per-PBX config/customization/rules. > >> And it does NOT mean you can't use a [draft-gin] REGISTER=20 > to do other=20 > >> things. =A0It just isn't covered by the draft, so there's no=20 > guarantee=20 > >> the PBX will accept or understand your request. > >> > >> The question is really: does [draft-gin] cover the 95%=20 > use-case, or=20 > >> not? > > > > =3D=3DBC: If you think that 95% of the use cases will not be=20 > IMS-based and will use E.164 numbers only, the answer is=20 > probably yes. But I don't share the same view. > >> > >> -hadriel > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From bernarda@microsoft.com Wed Apr 14 14:56:39 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53CA928C141 for ; Wed, 14 Apr 2010 14:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZMklqYXZcra for ; Wed, 14 Apr 2010 14:56:38 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 1530A3A6825 for ; Wed, 14 Apr 2010 14:56:31 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 14 Apr 2010 14:56:24 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.0.639.21; Wed, 14 Apr 2010 14:56:24 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.99]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 14 Apr 2010 14:56:23 -0700 From: Bernard Aboba To: "martini@ietf.org" Thread-Topic: MARTINI Virtual Interim IV Thread-Index: AcrZybvOXZ7dc6uPTdmyRRGb+Lnm6QCUMzLA Date: Wed, 14 Apr 2010 21:56:23 +0000 Message-ID: <3E368C9530D1B640AA7BAE85FECC05BF0B37E7@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3E368C9530D1B640AA7BAE85FECC05BF0B37E7TK5EX14MBXW653win_" MIME-Version: 1.0 Subject: [martini] MARTINI Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 21:56:39 -0000 --_000_3E368C9530D1B640AA7BAE85FECC05BF0B37E7TK5EX14MBXW653win_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hlbjogVGh1cnNkYXksIEFwcmlsIDI5LCAyMDEwIDExOjAwIEFNLTE6MDAgUE0gKFVUQy0wODow MCkgUGFjaWZpYyBUaW1lIChVUyAmIENhbmFkYSkuDQpXaGVyZTogVEJEDQoNCk5vdGU6IFRoZSBH TVQgb2Zmc2V0IGFib3ZlIGRvZXMgbm90IHJlZmxlY3QgZGF5bGlnaHQgc2F2aW5nIHRpbWUgYWRq dXN0bWVudHMuDQoNCip+Kn4qfip+Kn4qfip+Kn4qfioNCg0KDQoNCg== --_000_3E368C9530D1B640AA7BAE85FECC05BF0B37E7TK5EX14MBXW653win_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+V2hlbjogVGh1cnNkYXksIEFwcmlsIDI5LCAyMDEw IDExOjAwIEFNLTE6MDAgUE0gKFVUQy0wODowMCkgUGFjaWZpYyBUaW1lIChVUyAmYW1wOyBDYW5h ZGEpLjwvZGl2Pg0KPGRpdj5XaGVyZTogVEJEPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRp dj5Ob3RlOiBUaGUgR01UIG9mZnNldCBhYm92ZSBkb2VzIG5vdCByZWZsZWN0IGRheWxpZ2h0IHNh dmluZyB0aW1lIGFkanVzdG1lbnRzLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Kn4q fip+Kn4qfip+Kn4qfip+KjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9zcGFuPjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_3E368C9530D1B640AA7BAE85FECC05BF0B37E7TK5EX14MBXW653win_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAwNw0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpQYWNpZmlj IFN0YW5kYXJkIFRpbWUNCkJFR0lOOlNUQU5EQVJEDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0K VFpPRkZTRVRGUk9NOi0wNzAwDQpUWk9GRlNFVFRPOi0wODAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJ TlRFUlZBTD0xO0JZREFZPTFTVTtCWU1PTlRIPTExDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRBWUxJ R0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOi0wODAwDQpUWk9GRlNF VFRPOi0wNzAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPTJTVTtCWU1PTlRI PTMNCkVORDpEQVlMSUdIVA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpPUkdBTklaRVI7 Q049QmVybmFyZCBBYm9iYTpNQUlMVE86YmVybmFyZGFAbWljcm9zb2Z0LmNvbQ0KQVRURU5ERUU7 Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1t YXJ0aW5pQGllDQogdGYub3JnOk1BSUxUTzptYXJ0aW5pQGlldGYub3JnDQpERVNDUklQVElPTjtM QU5HVUFHRT1lbi1VUzpXaGVuOiBUaHVyc2RheVwsIEFwcmlsIDI5XCwgMjAxMCAxMTowMCBBTS0x OjAwIFANCiBNIChVVEMtMDg6MDApIFBhY2lmaWMgVGltZSAoVVMgJiBDYW5hZGEpLlxuV2hlcmU6 IFRCRFxuXG5Ob3RlOiBUaGUgR01UIG9mZg0KIHNldCBhYm92ZSBkb2VzIG5vdCByZWZsZWN0IGRh eWxpZ2h0IHNhdmluZyB0aW1lIGFkanVzdG1lbnRzLlxuXG4qfip+Kn4qfip+DQogKn4qfip+Kn4q XG5cblxuXG4NClNVTU1BUlk7TEFOR1VBR0U9ZW4tVVM6TUFSVElOSSBWaXJ0dWFsIEludGVyaW0g SVYNCkRUU1RBUlQ7VFpJRD1QYWNpZmljIFN0YW5kYXJkIFRpbWU6MjAxMDA0MjlUMTEwMDAwDQpE VEVORDtUWklEPVBhY2lmaWMgU3RhbmRhcmQgVGltZToyMDEwMDQyOVQxMzAwMDANClVJRDowNDAw MDAwMDgyMDBFMDAwNzRDNUI3MTAxQTgyRTAwODAwMDAwMDAwRTAzRTZGMEY4RkQ5Q0EwMTAwMDAw MDAwMDAwMDAwMA0KIDAxMDAwMDAwMEYwODk2Q0I5NTA5NjFDNEI4QjM4ODcxMzBCRDAzNjRCDQpD TEFTUzpQVUJMSUMNClBSSU9SSVRZOjUNCkRUU1RBTVA6MjAxMDA0MTRUMjEzNjI1Wg0KVFJBTlNQ Ok9QQVFVRQ0KU1RBVFVTOkNPTkZJUk1FRA0KU0VRVUVOQ0U6MA0KTE9DQVRJT047TEFOR1VBR0U9 ZW4tVVM6VEJEDQpYLU1JQ1JPU09GVC1DRE8tQVBQVC1TRVFVRU5DRTowDQpYLU1JQ1JPU09GVC1D RE8tT1dORVJBUFBUSUQ6MjAzOTM2NzY0Mg0KWC1NSUNST1NPRlQtQ0RPLUJVU1lTVEFUVVM6VEVO VEFUSVZFDQpYLU1JQ1JPU09GVC1DRE8tSU5URU5ERURTVEFUVVM6QlVTWQ0KWC1NSUNST1NPRlQt Q0RPLUFMTERBWUVWRU5UOkZBTFNFDQpYLU1JQ1JPU09GVC1DRE8tSU1QT1JUQU5DRToxDQpYLU1J Q1JPU09GVC1DRE8tSU5TVFRZUEU6MA0KWC1NSUNST1NPRlQtRElTQUxMT1ctQ09VTlRFUjpGQUxT RQ0KQkVHSU46VkFMQVJNDQpBQ1RJT046RElTUExBWQ0KREVTQ1JJUFRJT046UkVNSU5ERVINClRS SUdHRVI7UkVMQVRFRD1TVEFSVDotUFQxNU0NCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpW Q0FMRU5EQVINCg== --_000_3E368C9530D1B640AA7BAE85FECC05BF0B37E7TK5EX14MBXW653win_-- From bernard_aboba@hotmail.com Wed Apr 14 14:59:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAA8728C14E for ; Wed, 14 Apr 2010 14:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.168 X-Spam-Level: X-Spam-Status: No, score=0.168 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTMP00gbVb5g for ; Wed, 14 Apr 2010 14:59:14 -0700 (PDT) Received: from blu0-omc2-s1.blu0.hotmail.com (blu0-omc2-s1.blu0.hotmail.com [65.55.111.76]) by core3.amsl.com (Postfix) with ESMTP id 9176728C13D for ; Wed, 14 Apr 2010 14:59:14 -0700 (PDT) Received: from BLU137-DS9 ([65.55.111.73]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 14:59:08 -0700 X-Originating-IP: [131.107.0.117] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 14 Apr 2010 14:59:01 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B97_01CADBE3.05FFA6A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrcHbDkZuJveukNQqm6e66SAhP6cg== Content-Language: en-us x-cr-puzzleid: {4BE0717F-EF81-4641-9622-374141A61C3B} x-cr-hashedpuzzle: yJY= A51Q BOX4 CuKT DBIr DtKc D8i7 GAfl GIGt GKg+ GNjS HMhG IONy I6Rw JSLU LCm2; 1; bQBhAHIAdABpAG4AaQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {4BE0717F-EF81-4641-9622-374141A61C3B}; YgBlAHIAbgBhAHIAZABhAEAAbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQA=; Wed, 14 Apr 2010 21:59:01 GMT; RAByAGEAZgB0ACAATQBBAFIAVABJAE4ASQAgAFYAaQByAHQAdQBhAGwAIABJAG4AdABlAHIAaQBtACAASQBWACAAQQBnAGUAbgBkAGEAIAAtAC0AIABUAGEAawBlACAATwBuAGUA X-OriginalArrivalTime: 14 Apr 2010 21:59:08.0058 (UTC) FILETIME=[B4E577A0:01CADC1D] Subject: [martini] Draft MARTINI Virtual Interim IV Agenda -- Take One X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 21:59:19 -0000 ------=_NextPart_000_0B97_01CADBE3.05FFA6A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI Virtual Interim IV April 29, 2010 11 AM - 1 PM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/April-Interim-IV/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: TBD Agenda 11 AM - 11:10 AM PT: Preliminaries Conference issues/debugging Note Well Note Takers Agenda bash Requirements (15 minutes) 11:10 AM - 11:25 AM PT MARTINI Requirements Update, John Elwell (15 minutes) http://tools.ietf.org/html/draft-ietf-martini-reqs Solution Updates (30 minutes) 11:25 AM - 11:55 AM PT, MARTINI with Globally Identifiable Numbers, Adam Roach (30 minutes) http://tools.ietf.org/html/draft-ietf-martini-gin Other Identifier Values (30 minutes) 11:55 AM - 12:25 PM, Other Logical Identifier Values (OLIVE), Hadriel Kaplan (30 minutes) http://tools.ietf.org/html/draft-kaplan-martini-with-olive Discussion and Wrap-up (35 minutes) 12:25 AM - 12:40 PM PT Discussion: Participants (15 minutes) 12:40 PM - 12:50 PM PT Hums: WG Chairs (10 minutes) 12:50 PM - 1 PM PT Next Steps: WG Chairs & ADs (10 minutes) ------=_NextPart_000_0B97_01CADBE3.05FFA6A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI Virtual Interim IV

April 29, 2010

11 AM – 1 PM Pacific Time

 

Conferencing Details:

Slide Presentations:  = http://www.drizzle.com/~aboba/MARTINI/April-Interim-IV/=

Jabber room:  martini at jabber.ietf.org (Please = join)

Dial in Audioconference and WebEx details:   = TBD

 

Agenda

 

11 AM - 11:10 AM PT:  Preliminaries

     Conference issues/debugging

     Note Well

     Note Takers

     Agenda bash

 

Requirements (15 minutes)

 

11:10 AM - 11:25 AM PT MARTINI Requirements Update, John Elwell (15 = minutes)

http://tools.ietf.org/html/draft-ietf-martini-reqs

 

Solution Updates (30 minutes)

 

11:25 AM – 11:55 AM PT, MARTINI with Globally Identifiable Numbers, Adam = Roach (30 minutes)

http://tools.ietf.org/html/draft-ietf-martini-gin=

 

Other Identifier Values (30 minutes)

 

11:55 AM – 12:25 PM, Other Logical Identifier Values (OLIVE), Hadriel = Kaplan (30 minutes)

http://tools.ietf.org/html/draft-kaplan-martini-with-olive

 

Discussion and Wrap-up (35 minutes)

 

12:25 AM – 12:40 PM  PT Discussion:  Participants (15 = minutes)

12:40 PM - 12:50 PM PT  Hums:  WG Chairs (10 = minutes)

12:50 PM – 1 PM PT   Next Steps:  WG Chairs & ADs (10 minutes)

 

------=_NextPart_000_0B97_01CADBE3.05FFA6A0-- From bernard_aboba@hotmail.com Wed Apr 14 15:00:11 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2CDC28C150 for ; Wed, 14 Apr 2010 15:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_50=0.001, SARE_OBFU_SPLIT_HR2=0.183] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwoeFgSWnl0o for ; Wed, 14 Apr 2010 15:00:11 -0700 (PDT) Received: from blu0-omc2-s24.blu0.hotmail.com (blu0-omc2-s24.blu0.hotmail.com [65.55.111.99]) by core3.amsl.com (Postfix) with ESMTP id 17BE128C10F for ; Wed, 14 Apr 2010 15:00:11 -0700 (PDT) Received: from BLU137-DS5 ([65.55.111.73]) by blu0-omc2-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 15:00:05 -0700 X-Originating-IP: [131.107.0.117] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 14 Apr 2010 15:00:00 -0700 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrZybvOXZ7dc6uPTdmyRRGb+Lnm6QCVBg0Q Content-Language: en-us X-OriginalArrivalTime: 14 Apr 2010 22:00:05.0305 (UTC) FILETIME=[D704AA90:01CADC1D] Subject: [martini] MARTINI Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 22:00:12 -0000 BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN=martini@ietf.org;RSVP=TRUE:mailto:martini@ietf.org CLASS:PUBLIC CREATED:20100414T220000Z DESCRIPTION:When: Thursday\, April 29\, 2010 11:00 AM-1:00 PM (UTC-08:00) P acific Time (US & Canada).\nWhere: TBD\n\nNote: The GMT offset above does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~*~*~*\n\nMA RTINI Virtual Interim IV\nApril 29\, 2010\n11 AM – 1 PM Pacific Time\n\n Conferencing Details:\nSlide Presentations: http://www.drizzle.com/~aboba /MARTINI/April-Interim-IV/\nJabber room: martini at jabber.ietf.org (Plea se join)\nDial in Audioconference and WebEx details: TBD\n\nAgenda\n\n11 AM - 11:10 AM PT: Preliminaries\n Conference issues/debugging\n Note Well\n Note Takers\n Agenda bash\n\nRequirements (15 minutes) \n\n11:10 AM - 11:25 AM PT MARTINI Requirements Update\, John Elwell (15 m inutes)\nhttp://tools.ietf.org/html/draft-ietf-martini-reqs\n\nSolution Up dates (30 minutes)\n\n11:25 AM – 11:55 AM PT\, MARTINI with Globally Ide ntifiable Numbers\, Adam Roach (30 minutes)\nhttp://tools.ietf.org/html/dr aft-ietf-martini-gin\n\nOther Identifier Values (30 minutes)\n\n11:55 AM – 12:25 PM\, Other Logical Identifier Values (OLIVE)\, Hadriel Kaplan (3 0 minutes)\nhttp://tools.ietf.org/html/draft-kaplan-martini-with-olive\n\n Discussion and Wrap-up (35 minutes)\n\n12:25 AM – 12:40 PM PT Discussio n: Participants (15 minutes)\n12:40 PM - 12:50 PM PT Hums: WG Chairs (1 0 minutes)\n12:50 PM – 1 PM PT Next Steps: WG Chairs & ADs (10 minute s)\n\n\n DTEND:20100429T200000Z DTSTAMP:20100414T220000Z DTSTART:20100429T180000Z LAST-MODIFIED:20100414T220000Z LOCATION:TBD ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:1 SUMMARY;LANGUAGE=en-us:MARTINI Virtual Interim IV TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000E03E6F0F8FD9CA01000000000000000 010000000F0896CB950961C4B8B3887130BD0364B X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Thursday\, April 29\, 2010 11:00 AM-1:00 PM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: TBD

\n\n

Note: The GMT offset above does not reflec t daylight saving time adjustments.

\n\n

*~*~*~*~*~*~*~*~*~*

\n\ n

MARTINI Virtual Interim IV

\n\n

April 29\, 2010

\n\n

11 AM – 1 PM Pacific Time

\ n\n

Conferenc ing Details:

\n\n

Slide Presentations:  http://www.drizzle.com/ ~aboba/MARTINI/April-Interim-IV/

\n\n

Jabber room:  martini at jabber.ietf.org (Please join)

\n\n

Dia l in Audioconference and WebEx details:   TBD

\n\n

Agenda

\n\n

1 1 AM - 11:10 AM PT:  Preliminaries

\n\n

     Conference issues/de bugging

\n\n

     Note Well

\n\n

     Note Takers

\n\n

     Agenda bash

\n\n

< FONT SIZE=2 FACE="Courier New">Requirements (15 minutes)

\n\n

11:10 AM - 11:25 AM PT MARTINI Requirements Update\, John Elwell (15 minutes)

\n\n

http://tools.ietf.org/html/draft-ietf-martini-reqs

\n\n

Solution Updates (30 minutes)

\n\n

11:25 AM – 11:55 AM PT\, MARTINI with Globally Identifiable Numbers\ , Adam Roach (30 minutes)

\n\n

http://tools.ietf.org/html/dra ft-ietf-martini-gin

\n\n

Other I dentifier Values (30 minutes)

\n\n

11:55 AM – 12:25 PM\, Other Logic al Identifier Values (OLIVE)\, Hadriel Kaplan (30 minutes)\n\n

http://tools.ietf.org/html/draft-kaplan-martini-with-olive

\n\n

Discussion and Wrap-up (35 min utes)

\n\n

12:25 AM – 12:40 PM  PT Discussion:  Participants (15 m inutes)

\n\n

12:40 PM - 12:50 PM PT  Hums:  WG Chairs (10 minutes)

\n\n

12:50 PM – 1 PM PT   Next Steps:  WG Chairs &\; ADs (10 mi nutes)

\n\n

\n\n< P DIR=LTR>

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-APPTSEQTIME:20100414T213625Z X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR From spencer@wonderhamster.org Wed Apr 14 15:24:45 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BA163A6A86 for ; Wed, 14 Apr 2010 15:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-kfKpoXUBHJ for ; Wed, 14 Apr 2010 15:24:43 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 8B2623A68D9 for ; Wed, 14 Apr 2010 15:24:14 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Lvlo4-1NPoPX0D3E-017qyz; Wed, 14 Apr 2010 18:24:06 -0400 Message-ID: <9A91625EB0794661AA8908669AA7087F@china.huawei.com> From: "Spencer Dawkins" To: "Bernard Aboba" , References: Date: Wed, 14 Apr 2010 17:23:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX190olcOzYtKyWvs120EXKPWKLE+5c5WtnOCTHh JjBhvvSOjmwsfuxifvLNHg79+7HkPN0T5xiqHI3rAVIJyG2kY2 4h1FV2ye4ldGbLSghz20wNAXcEY82T74/OW6ITCRfQ= Subject: Re: [martini] Draft MARTINI Virtual Interim IV Agenda -- Take One X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 22:24:45 -0000 Speaking as co-chair, And, just to keep us on the same page ... Bernard and I are limiting topics for this interim to the existing working group deliverables, the requirements draft and GIN. We're shooting for pubreq in a very short remaining period of time, and want to make sure that we have the basics covered before adjusting our focus. We plan to have another interim before IETF 78, and to include the olive/glass/regevent topics on that agenda. Next Doodle poll in 3 ... 2 ... Thanks, Spencer, as co-chair ----- Original Message ----- From: Bernard Aboba To: martini@ietf.org Sent: Wednesday, April 14, 2010 4:59 PM Subject: [martini] Draft MARTINI Virtual Interim IV Agenda -- Take One MARTINI Virtual Interim IV April 29, 2010 11 AM - 1 PM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/April-Interim-IV/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: TBD Agenda 11 AM - 11:10 AM PT: Preliminaries Conference issues/debugging Note Well Note Takers Agenda bash Requirements (15 minutes) 11:10 AM - 11:25 AM PT MARTINI Requirements Update, John Elwell (15 minutes) http://tools.ietf.org/html/draft-ietf-martini-reqs Solution Updates (30 minutes) 11:25 AM - 11:55 AM PT, MARTINI with Globally Identifiable Numbers, Adam Roach (30 minutes) http://tools.ietf.org/html/draft-ietf-martini-gin Other Identifier Values (30 minutes) 11:55 AM - 12:25 PM, Other Logical Identifier Values (OLIVE), Hadriel Kaplan (30 minutes) http://tools.ietf.org/html/draft-kaplan-martini-with-olive Discussion and Wrap-up (35 minutes) 12:25 AM - 12:40 PM PT Discussion: Participants (15 minutes) 12:40 PM - 12:50 PM PT Hums: WG Chairs (10 minutes) 12:50 PM - 1 PM PT Next Steps: WG Chairs & ADs (10 minutes) _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From bernard_aboba@hotmail.com Wed Apr 14 15:46:54 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150783A69F4 for ; Wed, 14 Apr 2010 15:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.66 X-Spam-Level: * X-Spam-Status: No, score=1.66 tagged_above=-999 required=5 tests=[AWL=-1.341, BAYES_95=3, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw8AsgBZrLXI for ; Wed, 14 Apr 2010 15:46:53 -0700 (PDT) Received: from blu0-omc2-s28.blu0.hotmail.com (blu0-omc2-s28.blu0.hotmail.com [65.55.111.103]) by core3.amsl.com (Postfix) with ESMTP id 99ABA3A672E for ; Wed, 14 Apr 2010 15:46:49 -0700 (PDT) Received: from BLU137-W15 ([65.55.111.72]) by blu0-omc2-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 15:46:43 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f2d85a86-8625-42e8-bcc0-25a4787d2540_" X-Originating-IP: [131.107.0.118] From: Bernard Aboba To: Date: Wed, 14 Apr 2010 15:46:43 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 14 Apr 2010 22:46:43.0381 (UTC) FILETIME=[5ACD2E50:01CADC24] Subject: [martini] Doodle Poll for MARTINI Virtual Interim V: third week of May, 2010 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 22:46:54 -0000 --_f2d85a86-8625-42e8-bcc0-25a4787d2540_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In addition to the Virtual Interim scheduled for April 29=2C 2010=2C we would also like to schedule a Virtual Interim during the third w= eek of May.=20 =20 Please fill out the Doodle Poll so that we can determine availability: http://www.doodle.com/66qvn4umdfgk4ee3 = --_f2d85a86-8625-42e8-bcc0-25a4787d2540_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In addition to the Virtual Interim scheduled for Apr= il 29=2C 2010=2C we would also like to schedule a Virtual Interim during the third w= eek of May.

 =3B

Please fill out the Doodle Poll so that we can deter= mine availability:

h= ttp://www.doodle.com/66qvn4umdfgk4ee3




= --_f2d85a86-8625-42e8-bcc0-25a4787d2540_-- From spencer@wonderhamster.org Thu Apr 15 13:00:55 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6BDC3A67FC for ; Thu, 15 Apr 2010 13:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[AWL=-0.735, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9p-KePhN8o2 for ; Thu, 15 Apr 2010 13:00:54 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id C7E4D28C1D1 for ; Thu, 15 Apr 2010 13:00:53 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MUHYA-1Nt3IA1R46-00RAUb; Thu, 15 Apr 2010 16:00:41 -0400 Message-ID: <808BC86DBBBC46EABB98547CF95B16C6@china.huawei.com> From: "Spencer Dawkins" To: References: Date: Thu, 15 Apr 2010 15:00:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19h6CjRxJLdPO0EZ3zqtoQYwQG9dh2Sak/OeIb ZU/bSd8mB5PU9JM9MWiULbFN9Acf2gbw2sgE+LCVcR8VZZypKP IK+ycXOUecDepfXX2+rOh+ztyTBViIulBYlQS3xQyQ= Subject: Re: [martini] Martini Virtual Interim IV: April 29, 2010 (WebEx coordinates) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 20:00:55 -0000 >From the secretariat... IETF Secretariat invites you to attend this online meeting. Topic: MARTINI WG Meeting Date: Thursday, April 29, 2010 Time: 11:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 967 753 632 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To join the online meeting (Now from iPhones too!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=133297667&UID=1122112087&RT=MiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: (This meeting does not require a password.) 4. Click "Join". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=133297667&UID=1122112087&ORT=MiM0 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (US/Canada): 1-866-699-3239 Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=133297667&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:967 753 632 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=133297667&UID=1122112087&ICS=MI&LD=1&RD=2&ST=1&SHA2=9hwQiSdADa3kRhdv3bfVQAx8peXRn2JfyRK2/iuPFY4=&RT=MiM0 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session. ----- Original Message ----- From: Bernard Aboba To: martini@ietf.org Sent: Sunday, April 11, 2010 10:52 AM Subject: [martini] Martini Virtual Interim IV: April 29, 2010 Based on the Doodle Poll, MARTINI Virtual Interim IV will take place on Thursday, April 29, 2010 from 11 AM - 1 PM Pacific Time. Details to follow. If you have Agenda items, please send them to Spencer and myself. _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From wwwrun@core3.amsl.com Fri Apr 16 08:25:26 2010 Return-Path: X-Original-To: martini@ietf.org Delivered-To: martini@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B2BC128C20C; Fri, 16 Apr 2010 08:25:22 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100416152522.B2BC128C20C@core3.amsl.com> Date: Fri, 16 Apr 2010 08:25:22 -0700 (PDT) Cc: martini@ietf.org Subject: [martini] MARTINI WG Virtual Interim Meeting X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 15:25:28 -0000 The MARTINI WG has scheduled a virtual interim on April 29, 2010 from 11 AM - 1 PM Pacific Time. Details will be available on the MARTINI WG mailing list: http://www.ietf.org/mail-archive/web/martini/current/maillist.html From trac@tools.ietf.org Fri Apr 16 10:49:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8863A6939 for ; Fri, 16 Apr 2010 10:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgAdNwm1eLS9 for ; Fri, 16 Apr 2010 10:49:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 48C1B3A695C for ; Fri, 16 Apr 2010 10:49:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O2pfB-0003ka-33; Fri, 16 Apr 2010 10:49:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Fri, 16 Apr 2010 17:49:09 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/34#comment:1 Message-ID: <085.08b84331c89f403f2bcad5f2f8b53c9a@tools.ietf.org> References: <076.5a9f5b42f6ebff8a9e66a68ecd88deff@tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <076.5a9f5b42f6ebff8a9e66a68ecd88deff@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #34: Nits in gin-01 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 17:49:30 -0000 #34: Nits in gin-01 ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: gin | Version: Severity: Active WG Document | Keywords: ------------------------------------------------+--------------------------- Comment(by john.elwell@…): Test -- Ticket URL: martini From bernard_aboba@hotmail.com Fri Apr 16 19:24:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60073A699C for ; Fri, 16 Apr 2010 19:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.308 X-Spam-Level: X-Spam-Status: No, score=0.308 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_50=0.001, SARE_OBFU_SPLIT_HR2=0.183] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jnWi9iMbZ8j for ; Fri, 16 Apr 2010 19:24:41 -0700 (PDT) Received: from blu0-omc2-s1.blu0.hotmail.com (blu0-omc2-s1.blu0.hotmail.com [65.55.111.76]) by core3.amsl.com (Postfix) with ESMTP id 941D53A6B13 for ; Fri, 16 Apr 2010 19:24:26 -0700 (PDT) Received: from BLU137-DS3 ([65.55.111.71]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Apr 2010 19:24:19 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Fri, 16 Apr 2010 19:24:17 -0700 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrZybvOXZ7dc6uPTdmyRRGb+Lnm6QEC1hJA Content-Language: en-us X-OriginalArrivalTime: 17 Apr 2010 02:24:19.0384 (UTC) FILETIME=[159CA380:01CADDD5] Subject: [martini] MARTINI Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2010 02:24:42 -0000 BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN='martini@ietf.org';RSVP=TRUE:mailto:martini@ietf.org CLASS:PUBLIC CREATED:20100417T022416Z DESCRIPTION:When: Thursday\, April 29\, 2010 11:00 AM-1:00 PM (UTC-08:00) P acific Time (US & Canada).\nWhere: Webex\n\nNote: The GMT offset above doe s not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~*~*~*\n\n From the secretariat...\n\nIETF Secretariat invites you to attend this onl ine meeting.\n\nTopic: MARTINI WG Meeting\nDate: Thursday\, April 29\, 201 0\nTime: 11:00 am\, Pacific Daylight Time (San Francisco\, GMT-07:00)\nMee ting Number: 967 753 632\nMeeting Password: (This meeting does not require a password.)\n\n\n------------------------------------------------------- \nTo join the online meeting (Now from iPhones too!) \n------------------ ------------------------------------- \n1. Go to https://workgreen.webex.c om/workgreen/j.php?ED=133297667&UID=1122112087&RT=MiM0 \n2. If requested\, enter your name and email address.\n3. If a password is required\, enter the meeting password: (This meeting does not require a password.) \n4. Cli ck "Join".\n\nTo view in other time zones or languages\, please click the link:\nhttps://workgreen.webex.com/workgreen/j.php?ED=133297667&UID=112211 2087&ORT=MiM0\n\n------------------------------------------------------- \ nTo join the audio conference only \n------------------------------------- ------------------ \nTo receive a call back\, provide your phone number wh en you join the meeting\, or call the number below and enter the access co de. \nCall-in toll-free number (US/Canada): 1-866-699-3239\nCall-in toll n umber (US/Canada): 1-408-792-6300\nGlobal call-in numbers: https://workgre en.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=133297667&tollFr ee=1 \nToll-free dialing restrictions: http://www.webex.com/pdf/tollfree_r estrictions.pdf \n\nAccess code:967 753 632\n\n--------------------------- ---------------------------- \nFor assistance \n-------------------------- ----------------------------- \n1. Go to https://workgreen.webex.com/workg reen/mc \n2. On the left navigation bar\, click "Support".\n\nTo add this meeting to your calendar program (for example Microsoft Outlook)\, click t his link: \nhttps://workgreen.webex.com/workgreen/j.php?ED=133297667&UID=1 122112087&ICS=MI&LD=1&RD=2&ST=1&SHA2=9hwQiSdADa3kRhdv3bfVQAx8peXRn2JfyRK2/ iuPFY4=&RT=MiM0\n\nThe playback of UCF (Universal Communications Format) r ich media files requires appropriate players. To view this type of rich me dia files in the meeting\, please check whether you have the players insta lled on your computer by going to https://workgreen.webex.com/workgreen/sy stemdiagnosis.php \n\nSign up for a free trial of WebEx\nhttp://www.webex. com/go/mcemfreetrial\n\nhttp://www.webex.com\n\n========================== ======================================\nAgenda\nMARTINI Virtual Interim IV \nApril 29\, 2010\n11 AM – 1 PM Pacific Time\n\nConferencing Details:\nS lide Presentations: http://www.drizzle.com/~aboba/MARTINI/April-Interim-I V/\nJabber room: martini at jabber.ietf.org (Please join)\nDial in Audioc onference and WebEx details: TBD\n\nAgenda\n\n11 AM - 11:10 AM PT: Prel iminaries\n Conference issues/debugging\n Note Well\n Note Tak ers\n Agenda bash\n\nRequirements (15 minutes)\n\n11:10 AM - 11:25 AM PT MARTINI Requirements Update\, John Elwell (15 minutes)\nhttp://tools.ie tf.org/html/draft-ietf-martini-reqs\n\nSolution Updates (30 minutes)\n\n11 :25 AM – 11:55 AM PT\, MARTINI with Globally Identifiable Numbers\, Adam Roach (30 minutes)\nhttp://tools.ietf.org/html/draft-ietf-martini-gin\n\n Other Identifier Values (30 minutes)\n\n11:55 AM – 12:25 PM\, Other Logi cal Identifier Values (OLIVE)\, Hadriel Kaplan (30 minutes)\nhttp://tools. ietf.org/html/draft-kaplan-martini-with-olive\n\nDiscussion and Wrap-up (3 5 minutes)\n\n12:25 AM – 12:40 PM PT Discussion: Participants (15 minu tes)\n12:40 PM - 12:50 PM PT Hums: WG Chairs (10 minutes)\n12:50 PM – 1 PM PT Next Steps: WG Chairs & ADs (10 minutes)\n\n\n DTEND:20100429T200000Z DTSTAMP:20100417T022416Z DTSTART:20100429T180000Z LAST-MODIFIED:20100417T022416Z LOCATION:Webex ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:2 SUMMARY;LANGUAGE=en-us:MARTINI Virtual Interim IV TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000E03E6F0F8FD9CA01000000000000000 010000000F0896CB950961C4B8B3887130BD0364B X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Thursday\, April 29\, 2010 11:00 AM-1:00 PM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: Webex

\n\n

Note: The GMT offset above does not refl ect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~*~*~*~*

\ n\n

From the secretariat...

\n\n

< SPAN LANG="en-us">IETF Secretariat invites you to attend this online meeting.

\n\n

Topic: MARTINI WG Meeting

\n\n

Date: Thursday\, April 29\, 2010

\n\n

Time: 11:00 am\, Pacific D aylight Time (San Francisco\, GMT-07:00)

\n\n

< SPAN LANG="en-us">Meeting Number: 967 753 632

\n\n

Meeting Password: (This meeting does not require a password.)

\n
\n\n

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

\n\n

To join the online meeting (Now from iPhones too!)

\n\n

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

\ n\n

1. Go to< /FONT> https://workgreen.webex.com/workgr een/j.php?ED=133297667&\;UID=1122112087&\;RT=MiM0< SPAN LANG="en-us">

\n\n

2. If requested\, enter you r name and email address.

\n\n

3. If a password is required\, ente r the meeting password: (This meeting does not require a password.)

\n\n

4. Click "\;Jo in"\;.

\n\n

To view in other time zones or languages\, please clic k the link:

\n\n

https://workgreen.webex.com/workgreen/j.php?ED=13329766 7&\;UID=1122112087&\;ORT=MiM0

\n\n

< /SPAN>--------------------------------------- ----------------

\n\n

To join the audio conference only

\n\n

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

\n\ n

To receive a call back\, provide your phone number when you join the meeting\, or cal l the number below and enter the access code.

\n\n

Call-in toll-free number (US/Canada): 1- 866-699-3239

\n\n

Call-in toll number (US/Canada): 1-408-792-6300

\n\n

< /SPAN>Global call-in numbers: < A HREF="https://workgreen.webex.com/workgreen/globalcallin.php?serviceType =MC&\;ED=133297667&\;tollFree=1">https://workgreen.webex.com/workgreen/globalcallin.php?servic eType=MC&\;ED=133297667&\;tollFree=1

\n\n

Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf

\n\n

< /SPAN>

\n\n

Access code:967 753 632

\n\n< P DIR=LTR>--------- ----------------------------------------------

\n\n

For assistance

\n\n

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

\n\n

1. Go to https://workgreen.webex.com/workgreen/mc

\n\n

2. On the left navigation bar\, click &quo t\;Support"\;.

\n\n

To add this meeting to your calendar progr am (for example Microsoft Outlook)\, click this link:

\n\n

https://work green.webex.com/workgreen/j.php?ED=133297667&\;UID=1122112087&\;ICS= MI&\;LD=1&\;RD=2&\;ST=1&\;SHA2=9hwQiSdADa3kRhdv3bfVQAx8peXRn2J fyRK2/iuPFY4=&\;RT=MiM0

\n\n

The playback of UCF (Universal Communications Fo rmat) rich media files requires appropriate players. To view this type of rich media files in the meeting\, please check whether you have the player s installed on your computer by going to https://workgreen.webex.c om/workgreen/systemdiagnosis.php

\n\n

< /P>\n\n

Sign up for a free trial of WebEx

\n\n

http://www.webex. com/go/mcemfreetrial

\n\n

http://www.webex.com

\n\n

\n\n

================================================================< /FONT>

\n\n

Agenda

\n\n

MARTINI Virtual Interim IV

\n\n< P DIR=LTR>April 29\, 20 10

\n\n

11 AM – 1 PM Pacific Time

\n\n

Conferencing Details:

\n\n

Slide Presentations:  http://www.drizzle.com/~aboba/MARTINI/A pril-Interim-IV/

\n \n

Jabber roo m:  martini at jabber.ietf.org (Please join)

\n\n

Dial in Audioconfer ence and WebEx details:   TBD

\n\n

Agenda

\n\n

11 AM - 11:10 AM PT:  Preliminaries

\n\n

     Conference issues/debugging

\n\n

     Note Well

\n\n

     Note Takers

\n\n

     Agenda bash

\n\n

Requirements (15 minutes)

\n\n

< SPAN LANG="en-us">11:10 AM - 11:25 AM PT M ARTINI Requirements Update\, John Elwell (15 minutes)

\n\ n

h ttp://tools.ietf.org/html/draft-ietf-martini-reqs

\n\n

Solution Updates (30 minutes)

\n\n

11:25 AM – 11:55 AM PT\, MARTINI with Globally Identifiable Numbers\, Adam Roach (30 minutes)

\n\n

< /SPAN>http://tools.ietf.org/html/draft-ietf-martini- gin

\n\n

Other Identifier Values (30 minutes)

\n\n

11:55 AM – 12:25 PM\, Other Logical Identifier Va lues (OLIVE)\, Hadriel Kaplan (30 minutes)

\n\n

http ://tools.ietf.org/html/draft-kaplan-martini-with-olive< /SPAN>

\n\n

Discussion and Wrap-up (35 minutes)

\n\n

1 2:25 AM – 12:40 PM  PT Discussion:  Participants (15 minutes)

\n\n

12:40 PM - 12:50 PM PT  Hums:  WG Chairs (10 minutes)

\n\n

12:50 PM – 1 PM PT   Next Steps:  WG Chairs &\; ADs (10 minutes)

\n\n

\n\n

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-APPTLASTSEQUENCE:1 X-MS-OLK-APPTSEQTIME:20100414T220000Z X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR From keith.drage@alcatel-lucent.com Sun Apr 18 06:11:34 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC393A6979 for ; Sun, 18 Apr 2010 06:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.524 X-Spam-Level: X-Spam-Status: No, score=-5.524 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8NYGlDW8Fwb for ; Sun, 18 Apr 2010 06:11:32 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 167673A6945 for ; Sun, 18 Apr 2010 06:11:31 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o3IDBDKt012055 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 18 Apr 2010 15:11:13 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sun, 18 Apr 2010 15:11:13 +0200 From: "DRAGE, Keith (Keith)" To: "trac@localhost.amsl.com" , "hkaplan@acmepacket.com" Date: Sun, 18 Apr 2010 15:11:12 +0200 Thread-Topic: [martini] #31: GIN: add text requiring Path Thread-Index: AcrZKN7gtW9j61FlRgWcOsI+CjyzXQFz0Xxg Message-ID: References: <064.da47dcd1c0e82864cfd0f4f8eec80169@tools.ietf.org> In-Reply-To: <064.da47dcd1c0e82864cfd0f4f8eec80169@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "martini@ietf.org" Subject: Re: [martini] #31: GIN: add text requiring Path X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 13:11:34 -0000 U29tZSBjb21tZW50cyBvbiB0aGlzIHByb3Bvc2VkIHRleHQ6DQoNCjEpCUl0IHNob3VsZCBiZSBj bGVhcmVyIHdoYXQgaXMgYWx0ZXJlZCBmcm9tIFJGQyAzMzI3LiBBcyBmYXIgYXMgSSBjYW4gc2Vl LCB0aGUgb25seSBjaGFuZ2UgaGVyZSBpcyB0aGF0IHRoZSBTSE9VTEQgcmVnYXJkaW5nIHRoZSB1 c2Ugb2YgdGhlIG9wdGlvbiB0YWcgaW4gU3VwcG9ydGVkIGluIGFsbCByZXF1ZXN0cyBpbiBSRkMg MzMyNyBpcyBhbHRlcmVkIHRvIGEgTVVTVCBzcGVjaWZpY2FsbHkgZm9yIHRoZSBSRUdJU1RFUiBy ZXF1ZXN0Lg0KDQoyKQlNb3ZlIHRoZSB0ZXh0ICJhbHRob3VnaCBpdCBNQVkgaWdub3JlIHRoZSBQ YXRoIGhlYWRlciBmaWVsZHMgcmV0dXJuZWQgaW4gdGhlICBSRUdJU1RFUiByZXNwb25zZSIgdG8g YSBzZXBhcmF0ZSBzZW50ZW5jZSBhdCB0aGUgZW5kIG9mIHRoZSBmaXJzdCBwYXJhZ3JhcGguIEkg Z290IGNvbmZ1c2VkIHdpdGggdGhlIGludGVycG9zaXRpb24gb2YgdGhpcyBpbiB0aGUgbWlkZGxl IG9mIGRpc2N1c3Npb24gb2Ygb3B0aW9uIHRhZ3MuIEFsc28gdGhlIE1BWSBoZXJlIGlzIGV4YWN0 bHkgdGhlIE1BWSB0aGF0IGV4aXN0cyBpbiBSRkMgMzMyNywgc28gY2hhbmdlIHRvICJhbHRob3Vn aCBpdCBNQVkgKGluIGFjY29yYW5jZSB3aXRoIFJGQyAzMzI3KSBpZ25vcmUgdGhlIFBhdGggaGVh ZGVyIGZpZWxkcyByZXR1cm5lZCBpbiB0aGUgIFJFR0lTVEVSIHJlc3BvbnNlIg0KDQpyZWdhcmRz DQoNCktlaXRoDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbWFydGlu aS1ib3VuY2VzQGlldGYub3JnIA0KPiBbbWFpbHRvOm1hcnRpbmktYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIG1hcnRpbmkgaXNzdWUgdHJhY2tlcg0KPiBTZW50OiBTdW5kYXksIEFwcmls IDExLCAyMDEwIDQ6NDEgQU0NCj4gVG86IGhrYXBsYW5AYWNtZXBhY2tldC5jb20NCj4gQ2M6IG1h cnRpbmlAaWV0Zi5vcmcNCj4gU3ViamVjdDogW21hcnRpbmldICMzMTogR0lOOiBhZGQgdGV4dCBy ZXF1aXJpbmcgUGF0aA0KPiANCj4gIzMxOiBHSU46IGFkZCB0ZXh0IHJlcXVpcmluZyBQYXRoDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IC0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0NCj4gIFJlcG9ydGVyOiAgaGthcGxhbkDigKYgICAgICAgICAgICAgICB8ICAgICAg IE93bmVyOiAgICAgICAgICAgIA0KPiAgICAgIFR5cGU6ICBlbmhhbmNlbWVudCAgICAgICAgICAg ICB8ICAgICAgU3RhdHVzOiAgbmV3ICAgICAgIA0KPiAgUHJpb3JpdHk6ICBtYWpvciAgICAgICAg ICAgICAgICAgICB8ICAgTWlsZXN0b25lOiAgbWlsZXN0b25lMQ0KPiBDb21wb25lbnQ6ICBnaW4g ICAgICAgICAgICAgICAgICAgICB8ICAgICBWZXJzaW9uOiAgMS4wICAgICAgIA0KPiAgU2V2ZXJp dHk6ICBBY3RpdmUgV0cgRG9jdW1lbnQgICAgICB8ICAgIEtleXdvcmRzOiAgICAgICAgICAgIA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiAtLS0tLS0tLS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tDQo+ICBJIGhhdmUgaGVhcmQgbm8gb2JqZWN0aW9ucyB0byByZXF1aXJpbmcgUkZD IDMzMjcgUGF0aCBpbiANCj4gR0lOLiAgSSB0aGVyZWZvcmUgIGFzayBmb3Igc2VjdGlvbiA4IGV4 YW1wbGUgbWVzc2FnZXMgdG8gYmUgDQo+IHVwZGF0ZWQgd2l0aCB0aGUgJ3BhdGgnIG9wdGlvbi0g IHRhZyBpbiB0aGUgU3VwcG9ydGVkIGhlYWRlciANCj4gZmllbGQsIGFuZCBmb3Igc29tZXRoaW5n IGxpa2UgdGhlIGZvbGxvd2luZyAgdGV4dCB0byBiZSBhZGRlZCANCj4gYWZ0ZXIgdGhlIHRoaXJk IHBhcmFncmFwaCBvZiBTZWN0aW9uIDU6DQo+IA0KPiAgPGJlZ2luPg0KPiAgVGhlIFBCWCBNVVNU IGFsc28gc3VwcG9ydCB0aGUgUGF0aCBtZWNoYW5pc20gaW4gW1JGQzMzMjddLCANCj4gYW5kIE1V U1QgIGluY2x1ZGUgYSAncGF0aCcgb3B0aW9uLXRhZyBpbiB0aGUgU3VwcG9ydGVkIGhlYWRlciAN Cj4gZmllbGQgb2YgdGhlIFJFR0lTVEVSICByZXF1ZXN0LCBhbHRob3VnaCBpdCBNQVkgaWdub3Jl IHRoZSANCj4gUGF0aCBoZWFkZXIgZmllbGRzIHJldHVybmVkIGluIHRoZSAgUkVHSVNURVIgcmVz cG9uc2UuICBUaGlzIA0KPiBpcyBuZWNlc3NhcnkgYmVjYXVzZSBQcm94aWVzIGJldHdlZW4gdGhl IFBCWCBhbmQgIHRoZSANCj4gUmVnaXN0cmFyIG1heSBuZWVkIHRvIGluc2VydCBQYXRoIGhlYWRl ciBmaWVsZCB2YWx1ZXMgaW4gdGhlIA0KPiBSRUdJU1RFUiAgcmVxdWVzdCBmb3IgdGhpcyBkb2N1 bWVudCdzIG1lY2hhbmlzbSB0byBmdW5jdGlvbiANCj4gcHJvcGVybHksIGFuZCBwZXIgIFtSRkMz MzI3XSB0aGV5IGNhbiBvbmx5IGRvIHNvIGlmIHRoZSBVQUMgDQo+IGluc2VydGVkIHRoZSBvcHRp b24tdGFnIGluIHRoZSAgU3VwcG9ydGVkIGhlYWRlciBmaWVsZC4NCj4gDQo+ICBBIFJlZ2lzdHJh ciBjb21wbGlhbnQgd2l0aCB0aGlzIGRvY3VtZW50IE1VU1Qgc3VwcG9ydCB0aGUgDQo+IFBhdGgg bWVjaGFuaXNtICBkZWZpbmVkIGluIFtSRkMzMzI3XS4NCj4gIDxlbmQ+DQo+IA0KPiAtLQ0KPiBU aWNrZXQgVVJMOiA8aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvbWFydGluaS90cmFjL3Rp Y2tldC8zMT4NCj4gbWFydGluaSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL21hcnRpbmkvPg0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbWFy dGluaSBtYWlsaW5nIGxpc3QNCj4gbWFydGluaUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hcnRpbmkNCj4g From john.elwell@siemens-enterprise.com Sun Apr 18 23:36:48 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32E2A3A6AC9 for ; Sun, 18 Apr 2010 23:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3bBFUpC+YCN for ; Sun, 18 Apr 2010 23:36:47 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 2DA003A68D5 for ; Sun, 18 Apr 2010 23:36:46 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1590446 for martini@ietf.org; Mon, 19 Apr 2010 08:36:38 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 1466C23F0278 for ; Mon, 19 Apr 2010 08:36:38 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 19 Apr 2010 08:36:38 +0200 From: "Elwell, John" To: "martini@ietf.org" Date: Mon, 19 Apr 2010 08:36:36 +0200 Thread-Topic: Missing notifications from tracker Thread-Index: AcrfiqiQSfbPFcpMT72HzBrIXBCI/w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [martini] Missing notifications from tracker X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 06:36:48 -0000 At the end of last week I discovered a fault with the tracker, whereby noti= fications were not being sent out to the MARTINI list or to individuals con= cerned. The fault has now been fixed, thanks to prompt action by Henrik. Ho= wever, the notifications have been lost. I am aware of changes to the following tickets: - requirements: #26, #20 (both closed) - gin: #34, #35, #36 (all new). John= From trac@tools.ietf.org Mon Apr 19 01:01:17 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231533A67D2 for ; Mon, 19 Apr 2010 01:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSwgMSG+1b8s for ; Mon, 19 Apr 2010 01:01:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7A5BE3A677D for ; Mon, 19 Apr 2010 01:01:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3luj-0004am-Jy; Mon, 19 Apr 2010 01:01:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com, ietf.hanserik@gmail.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 08:01:05 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/20#comment:3 Message-ID: <074.e3d69bf9a75f716950757559ff5ca629@tools.ietf.org> References: <065.606d2b6083a21b5a6fdc3bf7754c2d3e@tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <065.606d2b6083a21b5a6fdc3bf7754c2d3e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, ietf.hanserik@gmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #20: Section 3.1.2 does not decscribe an issue X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 08:01:17 -0000 #20: Section 3.1.2 does not decscribe an issue -------------------------------------+-------------------------------------- Reporter: ietf.hanserik@… | Owner: john.elwell@… Type: defect | Status: reopened Priority: minor | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------+-------------------------------------- Changes (by ietf.hanserik@…): * status: closed => reopened * resolution: wontfix => Comment: There is no agreement if the issue described in the document is really an issue, therefore we keep the issue. ???? I would rather say, it is better to remove the issue from the requirements document in that case, especially as no requirement has been derived from it. Replying to [comment:2 john.elwell@…]: > We don't seem to have any consensus to make a change, so closing. -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 14:00:10 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E7A28C101 for ; Mon, 19 Apr 2010 14:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaPofRrH2q+K for ; Mon, 19 Apr 2010 14:00:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0F78528C129 for ; Mon, 19 Apr 2010 14:00:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3y4W-0006OG-Ok; Mon, 19 Apr 2010 14:00:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 21:00:00 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/martini/trac/ticket/32#comment:1 Message-ID: <073.c98b3c6448f0bb89c575a626da4b8ec7@tools.ietf.org> References: <064.feeb3a5a70015c5019da8d1e3378776a@tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <064.feeb3a5a70015c5019da8d1e3378776a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #32: GIN: need to specify the exact AoR format being registered X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 21:00:10 -0000 #32: GIN: need to specify the exact AoR format being registered ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: adam@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Changes (by adam@…): * owner: => adam@… * status: new => assigned -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 14:00:17 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E1A128C101 for ; Mon, 19 Apr 2010 14:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQFfoPkN8kqr for ; Mon, 19 Apr 2010 14:00:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5776528C12F for ; Mon, 19 Apr 2010 14:00:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3y4d-0006PV-66; Mon, 19 Apr 2010 14:00:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 21:00:07 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/31#comment:1 Message-ID: <073.11c2eca321dcb5518530996dddd70cb4@tools.ietf.org> References: <064.da47dcd1c0e82864cfd0f4f8eec80169@tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <064.da47dcd1c0e82864cfd0f4f8eec80169@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #31: GIN: add text requiring Path X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 21:00:17 -0000 #31: GIN: add text requiring Path ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: adam@… Type: enhancement | Status: assigned Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Changes (by adam@…): * owner: => adam@… * status: new => assigned -- Ticket URL: martini From adam@nostrum.com Mon Apr 19 14:06:57 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB363A691D for ; Mon, 19 Apr 2010 14:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-oOBYzjobrU for ; Mon, 19 Apr 2010 14:06:56 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id EFCF83A67FA for ; Mon, 19 Apr 2010 14:06:54 -0700 (PDT) Received: from Orthrus-2.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3JL6cI9082066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Apr 2010 16:06:41 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BCCC5DD.1000903@nostrum.com> Date: Mon, 19 Apr 2010 16:06:37 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Kyzivat References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> <4BC3B175.3020504@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D991@mail> <4BC46E42.2000206@cisco.com> In-Reply-To: <4BC46E42.2000206@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 21:06:57 -0000 I think a large part of this comes down to what the PBX needs to happen. Ultimately, the thing it sends in its contact header field for a registration is what it needs to get back from the SSP. If its internal processing needs a ";foo=bar" parameter to properly associate the incoming URI with the bulk registration, that's really its own private business. Given that the semantics of ";user=" are so thorougly ill-defined, I don't think it makes any sense at all to special case it. As paul points out, the URI comparison rules don't really let you maintain multiple userportion namespaces, with ";user=" as your differentiator. So it really all comes down to local policy at the PBX. If the PBX needs or wants a parameter to be there on inbound URIs, it includes it in the registration. If it doesn't, it doesn't. I think a normative requiring or prohibition on ";user=" in GIN would be specification for its own sake. It definitely doesn't help interoperability in any way. /a Paul Kyzivat wrote: > Hadriel Kaplan wrote: >> >>> -----Original Message----- >>> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >>> Behalf >>> Of Paul Kyzivat >>> >>> Hans Erik van Elburg wrote: >>>> An incoming INVITE carrying a SIP version of a number needs to carry >>>> user=phone, otherwise it is not a number. Period. >>> The user=phone thing is really very ugly - confusing and inadequate >>> definition. >> >> Totally. A hack, really. >> >>> If you look at 3261, the logic for updating the location service during >>> a REGISTER uses only the user part to select the entry, ignoring all >>> the >>> parameters. So while it might be possible for the server to route >>> incoming requests differently based on the presence/absence of >>> user=phone, you can't really have two unique entries in your location >>> service for those cases. >> >> Right, it would break in a heart-beat. >> >>> However, you could have a policy that incoming requests to be routed >>> are >>> treated differently if user=phone is present. For instance, in that >>> case >>> the user part might be canonicalized - stripping out separator >>> characters - before a location service dip is made. It might even >>> reject >>> values where the user part matches telephone-subscriber syntax but >>> user=phone is not present. >>> >>> But these are policies. Its not something that MUST be done. (Unless it >>> is made mandatory for martini.) >> >> Actually, it was my impression that since RFC 3966 said the >> visual-separators aren't used for URI comparison, that the Registrar >> processing of the REGISTER for a user=phone would remove them as part >> of the canonicalization step, and proxies would too as part of the >> location service lookup. > > Well, I can find nothing in 3261 section 19.1.4 (URI Comparison) that > would suggest you should. Nor do I see anything in registration > procedures that would suggest doing this. I'm not even certain if you > would be compliant if you did so. (I expect us spec-lawyers could > argue over that for a long time.) > > The place with the most latitude is retargeting, where you can do > pretty much as you wish. > >> But clearly it's too brittle all around, and the reality is you have >> to treat "sip:+123456789@foo.com" the same as >> "sip:+123456789@foo.com;user=phone" unless you want things to break >> left and right. > > Yup. Once upon a time I thought you could in effect have two > namespaces within your domain - one for user=phone, and another for > user=ip. But I eventually realized that isn't possible. > > Thanks, > Paul > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From trac@tools.ietf.org Mon Apr 19 14:18:33 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1533A6B22 for ; Mon, 19 Apr 2010 14:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.261 X-Spam-Level: X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6C0A4LJM1AKe for ; Mon, 19 Apr 2010 14:18:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2A23C3A69A0 for ; Mon, 19 Apr 2010 14:18:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3yMI-0003Yw-VI; Mon, 19 Apr 2010 14:18:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 21:18:22 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/28#comment:1 Message-ID: <073.5296045c19acdc0f64938033449d4042@tools.ietf.org> References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 21:18:33 -0000 #28: GIN: user=phone in the Contact ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: adam@… Type: defect | Status: assigned Priority: minor | Milestone: Component: gin | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Changes (by adam@…): * owner: => adam@… * status: new => assigned Comment: Propose the following text for -01: Although it is not a special case from a protocol perspective, implementors are reminded that this behavior includes any "user" parameter on the URI. For example, if the registering PBX requires incoming messages to include a "user=phone" parameter on their Request-URI, it will include "user=phone" on the URI in the "Contact" header field of its registration. Because of the requirement on the SSP to copy parameters into the location service, it will appear on any Request-URIs that are retargeted to the PBX based on that registration. Conversely, if the registering PBX does not include a "user=phone" parameter, any SSP using the procedures defined in this document would not be at liberty to include one on the Request-URI. -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 14:21:32 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384153A6B1A for ; Mon, 19 Apr 2010 14:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD+pyscKMbhN for ; Mon, 19 Apr 2010 14:21:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 90CAB3A6B23 for ; Mon, 19 Apr 2010 14:21:01 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3yOj-0001ue-DD; Mon, 19 Apr 2010 14:20:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 21:20:53 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/29#comment:1 Message-ID: <073.c328b1927e795dc75bce261d1d27109d@tools.ietf.org> References: <064.ee2915cc34068edb5fe6157b1cd193ad@tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <064.ee2915cc34068edb5fe6157b1cd193ad@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #29: GIN: inappropriate introductory text X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 21:21:32 -0000 #29: GIN: inappropriate introductory text ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by adam@…): * status: new => closed * resolution: => fixed Comment: The proposed text will appear in the -01 version of the document. -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 14:32:31 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244333A6B31 for ; Mon, 19 Apr 2010 14:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruz-YZpUdFAo for ; Mon, 19 Apr 2010 14:32:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CB99B3A6B1F for ; Mon, 19 Apr 2010 14:32:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3yZj-0001GV-TQ; Mon, 19 Apr 2010 14:32:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 21:32:15 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/32#comment:2 Message-ID: <073.267c0a86d1ffafcd2ca5a6f1406286dd@tools.ietf.org> References: <064.feeb3a5a70015c5019da8d1e3378776a@tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <064.feeb3a5a70015c5019da8d1e3378776a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #32: GIN: need to specify the exact AoR format being registered X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 21:32:31 -0000 #32: GIN: need to specify the exact AoR format being registered ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: adam@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by adam@…): * status: assigned => closed * resolution: => fixed Comment: Added text to forthcoming -01 completely nailing down any optionality: For each of these unique rows, the AOR will be in the format that the SSP expects to receive from external parties (e.g. "sip:+12145550102@ssp.example.com"), and the corresponding Contact will be formed by adding to the REGISTER's Contact URI a user portion containing the fully-qualified, E.164-formatted phone number (including the preceding "+" symbol) and removing the "bnc" parameter. Aside from the initial "+" symbol, this E.164-formatted number MUST consist exclusively of digits from 0 through 9, and explicitly MUST NOT contain any visual separator symbols (e.g., "-", ".", "(", or ")"). The second half of this ticket (involving "user=phone") is a duplicate of ticket #28, and is being handled as part of that ticket. -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 14:40:19 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70283A68DB for ; Mon, 19 Apr 2010 14:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajgJnn4BkO3C for ; Mon, 19 Apr 2010 14:40:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1D9E53A6781 for ; Mon, 19 Apr 2010 14:40:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3yhO-0001VC-LT; Mon, 19 Apr 2010 14:40:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 21:40:10 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/31#comment:2 Message-ID: <073.c5875efa721ef3b3c640d713df9d093d@tools.ietf.org> References: <064.da47dcd1c0e82864cfd0f4f8eec80169@tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <064.da47dcd1c0e82864cfd0f4f8eec80169@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #31: GIN: add text requiring Path X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 21:40:20 -0000 #31: GIN: add text requiring Path ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: adam@… Type: enhancement | Status: closed Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by adam@…): * status: assigned => closed * resolution: => fixed Comment: Text changed slightly per discussion on list. Addressed in -01 as: Any PBX implementing the registration mechanism defined in this document MUST also support the Path mechanism defined by RFC 3327 , and MUST include a 'path' option-tag in the Supported header field of the REGISTER request (which is a stronger requirement than imposed by the Path mechanism itself). This behavior is necessary because proxies between the PBX and the Registrar may need to insert Path header field values in the REGISTER request for this document's mechanism to function properly, and per RFC 3327 , they can only do so if the UAC inserted the option-tag in the Supported header field. In accordance with the procedures defined in RFC 3327 , the PBX is allowed to ignore the Path header fields returned in the REGISTER response. A Registrar compliant with this document MUST support the Path mechanism defined in RFC 3327 . -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 14:53:33 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 450873A6963 for ; Mon, 19 Apr 2010 14:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utUBqdeLSGWe for ; Mon, 19 Apr 2010 14:53:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 93D2A3A6961 for ; Mon, 19 Apr 2010 14:53:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3yu3-0007vg-3E; Mon, 19 Apr 2010 14:53:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com, john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 21:53:15 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/34#comment:2 Message-ID: <085.c058293cb7db6c609d12d91f3ce47791@tools.ietf.org> References: <076.5a9f5b42f6ebff8a9e66a68ecd88deff@tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <076.5a9f5b42f6ebff8a9e66a68ecd88deff@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #34: Nits in gin-01 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 21:53:33 -0000 #34: Nits in gin-01 ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: gin | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------------------+--------------------------- Changes (by adam@…): * status: new => closed * resolution: => fixed Comment: A small number of these were fixed prior to draft-ietf-martini-gin-00. The following suggestion appears to be founded in different dialects of English between the reporter and the author, as the suggested change makes the sentence nonsensical to me: - Section 6: Change "based on" to "based in". An alternate suggestion is welcome. The remainder of the nits have been accepted, and will be reflected in the -01 document. -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 14:57:07 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6B3B3A68DB for ; Mon, 19 Apr 2010 14:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTn-5bY4cVmT for ; Mon, 19 Apr 2010 14:57:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1DE303A6961 for ; Mon, 19 Apr 2010 14:57:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3yxd-00081X-Ie; Mon, 19 Apr 2010 14:56:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 21:56:57 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/35#comment:1 Message-ID: <085.ee7c973fed8954db8850f127ffce0fd5@tools.ietf.org> References: <076.e6cc00fa95c4de7c0466bc499cb65491@tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <076.e6cc00fa95c4de7c0466bc499cb65491@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #35: Use of the word "extensions" X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 21:57:07 -0000 #35: Use of the word "extensions" ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: gin | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------------------+--------------------------- Changes (by adam@…): * status: new => closed * resolution: => fixed Comment: Except when talking about protocol extensions, the word "extension" has been replaced with "terminal" and "phone number" as appropriate. This change will appear in the -01 version of the document. -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 15:13:10 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD7A3A68C5 for ; Mon, 19 Apr 2010 15:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfRIcE5GlRcl for ; Mon, 19 Apr 2010 15:13:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8C3523A68DB for ; Mon, 19 Apr 2010 15:13:03 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3zD4-0006fB-V9; Mon, 19 Apr 2010 15:12:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 22:12:54 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/36#comment:1 Message-ID: <085.ceee3770ac403db1e4a00bf5702eaea8@tools.ietf.org> References: <076.62325b62ff853b30a1d2932483b01dc0@tools.ietf.org> X-Trac-Ticket-ID: 36 In-Reply-To: <076.62325b62ff853b30a1d2932483b01dc0@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #36: Reg-event package and individual extension state (section 7.2.2) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 22:13:10 -0000 #36: Reg-event package and individual extension state (section 7.2.2) ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: gin | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------------------+--------------------------- Changes (by adam@…): * status: new => closed * resolution: => fixed Comment: This is mostly correct. There's nothing that says that the SSP can't, for example, act as a presence server for the users behind the PBX. That would be something that the SSP and PBX owners would need to agree on, of course. However, you are correct in pointing out that the behavior in 7.2.2 is a reiteration of the generally expected behavior described in section 6. This will be clarified as follows: As described in section 6, the SSP will generally retarget all requests addressed to a phone number owned by a PBX to that PBX according to the mapping established at registration time. Although policy at the SSP may override this generally expected behavior, proper behavior of the registration event package requires that all "reg" event SUBSCRIBE requests are processed by the PBX. As a consequence, the requirements on an SSP for processing registration event package SUBSCRIBE requests are not left to policy. This also highlights the fact that there are no normative requirements to handle INVITE in this way -- I've added some text to section 6 to both clarify that the processing generally applies to any method, and that it is mandatory for INVITE. -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 15:13:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5283A68D3 for ; Mon, 19 Apr 2010 15:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+Cb3GaBceIK for ; Mon, 19 Apr 2010 15:13:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F20E43A6939 for ; Mon, 19 Apr 2010 15:13:40 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3zDg-0008Am-Kh; Mon, 19 Apr 2010 15:13:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 22:13:32 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/30#comment:1 Message-ID: <073.602c97c351f0fc4baf13bacfc62743dc@tools.ietf.org> References: <064.d7efde8f2663b068aaab0de8469262ae@tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <064.d7efde8f2663b068aaab0de8469262ae@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #30: GIN: change 'bulknumbercontact' to 'bnc' or some such X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 22:13:46 -0000 #30: GIN: change 'bulknumbercontact' to 'bnc' or some such ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: enhancement | Status: closed Priority: trivial | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by adam@…): * status: new => closed * resolution: => fixed Comment: Fixed in -01. -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 15:17:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ECB43A68D4 for ; Mon, 19 Apr 2010 15:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nStUXI37SYlW for ; Mon, 19 Apr 2010 15:17:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A2C993A67A3 for ; Mon, 19 Apr 2010 15:17:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3zHI-0001zY-FH; Mon, 19 Apr 2010 15:17:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 22:17:16 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/martini/trac/ticket/11#comment:1 Message-ID: <076.472395ef721cfa1b85b68bbde5e12f86@tools.ietf.org> References: <067.1dc0363dbc71855d1326f8975eb439ff@tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <067.1dc0363dbc71855d1326f8975eb439ff@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #11: Section 7.3: Outbound Analysis X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 22:17:25 -0000 #11: Section 7.3: Outbound Analysis ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: adam@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Candidate WG Document | Keywords: ---------------------------------------+------------------------------------ Changes (by adam@…): * status: new => assigned Comment: I'm accepting this ticket, but we really need someone with the proper background to provide an analysis, similar to what Dean and François did for Path and Service-Route. -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 15:21:34 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E783A6855 for ; Mon, 19 Apr 2010 15:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMtB0bI4pWco for ; Mon, 19 Apr 2010 15:21:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3BF403A68DB for ; Mon, 19 Apr 2010 15:21:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3zL3-0002iW-1l; Mon, 19 Apr 2010 15:21:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 22:21:09 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/25#comment:1 Message-ID: <075.dea27fd7cd6ae8c2c7ebb6c2cc5c50bf@tools.ietf.org> References: <066.4c051f23c1899cccfe7d75c77c3b0ff6@tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <066.4c051f23c1899cccfe7d75c77c3b0ff6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #25: Sections 7.1-7.5 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 22:21:34 -0000 #25: Sections 7.1-7.5 --------------------------------------+------------------------------------- Reporter: francois.audet@… | Owner: adam@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Resolution: worksforme Keywords: | --------------------------------------+------------------------------------- Changes (by adam@…): * status: new => closed * resolution: => worksforme Comment: I think the additional text regarding Path and Service-Route makes it much clearer what is intended by these sections -- we're wanting to ensure that neither the mechanism itself nor any associated security mechanism is disrupted. I'm closing this ticket as no longer being relevant to the text that currently exists. If anyone thinks I've done this in error, feel free to re-open the ticket -- but please include concrete text to include rather than vague suggestions when doing so. -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 15:22:29 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34F03A6963 for ; Mon, 19 Apr 2010 15:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6bL0EuPMx2E for ; Mon, 19 Apr 2010 15:22:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 350483A6942 for ; Mon, 19 Apr 2010 15:22:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3zM8-0006Dh-VN; Mon, 19 Apr 2010 15:22:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 22:22:16 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/martini/trac/ticket/7#comment:2 Message-ID: <076.35453389e6e3740fc8e1482f697a16f1@tools.ietf.org> References: <067.5ec62977838b8c119ef7c4f9e3e654c6@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <067.5ec62977838b8c119ef7c4f9e3e654c6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #7: GIN idnits X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 22:22:29 -0000 #7: GIN idnits ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: adam@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Candidate WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Changes (by adam@…): * status: assigned => closed * resolution: => fixed Comment: I have updated to using the most recent tools (xml2rfc 1.35), so the final nit should be gone with the submission of -01. -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 15:24:01 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9CE3A68F9 for ; Mon, 19 Apr 2010 15:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-dAe-xsgNrA for ; Mon, 19 Apr 2010 15:24:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5530E3A68D7 for ; Mon, 19 Apr 2010 15:24:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3zNf-0003bz-V1; Mon, 19 Apr 2010 15:23:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 22:23:51 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/24#comment:1 Message-ID: <067.9b9adf8cb29d0b0c3e48e78a3af28ce7@tools.ietf.org> References: <058.de3f68c3042d5b4ea78b5da154dfecd3@tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <058.de3f68c3042d5b4ea78b5da154dfecd3@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #24: Security Considerations X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 22:24:01 -0000 #24: Security Considerations --------------------------------+------------------------------------------- Reporter: adam@… | Owner: adam@… Type: defect | Status: assigned Priority: major | Milestone: Component: gin | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Changes (by adam@…): * status: new => assigned -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 15:28:31 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F603A6995 for ; Mon, 19 Apr 2010 15:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3M47Ow-rt72J for ; Mon, 19 Apr 2010 15:28:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2B03C3A6938 for ; Mon, 19 Apr 2010 15:28:30 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3zS1-0003Bz-Qp; Mon, 19 Apr 2010 15:28:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 22:28:21 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/27#comment:1 Message-ID: <082.70fb6b51cd967378be672e460a34001e@tools.ietf.org> References: <073.0ef4965837f22ad1a2542e2ddf89134d@tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <073.0ef4965837f22ad1a2542e2ddf89134d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #27: Add/remove AORs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 22:28:31 -0000 #27: Add/remove AORs ---------------------------------------------+------------------------------ Reporter: christer.holmberg@… | Owner: adam@… Type: defect | Status: assigned Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------------+------------------------------ Changes (by adam@…): * status: new => assigned -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 15:28:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812A43A69AD for ; Mon, 19 Apr 2010 15:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFewPpWFsbI4 for ; Mon, 19 Apr 2010 15:28:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 04EA33A6938 for ; Mon, 19 Apr 2010 15:28:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3zS9-0003C3-RL; Mon, 19 Apr 2010 15:28:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 22:28:29 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/martini/trac/ticket/14#comment:1 Message-ID: <076.e774d835914ad2b1e56808eb160f8aec@tools.ietf.org> References: <067.1bb7d53ea30d51340c8bb804b8a8feb9@tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <067.1bb7d53ea30d51340c8bb804b8a8feb9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #14: Section 8: Examples X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 22:28:42 -0000 #14: Section 8: Examples ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: adam@… Type: defect | Status: assigned Priority: minor | Milestone: milestone1 Component: gin | Version: Severity: Candidate WG Document | Keywords: ---------------------------------------+------------------------------------ Changes (by adam@…): * status: new => assigned -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 15:40:15 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1553A67AF for ; Mon, 19 Apr 2010 15:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPScj9KSx+T7 for ; Mon, 19 Apr 2010 15:40:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CB5903A67A3 for ; Mon, 19 Apr 2010 15:40:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3zdN-0003Vf-47; Mon, 19 Apr 2010 15:40:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 22:40:05 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/martini/trac/ticket/14#comment:2 Message-ID: <076.7e9c364162f5d63190dfe921b6e684b4@tools.ietf.org> References: <067.1bb7d53ea30d51340c8bb804b8a8feb9@tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <067.1bb7d53ea30d51340c8bb804b8a8feb9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #14: Section 8: Examples X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 22:40:15 -0000 #14: Section 8: Examples ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: adam@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: gin | Version: Severity: Candidate WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Changes (by adam@…): * status: assigned => closed * resolution: => fixed Comment: Plans for fleshing out have been scaled back and implemented. Added "Proxy-Require: gin" and "Supported: path", as detailed in normative statements elsewhere in the document. Changes to appear in -01 -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 15:47:05 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C793A6880 for ; Mon, 19 Apr 2010 15:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pdsh9So+nAkl for ; Mon, 19 Apr 2010 15:47:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 761963A681F for ; Mon, 19 Apr 2010 15:47:01 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O3zjx-0008NP-3T; Mon, 19 Apr 2010 15:46:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 19 Apr 2010 22:46:53 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/martini/trac/ticket/27#comment:2 Message-ID: <082.fc53f08bc584e98a2c398646e3088347@tools.ietf.org> References: <073.0ef4965837f22ad1a2542e2ddf89134d@tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <073.0ef4965837f22ad1a2542e2ddf89134d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #27: Add/remove AORs X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 22:47:05 -0000 #27: Add/remove AORs ---------------------------------------------+------------------------------ Reporter: christer.holmberg@… | Owner: adam@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------------+------------------------------ Changes (by adam@…): * status: assigned => closed * resolution: => fixed Comment: Clarifying in -01: Although the SSP treats this registration as a number of discrete rows for the purpose of retargeting incoming requests, the renewal, expiration, and removal of these rows is bound to the registered "bnc" contact. In particular, this means that REGISTER requests that attempt to de-register a single phone number that has been implicitly registered MUST NOT remove that phone number from the bulk registration. A further implication of this property is that an individual extension that is implicitly registered may also be explicitly registered using a normal, non-bulk registration (subject to SSP policy). If such a registration exists, it is refreshed independently of the bulk registration, and is not removed when the bulk registration is removed. -- Ticket URL: martini From root@core3.amsl.com Mon Apr 19 16:00:01 2010 Return-Path: X-Original-To: martini@ietf.org Delivered-To: martini@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E53B63A69D0; Mon, 19 Apr 2010 16:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100419230001.E53B63A69D0@core3.amsl.com> Date: Mon, 19 Apr 2010 16:00:01 -0700 (PDT) Cc: martini@ietf.org Subject: [martini] I-D Action:draft-ietf-martini-gin-01.txt X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 23:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple AoR reachabiliTy InformatioN Indication Working Group of the IETF. Title : Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) Author(s) : A. Roach Filename : draft-ietf-martini-gin-01.txt Pages : 22 Date : 2010-04-19 This document defines a mechanism by which a SIP server acting as a traditional Private Branch Exchange (PBX) can register with a SIP Service Provider (SSP) to receive phone calls for terminals designated by phone numbers. In order to function properly, this mechanism relies on the fact that the phone numbers are fully qualified and globally unique. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-martini-gin-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-19155351.I-D@ietf.org> --NextPart-- From adam@nostrum.com Mon Apr 19 16:06:07 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F943A67EC for ; Mon, 19 Apr 2010 16:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErF0VoO3KtEF for ; Mon, 19 Apr 2010 16:06:06 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 5E6273A67E3 for ; Mon, 19 Apr 2010 16:06:06 -0700 (PDT) Received: from Orthrus-2.local (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3JN5tW8091704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Apr 2010 18:05:55 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BCCE1D3.2020806@nostrum.com> Date: Mon, 19 Apr 2010 18:05:55 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "martini@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [martini] New Version of GIN X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 23:06:07 -0000 I have produced a new version of GIN that I beleive addresses most of the tickets that had been opened (with only three exceptions, described below): http://www.ietf.org/id/draft-ietf-martini-gin-01.txt Changes from -00 are here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-martini-gin-01.txt This version includes a proposed resolution to the "user=phone" issue, based on the discussions in Anaheim. I have, however, left the ticket open, as there has been ongoing discussion after Anaheim that indicates that we may not yet have concensus in this area. The text currently in section 5 is my attempt to provide text for further crafting: Although it is not a special case from a protocol perspective, implementors are reminded that this behavior includes any "user" parameter on the URI. For example, if the registering PBX requires incoming messages to include a "user=phone" parameter on their Request-URI, it will include "user=phone" on the URI in the "Contact" header field of its registration. Because of the requirement on the SSP to copy parameters into the location service, it will appear on any Request-URIs that are retargeted to the PBX based on that registration. Conversely, if the registering PBX does not include a "user=phone" parameter, any SSP using the procedures defined in this document would not be at liberty to include one on the Request-URI. Comments and suggestions for improvements are welcome. The other two open issues entail the security implications of multiple users being registered with a single REGISTER request, and an analysis of the Outbound mechanism as it interacts with GIN. The first one is waiting on the second, which is in turn waiting on a qualified volunteer to perform the analysis. Aside from these three open tickets, I am aware of no constructive requests for changes to the document. Participants who feel otherwise should feel free to register their issues in the tracker. /a From ietf.hanserik@gmail.com Mon Apr 19 16:45:51 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8009E3A68C2 for ; Mon, 19 Apr 2010 16:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1rnbQGMMUSf for ; Mon, 19 Apr 2010 16:45:50 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 702773A6897 for ; Mon, 19 Apr 2010 16:45:50 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so325290eyf.51 for ; Mon, 19 Apr 2010 16:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zE9AJsr8AoR25St9oVgekdKPgwbkT/+xQ+uWVHTSHyg=; b=wpdkww4NUxvEoPvzRCFy0CnTUUDiNnl92e9AHCa/NGDj+lWhQMjT5IMKM5XUYwkzi7 FPfuQ76s752augBHDX/FoBgJPCEI0erInuYPP2GZp27+DrySIgyJ2HwsNEAnsy8tVrxy hWacFiqo60h/QQ3JLw6sDbnBniWjm2CMmy/8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uCIM4RCfymRdVbQNlxombEkfOSN8+N+9vsFUmVDbQrY8ZcER8RT8zPDR6/Z5sG1br3 ZokGEt0msc6ACrztJCF0DV77AlzS0MMvFjcvOBumTny28yqUrv8IQFxsM7HcxGpXp23O oBPGGkRaril5VpAx6cmFTsXGXlMH6ZLA8ztc8= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Mon, 19 Apr 2010 16:45:38 -0700 (PDT) In-Reply-To: <085.ee7c973fed8954db8850f127ffce0fd5@tools.ietf.org> References: <076.e6cc00fa95c4de7c0466bc499cb65491@tools.ietf.org> <085.ee7c973fed8954db8850f127ffce0fd5@tools.ietf.org> Date: Tue, 20 Apr 2010 01:45:38 +0200 Received: by 10.213.73.65 with SMTP id p1mr2982209ebj.65.1271720738921; Mon, 19 Apr 2010 16:45:38 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Adam Roach Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: martini@ietf.org Subject: Re: [martini] #35: Use of the word "extensions" X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 23:45:51 -0000 Hi Adam, Wouldn't UA or UAS not be more appropriate terminology in a SIP document instead of terminal? Further the cases where replacement with phone number has taken place, while correct when only facing telephone numbers, it will make it harder to extend the mechanism with other type of AOR's. Suggest we use AOR instead. /Hans Erik van Elburg On Mon, Apr 19, 2010 at 11:56 PM, martini issue tracker wrote: > #35: Use of the word "extensions" > ------------------------------------------------+------------------------= --- > =A0Reporter: =A0john.elwell@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 | =A0 =A0 =A0 =A0Owner: > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 Status: =A0closed > =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 | =A0 =A0Milestone: =A0milestone1 > Component: =A0gin =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 | =A0 =A0 =A0Version: > =A0Severity: =A0Active WG Document =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 Resolution: =A0fixed > =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0| > ------------------------------------------------+------------------------= --- > Changes (by adam@=85): > > =A0* status: =A0new =3D> closed > =A0* resolution: =A0=3D> fixed > > > Comment: > > =A0Except when talking about protocol extensions, the word "extension" ha= s > =A0been replaced with "terminal" and "phone number" as appropriate. This > =A0change will appear in the -01 version of the document. > > -- > Ticket URL: > martini > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From adam@nostrum.com Mon Apr 19 17:39:24 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53503A6902 for ; Mon, 19 Apr 2010 17:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+fEyqQfzqP0 for ; Mon, 19 Apr 2010 17:39:21 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 35DF13A689B for ; Mon, 19 Apr 2010 17:39:20 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3K0d8NJ098428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Apr 2010 19:39:09 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BCCF7AC.8040702@nostrum.com> Date: Mon, 19 Apr 2010 19:39:08 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hans Erik van Elburg References: <076.e6cc00fa95c4de7c0466bc499cb65491@tools.ietf.org> <085.ee7c973fed8954db8850f127ffce0fd5@tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] #35: Use of the word "extensions" X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 00:39:25 -0000 Both good points. I'll re-open this for -02. /a On 4/19/10 18:45, Apr 19, Hans Erik van Elburg wrote: > Hi Adam, > > Wouldn't UA or UAS not be more appropriate terminology in a SIP > document instead of terminal? > > Further the cases where replacement with phone number has taken place, > while correct when only facing telephone numbers, it will make it > harder to extend the mechanism with other type of AOR's. Suggest we > use AOR instead. > > /Hans Erik van Elburg > > On Mon, Apr 19, 2010 at 11:56 PM, martini issue tracker > wrote: > >> #35: Use of the word "extensions" >> ------------------------------------------------+--------------------------- >> Reporter: john.elwell@… | Owner: >> Type: defect | Status: closed >> Priority: minor | Milestone: milestone1 >> Component: gin | Version: >> Severity: Active WG Document | Resolution: fixed >> Keywords: | >> ------------------------------------------------+--------------------------- >> Changes (by adam@…): >> >> * status: new => closed >> * resolution: => fixed >> >> >> Comment: >> >> Except when talking about protocol extensions, the word "extension" has >> been replaced with "terminal" and "phone number" as appropriate. This >> change will appear in the -01 version of the document. >> >> -- >> Ticket URL: >> martini >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> >> From trac@tools.ietf.org Mon Apr 19 17:40:22 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251EA3A6860 for ; Mon, 19 Apr 2010 17:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luwiLP+RL3sO for ; Mon, 19 Apr 2010 17:40:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B63633A689B for ; Mon, 19 Apr 2010 17:40:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O41Vc-00072B-De; Mon, 19 Apr 2010 17:40:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Tue, 20 Apr 2010 00:40:12 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/35#comment:2 Message-ID: <085.60305c3d1fdd9240f967ac3a8fadc749@tools.ietf.org> References: <076.e6cc00fa95c4de7c0466bc499cb65491@tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <076.e6cc00fa95c4de7c0466bc499cb65491@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #35: Use of the word "extensions" X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 00:40:22 -0000 #35: Use of the word "extensions" ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: Type: defect | Status: reopened Priority: minor | Milestone: milestone1 Component: gin | Version: Severity: Active WG Document | Resolution: Keywords: | ------------------------------------------------+--------------------------- Changes (by adam@…): * status: closed => reopened * resolution: fixed => Comment: From Hans Erik van Elberg, via the MARTINI mailing list: Hi Adam, Wouldn't UA or UAS not be more appropriate terminology in a SIP document instead of terminal? Further the cases where replacement with phone number has taken place, while correct when only facing telephone numbers, it will make it harder to extend the mechanism with other type of AOR's. Suggest we use AOR instead. /Hans Erik van Elburg -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 17:40:50 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF873A689B for ; Mon, 19 Apr 2010 17:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMG-bsu4Jt0r for ; Mon, 19 Apr 2010 17:40:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6DBEF3A6860 for ; Mon, 19 Apr 2010 17:40:49 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O41W5-00074v-70; Mon, 19 Apr 2010 17:40:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Tue, 20 Apr 2010 00:40:41 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/35#comment:3 Message-ID: <085.f7ab907d5b7107e0bffe7d11c6e15a13@tools.ietf.org> References: <076.e6cc00fa95c4de7c0466bc499cb65491@tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <076.e6cc00fa95c4de7c0466bc499cb65491@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #35: Use of the word "extensions" X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 00:40:50 -0000 #35: Use of the word "extensions" ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: adam@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: gin | Version: Severity: Active WG Document | Resolution: Keywords: | ------------------------------------------------+--------------------------- Changes (by adam@…): * owner: => adam@… * status: reopened => new -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 19 17:41:20 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC3AB3A6938 for ; Mon, 19 Apr 2010 17:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opryOqcLSeoJ for ; Mon, 19 Apr 2010 17:41:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 17E753A6860 for ; Mon, 19 Apr 2010 17:41:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O41WY-00076H-S7; Mon, 19 Apr 2010 17:41:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Tue, 20 Apr 2010 00:41:10 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/35#comment:4 Message-ID: <085.b14611391977118c8fe72572bda59e78@tools.ietf.org> References: <076.e6cc00fa95c4de7c0466bc499cb65491@tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <076.e6cc00fa95c4de7c0466bc499cb65491@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #35: Use of the word "extensions" X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 00:41:20 -0000 #35: Use of the word "extensions" ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: adam@… Type: defect | Status: assigned Priority: minor | Milestone: milestone1 Component: gin | Version: Severity: Active WG Document | Resolution: Keywords: | ------------------------------------------------+--------------------------- Changes (by adam@…): * status: new => assigned Comment: These both seem like reasonable replacements for a SIP-centric document. -- Ticket URL: martini From john.elwell@siemens-enterprise.com Mon Apr 19 23:08:08 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB903A6A8C for ; Mon, 19 Apr 2010 23:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ho7AGb7wFTRt for ; Mon, 19 Apr 2010 23:08:06 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 760113A6A7B for ; Mon, 19 Apr 2010 23:08:01 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1605711; Tue, 20 Apr 2010 08:07:49 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 5BD8D23F0278; Tue, 20 Apr 2010 08:07:49 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 20 Apr 2010 08:07:49 +0200 From: "Elwell, John" To: "trac@localhost.localdomain" , "adam@nostrum.com" Date: Tue, 20 Apr 2010 08:07:47 +0200 Thread-Topic: [martini] #34: Nits in gin-01 Thread-Index: AcrgCrvwFPp3ZZ04RFCn35eyMJ5RmAAROoDw Message-ID: References: <076.5a9f5b42f6ebff8a9e66a68ecd88deff@tools.ietf.org> <085.c058293cb7db6c609d12d91f3ce47791@tools.ietf.org> In-Reply-To: <085.c058293cb7db6c609d12d91f3ce47791@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] #34: Nits in gin-01 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 06:08:08 -0000 =20 > -----Original Message----- > From: martini issue tracker [mailto:trac@tools.ietf.org]=20 > Sent: 19 April 2010 22:53 > To: adam@nostrum.com; Elwell, John > Cc: martini@ietf.org > Subject: Re: [martini] #34: Nits in gin-01 >=20 > #34: Nits in gin-01 > ------------------------------------------------+------------- > -------------- > Reporter: john.elwell@... | =20 > Owner: =20 > Type: defect | =20 > Status: closed =20 > Priority: minor | =20 > Milestone: milestone1 > Component: gin | =20 > Version: =20 > Severity: Active WG Document | =20 > Resolution: fixed =20 > Keywords: | =20 > ------------------------------------------------+------------- > -------------- > Changes (by adam@...): >=20 > * status: new =3D> closed > * resolution: =3D> fixed >=20 >=20 > Comment: >=20 > A small number of these were fixed prior to=20 > draft-ietf-martini-gin-00. >=20 > The following suggestion appears to be founded in different=20 > dialects of > English between the reporter and the author, as the=20 > suggested change makes > the sentence nonsensical to me: >=20 > - Section 6: Change "based on" to "based in". [JRE] I think the proposed change was meant to be the opposite way round, b= ut it had already been fixed in draft-ietf. John >=20 > An alternate suggestion is welcome. >=20 > The remainder of the nits have been accepted, and will be=20 > reflected in the > -01 document. >=20 > --=20 > Ticket URL:=20 > > martini >=20 > = From john.elwell@siemens-enterprise.com Tue Apr 20 00:38:35 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65ED3A692D for ; Tue, 20 Apr 2010 00:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gB9k+LitdXO for ; Tue, 20 Apr 2010 00:38:34 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 0A5883A6358 for ; Tue, 20 Apr 2010 00:38:29 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1606756; Tue, 20 Apr 2010 09:38:20 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 637B623F028E; Tue, 20 Apr 2010 09:38:20 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 20 Apr 2010 09:38:20 +0200 From: "Elwell, John" To: Adam Roach , "martini@ietf.org" Date: Tue, 20 Apr 2010 09:38:19 +0200 Thread-Topic: [martini] New Version of GIN Thread-Index: AcrgFOIPdSRaZqzfQkCKFm48O7OrQAARmIgg Message-ID: References: <4BCCE1D3.2020806@nostrum.com> In-Reply-To: <4BCCE1D3.2020806@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] New Version of GIN X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 07:38:36 -0000 Adam, Thanks, this is looking good, and addresses any tracker issues I have raise= d to date. See below. =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 20 April 2010 00:06 > To: martini@ietf.org > Subject: [martini] New Version of GIN >=20 > I have produced a new version of GIN that I beleive addresses most of=20 > the tickets that had been opened (with only three exceptions,=20 > described=20 > below): >=20 > http://www.ietf.org/id/draft-ietf-martini-gin-01.txt >=20 > Changes from -00 are here: >=20 > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-martini-gin-01.txt >=20 >=20 > This version includes a proposed resolution to the=20 > "user=3Dphone" issue,=20 > based on the discussions in Anaheim. I have, however, left the ticket=20 > open, as there has been ongoing discussion after Anaheim that=20 > indicates=20 > that we may not yet have concensus in this area. The text=20 > currently in=20 > section 5 is my attempt to provide text for further crafting: >=20 > Although it is not a special case from a protocol perspective, > implementors are reminded that this behavior includes any "user" [JRE] "This behaviour" needs to be clarified, since the text is now separat= ed from the text on parameter handling by a large paragraph on single numbe= r registrations. Or alternatively reverse the order of the two parameters. John > parameter on the URI. For example, if the registering=20 > PBX requires > incoming messages to include a "user=3Dphone" parameter on their > Request-URI, it will include "user=3Dphone" on the URI in=20 > the "Contact" > header field of its registration. Because of the=20 > requirement on the > SSP to copy parameters into the location service, it will=20 > appear on > any Request-URIs that are retargeted to the PBX based on that > registration. Conversely, if the registering PBX does=20 > not include a > "user=3Dphone" parameter, any SSP using the procedures=20 > defined in this > document would not be at liberty to include one on the=20 > Request-URI. >=20 > Comments and suggestions for improvements are welcome. >=20 > The other two open issues entail the security implications of=20 > multiple=20 > users being registered with a single REGISTER request, and an=20 > analysis=20 > of the Outbound mechanism as it interacts with GIN. The first one is=20 > waiting on the second, which is in turn waiting on a=20 > qualified volunteer=20 > to perform the analysis. >=20 > Aside from these three open tickets, I am aware of no constructive=20 > requests for changes to the document. Participants who feel otherwise=20 > should feel free to register their issues in the tracker. >=20 > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From trac@tools.ietf.org Tue Apr 20 00:44:29 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 155BE3A6813 for ; Tue, 20 Apr 2010 00:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT5CGdTBKoKZ for ; Tue, 20 Apr 2010 00:44:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 57FF83A6810 for ; Tue, 20 Apr 2010 00:44:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O487x-0008OO-Sk; Tue, 20 Apr 2010 00:44:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com, john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Tue, 20 Apr 2010 07:44:13 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/35#comment:5 Message-ID: <085.cb32f075a4385b56221b469511d2307e@tools.ietf.org> References: <076.e6cc00fa95c4de7c0466bc499cb65491@tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <076.e6cc00fa95c4de7c0466bc499cb65491@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #35: Use of the word "extensions" X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 07:44:29 -0000 #35: Use of the word "extensions" ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: adam@… Type: defect | Status: assigned Priority: minor | Milestone: milestone1 Component: gin | Version: Severity: Active WG Document | Resolution: Keywords: | ------------------------------------------------+--------------------------- Comment(by john.elwell@…): As originator of this issue, I agree with the changes proposed by Hans Erik, but please use "UA" (or "UAs") rather than "UAS" (or "UASs"). John -- Ticket URL: martini From trac@tools.ietf.org Tue Apr 20 03:41:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F03D3A6807 for ; Tue, 20 Apr 2010 03:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31bq0MHMTDhr for ; Tue, 20 Apr 2010 03:41:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 333353A68E7 for ; Tue, 20 Apr 2010 03:41:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4Atf-0000ad-0w; Tue, 20 Apr 2010 03:41:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com, ietf.hanserik@gmail.com X-Trac-Project: martini Date: Tue, 20 Apr 2010 10:41:38 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/20#comment:4 Message-ID: <074.dacbac571bc9b4d439bba5fd6db3d385@tools.ietf.org> References: <065.606d2b6083a21b5a6fdc3bf7754c2d3e@tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <065.606d2b6083a21b5a6fdc3bf7754c2d3e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, ietf.hanserik@gmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #20: Section 3.1.2 does not decscribe an issue X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 10:41:52 -0000 #20: Section 3.1.2 does not decscribe an issue -------------------------------------+-------------------------------------- Reporter: ietf.hanserik@… | Owner: john.elwell@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------+-------------------------------------- Changes (by john.elwell@…): * status: reopened => new Comment: The present text of 3.1.2 states "There is no defined behavior for the SIP-PBX if the PAU header field's list of URIs does not match what the SIP-PBX expects it to be. It is not clear if the SIP-PBX should de- register, re-register, or ignore the difference; nor is there a way for the SIP-PBX to indicate the error in signaling." I think this is missing some context. I would propose that we insert text at the start of 3.1.2 stating: "Some current implementations return a list of registered AORs in the response, by inclusion of the P-Associated-URI header field." Concerning Hans Erik's assertion that no requirement has been derived from this, should we add a requirement along the lines of "REQxx - Any solution involving transmitting a list of registered AORs from SIP-PBX to SSP or vice versa MUST define procedures for dealing with the case where the received list does not match expectations."? Note that since gin does not transmit such a list, it does not fail this requirement. John -- Ticket URL: martini From ietf.hanserik@gmail.com Tue Apr 20 04:39:06 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DFD43A6816 for ; Tue, 20 Apr 2010 04:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnULV9CpHryz for ; Tue, 20 Apr 2010 04:39:05 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 6A0E43A6B7A for ; Tue, 20 Apr 2010 04:38:59 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so345601eyf.51 for ; Tue, 20 Apr 2010 04:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oXHIsphv08LDiPdTurrwJg+4sCJBQKFgRGYyVgLETJg=; b=RcuSodocCHX1BXL02/00jLo5d1NbxMIbyK3zFNsU7/dW6h0jxPkwHXA4VAwsmXF6Xw V97yb8uqG0fh4gpNf8AUO+jg8K+VmUSbdvy7kcHjnjo0a3zzg4UYNMSksoB1GCPcssys 8ksnmIKQO3tazBCS8jvewJ9QyKKZzXeNj/B0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=k0lZTRlqesgIt9dTjVw54Ur3HD/cxW6lZb3MThNUryPzei1CU4Kv9Abqo+7yDAh7ra mfM0kka4bOojyRVpq2xs+7CcvA43IPoXzwmvfOokFVrTB7W6VvUGtgBWXuBOOIYcd2US sYltR73vCpFinYVEN+1san4U6mKvOSaznegE0= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Tue, 20 Apr 2010 04:38:46 -0700 (PDT) In-Reply-To: <074.dacbac571bc9b4d439bba5fd6db3d385@tools.ietf.org> References: <065.606d2b6083a21b5a6fdc3bf7754c2d3e@tools.ietf.org> <074.dacbac571bc9b4d439bba5fd6db3d385@tools.ietf.org> Date: Tue, 20 Apr 2010 13:38:46 +0200 Received: by 10.213.57.140 with SMTP id c12mr3418734ebh.3.1271763526562; Tue, 20 Apr 2010 04:38:46 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: john.elwell@siemens-enterprise.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: martini@ietf.org Subject: Re: [martini] #20: Section 3.1.2 does not decscribe an issue X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 11:39:06 -0000 Hi John, My point was not that we need to derive a requirement, my point was that it is not an issue and does therefore not be listed/described as an issue ;-) The main reason that P-Associated-URI is used in the ETSI/3GPP solution is to provide the P-CSCF (edge proxy) with information about explicitly and implicitly registered AORs, which allows this edge proxy to perform its policies regarding P-Preferred-Identity, P-Asserted-Identity and P-Served-User handling. It was IMHO not ment for any special processing by the PBX. BR, /Hans Erik van Elburg On Tue, Apr 20, 2010 at 12:41 PM, martini issue tracker wrote: > #20: Section 3.1.2 does not decscribe an issue > -------------------------------------+-----------------------------------= --- > =A0Reporter: =A0ietf.hanserik@=85 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0Own= er: =A0john.elwell@=85 > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0= Status: =A0new > =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0Mil= estone: =A0milestone1 > Component: =A0reqs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0V= ersion: =A01.0 > =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 =A0| =A0 Resolution: > =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > -------------------------------------+-----------------------------------= --- > Changes (by john.elwell@=85): > > =A0* status: =A0reopened =3D> new > > > Comment: > > =A0The present text of 3.1.2 states "There is no defined behavior for the > =A0SIP-PBX if the PAU header field's list of URIs does not match what the > =A0SIP-PBX expects it to be. =A0It is not clear if the SIP-PBX should de- > =A0register, re-register, or ignore the difference; nor is there a way fo= r > =A0the SIP-PBX to indicate the error in signaling." > > =A0I think this is missing some context. I would propose that we insert t= ext > =A0at the start of 3.1.2 stating: "Some current implementations return a = list > =A0of registered AORs in the response, by inclusion of the P-Associated-U= RI > =A0header field." > > =A0Concerning Hans Erik's assertion that no requirement has been derived = from > =A0this, should we add a requirement along the lines of "REQxx - Any solu= tion > =A0involving transmitting a list of registered AORs from SIP-PBX to SSP o= r > =A0vice versa MUST define procedures for dealing with the case where the > =A0received list does not match expectations."? > > =A0Note that since gin does not transmit such a list, it does not fail th= is > =A0requirement. > > =A0John > > -- > Ticket URL: > martini > > From brett@broadsoft.com Tue Apr 20 09:21:09 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3943A6944 for ; Tue, 20 Apr 2010 09:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvS2YyJyCJYD for ; Tue, 20 Apr 2010 09:21:04 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id EB5243A6965 for ; Tue, 20 Apr 2010 09:20:50 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Tue, 20 Apr 2010 09:20:41 -0700 From: Brett Tate To: Adam Roach , Paul Kyzivat , "martini@ietf.org" , Hadriel Kaplan Date: Tue, 20 Apr 2010 09:19:43 -0700 Thread-Topic: [martini] #28: GIN: user=phone in the Contact Thread-Index: AcrgBDwbwLNJ+e8lRmax2+b7YUYpxgAnAFGA Message-ID: <747A6506A991724FB09B129B79D5FEB61480ECE741@EXMBXCLUS01.citservers.local> References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> <4BC3B175.3020504@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D991@mail> <4BC46E42.2000206@cisco.com> <4BCCC5DD.1000903@nostrum.com> In-Reply-To: <4BCCC5DD.1000903@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BxY= A9FV MlxB ONUr PX0Z PYXj UHNf US89 Xpgt Yw1/ cjO1 hTCh mEso sLAU sWju ubUP; 4; YQBkAGEAbQBAAG4AbwBzAHQAcgB1AG0ALgBjAG8AbQA7AGgAawBhAHAAbABhAG4AQABhAGMAbQBlAHAAYQBjAGsAZQB0AC4AYwBvAG0AOwBtAGEAcgB0AGkAbgBpAEAAaQBlAHQAZgAuAG8AcgBnADsAcABrAHkAegBpAHYAYQB0AEAAYwBpAHMAYwBvAC4AYwBvAG0A; Sosha1_v1; 7; {C7B121BD-0849-49B1-8FED-C990D6529E14}; YgByAGUAdAB0AEAAYgByAG8AYQBkAHMAbwBmAHQALgBjAG8AbQA=; Tue, 20 Apr 2010 16:19:43 GMT; UgBFADoAIABbAG0AYQByAHQAaQBuAGkAXQAgACMAMgA4ADoAIABHAEkATgA6ACAAdQBzAGUAcgA9AHAAaABvAG4AZQAgAGkAbgAgAHQAaABlACAAQwBvAG4AdABhAGMAdAA= x-cr-puzzleid: {C7B121BD-0849-49B1-8FED-C990D6529E14} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 16:21:09 -0000 > Given that the semantics of ";user=3D" are so thorougly=20 > ill-defined, I don't think it makes any sense at all=20 > to special case it. As far as I know, this would be the first RFC to explicitly and intentional= ly interpret RFC 3261 in a way which allows user=3Dphone to be included whe= n the userinfo does not decode into an rfc3966/rfc2806 telephone-subscriber= . Does MARTINI and SIPCORE really want RFC 3261 to be interpreted in this = manor instead of fixing the ambiguity with another interpretation? From ietf.hanserik@gmail.com Tue Apr 20 12:32:37 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69DC28C136 for ; Tue, 20 Apr 2010 12:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bEea1g5oJao for ; Tue, 20 Apr 2010 12:32:37 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id E18EA3A6828 for ; Tue, 20 Apr 2010 12:32:36 -0700 (PDT) Received: by ewy24 with SMTP id 24so2144073ewy.13 for ; Tue, 20 Apr 2010 12:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FJxuJVMe0xROwevVso1DCkA8q49cjXJZfB+PXu1pS+0=; b=VX0AumMqSrtXbDZ36jfUF0sLKqd8VqMwuj/jTUsMrklPNTqnWY97kAehixjcNPjA1l sQYxMUyxdFxAe5hK+p/9PTiNJasJ26vW5boOebSOpIM9OwjzcLYCeDbhNs7lqRZeSgd7 RCTlV+XN/9MzLWv3regk8CUg3e8sdQ+shXWZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jv8ZpWVgDVVQZFVzu4H+4wDzx6Dr8Ekw4YYBVeqY6JS6I1K4N0VlcIAiepYkhrkFP3 jr4riHcyEllZHDmfxhv4mpi/MjOb2/IaJxKVx83Bl6OerfOxVS1ztWnQ9CiRTwcVLbNX EoaxAZ87tN6ouGmC0VIa2uIbOjbCTrHRChq3s= MIME-Version: 1.0 Received: by 10.213.55.209 with SMTP id v17mr577178ebg.98.1271791944730; Tue, 20 Apr 2010 12:32:24 -0700 (PDT) Received: by 10.213.33.140 with HTTP; Tue, 20 Apr 2010 12:32:24 -0700 (PDT) In-Reply-To: <747A6506A991724FB09B129B79D5FEB61480ECE741@EXMBXCLUS01.citservers.local> References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> <4BC3B175.3020504@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D991@mail> <4BC46E42.2000206@cisco.com> <4BCCC5DD.1000903@nostrum.com> <747A6506A991724FB09B129B79D5FEB61480ECE741@EXMBXCLUS01.citservers.local> Date: Tue, 20 Apr 2010 21:32:24 +0200 Message-ID: From: Hans Erik van Elburg To: Brett Tate Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 19:32:37 -0000 Point. Wouldn't it be better instead that the draft clarifies that user=3Dphone does not survive the Request-URI replacement with the pbx-contact. And refrains from awkard examples where user=3Dphone is attached to a registered contact address. Really awkward. Without the example people are still free to configure their PBX to do it if it makes them happy. If user=3Dphone needs to survive the gin contact routing transformation, then that transformation better specifies that policy. /Hans Erik van Elburg On Tue, Apr 20, 2010 at 6:19 PM, Brett Tate wrote: >> Given that the semantics of ";user=3D" are so thorougly >> ill-defined, I don't think it makes any sense at all >> to special case it. > > As far as I know, this would be the first RFC to explicitly and intention= ally interpret RFC 3261 in a way which allows user=3Dphone to be included w= hen the userinfo does not decode into an rfc3966/rfc2806 telephone-subscrib= er. =A0Does MARTINI and SIPCORE really want RFC 3261 to be interpreted in t= his manor instead of fixing the ambiguity with another interpretation? > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From adam@nostrum.com Tue Apr 20 12:57:13 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482033A68F1 for ; Tue, 20 Apr 2010 12:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xb075ogcM9Yt for ; Tue, 20 Apr 2010 12:57:12 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 324703A6946 for ; Tue, 20 Apr 2010 12:57:07 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3KJumDu095778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Apr 2010 14:56:50 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BCE06FF.6080902@nostrum.com> Date: Tue, 20 Apr 2010 14:56:47 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hans Erik van Elburg References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> <4BC3B175.3020504@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D991@mail> <4BC46E42.2000206@cisco.com> <4BCCC5DD.1000903@nostrum.com> <747A6506A991724FB09B129B79D5FEB61480ECE741@EXMBXCLUS01.citservers.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 19:57:13 -0000 Let me make sure I understand what you're lobbying for. You both seem to be saying that you want to prevent a PBX from telling an SSP that it needs a "user=phone" on inbound URIs. Which means that PBXes that use this as some kind of optimization or necessity for internal processing are excluded from being able to use GIN for some artificial -- or, at best, aesthetic -- reason. Keep in mind that the thing we're sending in the Contact header field isn't a traditional SIP URI, in that it will never, by itself, be used for routing anything. It's a *TEMPLATE*. It is *USELESS* until it is *INSTANTIATED*. And when it is instantiated, it will contain a telephone number. So, by the time it exists as a usable URI, it is correct. As we went over in Anaheim, objections that the template itself doesn't contain a user portion while a "user" parameter are present are pedanticism of the highest degree. We're taking some rather extreme measures to ensure that all parties to the transaction are fully aware of the meaning of the "bnc" parameter, so nothing can possibly be broken by this syntax. Everything that can potentially be involved *knows* this is a template. It will *understand* that you can't use the URI until it has been instantiated. Now, I'm happy to take it off the examples -- I don't have a strong opinion about whether PBXes should be doing this -- but I think artificially constraining the functionality can only make interop more difficult, not easier. /a On 4/20/10 2:32 PM, Hans Erik van Elburg wrote: > Point. > > Wouldn't it be better instead that the draft clarifies that user=phone > does not survive the Request-URI replacement with the pbx-contact. > > And refrains from awkard examples where user=phone is attached to a > registered contact address. Really awkward. Without the example people > are still free to configure their PBX to do it if it makes them happy. > > If user=phone needs to survive the gin contact routing transformation, > then that transformation better specifies that policy. > > /Hans Erik van Elburg > > > On Tue, Apr 20, 2010 at 6:19 PM, Brett Tate wrote: > >>> Given that the semantics of ";user=" are so thorougly >>> ill-defined, I don't think it makes any sense at all >>> to special case it. >>> >> As far as I know, this would be the first RFC to explicitly and intentionally interpret RFC 3261 in a way which allows user=phone to be included when the userinfo does not decode into an rfc3966/rfc2806 telephone-subscriber. Does MARTINI and SIPCORE really want RFC 3261 to be interpreted in this manor instead of fixing the ambiguity with another interpretation? >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> >> From HKaplan@acmepacket.com Tue Apr 20 13:10:13 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C794828C1AC for ; Tue, 20 Apr 2010 13:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29NSSowfJOic for ; Tue, 20 Apr 2010 13:10:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 55E2028C1B6 for ; Tue, 20 Apr 2010 13:10:11 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 20 Apr 2010 16:10:01 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 20 Apr 2010 16:10:01 -0400 From: Hadriel Kaplan To: Adam Roach , Hans Erik van Elburg Date: Tue, 20 Apr 2010 16:09:59 -0400 Thread-Topic: [martini] #28: GIN: user=phone in the Contact Thread-Index: Acrgw6IWj3a11GrZTsWgui5oI13a2QAAJBxQ Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCF348@mail> References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> <4BC3B175.3020504@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D991@mail> <4BC46E42.2000206@cisco.com> <4BCCC5DD.1000903@nostrum.com> <747A6506A991724FB09B129B79D5FEB61480ECE741@EXMBXCLUS01.citservers.local> <4BCE06FF.6080902@nostrum.com> In-Reply-To: <4BCE06FF.6080902@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 20:10:13 -0000 No I think the concern is different, and more along the lines of why I subm= itted the tracker. The UA is registering a template, of course, but any/all params other than = the 'bnc' one are opaque to the SSP Registrar/proxy, right? The SSP reg-pr= oxy expands them into sip:foobar@ in the DB. And when doing a req-uri replacement the SSP proxy replaces the req-uri wit= h the (now expanded) registered contact-URI, right? So when routing to the PBX, the SSP proxy is sending a req-uri that now has= a "user=3Dphone" param, without having any idea if the user portion is in = fact a telephone format. For example, in draft-olive they're not. The SSP= proxy performing the req-uri routing replacement is just looking up an AoR= and replacing it with a registered contact-URI. -hadriel > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, April 20, 2010 3:57 PM > To: Hans Erik van Elburg > Cc: Brett Tate; Paul Kyzivat; martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] #28: GIN: user=3Dphone in the Contact >=20 > Let me make sure I understand what you're lobbying for. >=20 > You both seem to be saying that you want to prevent a PBX from telling > an SSP that it needs a "user=3Dphone" on inbound URIs. Which means that > PBXes that use this as some kind of optimization or necessity for > internal processing are excluded from being able to use GIN for some > artificial -- or, at best, aesthetic -- reason. >=20 > Keep in mind that the thing we're sending in the Contact header field > isn't a traditional SIP URI, in that it will never, by itself, be used > for routing anything. It's a *TEMPLATE*. It is *USELESS* until it is > *INSTANTIATED*. And when it is instantiated, it will contain a telephone > number. So, by the time it exists as a usable URI, it is correct. >=20 > As we went over in Anaheim, objections that the template itself doesn't > contain a user portion while a "user" parameter are present are > pedanticism of the highest degree. We're taking some rather extreme > measures to ensure that all parties to the transaction are fully aware > of the meaning of the "bnc" parameter, so nothing can possibly be broken > by this syntax. Everything that can potentially be involved *knows* this > is a template. It will *understand* that you can't use the URI until it > has been instantiated. >=20 > Now, I'm happy to take it off the examples -- I don't have a strong > opinion about whether PBXes should be doing this -- but I think > artificially constraining the functionality can only make interop more > difficult, not easier. >=20 > /a >=20 > On 4/20/10 2:32 PM, Hans Erik van Elburg wrote: > > Point. > > > > Wouldn't it be better instead that the draft clarifies that user=3Dphon= e > > does not survive the Request-URI replacement with the pbx-contact. > > > > And refrains from awkard examples where user=3Dphone is attached to a > > registered contact address. Really awkward. Without the example people > > are still free to configure their PBX to do it if it makes them happy. > > > > If user=3Dphone needs to survive the gin contact routing transformation= , > > then that transformation better specifies that policy. > > > > /Hans Erik van Elburg > > > > > > On Tue, Apr 20, 2010 at 6:19 PM, Brett Tate wrote= : > > > >>> Given that the semantics of ";user=3D" are so thorougly > >>> ill-defined, I don't think it makes any sense at all > >>> to special case it. > >>> > >> As far as I know, this would be the first RFC to explicitly and > intentionally interpret RFC 3261 in a way which allows user=3Dphone to be > included when the userinfo does not decode into an rfc3966/rfc2806 > telephone-subscriber. Does MARTINI and SIPCORE really want RFC 3261 to b= e > interpreted in this manor instead of fixing the ambiguity with another > interpretation? > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > >> From ietf.hanserik@gmail.com Tue Apr 20 13:11:11 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078DD28C1C2 for ; Tue, 20 Apr 2010 13:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsDkCUrlLZzJ for ; Tue, 20 Apr 2010 13:11:05 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 1699C3A6A99 for ; Tue, 20 Apr 2010 13:10:41 -0700 (PDT) Received: by ewy24 with SMTP id 24so2161659ewy.13 for ; Tue, 20 Apr 2010 13:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=egqu4h1hm4+xkVyoVezUnPtv6qPoRqZpPkrB28lLBpA=; b=Fnmlv6SU8r2wHjW/Rh06EUur36Fx94rLndOxsYEX7PoXEgVHOcVa+8aHEZS68TrpQS 0J3OZVgwcBF5u101vowT5Ck2L13sg0ZdpMZsNf89zV9p4BCfXyhN5sAulgf1E/XfhD5G RPaKWnw/YS1tTdSFhitmGbcU0K5HU8wsMnx+4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=C/RD0p6+7Gq12FscV0XNWyEQIwEGyTa65FbJEcc27jXEthKrce4LuduCRGhX+mUWB0 IKdJTzFimMgPBwDv+pCZtLtM5sm3h267X6rGHKTkf7yPVLlWE79tnm0SBb/0CytAEpEq B7L0FwSpzZ8T0AtGHxto3aMuOa0iOZPByNgHo= MIME-Version: 1.0 Received: by 10.213.33.140 with HTTP; Tue, 20 Apr 2010 13:10:32 -0700 (PDT) In-Reply-To: <4BCE06FF.6080902@nostrum.com> References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> <4BC3B175.3020504@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D991@mail> <4BC46E42.2000206@cisco.com> <4BCCC5DD.1000903@nostrum.com> <747A6506A991724FB09B129B79D5FEB61480ECE741@EXMBXCLUS01.citservers.local> <4BCE06FF.6080902@nostrum.com> Date: Tue, 20 Apr 2010 22:10:32 +0200 Received: by 10.213.44.71 with SMTP id z7mr3633257ebe.53.1271794232531; Tue, 20 Apr 2010 13:10:32 -0700 (PDT) Message-ID: From: Hans Erik van Elburg To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 20:11:11 -0000 On Tue, Apr 20, 2010 at 9:56 PM, Adam Roach wrote: > Let me make sure I understand what you're lobbying for. > > You both seem to be saying that you want to prevent a PBX from telling an > SSP that it needs a "user=phone" on inbound URIs. Which means that PBXes > that use this as some kind of optimization or necessity for internal > processing are excluded from being able to use GIN for some artificial -- > or, at best, aesthetic -- reason. > No I wasn't implying that. I was saying that it is an awkward example, if a pbx wants to do this it can still do it. > Keep in mind that the thing we're sending in the Contact header field isn't > a traditional SIP URI, in that it will never, by itself, be used for routing > anything. It's a *TEMPLATE*. It is *USELESS* until it is *INSTANTIATED*. And > when it is instantiated, it will contain a telephone number. So, by the time > it exists as a usable URI, it is correct. > I was also saying that if user=phone needs to be carried over, then it better be part of the transformation G(I,N) where I is a template and N a number a template and constructs the new Request-URI. > As we went over in Anaheim, objections that the template itself doesn't > contain a user portion while a "user" parameter are present are pedanticism > of the highest degree. We're taking some rather extreme measures to ensure > that all parties to the transaction are fully aware of the meaning of the > "bnc" parameter, so nothing can possibly be broken by this syntax. > Everything that can potentially be involved *knows* this is a template. It > will *understand* that you can't use the URI until it has been instantiated. > That is why it is good to explain the consequences of the chosen mechanism, so that everybody understands them. To be honest I did not understand the discussion in Anaheim, today after reading Brett's reply I understood why I didn't understand it ;-) > Now, I'm happy to take it off the examples -- I don't have a strong opinion > about whether PBXes should be doing this -- but I think artificially > constraining the functionality can only make interop more difficult, not > easier. Removing it from the examples does not constrain it in any way does it? Having every PBX attach it to the PBX-Contact (or template), on the other hand constrains the mechanisms extensibility. From ietf.hanserik@gmail.com Tue Apr 20 13:13:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164693A6BA8 for ; Tue, 20 Apr 2010 13:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7NY4q5HQrOG for ; Tue, 20 Apr 2010 13:13:16 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 6C8D03A67B2 for ; Tue, 20 Apr 2010 13:12:44 -0700 (PDT) Received: by ewy24 with SMTP id 24so2162477ewy.13 for ; Tue, 20 Apr 2010 13:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YP/5YQIVZ/7u2zwYmrus2colrLUXBK5IMRfokzwG6Lw=; b=NntogRBgvZOuzcx6HMEphga2uqrNDA28+HN1OskLXTrA25ILEHzyd8x8eRc59OJGpp KDeBsAwGuHnvGe+DPhW73T39C0CAxMY2gwO0iqvSUyN+/W6KixooaGwCudE8qlc8UrJc EzkTEz5XEgnz1FUh5NBKhRXlSwzEmeflvQ/6Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Je3iQKJ4BWiv7K98g+C3IXIvAvhDVQZa/RE3WnFzm8iig9UQ86PpTKTvx7TnWss40B UILWcA+hEiMdE3JluBmR8TWXePdr3RsKA3ILfxSY5SXsKjPInEWTPP8rE9CgICUa49uw 4PD3WThJ8CYHgP7wVntVb8i033l+sK5lKNN6s= MIME-Version: 1.0 Received: by 10.213.47.195 with SMTP id o3mr621230ebf.48.1271794350542; Tue, 20 Apr 2010 13:12:30 -0700 (PDT) Received: by 10.213.33.140 with HTTP; Tue, 20 Apr 2010 13:12:30 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCF348@mail> References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> <4BC3B175.3020504@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D991@mail> <4BC46E42.2000206@cisco.com> <4BCCC5DD.1000903@nostrum.com> <747A6506A991724FB09B129B79D5FEB61480ECE741@EXMBXCLUS01.citservers.local> <4BCE06FF.6080902@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79FCF348@mail> Date: Tue, 20 Apr 2010 22:12:30 +0200 Message-ID: From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "martini@ietf.org" Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 20:13:18 -0000 Right. I realised after writing it that it is actually the point you was trying to make when starting this thread. /Hans Erik van Elburg On Tue, Apr 20, 2010 at 10:09 PM, Hadriel Kaplan w= rote: > > No I think the concern is different, and more along the lines of why I su= bmitted the tracker. > > The UA is registering a template, of course, but any/all params other tha= n the 'bnc' one are opaque to the SSP Registrar/proxy, right? =A0The SSP re= g-proxy expands them into sip:foobar@ in the DB. > > And when doing a req-uri replacement the SSP proxy replaces the req-uri w= ith the (now expanded) registered contact-URI, right? > > So when routing to the PBX, the SSP proxy is sending a req-uri that now h= as a "user=3Dphone" param, without having any idea if the user portion is i= n fact a telephone format. =A0For example, in draft-olive they're not. =A0T= he SSP proxy performing the req-uri routing replacement is just looking up = an AoR and replacing it with a registered contact-URI. > > -hadriel > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Tuesday, April 20, 2010 3:57 PM >> To: Hans Erik van Elburg >> Cc: Brett Tate; Paul Kyzivat; martini@ietf.org; Hadriel Kaplan >> Subject: Re: [martini] #28: GIN: user=3Dphone in the Contact >> >> Let me make sure I understand what you're lobbying for. >> >> You both seem to be saying that you want to prevent a PBX from telling >> an SSP that it needs a "user=3Dphone" on inbound URIs. Which means that >> PBXes that use this as some kind of optimization or necessity for >> internal processing are excluded from being able to use GIN for some >> artificial -- or, at best, aesthetic -- reason. >> >> Keep in mind that the thing we're sending in the Contact header field >> isn't a traditional SIP URI, in that it will never, by itself, be used >> for routing anything. It's a *TEMPLATE*. It is *USELESS* until it is >> *INSTANTIATED*. And when it is instantiated, it will contain a telephone >> number. So, by the time it exists as a usable URI, it is correct. >> >> As we went over in Anaheim, objections that the template itself doesn't >> contain a user portion while a "user" parameter are present are >> pedanticism of the highest degree. We're taking some rather extreme >> measures to ensure that all parties to the transaction are fully aware >> of the meaning of the "bnc" parameter, so nothing can possibly be broken >> by this syntax. Everything that can potentially be involved *knows* this >> is a template. It will *understand* that you can't use the URI until it >> has been instantiated. >> >> Now, I'm happy to take it off the examples -- I don't have a strong >> opinion about whether PBXes should be doing this -- but I think >> artificially constraining the functionality can only make interop more >> difficult, not easier. >> >> /a >> >> On 4/20/10 2:32 PM, Hans Erik van Elburg wrote: >> > Point. >> > >> > Wouldn't it be better instead that the draft clarifies that user=3Dpho= ne >> > does not survive the Request-URI replacement with the pbx-contact. >> > >> > And refrains from awkard examples where user=3Dphone is attached to a >> > registered contact address. Really awkward. Without the example people >> > are still free to configure their PBX to do it if it makes them happy. >> > >> > If user=3Dphone needs to survive the gin contact routing transformatio= n, >> > then that transformation better specifies that policy. >> > >> > /Hans Erik van Elburg >> > >> > >> > On Tue, Apr 20, 2010 at 6:19 PM, Brett Tate =A0wr= ote: >> > >> >>> Given that the semantics of ";user=3D" are so thorougly >> >>> ill-defined, I don't think it makes any sense at all >> >>> to special case it. >> >>> >> >> As far as I know, this would be the first RFC to explicitly and >> intentionally interpret RFC 3261 in a way which allows user=3Dphone to b= e >> included when the userinfo does not decode into an rfc3966/rfc2806 >> telephone-subscriber. =A0Does MARTINI and SIPCORE really want RFC 3261 t= o be >> interpreted in this manor instead of fixing the ambiguity with another >> interpretation? >> >> >> >> _______________________________________________ >> >> martini mailing list >> >> martini@ietf.org >> >> https://www.ietf.org/mailman/listinfo/martini >> >> >> >> > > From adam@nostrum.com Tue Apr 20 13:16:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF14F3A67A2 for ; Tue, 20 Apr 2010 13:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns1D8g1Bdh2c for ; Tue, 20 Apr 2010 13:16:51 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 4BB0D3A6B9E for ; Tue, 20 Apr 2010 13:15:51 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3KKFD4S097235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Apr 2010 15:15:15 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BCE0B50.5000702@nostrum.com> Date: Tue, 20 Apr 2010 15:15:12 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> <4BC3B175.3020504@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D991@mail> <4BC46E42.2000206@cisco.com> <4BCCC5DD.1000903@nostrum.com> <747A6506A991724FB09B129B79D5FEB61480ECE741@EXMBXCLUS01.citservers.local> <4BCE06FF.6080902@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79FCF348@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79FCF348@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 20:16:52 -0000 On 4/20/10 3:09 PM, Hadriel Kaplan wrote: > The UA is registering a template, of course, but any/all params other than the 'bnc' one are opaque to the SSP Registrar/proxy, right? The SSP reg-proxy expands them into sip:foobar@ in the DB. > > And when doing a req-uri replacement the SSP proxy replaces the req-uri with the (now expanded) registered contact-URI, right? > > So when routing to the PBX, the SSP proxy is sending a req-uri that now has a "user=phone" param, without having any idea if the user portion is in fact a telephone format. For example, in draft-olive they're not. The SSP proxy performing the req-uri routing replacement is just looking up an AoR and replacing it with a registered contact-URI. > So a PBX provisioned to use non-telephone-number user portions -- such as is described in olive -- would be misbehaving if it tacked on a "user=phone." It would effectively be a provisioning mismatch. And there's been a strong consensus that we're not detecting or correcting provisioning mismatches in GIN. /a From ietf.hanserik@gmail.com Tue Apr 20 13:24:33 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B8C3A67A2 for ; Tue, 20 Apr 2010 13:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrwgyvlWcvJy for ; Tue, 20 Apr 2010 13:24:31 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id F3D4B3A6B0B for ; Tue, 20 Apr 2010 13:22:28 -0700 (PDT) Received: by ewy24 with SMTP id 24so2166866ewy.13 for ; Tue, 20 Apr 2010 13:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=po6+hyxT0tXfqANuUjEV6SjPNjJUW4KgWX7c24rmg5E=; b=wz2MWsKsXXl2jpH/4JJa8RGwYVWlozhMpre3gXR23a1Mwzs6/Ul9BftcMtCmKMvDGe SLwdeWI7EEylgOIBq8Q9q17P6MWn+wuoYXTkxDQfyO/v0RzE+li8UBq40N9yA9Oa72+N YBEWXm39A24KLymqFBnrM0lYRnv2leCfrRCnI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gAdTFWUT3pJnbGObP4mfy7UluQoOL/DAgxTYxT5I0utiqBFs0sBU1egibqrbNIoq5q MJCK0khPgYV9IYeQTxExjhgdaPKcEsNBFM0sCsdMR98uoUrJ+UfdM6d0MxocMzyJ53dN pXLrauVdYuav8gi8zkljbMbMyJwZWzyQu8qOc= MIME-Version: 1.0 Received: by 10.213.39.71 with SMTP id f7mr646908ebe.32.1271794937226; Tue, 20 Apr 2010 13:22:17 -0700 (PDT) Received: by 10.213.33.140 with HTTP; Tue, 20 Apr 2010 13:22:17 -0700 (PDT) In-Reply-To: <4BCE0B50.5000702@nostrum.com> References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> <4BC3B175.3020504@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D991@mail> <4BC46E42.2000206@cisco.com> <4BCCC5DD.1000903@nostrum.com> <747A6506A991724FB09B129B79D5FEB61480ECE741@EXMBXCLUS01.citservers.local> <4BCE06FF.6080902@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79FCF348@mail> <4BCE0B50.5000702@nostrum.com> Date: Tue, 20 Apr 2010 22:22:17 +0200 Message-ID: From: Hans Erik van Elburg To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 20:24:33 -0000 On Tue, Apr 20, 2010 at 10:15 PM, Adam Roach wrote: > On 4/20/10 3:09 PM, Hadriel Kaplan wrote: >> >> The UA is registering a template, of course, but any/all params other th= an >> the 'bnc' one are opaque to the SSP Registrar/proxy, right? =A0The SSP >> reg-proxy expands them into sip:foobar@ =A0in the DB. >> >> And when doing a req-uri replacement the SSP proxy replaces the req-uri >> with the (now expanded) registered contact-URI, right? >> >> So when routing to the PBX, the SSP proxy is sending a req-uri that now >> has a "user=3Dphone" param, without having any idea if the user portion = is in >> fact a telephone format. =A0For example, in draft-olive they're not. =A0= The SSP >> proxy performing the req-uri routing replacement is just looking up an A= oR >> and replacing it with a registered contact-URI. >> > > So a PBX provisioned to use non-telephone-number user portions -- such as= is > described in olive -- would be misbehaving if it tacked on a "user=3Dphon= e." > It would effectively be a provisioning mismatch. And there's been a stron= g > consensus that we're not detecting or correcting provisioning mismatches = in > GIN. No, it is not. The PBX may accept a mix of telephone numbers and non-telephone numbers. Having user=3Dphone on that template is plainly wrong. /Hans Erik From HKaplan@acmepacket.com Tue Apr 20 13:25:57 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08BC33A6BB3 for ; Tue, 20 Apr 2010 13:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IURcwCfheNFE for ; Tue, 20 Apr 2010 13:25:56 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E92B728C200 for ; Tue, 20 Apr 2010 13:23:48 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 20 Apr 2010 16:23:36 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 20 Apr 2010 16:23:36 -0400 From: Hadriel Kaplan To: Adam Roach Date: Tue, 20 Apr 2010 16:23:34 -0400 Thread-Topic: [martini] #28: GIN: user=phone in the Contact Thread-Index: AcrgxjzDUu40AYBDSsqcGj+NCFsIyAAAJ5Fg Message-ID: <430FC6BDED356B4C8498F634416644A91A79FCF35F@mail> References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> <4BC3B175.3020504@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D991@mail> <4BC46E42.2000206@cisco.com> <4BCCC5DD.1000903@nostrum.com> <747A6506A991724FB09B129B79D5FEB61480ECE741@EXMBXCLUS01.citservers.local> <4BCE06FF.6080902@nostrum.com> <430FC6BDED356B4C8498F634416644A91A79FCF348@mail> <4BCE0B50.5000702@nostrum.com> In-Reply-To: <4BCE0B50.5000702@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 20:25:57 -0000 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, April 20, 2010 4:15 PM > To: Hadriel Kaplan > Cc: Hans Erik van Elburg; Brett Tate; Paul Kyzivat; martini@ietf.org > Subject: Re: [martini] #28: GIN: user=3Dphone in the Contact >=20 > So a PBX provisioned to use non-telephone-number user portions -- such > as is described in olive -- would be misbehaving if it tacked on a > "user=3Dphone." It would effectively be a provisioning mismatch. And > there's been a strong consensus that we're not detecting or correcting > provisioning mismatches in GIN. Yup, and in a draft of olive I actually use that as an indication of such, = but then realized this would be in conflict with draft-gin, if draft-gin sh= owed such things in examples and gave no guidance about it. Which is what = made me think about it more and triggered me to submit a tracker. :) -hadriel From brett@broadsoft.com Tue Apr 20 15:11:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6EC3A698F for ; Tue, 20 Apr 2010 15:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXjS-Ndt63rl for ; Tue, 20 Apr 2010 15:11:29 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 0AFCA3A67D9 for ; Tue, 20 Apr 2010 15:11:26 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Tue, 20 Apr 2010 15:11:17 -0700 From: Brett Tate To: Adam Roach , "martini@ietf.org" Date: Tue, 20 Apr 2010 15:10:23 -0700 Thread-Topic: [martini] #28: GIN: user=phone in the Contact Thread-Index: Acrgw6K8V+pa7trrQcOubL7tmgst4wADKEtQ Message-ID: <747A6506A991724FB09B129B79D5FEB61480F78FB6@EXMBXCLUS01.citservers.local> References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> <4BC3B175.3020504@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D991@mail> <4BC46E42.2000206@cisco.com> <4BCCC5DD.1000903@nostrum.com> <747A6506A991724FB09B129B79D5FEB61480ECE741@EXMBXCLUS01.citservers.local> <4BCE06FF.6080902@nostrum.com> In-Reply-To: <4BCE06FF.6080902@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 22:11:30 -0000 > Let me make sure I understand what you're lobbying for. I'm not lobbying for anything. I asked a question since #28 had been raise= d against GIN. > You both seem to be saying that you want to prevent=20 > a PBX from telling an SSP that it needs a "user=3Dphone"=20 > on inbound URIs. No; I just asked a question. I assume that there are a variety of answers;= the following are few. 1) Yes. 2) No; however tolerating such an interpretation is required for devices th= at support gin. 3) No; #28 will be resolved in some other way. > > On Tue, Apr 20, 2010 at 6:19 PM, Brett Tate > wrote: > > > >>> Given that the semantics of ";user=3D" are so thorougly > >>> ill-defined, I don't think it makes any sense at all > >>> to special case it. > >>> > >> As far as I know, this would be the first RFC to explicitly and > intentionally interpret RFC 3261 in a way which allows user=3Dphone to be > included when the userinfo does not decode into an rfc3966/rfc2806 > telephone-subscriber. Does MARTINI and SIPCORE really want RFC 3261 to > be interpreted in this manor instead of fixing the ambiguity with > another interpretation? From bernard_aboba@hotmail.com Wed Apr 21 18:36:19 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C33E3A69A6 for ; Wed, 21 Apr 2010 18:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.304 X-Spam-Level: X-Spam-Status: No, score=0.304 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNBR3ySGtwFz for ; Wed, 21 Apr 2010 18:36:18 -0700 (PDT) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by core3.amsl.com (Postfix) with ESMTP id BFFA73A6920 for ; Wed, 21 Apr 2010 18:36:17 -0700 (PDT) Received: from BLU137-W11 ([65.55.111.72]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 18:36:08 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_adfd9c6c-0d44-4e24-b4d3-0abb6d344b72_" X-Originating-IP: [131.107.0.69] From: Bernard Aboba To: Date: Wed, 21 Apr 2010 18:36:08 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 22 Apr 2010 01:36:08.0610 (UTC) FILETIME=[2EA44820:01CAE1BC] Subject: [martini] REMINDER: Doodle Poll for MARTINI Virtual Interim V X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 01:36:19 -0000 --_adfd9c6c-0d44-4e24-b4d3-0abb6d344b72_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In addition to the Virtual Interim scheduled for=20 April 29=2C 2010=2C we would also like to schedule a Virtual Interim during the third=20 week of May.=20 =20 Please fill out the Doodle Poll if you haven't already=2C so that we can=20 determine availability: http://www.doodle.com/66qvn4umdfgk4ee3 = --_adfd9c6c-0d44-4e24-b4d3-0abb6d344b72_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In addition to the Virtual Interim scheduled for=20 April 29=2C 2010=2C we would also like to schedule a Virtual Interim during the third=20 week of May.

 =3B

Please fill out the Doodle Poll if you haven't alrea= dy=2C so that we can=20 determine availability:

http://= www.doodle.com/66qvn4umdfgk4ee3



= --_adfd9c6c-0d44-4e24-b4d3-0abb6d344b72_-- From bernard_aboba@hotmail.com Wed Apr 21 18:38:24 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6759A3A69A6 for ; Wed, 21 Apr 2010 18:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccCp-LA1crsm for ; Wed, 21 Apr 2010 18:38:23 -0700 (PDT) Received: from blu0-omc2-s31.blu0.hotmail.com (blu0-omc2-s31.blu0.hotmail.com [65.55.111.106]) by core3.amsl.com (Postfix) with ESMTP id A97BF3A6894 for ; Wed, 21 Apr 2010 18:38:22 -0700 (PDT) Received: from BLU137-W13 ([65.55.111.73]) by blu0-omc2-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 18:38:12 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_1e0fc340-ea70-4f45-86fc-cb7f3b9049c5_" X-Originating-IP: [131.107.0.69] From: Bernard Aboba To: Date: Wed, 21 Apr 2010 18:38:12 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 22 Apr 2010 01:38:12.0608 (UTC) FILETIME=[788CE000:01CAE1BC] Subject: [martini] Agenda for MARTINI Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 01:38:24 -0000 --_1e0fc340-ea70-4f45-86fc-cb7f3b9049c5_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Agenda MARTINI Virtual Interim IV April 29=2C 2010 11 AM =96 1 PM Pacific Time =20 Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/April-Interim-IV/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/= martini/current/msg01340.html=20 =20 Agenda =20 11 AM - 11:10 AM PT: Preliminaries =20 Conference issues/debugging =20 Note Well =20 Note Takers =20 Agenda bash =20 Requirements (15 minutes) =20 11:10 AM - 11:25 AM PT MARTINI Requirements Update=2C John Elwell (15 minutes) http://tools.ietf.org/html/draft-ietf-martini-reqs =20 Solution Updates (30 minutes) =20 11:25 AM =96 11:55 AM PT=2C MARTINI with Globally Identifiable Numbers Update=2C = Adam Roach (30 minutes) http://tools.ietf.org/html/draft-ietf-martini-gin =20 Other Identifier Values (30 minutes) =20 11:55 AM =96 12:25 PM=2C Other Logical Identifier Values (OLIVE)=2C Hadriel Kapla= n (30 minutes) http://tools.ietf.org/html/draft-kaplan-martini-with-olive =20 Discussion and Wrap-up (35 minutes) =20 12:25 AM =96 12:40 PM PT Discussion: Participants (15 minutes) 12:40 PM - 12:50 PM PT Hums: WG Chairs (10 minutes) 12:50 PM =96 1 PM PT Next Steps: WG Chairs & ADs (10 minutes) =20 =20 = --_1e0fc340-ea70-4f45-86fc-cb7f3b9049c5_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =

Agenda

MARTINI Virtual Interim IV

April 29=2C 2010

11 AM =96 1 PM Pacific Time

 =3B

Conferencing Details:

Slide Presentations: =3B http://www.drizzle.com/~aboba/MARTINI/Ap= ril-Interim-IV/

Jabber room: =3B martini at jabber.ietf.org (Please join)

Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/= martini/current/msg01340.html

 =3B

Agenda

 =3B

11 AM - 11:10 AM PT: =3B Preliminaries

 =3B =3B =3B =3B Conference issues/debugging

 =3B =3B =3B =3B Note Well

 =3B =3B =3B =3B Note Takers

 =3B =3B =3B =3B Agenda bash

 =3B

Requirements (15 minutes)

 =3B

11:10 AM - 11:25 AM PT MARTINI Requirements Update=2C John Elwell (15 minutes)

http://tools.ietf.org/html/draft-ietf-marti= ni-reqs

 =3B

Solution Updates (30 minutes)

 =3B

11:25 AM =96 11:55 AM PT=2C MARTINI with Globally Identifiable Numbers Update=2C = Adam Roach (30 minutes)

http://tools.ietf.org/html/draft-ietf-martin= i-gin

 =3B

Other Identifier Values (30 minutes)

 =3B

11:55 AM =96 12:25 PM=2C Other Logical Identifier Values (OLIVE)=2C Hadriel Kapla= n (30 minutes)

http://tools.ietf.org/html/draft-ka= plan-martini-with-olive

 =3B

Discussion and Wrap-up (35 minutes)

 =3B

12:25 AM =96 12:40 PM =3B PT Discussion: =3B Participants (15 minutes)

12:40 PM - 12:50 PM PT =3B Hums: =3B WG Chairs (10 minutes)

12:50 PM =96 1 PM PT =3B =3B Next Steps: =3B WG Chairs &=3B ADs (1= 0 minutes)

 =3B

 =3B






= --_1e0fc340-ea70-4f45-86fc-cb7f3b9049c5_-- From bernard_aboba@hotmail.com Wed Apr 21 18:41:44 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF173A69AD for ; Wed, 21 Apr 2010 18:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.291 X-Spam-Level: X-Spam-Status: No, score=0.291 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJM2s1D3BYFz for ; Wed, 21 Apr 2010 18:41:42 -0700 (PDT) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by core3.amsl.com (Postfix) with ESMTP id EFC943A69A6 for ; Wed, 21 Apr 2010 18:41:40 -0700 (PDT) Received: from BLU137-W36 ([65.55.111.71]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 18:40:03 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_e072860f-c42a-4b69-b47b-5f36800b8139_" X-Originating-IP: [131.107.0.69] From: Bernard Aboba To: Date: Wed, 21 Apr 2010 18:40:02 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 22 Apr 2010 01:40:03.0280 (UTC) FILETIME=[BA841500:01CAE1BC] Subject: [martini] Slides Reminder: MARTINI Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 01:41:44 -0000 --_e072860f-c42a-4b69-b47b-5f36800b8139_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you're on the agenda for MARTINI Virtual Interim IV on April 29=2C this = is a reminder to get your slides in to myself and Spencer no later than Tue= sday of next week (April 27).=20 = --_e072860f-c42a-4b69-b47b-5f36800b8139_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you're on the agenda for MARTINI Virtual Interim IV on April 29=2C this = is a reminder to get your slides in to myself and Spencer no later than Tue= sday of next week (April 27).




= --_e072860f-c42a-4b69-b47b-5f36800b8139_-- From john.elwell@siemens-enterprise.com Thu Apr 22 01:37:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8F9D3A68D3 for ; Thu, 22 Apr 2010 01:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kfMUh+Xuqnx for ; Thu, 22 Apr 2010 01:37:24 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 748273A6813 for ; Thu, 22 Apr 2010 01:37:24 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1637273; Thu, 22 Apr 2010 10:37:12 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 002F723F0278; Thu, 22 Apr 2010 10:37:12 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 22 Apr 2010 10:37:12 +0200 From: "Elwell, John" To: Hans Erik van Elburg , Hadriel Kaplan Date: Thu, 22 Apr 2010 10:37:10 +0200 Thread-Topic: [martini] #20: Section 3.1.2 does not decscribe an issue Thread-Index: Acrgfgnajd6DiczYT3mDfLR9AgCT9wBeNuOA Message-ID: References: <065.606d2b6083a21b5a6fdc3bf7754c2d3e@tools.ietf.org> <074.dacbac571bc9b4d439bba5fd6db3d385@tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] #20: Section 3.1.2 does not decscribe an issue X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 08:37:25 -0000 I would like to seek Hadriel's opinion on this, because he provided the tex= t for this section. John=20 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: 20 April 2010 12:39 > To: Elwell, John > Cc: martini@ietf.org > Subject: Re: [martini] #20: Section 3.1.2 does not decscribe an issue >=20 > Hi John, >=20 > My point was not that we need to derive a requirement, my point was > that it is not an issue and does therefore not be listed/described as > an issue ;-) >=20 > The main reason that P-Associated-URI is used in the ETSI/3GPP > solution is to provide the P-CSCF (edge proxy) with information about > explicitly and implicitly registered AORs, which allows this edge > proxy to perform its policies regarding P-Preferred-Identity, > P-Asserted-Identity and P-Served-User handling. It was IMHO not ment > for any special processing by the PBX. >=20 > BR, > /Hans Erik van Elburg >=20 > On Tue, Apr 20, 2010 at 12:41 PM, martini issue tracker > wrote: > > #20: Section 3.1.2 does not decscribe an issue > >=20 > -------------------------------------+------------------------ > -------------- > > =A0Reporter: =A0ietf.hanserik@. =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0Own= er: =A0john.elwell@. > > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 Status: =A0new > > =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0M= ilestone: =A0milestone1 > > Component: =A0reqs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0Version: =A01.0 > > =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 =A0| =A0 Resolution: > > =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > >=20 > -------------------------------------+------------------------ > -------------- > > Changes (by john.elwell@.): > > > > =A0* status: =A0reopened =3D> new > > > > > > Comment: > > > > =A0The present text of 3.1.2 states "There is no defined=20 > behavior for the > > =A0SIP-PBX if the PAU header field's list of URIs does not=20 > match what the > > =A0SIP-PBX expects it to be. =A0It is not clear if the SIP-PBX=20 > should de- > > =A0register, re-register, or ignore the difference; nor is=20 > there a way for > > =A0the SIP-PBX to indicate the error in signaling." > > > > =A0I think this is missing some context. I would propose that=20 > we insert text > > =A0at the start of 3.1.2 stating: "Some current=20 > implementations return a list > > =A0of registered AORs in the response, by inclusion of the=20 > P-Associated-URI > > =A0header field." > > > > =A0Concerning Hans Erik's assertion that no requirement has=20 > been derived from > > =A0this, should we add a requirement along the lines of=20 > "REQxx - Any solution > > =A0involving transmitting a list of registered AORs from=20 > SIP-PBX to SSP or > > =A0vice versa MUST define procedures for dealing with the=20 > case where the > > =A0received list does not match expectations."? > > > > =A0Note that since gin does not transmit such a list, it does=20 > not fail this > > =A0requirement. > > > > =A0John > > > > -- > > Ticket URL:=20 > > > martini > > > > > = From trac@tools.ietf.org Thu Apr 22 13:48:08 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5DCE3A6876 for ; Thu, 22 Apr 2010 13:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tffdrQrR6Wqa for ; Thu, 22 Apr 2010 13:48:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B95BA3A6800 for ; Thu, 22 Apr 2010 13:48:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O53JV-00073M-4q; Thu, 22 Apr 2010 13:47:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Thu, 22 Apr 2010 20:47:57 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/38 Message-ID: <076.a6ed9b1d6f5ef0f1b188c29c879902e8@tools.ietf.org> X-Trac-Ticket-ID: 38 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #38: Removal of last 2 paragraphs of section 1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 20:48:09 -0000 #38: Removal of last 2 paragraphs of section 1 ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: reqs | Version: Severity: In WG Last Call | Keywords: ------------------------------------------------+--------------------------- I have received an off-list comment that the following 2 paragraphs at the end of section 1 could be removed, and might be better left for discussion in the context of 'olive' or inclusion in a solutions document: "Telephone numbers are conveyed either as TEL URIs or as SIP URIs. SIP URIs based on E.164 telephone numbers have the property that the domain part is irrelevant, since the fully qualified E.164 number in the user part is globally unique. This makes it easier for both the SIP-PBX and the SSP to share responsibility for routing requests targeted at such a URI: the SSP can perform contact routing for a request targeted at a URI with the SSP domain name, and can change the domain name when forwarding the request to the SIP-PBX; the latter can then perform contact routing to reach a UA registered with the SIP-PBX. Name-based SIP-URIs do not have this property, and an SSP would not be able to change the domain part when forwarding the request with a target URI having the SSP's domain name, yet would be unable to perform contact routing on a request with a target URI having the SIP-PBX's domain name (without some means of acting as a host for the SIP-PBX's domain name). Non-E.164-based telephone numbers (e.g., private numbers) can be conveyed either as TEL URIs or as SIP URIs, and can be made globally unique by means of the phone-context parameter. In this case the domain part of a SIP URI might again be irrelevant. The use of non-E.164-based telephone numbers as AORs is far less common, and therefore this document does not require that support be available. However, it is likely that the solution will not preclude such AORs." Comments? -- Ticket URL: martini From bernard_aboba@hotmail.com Thu Apr 22 14:55:09 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD46E28C0D6 for ; Thu, 22 Apr 2010 14:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.125 X-Spam-Level: ** X-Spam-Status: No, score=2.125 tagged_above=-999 required=5 tests=[AWL=-1.558, BAYES_99=3.5, SARE_OBFU_SPLIT_HR2=0.183] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNOfNOt6-Tld for ; Thu, 22 Apr 2010 14:55:09 -0700 (PDT) Received: from blu0-omc2-s10.blu0.hotmail.com (blu0-omc2-s10.blu0.hotmail.com [65.55.111.85]) by core3.amsl.com (Postfix) with ESMTP id 885433A6AA0 for ; Thu, 22 Apr 2010 14:55:07 -0700 (PDT) Received: from BLU137-DS10 ([65.55.111.72]) by blu0-omc2-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 14:54:57 -0700 X-Originating-IP: [12.19.192.7] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Thu, 22 Apr 2010 14:54:54 -0700 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="utf-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrZybvOXZ7dc6uPTdmyRRGb+Lnm6QInLUrw Content-Language: en-us X-OriginalArrivalTime: 22 Apr 2010 21:54:57.0539 (UTC) FILETIME=[72E14D30:01CAE266] Subject: [martini] MARTINI Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 21:55:09 -0000 BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN='martini@ietf.org';RSVP=TRUE:mailto:martini@ietf.org CLASS:PUBLIC CREATED:20100422T215454Z DESCRIPTION:When: Thursday\, April 29\, 2010 11:00 AM-1:30 PM (UTC-08:00) P acific Time (US & Canada).\nWhere: Webex\n\nNote: The GMT offset above doe s not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~*~*~*\n\n From the secretariat...\n\nIETF Secretariat invites you to attend this onl ine meeting.\n\nTopic: MARTINI WG Meeting\nDate: Thursday\, April 29\, 201 0\nTime: 11:00 am\, Pacific Daylight Time (San Francisco\, GMT-07:00)\nMee ting Number: 967 753 632\nMeeting Password: (This meeting does not require a password.)\n\n\n------------------------------------------------------- \nTo join the online meeting (Now from iPhones too!) \n------------------ ------------------------------------- \n1. Go to https://workgreen.webex.c om/workgreen/j.php?ED=133297667&UID=1122112087&RT=MiM0 \n2. If requested\, enter your name and email address.\n3. If a password is required\, enter the meeting password: (This meeting does not require a password.) \n4. Cli ck "Join".\n\nTo view in other time zones or languages\, please click the link:\nhttps://workgreen.webex.com/workgreen/j.php?ED=133297667&UID=112211 2087&ORT=MiM0\n\n------------------------------------------------------- \ nTo join the audio conference only \n------------------------------------- ------------------ \nTo receive a call back\, provide your phone number wh en you join the meeting\, or call the number below and enter the access co de. \nCall-in toll-free number (US/Canada): 1-866-699-3239\nCall-in toll n umber (US/Canada): 1-408-792-6300\nGlobal call-in numbers: https://workgre en.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=133297667&tollFr ee=1 \nToll-free dialing restrictions: http://www.webex.com/pdf/tollfree_r estrictions.pdf \n\nAccess code:967 753 632\n\n--------------------------- ---------------------------- \nFor assistance \n-------------------------- ----------------------------- \n1. Go to https://workgreen.webex.com/workg reen/mc \n2. On the left navigation bar\, click "Support".\n\nTo add this meeting to your calendar program (for example Microsoft Outlook)\, click t his link: \nhttps://workgreen.webex.com/workgreen/j.php?ED=133297667&UID=1 122112087&ICS=MI&LD=1&RD=2&ST=1&SHA2=9hwQiSdADa3kRhdv3bfVQAx8peXRn2JfyRK2/ iuPFY4=&RT=MiM0\n\nThe playback of UCF (Universal Communications Format) r ich media files requires appropriate players. To view this type of rich me dia files in the meeting\, please check whether you have the players insta lled on your computer by going to https://workgreen.webex.com/workgreen/sy stemdiagnosis.php \n\nSign up for a free trial of WebEx\nhttp://www.webex. com/go/mcemfreetrial\n\nhttp://www.webex.com\n\n========================== ======================================\nAgenda\nMARTINI Virtual Interim IV \nApril 29\, 2010\n11 AM – 1 PM Pacific Time\n\nConferencing Details:\nS lide Presentations: http://www.drizzle.com/~aboba/MARTINI/April-Interim-I V/\nJabber room: martini at jabber.ietf.org (Please join)\nDial in Audioc onference and WebEx details: TBD\n\nAgenda\n\n11 AM - 11:10 AM PT: Prel iminaries\n Conference issues/debugging\n Note Well\n Note Tak ers\n Agenda bash\n\nRequirements (15 minutes)\n\n11:10 AM - 11:25 AM PT MARTINI Requirements Update\, John Elwell (15 minutes)\nhttp://tools.ie tf.org/html/draft-ietf-martini-reqs\n\nSolution Updates (30 minutes)\n\n11 :25 AM – 11:55 AM PT\, MARTINI with Globally Identifiable Numbers\, Adam Roach (30 minutes)\nhttp://tools.ietf.org/html/draft-ietf-martini-gin\n\n Other Identifier Values (30 minutes)\n\n11:55 AM – 12:25 PM\, Other Logi cal Identifier Values (OLIVE)\, Hadriel Kaplan (30 minutes)\nhttp://tools. ietf.org/html/draft-kaplan-martini-with-olive\n\nDiscussion and Wrap-up (3 5 minutes)\n\n12:25 AM – 12:40 PM PT Discussion: Participants (15 minu tes)\n12:40 PM - 12:50 PM PT Hums: WG Chairs (10 minutes)\n12:50 PM – 1 PM PT Next Steps: WG Chairs & ADs (10 minutes)\n\n\n DTEND:20100429T203000Z DTSTAMP:20100422T215454Z DTSTART:20100429T180000Z LAST-MODIFIED:20100422T215454Z LOCATION:Webex ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:3 SUMMARY;LANGUAGE=en-us:MARTINI Virtual Interim IV TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000E03E6F0F8FD9CA01000000000000000 010000000F0896CB950961C4B8B3887130BD0364B X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Thursday\, April 29\, 2010 11:00 AM-1:30 PM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: Webex

\n\n

Note: The GMT offset above does not refl ect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~*~*~*~*

\ n\n

From the secretariat...

\n\n

< SPAN LANG="en-us">IETF Secretariat invites you to attend this online meeting.

\n\n

Topic: MARTINI WG Meeting

\n\n

Date: Thursday\, April 29\, 2010

\n\n

Time: 11:00 am\, Pacific D aylight Time (San Francisco\, GMT-07:00)

\n\n

< SPAN LANG="en-us">Meeting Number: 967 753 632

\n\n

Meeting Password: (This meeting does not require a password.)

\n
\n\n

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

\n\n

To join the online meeting (Now from iPhones too!)

\n\n

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

\ n\n

1. Go to< /FONT> https://workgreen.webex.com/workgr een/j.php?ED=133297667&\;UID=1122112087&\;RT=MiM0< SPAN LANG="en-us">

\n\n

2. If requested\, enter you r name and email address.

\n\n

3. If a password is required\, ente r the meeting password: (This meeting does not require a password.)

\n\n

4. Click "\;Jo in"\;.

\n\n

To view in other time zones or languages\, please clic k the link:

\n\n

https://workgreen.webex.com/workgreen/j.php?ED=13329766 7&\;UID=1122112087&\;ORT=MiM0

\n\n

< /SPAN>--------------------------------------- ----------------

\n\n

To join the audio conference only

\n\n

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

\n\ n

To receive a call back\, provide your phone number when you join the meeting\, or cal l the number below and enter the access code.

\n\n

Call-in toll-free number (US/Canada): 1- 866-699-3239

\n\n

Call-in toll number (US/Canada): 1-408-792-6300

\n\n

< /SPAN>Global call-in numbers: < A HREF="https://workgreen.webex.com/workgreen/globalcallin.php?serviceType =MC&\;ED=133297667&\;tollFree=1">https://workgreen.webex.com/workgreen/globalcallin.php?servic eType=MC&\;ED=133297667&\;tollFree=1

\n\n

Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf

\n\n

< /SPAN>

\n\n

Access code:967 753 632

\n\n< P DIR=LTR>--------- ----------------------------------------------

\n\n

For assistance

\n\n

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

\n\n

1. Go to https://workgreen.webex.com/workgreen/mc

\n\n

2. On the left navigation bar\, click &quo t\;Support"\;.

\n\n

To add this meeting to your calendar progr am (for example Microsoft Outlook)\, click this link:

\n\n

https://work green.webex.com/workgreen/j.php?ED=133297667&\;UID=1122112087&\;ICS= MI&\;LD=1&\;RD=2&\;ST=1&\;SHA2=9hwQiSdADa3kRhdv3bfVQAx8peXRn2J fyRK2/iuPFY4=&\;RT=MiM0

\n\n

The playback of UCF (Universal Communications Fo rmat) rich media files requires appropriate players. To view this type of rich media files in the meeting\, please check whether you have the player s installed on your computer by going to https://workgreen.webex.c om/workgreen/systemdiagnosis.php

\n\n

< /P>\n\n

Sign up for a free trial of WebEx

\n\n

http://www.webex. com/go/mcemfreetrial

\n\n

http://www.webex.com

\n\n

\n\n

================================================================< /FONT>

\n\n

Agenda

\n\n

MARTINI Virtual Interim IV

\n\n< P DIR=LTR>April 29\, 20 10

\n\n

11 AM – 1 PM Pacific Time

\n\n

Conferencing Details:

\n\n

Slide Presentations:  http://www.drizzle.com/~aboba/MARTINI/A pril-Interim-IV/

\n \n

Jabber roo m:  martini at jabber.ietf.org (Please join)

\n\n

Dial in Audioconfer ence and WebEx details:   TBD

\n\n

Agenda

\n\n

11 AM - 11:10 AM PT:  Preliminaries

\n\n

     Conference issues/debugging

\n\n

     Note Well

\n\n

     Note Takers

\n\n

     Agenda bash

\n\n

Requirements (15 minutes)

\n\n

< SPAN LANG="en-us">11:10 AM - 11:25 AM PT M ARTINI Requirements Update\, John Elwell (15 minutes)

\n\ n

h ttp://tools.ietf.org/html/draft-ietf-martini-reqs

\n\n

Solution Updates (30 minutes)

\n\n

11:25 AM – 11:55 AM PT\, MARTINI with Globally Identifiable Numbers\, Adam Roach (30 minutes)

\n\n

< /SPAN>http://tools.ietf.org/html/draft-ietf-martini- gin

\n\n

Other Identifier Values (30 minutes)

\n\n

11:55 AM – 12:25 PM\, Other Logical Identifier Va lues (OLIVE)\, Hadriel Kaplan (30 minutes)

\n\n

http ://tools.ietf.org/html/draft-kaplan-martini-with-olive< /SPAN>

\n\n

Discussion and Wrap-up (35 minutes)

\n\n

1 2:25 AM – 12:40 PM  PT Discussion:  Participants (15 minutes)

\n\n

12:40 PM - 12:50 PM PT  Hums:  WG Chairs (10 minutes)

\n\n

12:50 PM – 1 PM PT   Next Steps:  WG Chairs &\; ADs (10 minutes)

\n\n

\n\n

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-APPTLASTSEQUENCE:2 X-MS-OLK-APPTSEQTIME:20100417T022416Z X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR From trac@tools.ietf.org Thu Apr 22 15:20:29 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2543A6A6C for ; Thu, 22 Apr 2010 15:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IhbepIgjXsf for ; Thu, 22 Apr 2010 15:20:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 17A7D3A6A29 for ; Thu, 22 Apr 2010 15:20:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O54ki-00057H-AZ; Thu, 22 Apr 2010 15:20:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com, bernard_aboba@hotmail.com X-Trac-Project: martini Date: Thu, 22 Apr 2010 22:20:08 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/39 Message-ID: <067.f3a7b7aa7fd51ebcf25b5734dc877c4d@tools.ietf.org> X-Trac-Ticket-ID: 39 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, bernard_aboba@hotmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #39: Section 1 Explanatory Text X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 22:20:29 -0000 #39: Section 1 Explanatory Text ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: john.elwell@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ The last two paragraphs of Section 1 provide background on the issues involved in supporting E.164 numbers versus non-E.164 numbers and name- based URIs. Given the ongoing discussion relating to this (including OLIVE), do we need this text, or can we remove it from the requirements document and put it elsewhere, such as in a solutions document? If we do decide we need this text, is the existing text satisfactory? ================================================================= Telephone numbers are conveyed either as TEL URIs or as SIP URIs. SIP URIs based on E.164 telephone numbers have the property that the domain part is irrelevant, since the fully qualified E.164 number in the user part is globally unique. This makes it easier for both the SIP-PBX and the SSP to share responsibility for routing requests targeted at such a URI: the SSP can perform contact routing for a request targeted at a URI with the SSP domain name, and can change the domain name when forwarding the request to the SIP-PBX; the latter can then perform contact routing to reach a UA registered with the SIP-PBX. Name-based SIP-URIs do not have this property, and an SSP would not be able to change the domain part when forwarding the request with a target URI having the SSP's domain name, yet would be unable to perform contact routing on a request with a target URI having the SIP-PBX's domain name (without some means of acting as a host for the SIP-PBX's domain name). Non-E.164-based telephone numbers (e.g., private numbers) can be conveyed either as TEL URIs or as SIP URIs, and can be made globally unique by means of the phone-context parameter. In this case the domain part of a SIP URI might again be irrelevant. The use of non-E.164-based telephone numbers as AORs is far less common, and therefore this document does not require that support be available. However, it is likely that the solution will not preclude such AORs. -- Ticket URL: martini From trac@tools.ietf.org Thu Apr 22 23:25:24 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417673A6970 for ; Thu, 22 Apr 2010 23:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ctsav0VVUGQ for ; Thu, 22 Apr 2010 23:25:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 36AA83A68D4 for ; Thu, 22 Apr 2010 23:25:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O5CJs-0002QQ-9B; Thu, 22 Apr 2010 23:24:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Fri, 23 Apr 2010 06:24:56 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/38#comment:1 Message-ID: <085.2f899b009adc8e2b1e78ed52fc2eb8e5@tools.ietf.org> References: <076.a6ed9b1d6f5ef0f1b188c29c879902e8@tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <076.a6ed9b1d6f5ef0f1b188c29c879902e8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #38: Removal of last 2 paragraphs of section 1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 06:25:24 -0000 #38: Removal of last 2 paragraphs of section 1 ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: reqs | Version: Severity: In WG Last Call | Resolution: duplicate Keywords: | ------------------------------------------------+--------------------------- Changes (by john.elwell@…): * status: new => closed * resolution: => duplicate Comment: Now duplicated by #39 -- Ticket URL: martini From HKaplan@acmepacket.com Fri Apr 23 07:55:40 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C86063A6A15 for ; Fri, 23 Apr 2010 07:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY8HYHqPBfgt for ; Fri, 23 Apr 2010 07:55:39 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 402D63A68B7 for ; Fri, 23 Apr 2010 07:55:39 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 23 Apr 2010 10:55:27 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Apr 2010 10:55:27 -0400 From: Hadriel Kaplan To: "Elwell, John" , Hans Erik van Elburg Date: Fri, 23 Apr 2010 10:55:11 -0400 Thread-Topic: [martini] #20: Section 3.1.2 does not decscribe an issue Thread-Index: Acrgfgnajd6DiczYT3mDfLR9AgCT9wBeNuOAAD7mAaA= Message-ID: <430FC6BDED356B4C8498F634416644A91A7A06BE07@mail> References: <065.606d2b6083a21b5a6fdc3bf7754c2d3e@tools.ietf.org> <074.dacbac571bc9b4d439bba5fd6db3d385@tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] #20: Section 3.1.2 does not decscribe an issue X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 14:55:40 -0000 Right, no debate it wasn't intended for PBX's in 3gpp's usage of it. As fa= r as I know, it's mostly used today by middleboxes for later authorization = checks for requests coming from the PBX. (or at least that's what SBC's do = with it :) However, in earlier discussions in Martini and in SIP-Forum there was inter= est in using it for provisioning verification (ie, the PBX making sure it a= nd the SSP are in synch about the AoRs). That's what made me add this sect= ion in the problems draft, to avoid the problems we'd seen with PAU previou= sly when even the authorization usage by middleboxes had interop problems w= hen the PAU contents didn't match a format the middlebox expected or knew w= hat to do with. But now that we're not talking about using it for provisioning verification= , I agree this section should be removed as it's no longer applicable. -hadriel > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Thursday, April 22, 2010 4:37 AM >=20 > I would like to seek Hadriel's opinion on this, because he provided the > text for this section. >=20 > John >=20 > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: 20 April 2010 12:39 > > To: Elwell, John > > Cc: martini@ietf.org > > Subject: Re: [martini] #20: Section 3.1.2 does not decscribe an issue > > > > Hi John, > > > > My point was not that we need to derive a requirement, my point was > > that it is not an issue and does therefore not be listed/described as > > an issue ;-) > > > > The main reason that P-Associated-URI is used in the ETSI/3GPP > > solution is to provide the P-CSCF (edge proxy) with information about > > explicitly and implicitly registered AORs, which allows this edge > > proxy to perform its policies regarding P-Preferred-Identity, > > P-Asserted-Identity and P-Served-User handling. It was IMHO not ment > > for any special processing by the PBX. > > > > BR, > > /Hans Erik van Elburg > > > > On Tue, Apr 20, 2010 at 12:41 PM, martini issue tracker > > wrote: > > > #20: Section 3.1.2 does not decscribe an issue > > > > > -------------------------------------+------------------------ > > -------------- > > > =A0Reporter: =A0ietf.hanserik@. =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0O= wner: =A0john.elwell@. > > > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0= =A0 Status: =A0new > > > =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 = =A0Milestone: =A0milestone1 > > > Component: =A0reqs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0Version: =A01.0 > > > =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 =A0| =A0 Resolution: > > > =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > > > > -------------------------------------+------------------------ > > -------------- > > > Changes (by john.elwell@.): > > > > > > =A0* status: =A0reopened =3D> new > > > > > > > > > Comment: > > > > > > =A0The present text of 3.1.2 states "There is no defined > > behavior for the > > > =A0SIP-PBX if the PAU header field's list of URIs does not > > match what the > > > =A0SIP-PBX expects it to be. =A0It is not clear if the SIP-PBX > > should de- > > > =A0register, re-register, or ignore the difference; nor is > > there a way for > > > =A0the SIP-PBX to indicate the error in signaling." > > > > > > =A0I think this is missing some context. I would propose that > > we insert text > > > =A0at the start of 3.1.2 stating: "Some current > > implementations return a list > > > =A0of registered AORs in the response, by inclusion of the > > P-Associated-URI > > > =A0header field." > > > > > > =A0Concerning Hans Erik's assertion that no requirement has > > been derived from > > > =A0this, should we add a requirement along the lines of > > "REQxx - Any solution > > > =A0involving transmitting a list of registered AORs from > > SIP-PBX to SSP or > > > =A0vice versa MUST define procedures for dealing with the > > case where the > > > =A0received list does not match expectations."? > > > > > > =A0Note that since gin does not transmit such a list, it does > > not fail this > > > =A0requirement. > > > > > > =A0John > > > > > > -- > > > Ticket URL: > > > > > martini > > > > > > > > From trac@tools.ietf.org Fri Apr 23 08:10:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A22C3A69FF for ; Fri, 23 Apr 2010 08:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYi4AxrPDicI for ; Fri, 23 Apr 2010 08:10:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0287B3A67D7 for ; Fri, 23 Apr 2010 08:10:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O5KWc-0006kp-K6; Fri, 23 Apr 2010 08:10:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com, ietf.hanserik@gmail.com X-Trac-Project: martini Date: Fri, 23 Apr 2010 15:10:38 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/20#comment:5 Message-ID: <074.a6b3107b52489f6aff5dec6f5f1e809d@tools.ietf.org> References: <065.606d2b6083a21b5a6fdc3bf7754c2d3e@tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <065.606d2b6083a21b5a6fdc3bf7754c2d3e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, ietf.hanserik@gmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #20: Section 3.1.2 does not decscribe an issue X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 15:10:52 -0000 #20: Section 3.1.2 does not decscribe an issue -------------------------------------+-------------------------------------- Reporter: ietf.hanserik@… | Owner: john.elwell@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Changes (by john.elwell@…): * status: new => closed * resolution: => fixed -- Ticket URL: martini From HKaplan@acmepacket.com Fri Apr 23 08:17:34 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150223A67D7 for ; Fri, 23 Apr 2010 08:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlrYJYYnkGyT for ; Fri, 23 Apr 2010 08:17:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4D2BE3A6A15 for ; Fri, 23 Apr 2010 08:16:58 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 23 Apr 2010 11:16:47 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Apr 2010 11:16:46 -0400 From: Hadriel Kaplan To: "adam@nostrum.com" Date: Fri, 23 Apr 2010 11:16:20 -0400 Thread-Topic: [martini] #36: Reg-event package and individual extension state (section 7.2.2) Thread-Index: AcrgDYgzZkdtphqvRNOKsD75Kmel4QC6NFmg Message-ID: <430FC6BDED356B4C8498F634416644A91A7A06BE19@mail> References: <076.62325b62ff853b30a1d2932483b01dc0@tools.ietf.org> <085.ceee3770ac403db1e4a00bf5702eaea8@tools.ietf.org> In-Reply-To: <085.ceee3770ac403db1e4a00bf5702eaea8@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] #36: Reg-event package and individual extension state (section 7.2.2) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 15:17:34 -0000 Huh. This is an interesting issue, because I think it means the bulk regis= tration is not just a short-hand for multiple unique registrations. What I mean is that I was assuming the bulk REGISTER was just a collapsed/c= ompressed form of separate Registrations, and that it really does register = contacts for separate AoRs, which really are the SSP's AoRs, as in "sip:+12= 345@ssp.com". And the SSP Registrar really does have registration state fo= r that AoR: one that has the expanded contact of the PBX, an expires of the= bnc REGISTER, etc. If that's true, I don't see why a SUBSCRIBE to "sip:+12345@ssp.com" for reg= -event should be automatically contact-routed to the PBX. It wouldn't have= been if the registered AoR was "sip:bob@ssp.com", for example. If the subscriber is asking for the reg-event state of "sip:+12345@ssp.com"= , then that's what it should get. It may, upon learning the registered con= tact, send another SUBSCRIBE to the contact itself, which would go to the P= BX, but that's a different target. -hadriel > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of martini issue tracker > Sent: Monday, April 19, 2010 6:13 PM > To: adam@nostrum.com > Cc: martini@ietf.org > Subject: Re: [martini] #36: Reg-event package and individual extension > state (section 7.2.2) >=20 > #36: Reg-event package and individual extension state (section 7.2.2) > ------------------------------------------------+------------------------= - > -- > Reporter: john.elwell@... | Owner: > Type: defect | Status: closed > Priority: minor | Milestone: > milestone1 > Component: gin | Version: > Severity: Active WG Document | Resolution: fixed > Keywords: | > ------------------------------------------------+------------------------= - > -- > Changes (by adam@...): >=20 > * status: new =3D> closed > * resolution: =3D> fixed >=20 >=20 > Comment: >=20 > This is mostly correct. There's nothing that says that the SSP can't, fo= r > example, act as a presence server for the users behind the PBX. That > would > be something that the SSP and PBX owners would need to agree on, of > course. However, you are correct in pointing out that the behavior in > 7.2.2 is a reiteration of the generally expected behavior described in > section 6. This will be clarified as follows: >=20 > As described in section 6, the > SSP will generally retarget all requests addressed to > a phone number owned by a PBX to that PBX according > to the mapping established at registration time. > Although policy at the SSP may override this generally > expected behavior, proper behavior of the registration > event package requires that all "reg" event SUBSCRIBE > requests are processed by the PBX. As a consequence, > the requirements on an SSP for processing registration > event package SUBSCRIBE requests are not left to policy. >=20 > This also highlights the fact that there are no normative requirements t= o > handle INVITE in this way -- I've added some text to section 6 to both > clarify that the processing generally applies to any method, and that it > is mandatory for INVITE. >=20 > -- > Ticket URL: > > martini >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From trac@tools.ietf.org Fri Apr 23 08:37:32 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954AC3A69D6 for ; Fri, 23 Apr 2010 08:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOuBmVBkkhDH for ; Fri, 23 Apr 2010 08:37:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 78C8E3A695E for ; Fri, 23 Apr 2010 08:37:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O5KwR-0002di-He; Fri, 23 Apr 2010 08:37:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com, hkaplan@acmepacket.com X-Trac-Project: martini Date: Fri, 23 Apr 2010 15:37:19 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/36#comment:2 Message-ID: <085.84c1370badd6cfbb13674c3d039f1220@tools.ietf.org> References: <076.62325b62ff853b30a1d2932483b01dc0@tools.ietf.org> X-Trac-Ticket-ID: 36 In-Reply-To: <076.62325b62ff853b30a1d2932483b01dc0@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, hkaplan@acmepacket.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #36: Reg-event package and individual extension state (section 7.2.2) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 15:37:32 -0000 #36: Reg-event package and individual extension state (section 7.2.2) ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: Type: defect | Status: reopened Priority: minor | Milestone: milestone1 Component: gin | Version: Severity: Active WG Document | Resolution: Keywords: | ------------------------------------------------+--------------------------- Changes (by hkaplan@…): * status: closed => reopened * resolution: fixed => Comment: I don't see why this should act any differently from reg-event for any other AoR of the SSP. If a SUBSCRIBE request for the reg-event package is targeted at "sip:+12345@ssp.com", then it is asking for registration state info of that AoR. The PBX does not know that information. Only the Registrar or something with access to the location service database knows that information. For example, there may be other registered contacts for that AoR, or no registered contacts currently (no PBX). The register state-machine described in RFC 3680 for the resource identified by the target is the one in the SSP for that AoR, not the PBX. -- Ticket URL: martini From BLINDSAY@nortel.com Fri Apr 23 11:49:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3B53A6AB0 for ; Fri, 23 Apr 2010 11:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.569 X-Spam-Level: X-Spam-Status: No, score=-5.569 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqAW7g4hmcIR for ; Fri, 23 Apr 2010 11:49:44 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1953F3A6A00 for ; Fri, 23 Apr 2010 11:49:43 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o3NImud08498; Fri, 23 Apr 2010 18:48:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Apr 2010 14:48:34 -0400 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141D3DBECE@zcarhxm1.corp.nortel.com> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A7A06BE19@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 7.1.1 Public GRUUs in GIN Draft Thread-Index: AcrgDYgzZkdtphqvRNOKsD75Kmel4QC6NFmgAAcuQQA= References: <076.62325b62ff853b30a1d2932483b01dc0@tools.ietf.org><085.ceee3770ac403db1e4a00bf5702eaea8@tools.ietf.org> <430FC6BDED356B4C8498F634416644A91A7A06BE19@mail> From: "Brian Lindsay" To: , Subject: [martini] 7.1.1 Public GRUUs in GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 18:49:46 -0000 Hi Adam/all, Regarding section 7.1.1, there is the following text: "When an incoming request arrives at the SSP for a GRUU corresponding to a bulk number contact ("bnc"), the SSP performs slightly different processing for the GRUU than a Proxy/Registrar would. When the GRUU is retargeted to the registered bulk number contact, the SSP MUST copy the "sg" parameter from the GRUU to the new target. The PBX can then use this "sg" parameter to determine which user agent the request should be routed to. For example, the first line of an INVITE request that has been retargeted to the PBX for the terminal shown above would look like this: INVITE sip:+12145550102@198.51.100.3;gr=3Durn:uuid:f81d4fae-7dec- 11d0-a765-00a0c91e6bf6;sg=3D00:05:03:5e:70:a6 SIP/2.0 " The text above calls out the "sg" parm is copied to the new target, but it doesn't explicitly mention the "gr" parm being copied. RFC 5627 states regarding request targeting : "[...] the Request-URI will be rewritten with the registered contacts, replacing the GRUU and its "gr" URI parameter. The "gr" URI parameter is not carried forward into the rewritten Request-URI." It seems like the text would need to be modified to also note the deviation from RFC 5627 in terms of handling of the gr parm itself (unless I'm missing something?). Thanks Brian =20 From adam@nostrum.com Fri Apr 23 11:52:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE663A6A00 for ; Fri, 23 Apr 2010 11:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2v6i443xGkn1 for ; Fri, 23 Apr 2010 11:52:41 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 3F5D73A681D for ; Fri, 23 Apr 2010 11:52:41 -0700 (PDT) Received: from [172.16.3.81] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3NIqSFn029308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Apr 2010 13:52:29 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BD1EC6C.20302@nostrum.com> Date: Fri, 23 Apr 2010 13:52:28 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Brian Lindsay References: <076.62325b62ff853b30a1d2932483b01dc0@tools.ietf.org><085.ceee3770ac403db1e4a00bf5702eaea8@tools.ietf.org> <430FC6BDED356B4C8498F634416644A91A7A06BE19@mail> <09B7DBFE70A9E24BBB21689DAD3A06141D3DBECE@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141D3DBECE@zcarhxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] 7.1.1 Public GRUUs in GIN Draft X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 18:52:42 -0000 On 04/23/2010 01:48 PM, Brian Lindsay wrote: > It seems like the text would need to be modified to also note the > deviation from RFC 5627 in terms of handling of the gr parm itself > (unless I'm missing something?). > Good catch. The text is correct -- the example is wrong. /a From bernard_aboba@hotmail.com Sat Apr 24 11:12:35 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973163A6A3E for ; Sat, 24 Apr 2010 11:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.083 X-Spam-Level: ** X-Spam-Status: No, score=2.083 tagged_above=-999 required=5 tests=[AWL=-1.418, BAYES_99=3.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9f2Xe0-0MU6r for ; Sat, 24 Apr 2010 11:12:35 -0700 (PDT) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by core3.amsl.com (Postfix) with ESMTP id C1CAE3A6A0F for ; Sat, 24 Apr 2010 11:12:14 -0700 (PDT) Received: from BLU137-W13 ([65.55.111.72]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Apr 2010 11:12:04 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_87ff5f00-22f7-48f5-8fc1-c53ba8cafece_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Sat, 24 Apr 2010 11:12:03 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 24 Apr 2010 18:12:04.0124 (UTC) FILETIME=[A4879DC0:01CAE3D9] Subject: [martini] MARTINI Virtual Interim V dates X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 18:12:35 -0000 --_87ff5f00-22f7-48f5-8fc1-c53ba8cafece_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looking at the responses to the Doodle poll on the potential MARTINI Virtua= l Interim V dates=2C it would appear that there is no single date/time that= is available to a wide number of participants. Also=2C it has been brough= t to our attention that the dates conflict with a conference that some of t= he key participants will be attending.=20 Given this=2C we are going to try again with dates in mid-June. =20 = --_87ff5f00-22f7-48f5-8fc1-c53ba8cafece_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looking at the responses to the Doodle poll on the potential MARTINI Virtua= l Interim V dates=2C it would appear that there is no single date/time that= is available to a wide number of participants. =3B Also=2C it has been= brought to our attention that the dates conflict with a conference that so= me of the key participants will be attending.

Given this=2C we are = going to try again with dates in mid-June. =3B
= --_87ff5f00-22f7-48f5-8fc1-c53ba8cafece_-- From bernard_aboba@hotmail.com Sun Apr 25 14:49:31 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4EC13A67D9 for ; Sun, 25 Apr 2010 14:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.11 X-Spam-Level: ** X-Spam-Status: No, score=2.11 tagged_above=-999 required=5 tests=[AWL=-1.391, BAYES_99=3.5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxuV+hVQnksM for ; Sun, 25 Apr 2010 14:49:31 -0700 (PDT) Received: from blu0-omc2-s31.blu0.hotmail.com (blu0-omc2-s31.blu0.hotmail.com [65.55.111.106]) by core3.amsl.com (Postfix) with ESMTP id EAD9C3A677E for ; Sun, 25 Apr 2010 14:49:30 -0700 (PDT) Received: from BLU137-W12 ([65.55.111.73]) by blu0-omc2-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Apr 2010 14:49:19 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_1982d720-aae8-4274-9daf-504178a75e4f_" X-Originating-IP: [68.178.109.243] From: Bernard Aboba To: Date: Sun, 25 Apr 2010 14:49:19 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 25 Apr 2010 21:49:19.0537 (UTC) FILETIME=[28A78A10:01CAE4C1] Subject: [martini] MARTINI Virtual Interim V Doodle Poll - Take Two X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 21:49:32 -0000 --_1982d720-aae8-4274-9daf-504178a75e4f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Given the conflicts discovered during the week of May 17=2C we are going to= try another Doodle Poll for MARTINI Virtual Interim V=2C this time for the= week of June 14=2C 2010. Let us know your availability for the new set of potential dates/times by r= esponding to the new Doodle Poll: http://www.doodle.com/8wcp4a2ye7bbq42v = --_1982d720-aae8-4274-9daf-504178a75e4f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Given the conflicts discovered during the week of May 17=2C we are going to= try another Doodle Poll for MARTINI Virtual Interim V=2C this time for the= week of June 14=2C 2010.

Let us know your availability for the new = set of potential dates/times by responding to the new Doodle Poll:
http:= //www.doodle.com/8wcp4a2ye7bbq42v



= --_1982d720-aae8-4274-9daf-504178a75e4f_-- From bernard_aboba@hotmail.com Sun Apr 25 16:24:57 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E783A68BF for ; Sun, 25 Apr 2010 16:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.713 X-Spam-Level: X-Spam-Status: No, score=0.713 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeXOlR3eHxGx for ; Sun, 25 Apr 2010 16:24:56 -0700 (PDT) Received: from blu0-omc2-s2.blu0.hotmail.com (blu0-omc2-s2.blu0.hotmail.com [65.55.111.77]) by core3.amsl.com (Postfix) with ESMTP id 114C83A69E5 for ; Sun, 25 Apr 2010 16:24:54 -0700 (PDT) Received: from BLU137-W27 ([65.55.111.72]) by blu0-omc2-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Apr 2010 16:24:43 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_87042340-34e4-4d2a-8f80-f85803e9d970_" X-Originating-IP: [68.178.109.243] From: Bernard Aboba To: Date: Sun, 25 Apr 2010 16:24:43 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 25 Apr 2010 23:24:43.0624 (UTC) FILETIME=[7C79E680:01CAE4CE] Subject: [martini] Slides & Agenda Bash: MARTINI Virtual Interim IV (April 29, 2010) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 23:24:57 -0000 --_87042340-34e4-4d2a-8f80-f85803e9d970_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yet another reminder that the MARTINI WG will be holding a Virtual Interim = meeting on Thursday=2C April 29=2C 2010.=20 For details=2C see: http://www.ietf.org/mail-archive/web/martini/current/msg01389.html If you have a new agenda item for the meeting=2C please let Spencer and mys= elf know ASAP. We did schedule a bit of extra time on WebEx (so we wouldn'= t be cut off in mid-sentence)=2C so while the agenda is somewhat tight=2C w= e can probably still fit you in.=20 Also=2C if you are already on the agenda=2C we would like to get your slide= s by Tuesday=2C April 27=2C 2010 so we can get them online well before the = meeting.=20 = --_87042340-34e4-4d2a-8f80-f85803e9d970_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yet another reminder that the MARTINI WG will be holding a Virtual Interim = meeting on Thursday=2C April 29=2C 2010.

For details=2C see:
htt= p://www.ietf.org/mail-archive/web/martini/current/msg01389.html

If y= ou have a new agenda item for the meeting=2C please let Spencer and myself = know ASAP. =3B We did schedule a bit of extra time on WebEx (so we woul= dn't be cut off in mid-sentence)=2C so while the agenda is somewhat tight= =2C we can probably still fit you in.

Also=2C if you are already on= the agenda=2C we would like to get your slides by Tuesday=2C April 27=2C 2= 010 so we can get them online well before the meeting.
= --_87042340-34e4-4d2a-8f80-f85803e9d970_-- From dean.willis@softarmor.com Sun Apr 25 23:00:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ED863A67F9 for ; Sun, 25 Apr 2010 23:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.075 X-Spam-Level: X-Spam-Status: No, score=-1.075 tagged_above=-999 required=5 tests=[AWL=-1.076, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3biGAwDyUTH for ; Sun, 25 Apr 2010 23:00:17 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B22EB3A67B4 for ; Sun, 25 Apr 2010 23:00:15 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3Q6005U011721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Apr 2010 01:00:01 -0500 Message-Id: <2089EB21-5B50-43A7-AEA6-C4A238E7F7A1@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: <430FC6BDED356B4C8498F634416644A91A7A06BE19@mail> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Apr 2010 00:59:54 -0500 References: <076.62325b62ff853b30a1d2932483b01dc0@tools.ietf.org> <085.ceee3770ac403db1e4a00bf5702eaea8@tools.ietf.org> <430FC6BDED356B4C8498F634416644A91A7A06BE19@mail> X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" Subject: Re: [martini] #36: Reg-event package and individual extension state (section 7.2.2) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 06:00:18 -0000 On Apr 23, 2010, at 10:16 AM, Hadriel Kaplan wrote: > > Huh. This is an interesting issue, because I think it means the > bulk registration is not just a short-hand for multiple unique > registrations. > > What I mean is that I was assuming the bulk REGISTER was just a > collapsed/compressed form of separate Registrations, and that it > really does register contacts for separate AoRs, which really are > the SSP's AoRs, as in "sip:+12345@ssp.com". And the SSP Registrar > really does have registration state for that AoR: one that has the > expanded contact of the PBX, an expires of the bnc REGISTER, etc. > > If that's true, I don't see why a SUBSCRIBE to "sip:+12345@ssp.com" > for reg-event should be automatically contact-routed to the PBX. It > wouldn't have been if the registered AoR was "sip:bob@ssp.com", for > example. I'm thinking along similar lines. Assumption #1 for MARTINI (at least at this phase) is that we're doing a bulk registration that produces a result which can not be externally distinguished from multiple unique registrations. It's not a new routing model -- it is just a bulk registration. I'd LIKE to do a new routing model, but that's a bigger more complex thing that can be handled separately. -- Dean From bernard_aboba@hotmail.com Mon Apr 26 00:07:21 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A77C3A67F0 for ; Mon, 26 Apr 2010 00:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_60=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+6K3W-yDHhm for ; Mon, 26 Apr 2010 00:07:19 -0700 (PDT) Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by core3.amsl.com (Postfix) with ESMTP id 203A13A6800 for ; Mon, 26 Apr 2010 00:07:19 -0700 (PDT) Received: from BLU137-W4 ([65.55.111.71]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 00:07:04 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_80f436d5-0c9c-4c08-a73b-7c76680610ad_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Mon, 26 Apr 2010 00:07:03 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2010 07:07:05.0458 (UTC) FILETIME=[13E5D520:01CAE50F] Subject: Re: [martini] #36: Reg-event package and individual extension state (section 7.2.2) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 07:07:21 -0000 --_80f436d5-0c9c-4c08-a73b-7c76680610ad_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dean Willis said: "Assumption #1 for MARTINI (at least at this phase) is that we're=20 doing =20 a bulk registration that produces a result which can not be=20 externally =20 distinguished from multiple unique registrations. It's not a=20 new =20 routing model -- it is just a bulk registration. " [BA] Speaking with chair hat off --=20 At various points=2C I have wondered about whether this was just an assumpt= ion=2C or something more akin to a tenet or a boundary condition. Having a= "multiple AoR registration" procedure that doesn't produce the same result= s as a "single AoR registration" when there is only one AoR involved seems = to violate the principle of least astonishment=2C at least for me.=20 = --_80f436d5-0c9c-4c08-a73b-7c76680610ad_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dean Willis said:

"Assumption #1 for MARTINI (at least at this p= hase) is that we're=20 doing =20 a bulk registration that produces a result which can not be=20 externally =20 distinguished from multiple unique registrations. It's not a=20 new =20 routing model -- it is just a bulk registration. "

[BA] Speaking with chair hat off --

At various points= =2C I have wondered about whether this was just an assumption=2C or somethi= ng more akin to a tenet or a boundary condition. =3B Having a "multiple= AoR registration" procedure that doesn't produce the same results as a "si= ngle AoR registration" when there is only one AoR involved seems to violate= the principle of least astonishment=2C at least for me.





= --_80f436d5-0c9c-4c08-a73b-7c76680610ad_-- From trac@tools.ietf.org Mon Apr 26 01:26:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C040B3A6A66 for ; Mon, 26 Apr 2010 01:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDjlOBlFUrY5 for ; Mon, 26 Apr 2010 01:26:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C6F663A6954 for ; Mon, 26 Apr 2010 01:24:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6Jbw-00082o-5f; Mon, 26 Apr 2010 01:24:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Mon, 26 Apr 2010 08:24:12 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/15#comment:1 Message-ID: <074.debd425b495e8a8c4dd7f096b02116ed@tools.ietf.org> References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #15: support for non E.164 numbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 08:26:31 -0000 #15: support for non E.164 numbers -------------------------------------+-------------------------------------- Reporter: ietf.hanserik@… | Owner: Type: defect | Status: closed Priority: critical | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Resolution: wontfix Keywords: | -------------------------------------+-------------------------------------- Changes (by john.elwell@…): * status: new => closed * resolution: => wontfix Comment: This is being discussed in the context of the olive draft. In addition, there was agreement at IETF#77 to add text explaining the limitations, which was done in -03. -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 26 01:28:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 822783A6954 for ; Mon, 26 Apr 2010 01:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUiKpcyxOGxf for ; Mon, 26 Apr 2010 01:28:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E8D5D3A6A0A for ; Mon, 26 Apr 2010 01:27:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6Jek-0002J6-Pu; Mon, 26 Apr 2010 01:27:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: bernard_aboba@hotmail.com, john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Mon, 26 Apr 2010 08:27:06 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/16#comment:3 Message-ID: <074.386dd14bf545f1124536348f72685898@tools.ietf.org> References: <065.111f925a59a8643c429a6e1e5e86d2da@tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <065.111f925a59a8643c429a6e1e5e86d2da@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #16: Extensibility to support any AOR X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 08:28:30 -0000 #16: Extensibility to support any AOR -------------------------------------+-------------------------------------- Reporter: ietf.hanserik@… | Owner: Type: enhancement | Status: closed Priority: critical | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Resolution: wontfix Keywords: | -------------------------------------+-------------------------------------- Changes (by john.elwell@…): * status: reopened => closed * resolution: => wontfix Comment: This is being discussed in the context of the olive draft. In addition, there was agreement at IETF#77 to add text explaining the limitations, which was done in -03. -- Ticket URL: martini From trac@tools.ietf.org Mon Apr 26 01:32:02 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6BF63A684C for ; Mon, 26 Apr 2010 01:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MP3j3DaaXhVS for ; Mon, 26 Apr 2010 01:32:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6E6163A6A28 for ; Mon, 26 Apr 2010 01:31:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6Jiv-0001uC-5Y; Mon, 26 Apr 2010 01:31:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Mon, 26 Apr 2010 08:31:25 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/39#comment:1 Message-ID: <076.471a6d21a78cc72dd1fa2c1cea5bc66f@tools.ietf.org> References: <067.f3a7b7aa7fd51ebcf25b5734dc877c4d@tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <067.f3a7b7aa7fd51ebcf25b5734dc877c4d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #39: Section 1 Explanatory Text X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 08:32:02 -0000 #39: Section 1 Explanatory Text ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: john.elwell@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Comment(by john.elwell@…): I believe the consensus at IETF#77 was to put such text into the Requirements draft (statement from Jon Peterson, marked as "agreed"). I guess we could discuss again in the context of olive - other opinions? John -- Ticket URL: martini From dean.willis@softarmor.com Mon Apr 26 02:08:51 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC5A3A6A9F for ; Mon, 26 Apr 2010 02:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[AWL=-1.011, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLC5ZCz5wLZg for ; Mon, 26 Apr 2010 02:08:50 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2ABF03A6A72 for ; Mon, 26 Apr 2010 02:08:49 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3Q98YTV012842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Apr 2010 04:08:36 -0500 Message-Id: <02793872-EE56-4397-A077-8F94B16CEBA8@softarmor.com> From: Dean Willis To: Bernard Aboba In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Apr 2010 04:08:29 -0500 References: X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] #36: Reg-event package and individual extension state (section 7.2.2) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 09:08:51 -0000 On Apr 26, 2010, at 2:07 AM, Bernard Aboba wrote: > Dean Willis said: > > "Assumption #1 for MARTINI (at least at this phase) is that we're > doing a bulk registration that produces a result which can not be > externally distinguished from multiple unique registrations. It's > not a new routing model -- it is just a bulk registration. " > > [BA] Speaking with chair hat off -- > > At various points, I have wondered about whether this was just an > assumption, or something more akin to a tenet or a boundary > condition. Having a "multiple AoR registration" procedure that > doesn't produce the same results as a "single AoR registration" when > there is only one AoR involved seems to violate the principle of > least astonishment, at least for me. While I agree, it is notable that a number of the proposals made on- list crossed this boundary condition, sometimes dramatically. For example, proposals wherein a MARTINI registration would cause the proxy to do something other than RFC 3261 contact-routing, such as perhaps loose-routing an unchanged request-URI towards the PBX, don't work like single registrations. While I think using loose-routing to solve the request-URI dispatch problem is a reasonable thing, doing it at a proxy in response to a REGISTER seems to be likely to get strange. I could see a MARTINI phase-2 that uses loose routing, perhaps in combination with PUBLISHed routes instead of REGISTERed contacts. We've also got a contingent that favors the IMS model, which again is subtly different (arguably in very useful ways) from "ordinary" registration. So perhaps we should find a way to carve "MARTINI phase 1 is bulk registration" into granite monoliths... -- Dean From john.elwell@siemens-enterprise.com Mon Apr 26 02:12:36 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2252328C10A for ; Mon, 26 Apr 2010 02:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_05=-1.11, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BTePlfGlthS for ; Mon, 26 Apr 2010 02:12:35 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id DD16828C0F7 for ; Mon, 26 Apr 2010 02:11:59 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1669233 for martini@ietf.org; Mon, 26 Apr 2010 11:11:47 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 012FB23F0278 for ; Mon, 26 Apr 2010 11:11:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 26 Apr 2010 11:11:47 +0200 From: "Elwell, John" To: "martini@ietf.org" Date: Mon, 26 Apr 2010 11:11:45 +0200 Thread-Topic: draft-ietf-martini-reqs-04 available Thread-Index: AcrlIH4hXGJ6zBCoTB6RoFrmhbtOQA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [martini] draft-ietf-martini-reqs-04 available X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 09:12:36 -0000 http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-04.txt Changes: - deletion of 3.1.2 (resolution of #20) - clarification to title of 3.2 - revised title and text of 3.2.2 (arising from discussion of #21) - addition of REQ19 in place of DES4 (resolution of #23) At this point in time, the only issue still open is #39. John From root@core3.amsl.com Mon Apr 26 02:15:02 2010 Return-Path: X-Original-To: martini@ietf.org Delivered-To: martini@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5A52B3A6AF8; Mon, 26 Apr 2010 02:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100426091502.5A52B3A6AF8@core3.amsl.com> Date: Mon, 26 Apr 2010 02:15:02 -0700 (PDT) Cc: martini@ietf.org Subject: [martini] I-D Action:draft-ietf-martini-reqs-04.txt X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 09:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple AoR reachabiliTy InformatioN Indication Working Group of the IETF. Title : Requirements for multiple address of record (AOR) reachability information in the Session Initiation Protocol (SIP) Author(s) : J. Elwell, H. Kaplan Filename : draft-ietf-martini-reqs-04.txt Pages : 13 Date : 2010-04-26 This document states requirements for a standardized SIP registration mechanism for multiple addresses of record, the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized PBXs. The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. This work is being discussed on the martini@ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-martini-reqs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-26020629.I-D@ietf.org> --NextPart-- From john.elwell@siemens-enterprise.com Mon Apr 26 02:39:07 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833B93A685D for ; Mon, 26 Apr 2010 02:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[AWL=-1.099, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Muz9Ifm7tybB for ; Mon, 26 Apr 2010 02:39:06 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 889C33A68A5 for ; Mon, 26 Apr 2010 02:38:59 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1670277; Mon, 26 Apr 2010 11:38:47 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 32FCA23F0294; Mon, 26 Apr 2010 11:38:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 26 Apr 2010 11:38:47 +0200 From: "Elwell, John" To: Bernard Aboba , "martini@ietf.org" Date: Mon, 26 Apr 2010 11:38:46 +0200 Thread-Topic: [martini] MARTINI Virtual Interim V Doodle Poll - Take Two Thread-Index: AcrkwSs4Cj7cZyBZSROLvP+OmPtUTAAYpLug Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A444A0F8084434499206E78C106220CAE31805CAMCHP058Aglobala_" MIME-Version: 1.0 Subject: Re: [martini] MARTINI Virtual Interim V Doodle Poll - Take Two X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 09:39:07 -0000 --_000_A444A0F8084434499206E78C106220CAE31805CAMCHP058Aglobala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard, I am always curious what the convention is for filling these in for a 2 hou= r meeting (which I assume this is). For example, if I am available for a 2 = hour meeting starting at 15.00 but not available from 17.00, do I tick 15.0= 0 and 16.00 (to indicate the two 1-hour slots are free) or do I just tick 1= 5.00 (because I would not be available for a 2 hour meeting starting at 16.= 00)? I have assumed the latter. John ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Bernard Aboba Sent: 25 April 2010 22:49 To: martini@ietf.org Subject: [martini] MARTINI Virtual Interim V Doodle Poll - Take Two Given the conflicts discovered during the week of May 17, we are going to t= ry another Doodle Poll for MARTINI Virtual Interim V, this time for the wee= k of June 14, 2010. Let us know your availability for the new set of potential dates/times by r= esponding to the new Doodle Poll: http://www.doodle.com/8wcp4a2ye7bbq42v --_000_A444A0F8084434499206E78C106220CAE31805CAMCHP058Aglobala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bernard,
 
I am always curious what the convention is for filling thes= e in=20 for a 2 hour meeting (which I assume this is). For example, if I am availab= le=20 for a 2 hour meeting starting at 15.00 but not available from 17.00, do I t= ick=20 15.00 and 16.00 (to indicate the two 1-hour slots are free) or do I just ti= ck=20 15.00 (because I would not be available for a 2 hour meeting starting at 16= .00)?=20 I have assumed the latter.
 
John

From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: 25 April 2010 22:49
To:=20 martini@ietf.org
Subject: [martini] MARTINI Virtual Interim V D= oodle=20 Poll - Take Two

Given the conflicts discovered during the week of May 17, we a= re=20 going to try another Doodle Poll for MARTINI Virtual Interim V, this time= for=20 the week of June 14, 2010.

Let us know your availability for the n= ew=20 set of potential dates/times by responding to the new Doodle=20 Poll:
http://www.doodle.com/8wcp4a2ye7bbq42v



= --_000_A444A0F8084434499206E78C106220CAE31805CAMCHP058Aglobala_-- From bernard_aboba@hotmail.com Mon Apr 26 09:10:09 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C4CD3A6B34 for ; Mon, 26 Apr 2010 09:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.404 X-Spam-Level: X-Spam-Status: No, score=0.404 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylNOG950YL4i for ; Mon, 26 Apr 2010 09:10:04 -0700 (PDT) Received: from blu0-omc3-s38.blu0.hotmail.com (blu0-omc3-s38.blu0.hotmail.com [65.55.116.113]) by core3.amsl.com (Postfix) with ESMTP id D992B28C126 for ; Mon, 26 Apr 2010 09:08:23 -0700 (PDT) Received: from BLU137-W16 ([65.55.116.72]) by blu0-omc3-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 09:08:12 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_67765095-dc72-491d-8d74-8eecc9135b95_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , Date: Mon, 26 Apr 2010 09:08:12 -0700 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2010 16:08:12.0112 (UTC) FILETIME=[AB881500:01CAE55A] Subject: Re: [martini] MARTINI Virtual Interim V Doodle Poll - Take Two X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 16:10:09 -0000 --_67765095-dc72-491d-8d74-8eecc9135b95_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An hour can be filled in as available if you're free for the entire hour. = =20 On evaluating the potential times we will look for consecutive slots that a= re free for the most participants. =20 = --_67765095-dc72-491d-8d74-8eecc9135b95_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An hour can be filled in as available if you're free for the entire hour.&n= bsp=3B

On evaluating the potential times we will look for consecuti= ve slots that are free for the most participants. =3B
<= /body> = --_67765095-dc72-491d-8d74-8eecc9135b95_-- From ietf.hanserik@gmail.com Mon Apr 26 11:36:06 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA5E3A6A4A for ; Mon, 26 Apr 2010 11:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLzS2GGse5LI for ; Mon, 26 Apr 2010 11:36:05 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 7EAD33A697A for ; Mon, 26 Apr 2010 11:36:05 -0700 (PDT) Received: by ewy24 with SMTP id 24so3793626ewy.13 for ; Mon, 26 Apr 2010 11:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=F5vxbwjwEwB9rbkh6S98i/VjHF+xQzQHflX9ULrAb9s=; b=oD9/7ZWxJ9vCdh8rvgYZ6CJ2pk3+So4Bsdm4Na4ofOuycoGFjY9eDiMPVy3+/gB6yM Q7fKPKSmU4/jEpiLeA6xQlbptCUjR8rr0Lq4xa0ImRFYnX3/QlFv+sAW1R21sEMezo+A 3hfanSrtqY99sdsIPgOaGoMhNI3ylkPa1dLLg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CWFV2HxpmgXatxEAEC+RcDDdxmrsURaRV8bjXQamoezuutO88RwWD86LY9DDwzsw4a tuS59sargHGCny3jv/wEgVDzHBDPieNKug7RQI/cZ5HVJK+fCk0krUuExR05DL5cw1yB GRxUs3Iz5qGCF5hKCVPD3z/ZKckwzh01qD+8o= MIME-Version: 1.0 Received: by 10.213.51.78 with SMTP id c14mr1844495ebg.89.1272306950335; Mon, 26 Apr 2010 11:35:50 -0700 (PDT) Received: by 10.213.15.138 with HTTP; Mon, 26 Apr 2010 11:35:50 -0700 (PDT) In-Reply-To: <074.386dd14bf545f1124536348f72685898@tools.ietf.org> References: <065.111f925a59a8643c429a6e1e5e86d2da@tools.ietf.org> <074.386dd14bf545f1124536348f72685898@tools.ietf.org> Date: Mon, 26 Apr 2010 20:35:50 +0200 Message-ID: From: Hans Erik van Elburg To: martini issue tracker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: bernard_aboba@hotmail.com, martini@ietf.org Subject: Re: [martini] #16: Extensibility to support any AOR X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 18:36:06 -0000 I do not agree that this has been sufficiently covered in the new version 04. Please reopen this issue. There was a very clear proposal in the ticket. /Hans Erik van Elburg On Mon, Apr 26, 2010 at 10:27 AM, martini issue tracker wrote: > #16: Extensibility to support any AOR > -------------------------------------+-----------------------------------= --- > =A0Reporter: =A0ietf.hanserik@=85 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0Own= er: > =A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 Sta= tus: =A0closed > =A0Priority: =A0critical =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Milesto= ne: =A0milestone1 > Component: =A0reqs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0V= ersion: =A01.0 > =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 =A0| =A0 Resolution: =A0w= ontfix > =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > -------------------------------------+-----------------------------------= --- > Changes (by john.elwell@=85): > > =A0* status: =A0reopened =3D> closed > =A0* resolution: =A0=3D> wontfix > > > Comment: > > =A0This is being discussed in the context of the olive draft. In addition= , > =A0there was agreement at IETF#77 to add text explaining the limitations, > =A0which was done in -03. > > -- > Ticket URL: > martini > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From ietf.hanserik@gmail.com Mon Apr 26 11:38:35 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E66F3A6AC3 for ; Mon, 26 Apr 2010 11:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOhmpjcNGutl for ; Mon, 26 Apr 2010 11:38:34 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 015623A6AC2 for ; Mon, 26 Apr 2010 11:38:33 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so864632eyf.51 for ; Mon, 26 Apr 2010 11:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=a9etfYa4tLXSLMEl1DBUeGuWBCEifLGv+0VjhKZ+5SQ=; b=jRrNN9XSUsE0Pw8zICBOP4BDIElAO8x8HS5y584GU2eHk2WACSlXRF0oTTJ6yvyKSl uphyDHPt+VtcQKEI1nG9B6qc8ns5XXhjt/xBbRSSjqmwyAAgoWj4Q/0FGVRNxrho+Nre Z6i3ni7ISnjtWC15M42RoGA/4OQ2d6XzqmqEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=V+nCg2ox8l2/z4vIkQ2lVuSfeioRQ2ouoXtVGFxG0QfQiyecouRXI6yBixUAktziIs 2PpyeDdZ2S+01SXq5OUyih88qSgm+a6XGbggasyn+7r2m6hIRck+5Ec4c7V5EjPIp0KQ Z0tx5NHK5jQ7clIDFrZRwo7w7b+5QwC8ekpeQ= MIME-Version: 1.0 Received: by 10.213.47.202 with SMTP id o10mr2163891ebf.33.1272307098270; Mon, 26 Apr 2010 11:38:18 -0700 (PDT) Received: by 10.213.15.138 with HTTP; Mon, 26 Apr 2010 11:38:17 -0700 (PDT) In-Reply-To: <074.debd425b495e8a8c4dd7f096b02116ed@tools.ietf.org> References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org> <074.debd425b495e8a8c4dd7f096b02116ed@tools.ietf.org> Date: Mon, 26 Apr 2010 20:38:17 +0200 Message-ID: From: Hans Erik van Elburg To: martini issue tracker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: martini@ietf.org Subject: Re: [martini] #15: support for non E.164 numbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 18:38:35 -0000 Indeed this is being partly addressed in the olive draft, which shows that there is a need for this. Therefore please incorporate the requirement as was proposed in the original ticket. /Hans Erik van Elburg On Mon, Apr 26, 2010 at 10:24 AM, martini issue tracker wrote: > #15: support for non E.164 numbers > -------------------------------------+-----------------------------------= --- > =A0Reporter: =A0ietf.hanserik@=85 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0Own= er: > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0= Status: =A0closed > =A0Priority: =A0critical =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Milesto= ne: =A0milestone1 > Component: =A0reqs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0V= ersion: =A01.0 > =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 =A0| =A0 Resolution: =A0w= ontfix > =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > -------------------------------------+-----------------------------------= --- > Changes (by john.elwell@=85): > > =A0* status: =A0new =3D> closed > =A0* resolution: =A0=3D> wontfix > > > Comment: > > =A0This is being discussed in the context of the olive draft. In addition= , > =A0there was agreement at IETF#77 to add text explaining the limitations, > =A0which was done in -03. > > -- > Ticket URL: > martini > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From ietf.hanserik@gmail.com Mon Apr 26 11:40:54 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF9E3A6ADA for ; Mon, 26 Apr 2010 11:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hktiETJ88Pgy for ; Mon, 26 Apr 2010 11:40:53 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id AD94B3A6ADE for ; Mon, 26 Apr 2010 11:40:50 -0700 (PDT) Received: by ewy24 with SMTP id 24so3796557ewy.13 for ; Mon, 26 Apr 2010 11:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=U4sJOXR1h0eFEDVNwhBzHUEKPgDzYNm2uoORMSL8SV4=; b=ocqOoXMAI3hyFYM855ac82YCi/Myf5Ithy3z8c/sbDKFswU/qGcSQYKSFuIKM+047O b3vXNLCK6zH3wNQToyRZiw6gFv9dq6d1/PKsPQbaYWOuaa519cgrCydEnk5biVkeXVlD EXCFFHqkjdR1RkUyZ1jzywQc1gvG+VtN+qsbU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WalZG00ZjhICyJi6syUq/dHHQ0p/X92YAoHgtqNpaWGSpsSGwokp2U+yf7yL1HuJmM Ee+KXIA9y2jOFYIdrgntlo7dWfEcgfVBqrcOivBaHCqnhY0hYvVIoNhY0bC6crGt6StC xCDs/VRNZ7XhkhdDafD6EjoMV8evNnRWgdpHo= MIME-Version: 1.0 Received: by 10.213.51.78 with SMTP id c14mr1846912ebg.89.1272307235312; Mon, 26 Apr 2010 11:40:35 -0700 (PDT) Received: by 10.213.15.138 with HTTP; Mon, 26 Apr 2010 11:40:35 -0700 (PDT) In-Reply-To: References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org> <074.debd425b495e8a8c4dd7f096b02116ed@tools.ietf.org> Date: Mon, 26 Apr 2010 20:40:35 +0200 Message-ID: From: Hans Erik van Elburg To: martini issue tracker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: martini@ietf.org Subject: Re: [martini] #15: support for non E.164 numbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 18:40:54 -0000 Forgot to say that I do not agree with that it is being closed. Please reop= en. /Hans Erik van Elburg On Mon, Apr 26, 2010 at 8:38 PM, Hans Erik van Elburg wrote: > Indeed this is being partly addressed in the olive draft, which shows > that there is a need for this. > > Therefore please incorporate the requirement as was proposed in the > original ticket. > > /Hans Erik van Elburg > > On Mon, Apr 26, 2010 at 10:24 AM, martini issue tracker > wrote: >> #15: support for non E.164 numbers >> -------------------------------------+----------------------------------= ---- >> =A0Reporter: =A0ietf.hanserik@=85 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0Ow= ner: >> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 Status: =A0closed >> =A0Priority: =A0critical =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Milest= one: =A0milestone1 >> Component: =A0reqs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0= Version: =A01.0 >> =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 =A0| =A0 Resolution: =A0= wontfix >> =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> -------------------------------------+----------------------------------= ---- >> Changes (by john.elwell@=85): >> >> =A0* status: =A0new =3D> closed >> =A0* resolution: =A0=3D> wontfix >> >> >> Comment: >> >> =A0This is being discussed in the context of the olive draft. In additio= n, >> =A0there was agreement at IETF#77 to add text explaining the limitations= , >> =A0which was done in -03. >> >> -- >> Ticket URL: >> martini >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> > From spencer@wonderhamster.org Mon Apr 26 11:53:50 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356AC3A690C for ; Mon, 26 Apr 2010 11:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[AWL=-1.009, BAYES_50=0.001, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtesJ9OOkhbN for ; Mon, 26 Apr 2010 11:53:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 312E73A69C1 for ; Mon, 26 Apr 2010 11:53:49 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MEG1o-1OD44S0MK8-00FSMX; Mon, 26 Apr 2010 14:53:28 -0400 Message-ID: <7FF15E8C95A84498A184B8E66DFC6D60@china.huawei.com> From: "Spencer Dawkins" To: "Dean Willis" , "Bernard Aboba" References: <02793872-EE56-4397-A077-8F94B16CEBA8@softarmor.com> Date: Mon, 26 Apr 2010 13:53:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+C7y8js/1Lj87vC7/p6k1TB9e3sNeX3zvu5PS NHPu5YTE4udR5eY8aUw93Fi7IdUv/kyBDPx5R2reUDq3xZZx4+ O1AIVyLCA9eBQjHnf0CKXrLZpqJa9A+4cUr8ZU1W8o= Cc: martini@ietf.org Subject: Re: [martini] #36: Reg-event package and individual extension state(section 7.2.2) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 18:53:50 -0000 Speaking as individual participant... We've certainly considered "bulk registration = individual registrations - multiple REGISTER messages/responses" in discussions that we've cycled through several times. It would be good to decide our understanding about this, in writing, so that when we're concluding MARTINI and someone brings in a new proposal, we have some place to point them before they waste a lot of time on a proposal that would require us to change our shared understanding about this point, before we would adopt the new proposal. Speaking as co-chair... Should that shared understanding go in the (various) solution drafts? Thanks, Spencer >> Dean Willis said: >> >> "Assumption #1 for MARTINI (at least at this phase) is that we're doing >> a bulk registration that produces a result which can not be externally >> distinguished from multiple unique registrations. It's not a new routing >> model -- it is just a bulk registration. " >> >> [BA] Speaking with chair hat off -- >> >> At various points, I have wondered about whether this was just an >> assumption, or something more akin to a tenet or a boundary condition. >> Having a "multiple AoR registration" procedure that doesn't produce the >> same results as a "single AoR registration" when there is only one AoR >> involved seems to violate the principle of least astonishment, at least >> for me. > > While I agree, it is notable that a number of the proposals made on- list > crossed this boundary condition, sometimes dramatically. For example, > proposals wherein a MARTINI registration would cause the proxy to do > something other than RFC 3261 contact-routing, such as perhaps > loose-routing an unchanged request-URI towards the PBX, don't work like > single registrations. While I think using loose-routing to solve the > request-URI dispatch problem is a reasonable thing, doing it at a proxy > in response to a REGISTER seems to be likely to get strange. I could see > a MARTINI phase-2 that uses loose routing, perhaps in combination with > PUBLISHed routes instead of REGISTERed contacts. > > We've also got a contingent that favors the IMS model, which again is > subtly different (arguably in very useful ways) from "ordinary" > registration. > > So perhaps we should find a way to carve "MARTINI phase 1 is bulk > registration" into granite monoliths... > > -- > Dean > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From john.elwell@siemens-enterprise.com Mon Apr 26 12:25:26 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EDC028C199 for ; Mon, 26 Apr 2010 12:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3zbaN3k6PbW for ; Mon, 26 Apr 2010 12:25:25 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id EC93928C197 for ; Mon, 26 Apr 2010 12:25:18 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1679751; Mon, 26 Apr 2010 21:25:05 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id E2C5B1EB82B0; Mon, 26 Apr 2010 21:25:05 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 26 Apr 2010 21:25:05 +0200 From: "Elwell, John" To: Hans Erik van Elburg , martini issue tracker Date: Mon, 26 Apr 2010 21:25:05 +0200 Thread-Topic: #15 and #16 (was RE: [martini] #15: support for non E.164 numbers) Thread-Index: Acrlb6PfVv37sDkKQkCl7geeYGiGmgABfQjw Message-ID: References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org> <074.debd425b495e8a8c4dd7f096b02116ed@tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 19:25:26 -0000 For both #15 and #16, the issue is where to document requirements for subse= quent deliverables, given that, in accordance with an agreement many weeks = ago, initial deliverables are limited to E.164-based AORs. Other forms of A= OR are being considered in the context of the olive draft, but I am not sur= e whether requirements need to go into the present requirements draft, and = if so how to segregate them. Perhaps chair guidance on this would be approp= riate. John=20 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: 26 April 2010 19:38 > To: martini issue tracker > Cc: Elwell, John; martini@ietf.org > Subject: Re: [martini] #15: support for non E.164 numbers >=20 > Indeed this is being partly addressed in the olive draft, which shows > that there is a need for this. >=20 > Therefore please incorporate the requirement as was proposed in the > original ticket. >=20 > /Hans Erik van Elburg >=20 > On Mon, Apr 26, 2010 at 10:24 AM, martini issue tracker > wrote: > > #15: support for non E.164 numbers > >=20 > -------------------------------------+------------------------ > -------------- > > =A0Reporter: =A0ietf.hanserik@. =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0Own= er: > > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 Status: =A0closed > > =A0Priority: =A0critical =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Miles= tone: =A0milestone1 > > Component: =A0reqs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0Version: =A01.0 > > =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 =A0| =A0 Resolution: = =A0wontfix > > =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > >=20 > -------------------------------------+------------------------ > -------------- > > Changes (by john.elwell@.): > > > > =A0* status: =A0new =3D> closed > > =A0* resolution: =A0=3D> wontfix > > > > > > Comment: > > > > =A0This is being discussed in the context of the olive draft.=20 > In addition, > > =A0there was agreement at IETF#77 to add text explaining the=20 > limitations, > > =A0which was done in -03. > > > > -- > > Ticket URL:=20 > > > martini > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > > = From trac@tools.ietf.org Mon Apr 26 15:18:31 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D59773A6861 for ; Mon, 26 Apr 2010 15:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9WPl6jZgXJ7 for ; Mon, 26 Apr 2010 15:18:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 568433A6ADF for ; Mon, 26 Apr 2010 15:18:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O6Wcz-00066V-DS; Mon, 26 Apr 2010 15:18:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 26 Apr 2010 22:18:09 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/40 Message-ID: <058.d58a10c6dc955f4daed65c19fdcf878b@tools.ietf.org> X-Trac-Ticket-ID: 40 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #40: Public GRUU Example is Incorrect X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 22:18:32 -0000 #40: Public GRUU Example is Incorrect --------------------------------+------------------------------------------- Reporter: adam@… | Owner: Type: defect | Status: new Priority: trivial | Milestone: milestone1 Component: gin | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- The example in section 7.1.1 shows the SSP copying the ";gr=..." parameter from the incoming GRUU to the retargeted URI. This is not consistent with the normative text. The example is incorrect. The ";gr=..." parameter needs to be removed. -- Ticket URL: martini From bernard_aboba@hotmail.com Mon Apr 26 17:23:28 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1BD3A67FE for ; Mon, 26 Apr 2010 17:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.696 X-Spam-Level: X-Spam-Status: No, score=0.696 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_50=0.001, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRLfv-VNh-7h for ; Mon, 26 Apr 2010 17:23:27 -0700 (PDT) Received: from blu0-omc2-s30.blu0.hotmail.com (blu0-omc2-s30.blu0.hotmail.com [65.55.111.105]) by core3.amsl.com (Postfix) with ESMTP id 3D39B3A6C04 for ; Mon, 26 Apr 2010 17:23:24 -0700 (PDT) Received: from BLU137-DS8 ([65.55.111.71]) by blu0-omc2-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 17:23:12 -0700 X-Originating-IP: [131.107.0.117] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Spencer Dawkins'" , "'Dean Willis'" References: <02793872-EE56-4397-A077-8F94B16CEBA8@softarmor.com> <7FF15E8C95A84498A184B8E66DFC6D60@china.huawei.com> In-Reply-To: <7FF15E8C95A84498A184B8E66DFC6D60@china.huawei.com> Date: Mon, 26 Apr 2010 17:23:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKhB3+F4rxbXkx30Q2NYzbdI3QHEAI5Yq+TAS7dfD2Qbe4JQA== Content-Language: en-us X-OriginalArrivalTime: 27 Apr 2010 00:23:12.0262 (UTC) FILETIME=[D2335260:01CAE59F] Cc: martini@ietf.org Subject: Re: [martini] #36: Reg-event package and individual extension state(section 7.2.2) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 00:23:28 -0000 Spencer said: "Speaking as co-chair... Should that shared understanding go in the (various) solution drafts?" [BA] I would think that it should go somewhere, certainly. From bruno.chatras@orange-ftgroup.com Tue Apr 27 00:00:29 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49443A6B00 for ; Tue, 27 Apr 2010 00:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wxv5D8nvVPlU for ; Tue, 27 Apr 2010 00:00:28 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 6E68F3A68D4 for ; Tue, 27 Apr 2010 00:00:27 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 346088B8017; Tue, 27 Apr 2010 08:54:50 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 130918B8029; Tue, 27 Apr 2010 08:52:22 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 08:51:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Apr 2010 08:51:58 +0200 Message-ID: <9ECCF01B52E7AB408A7EB85352642141015F06A7@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) Thread-Index: Acrlb6PfVv37sDkKQkCl7geeYGiGmgABfQjwABgS1OA= References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org><074.debd425b495e8a8c4dd7f096b02116ed@tools.ietf.org> From: To: , , X-OriginalArrivalTime: 27 Apr 2010 06:51:59.0532 (UTC) FILETIME=[22563EC0:01CAE5D6] Cc: martini@ietf.org Subject: Re: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 07:00:29 -0000 Whatever is supported by the gin draft should not change the = requirements. The industry does have a requirement to support other = forms of identities than just E.164. Therefore I believe #15 and #16 = should be incorporated in the requirements draft. BC > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Elwell, John > Envoy=E9 : lundi 26 avril 2010 21:25 > =C0 : Hans Erik van Elburg; martini issue tracker > Cc : martini@ietf.org > Objet : [martini] #15 and #16 (was RE: #15: support for non=20 > E.164 numbers) >=20 > For both #15 and #16, the issue is where to document=20 > requirements for subsequent deliverables, given that, in=20 > accordance with an agreement many weeks ago, initial=20 > deliverables are limited to E.164-based AORs. Other forms of=20 > AOR are being considered in the context of the olive draft,=20 > but I am not sure whether requirements need to go into the=20 > present requirements draft, and if so how to segregate them.=20 > Perhaps chair guidance on this would be appropriate. >=20 > John=20 >=20 > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: 26 April 2010 19:38 > > To: martini issue tracker > > Cc: Elwell, John; martini@ietf.org > > Subject: Re: [martini] #15: support for non E.164 numbers > >=20 > > Indeed this is being partly addressed in the olive draft,=20 > which shows=20 > > that there is a need for this. > >=20 > > Therefore please incorporate the requirement as was proposed in the=20 > > original ticket. > >=20 > > /Hans Erik van Elburg > >=20 > > On Mon, Apr 26, 2010 at 10:24 AM, martini issue tracker=20 > > wrote: > > > #15: support for non E.164 numbers > > >=20 > > -------------------------------------+------------------------ > > -------------- > > > =A0Reporter: =A0ietf.hanserik@. =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0Owner: > > > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 =A0 Status: =A0closed > > > =A0Priority: =A0critical =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 = =A0Milestone: =A0milestone1 > > > Component: =A0reqs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 =A0Version: =A01.0 > > > =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 =A0| =A0 = Resolution: =A0wontfix > > > =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > >=20 > > -------------------------------------+------------------------ > > -------------- > > > Changes (by john.elwell@.): > > > > > > =A0* status: =A0new =3D> closed > > > =A0* resolution: =A0=3D> wontfix > > > > > > > > > Comment: > > > > > > =A0This is being discussed in the context of the olive draft.=20 > > In addition, > > > =A0there was agreement at IETF#77 to add text explaining the > > limitations, > > > =A0which was done in -03. > > > > > > -- > > > Ticket URL:=20 > > > > > martini > > > > > > _______________________________________________ > > > martini mailing list > > > martini@ietf.org > > > https://www.ietf.org/mailman/listinfo/martini > > > > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 From md3135@att.com Tue Apr 27 01:49:50 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E619F3A68F9 for ; Tue, 27 Apr 2010 01:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.376 X-Spam-Level: X-Spam-Status: No, score=-106.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWMihefSp91a for ; Tue, 27 Apr 2010 01:49:47 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 5E7733A6926 for ; Tue, 27 Apr 2010 01:49:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-14.tower-146.messagelabs.com!1272358182!16393848!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 8195 invoked from network); 27 Apr 2010 08:49:42 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Apr 2010 08:49:42 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3R8nHdZ006690; Tue, 27 Apr 2010 04:49:17 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o3R8nBoU006641; Tue, 27 Apr 2010 04:49:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Apr 2010 04:49:25 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA06591352@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141015F06A7@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] #15 and #16 (was RE: #15: support for non E.164numbers) Thread-Index: Acrlb6PfVv37sDkKQkCl7geeYGiGmgABfQjwABgS1OAABCWk8A== References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org><074.debd425b495e8a8c4dd7f096b02116ed@tools.ietf.org> <9ECCF01B52E7AB408A7EB85352642141015F06A7@ftrdmel0.rd.francetelecom.fr> From: "DOLLY, MARTIN C (ATTLABS)" To: , , , Cc: martini@ietf.org Subject: Re: [martini] #15 and #16 (was RE: #15: support for non E.164numbers) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 08:49:51 -0000 Requirements 15/16 should remain. -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of bruno.chatras@orange-ftgroup.com Sent: Tuesday, April 27, 2010 2:52 AM To: john.elwell@siemens-enterprise.com; ietf.hanserik@gmail.com; = trac@tools.ietf.org Cc: martini@ietf.org Subject: Re: [martini] #15 and #16 (was RE: #15: support for non = E.164numbers) Whatever is supported by the gin draft should not change the = requirements. The industry does have a requirement to support other = forms of identities than just E.164. Therefore I believe #15 and #16 = should be incorporated in the requirements draft. BC > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Elwell, John > Envoy=E9 : lundi 26 avril 2010 21:25 > =C0 : Hans Erik van Elburg; martini issue tracker > Cc : martini@ietf.org > Objet : [martini] #15 and #16 (was RE: #15: support for non=20 > E.164 numbers) >=20 > For both #15 and #16, the issue is where to document=20 > requirements for subsequent deliverables, given that, in=20 > accordance with an agreement many weeks ago, initial=20 > deliverables are limited to E.164-based AORs. Other forms of=20 > AOR are being considered in the context of the olive draft,=20 > but I am not sure whether requirements need to go into the=20 > present requirements draft, and if so how to segregate them.=20 > Perhaps chair guidance on this would be appropriate. >=20 > John=20 >=20 > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: 26 April 2010 19:38 > > To: martini issue tracker > > Cc: Elwell, John; martini@ietf.org > > Subject: Re: [martini] #15: support for non E.164 numbers > >=20 > > Indeed this is being partly addressed in the olive draft,=20 > which shows=20 > > that there is a need for this. > >=20 > > Therefore please incorporate the requirement as was proposed in the=20 > > original ticket. > >=20 > > /Hans Erik van Elburg > >=20 > > On Mon, Apr 26, 2010 at 10:24 AM, martini issue tracker=20 > > wrote: > > > #15: support for non E.164 numbers > > >=20 > > -------------------------------------+------------------------ > > -------------- > > > =A0Reporter: =A0ietf.hanserik@. =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0Owner: > > > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 =A0 Status: =A0closed > > > =A0Priority: =A0critical =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 = =A0Milestone: =A0milestone1 > > > Component: =A0reqs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 =A0Version: =A01.0 > > > =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 =A0| =A0 = Resolution: =A0wontfix > > > =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > >=20 > > -------------------------------------+------------------------ > > -------------- > > > Changes (by john.elwell@.): > > > > > > =A0* status: =A0new =3D> closed > > > =A0* resolution: =A0=3D> wontfix > > > > > > > > > Comment: > > > > > > =A0This is being discussed in the context of the olive draft.=20 > > In addition, > > > =A0there was agreement at IETF#77 to add text explaining the > > limitations, > > > =A0which was done in -03. > > > > > > -- > > > Ticket URL:=20 > > > > > martini > > > > > > _______________________________________________ > > > martini mailing list > > > martini@ietf.org > > > https://www.ietf.org/mailman/listinfo/martini > > > > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From john.elwell@siemens-enterprise.com Tue Apr 27 02:00:03 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C159D3A67E3 for ; Tue, 27 Apr 2010 02:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFkA3raZlf1c for ; Tue, 27 Apr 2010 02:00:03 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 0CC933A6A3B for ; Tue, 27 Apr 2010 01:59:40 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1683836; Tue, 27 Apr 2010 10:59:19 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 8FD181EB82B0; Tue, 27 Apr 2010 10:59:19 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 27 Apr 2010 10:59:19 +0200 From: "Elwell, John" To: "bruno.chatras@orange-ftgroup.com" , "ietf.hanserik@gmail.com" , "trac@tools.ietf.org" Date: Tue, 27 Apr 2010 10:59:16 +0200 Thread-Topic: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) Thread-Index: Acrlb6PfVv37sDkKQkCl7geeYGiGmgABfQjwABgS1OAABFZlIA== Message-ID: References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org><074.debd425b495e8a8c4dd7f096b02116ed@tools.ietf.org> <9ECCF01B52E7AB408A7EB85352642141015F06A7@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141015F06A7@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 09:00:03 -0000 Bruno, The MARTINI charter says "The solution will support AoRs with E.164 addresses at a minimum, although support for other classes of AoRs may be included." I think the req-04 draft reflects that well. John > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com]=20 > Sent: 27 April 2010 07:52 > To: Elwell, John; ietf.hanserik@gmail.com; trac@tools.ietf.org > Cc: martini@ietf.org > Subject: RE: [martini] #15 and #16 (was RE: #15: support for=20 > non E.164 numbers) >=20 > Whatever is supported by the gin draft should not change the=20 > requirements. The industry does have a requirement to support=20 > other forms of identities than just E.164. Therefore I=20 > believe #15 and #16 should be incorporated in the requirements draft. > BC >=20 > > -----Message d'origine----- > > De : martini-bounces@ietf.org=20 > > [mailto:martini-bounces@ietf.org] De la part de Elwell, John > > Envoy=E9 : lundi 26 avril 2010 21:25 > > =C0 : Hans Erik van Elburg; martini issue tracker > > Cc : martini@ietf.org > > Objet : [martini] #15 and #16 (was RE: #15: support for non=20 > > E.164 numbers) > >=20 > > For both #15 and #16, the issue is where to document=20 > > requirements for subsequent deliverables, given that, in=20 > > accordance with an agreement many weeks ago, initial=20 > > deliverables are limited to E.164-based AORs. Other forms of=20 > > AOR are being considered in the context of the olive draft,=20 > > but I am not sure whether requirements need to go into the=20 > > present requirements draft, and if so how to segregate them.=20 > > Perhaps chair guidance on this would be appropriate. > >=20 > > John=20 > >=20 > > > -----Original Message----- > > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > > Sent: 26 April 2010 19:38 > > > To: martini issue tracker > > > Cc: Elwell, John; martini@ietf.org > > > Subject: Re: [martini] #15: support for non E.164 numbers > > >=20 > > > Indeed this is being partly addressed in the olive draft,=20 > > which shows=20 > > > that there is a need for this. > > >=20 > > > Therefore please incorporate the requirement as was=20 > proposed in the=20 > > > original ticket. > > >=20 > > > /Hans Erik van Elburg > > >=20 > > > On Mon, Apr 26, 2010 at 10:24 AM, martini issue tracker=20 > > > wrote: > > > > #15: support for non E.164 numbers > > > >=20 > > > -------------------------------------+------------------------ > > > -------------- > > > > =A0Reporter: =A0ietf.hanserik@. =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0Owner: > > > > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 =A0 Status: =A0closed > > > > =A0Priority: =A0critical =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0M= ilestone: =A0milestone1 > > > > Component: =A0reqs =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 = =A0 =A0Version: =A01.0 > > > > =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 =A0| =A0 Resolution= : =A0wontfix > > > > =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > > >=20 > > > -------------------------------------+------------------------ > > > -------------- > > > > Changes (by john.elwell@.): > > > > > > > > =A0* status: =A0new =3D> closed > > > > =A0* resolution: =A0=3D> wontfix > > > > > > > > > > > > Comment: > > > > > > > > =A0This is being discussed in the context of the olive draft.=20 > > > In addition, > > > > =A0there was agreement at IETF#77 to add text explaining the > > > limitations, > > > > =A0which was done in -03. > > > > > > > > -- > > > > Ticket URL:=20 > > > > > > > martini > > > > > > > > _______________________________________________ > > > > martini mailing list > > > > martini@ietf.org > > > > https://www.ietf.org/mailman/listinfo/martini > > > > > > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 > = From dean.willis@softarmor.com Tue Apr 27 11:09:45 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD123A6AC5 for ; Tue, 27 Apr 2010 11:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es5+UL83XkgS for ; Tue, 27 Apr 2010 11:09:44 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 08D443A6AB3 for ; Tue, 27 Apr 2010 11:09:26 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3RI9A9S029571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Apr 2010 13:09:11 -0500 Message-Id: From: Dean Willis To: "" In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141015F06A7@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Apr 2010 13:09:04 -0500 References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org><074.debd425b495e8a8c4dd7f096b02116ed@tools.ietf.org> <9ECCF01B52E7AB408A7EB85352642141015F06A7@ftrdmel0.rd.francetelecom.fr> X-Mailer: Apple Mail (2.936) Cc: trac@tools.ietf.org, martini@ietf.org Subject: Re: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 18:09:46 -0000 On Apr 27, 2010, at 1:51 AM, wrote: > Whatever is supported by the gin draft should not change the > requirements. The industry does have a requirement to support other > forms of identities than just E.164. Therefore I believe #15 and #16 > should be incorporated in the requirements draft. Is this requirements draft supposed to cover just phase 1, or everything the MARTINI group plans to do over its lifetime? If the former, then we risk stalling the work because the first-gen solutions drafts don't (and aren't meant to) meet every possible requirement. -- Dean From spencer@wonderhamster.org Tue Apr 27 15:05:26 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86A2B3A68F1 for ; Tue, 27 Apr 2010 15:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BG2eenRo6VJO for ; Tue, 27 Apr 2010 15:05:25 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 6B21F3A6812 for ; Tue, 27 Apr 2010 15:05:25 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MRF4x-1NyJHb0su7-00UicD; Tue, 27 Apr 2010 18:05:07 -0400 Message-ID: From: "Spencer Dawkins" To: "Elwell, John" , "Hans Erik van Elburg" References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org><074.debd425b495e8a8c4dd7f096b02116ed@tools.ietf.org> Date: Tue, 27 Apr 2010 17:04:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19VPQirokTzhRtWPD+Dje/vTjOGhYefKDJIIau tQsl3VAipRCMAhzv46LjVXB85rdv2MuL5Pfw0HdLSqgVaqqVbp ARqgg/FhcVlCE1HQqVXRvGqgK2UAO2DRwXZlNVytjE= Cc: martini@ietf.org Subject: Re: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 22:05:26 -0000 After chatting with my co-chair... Bernard and I are sympathetic to these requirements. We don't want to cycle on closing/reopening them. We are seeing people doing analysis for these requirements (see OLIVE, as a start). We don't want to stall on delivering a solution that meets the scope we were chartered for, because we accepted these as requirements. We propose that we accept both #15 and #16 for Section 5, "Desireables". There is no penalty for delivering a solution that provides this support. Please feel free to express opinions about this, of course. Spencer, as co-chair ----- Original Message ----- From: "Elwell, John" To: "Hans Erik van Elburg" ; "martini issue tracker" Cc: Sent: Monday, April 26, 2010 2:25 PM Subject: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) For both #15 and #16, the issue is where to document requirements for subsequent deliverables, given that, in accordance with an agreement many weeks ago, initial deliverables are limited to E.164-based AORs. Other forms of AOR are being considered in the context of the olive draft, but I am not sure whether requirements need to go into the present requirements draft, and if so how to segregate them. Perhaps chair guidance on this would be appropriate. John > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: 26 April 2010 19:38 > To: martini issue tracker > Cc: Elwell, John; martini@ietf.org > Subject: Re: [martini] #15: support for non E.164 numbers > > Indeed this is being partly addressed in the olive draft, which shows > that there is a need for this. > > Therefore please incorporate the requirement as was proposed in the > original ticket. > > /Hans Erik van Elburg > > On Mon, Apr 26, 2010 at 10:24 AM, martini issue tracker > wrote: > > #15: support for non E.164 numbers > > > -------------------------------------+------------------------ > -------------- > > Reporter: ietf.hanserik@. | Owner: > > Type: defect | Status: closed > > Priority: critical | Milestone: milestone1 > > Component: reqs | Version: 1.0 > > Severity: In WG Last Call | Resolution: wontfix > > Keywords: | > > > -------------------------------------+------------------------ > -------------- > > Changes (by john.elwell@.): > > > > * status: new => closed > > * resolution: => wontfix > > > > > > Comment: > > > > This is being discussed in the context of the olive draft. > In addition, > > there was agreement at IETF#77 to add text explaining the > limitations, > > which was done in -03. > > > > -- > > Ticket URL: > > > martini > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > > _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From dean.willis@softarmor.com Tue Apr 27 17:47:45 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991AB3A6955 for ; Tue, 27 Apr 2010 17:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HpGjPrRFGcL for ; Tue, 27 Apr 2010 17:47:44 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id AEA663A62C1 for ; Tue, 27 Apr 2010 17:47:44 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3S0lD9X032446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Apr 2010 19:47:29 -0500 From: Dean Willis To: Spencer Dawkins In-Reply-To: X-Priority: 3 References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org><074.debd425b495e8a8c4dd7f096b02116ed@tools.ietf.org> Message-Id: <66FAD263-C930-4D8C-99B3-0EB6619DC554@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Apr 2010 19:47:07 -0500 X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 00:47:45 -0000 On Apr 27, 2010, at 5:04 PM, Spencer Dawkins wrote: > After chatting with my co-chair... > > Bernard and I are sympathetic to these requirements. > > We don't want to cycle on closing/reopening them. > > We are seeing people doing analysis for these requirements (see > OLIVE, as a start). > > We don't want to stall on delivering a solution that meets the scope > we were chartered for, because we accepted these as requirements. > > We propose that we accept both #15 and #16 for Section 5, > "Desireables". > > There is no penalty for delivering a solution that provides this > support. > > Please feel free to express opinions about this, of course. That works for documentary purposes, but I'd like to see somewhere a commitment to getting the things done "at some point" that GIN doesn't do. Olive is a good start, of course; it shows that we know that there is more work to do and are working on in a reasonable incremental fashion. The cleanest solution would probably be to structure the requirements into phases inside the actual requirements draft. That's also a pretty heavy solution. Another approach would be to add a preamble to the requirements that says something about eventually finding solutions to all the requirements but not anticipating that a single mechanism or draft is likely to solve everything. With this route, we could keep 15 and 16 "in place" as requirements, but be able to advance a draft like Gin without somebody saying "You can't advance this draft, it doesn't meet all the requirements in the requirements draft!" This approach lets next-step drafts refer back to the requirements with something like "This draft addresses Requirements 15 and 16, which were not addressed by draft-gin..." -- Dean From HKaplan@acmepacket.com Tue Apr 27 19:37:07 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1713A67FE for ; Tue, 27 Apr 2010 19:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neXxbFvpWLas for ; Tue, 27 Apr 2010 19:37:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D24CB3A6782 for ; Tue, 27 Apr 2010 19:37:06 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 27 Apr 2010 22:36:53 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 27 Apr 2010 22:36:53 -0400 From: Hadriel Kaplan To: Dean Willis , Spencer Dawkins Date: Tue, 27 Apr 2010 22:36:53 -0400 Thread-Topic: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) Thread-Index: AcrmbGaGKMP4Ur9XTRuHqX/L83txdAADpOYA Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1352@mail> References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org><074.debd425b495e8a8c4dd7f096b02116ed@tools.ietf.org> <66FAD263-C930-4D8C-99B3-0EB6619DC554@softarmor.com> In-Reply-To: <66FAD263-C930-4D8C-99B3-0EB6619DC554@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 02:37:08 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Dean Willis > Sent: Tuesday, April 27, 2010 8:47 PM >=20 > That works for documentary purposes, but I'd like to see somewhere a > commitment to getting the things done "at some point" that GIN doesn't > do. Olive is a good start, of course; it shows that we know that there > is more work to do and are working on in a reasonable incremental > fashion. I agree, but I think the "commitment" is simply the interest of the group. = If there is interest, we keep working; if there isn't, we don't.=20 =20 > The cleanest solution would probably be to structure the requirements > into phases inside the actual requirements draft. That's also a pretty > heavy solution. Isn't that what charters are for? We make changes the charters to add new = goals, with milestones, etc. =20 -hadriel From HKaplan@acmepacket.com Tue Apr 27 19:41:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D5D3A6A8E for ; Tue, 27 Apr 2010 19:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqrvdwjN-wXu for ; Tue, 27 Apr 2010 19:41:23 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B57743A6A6A for ; Tue, 27 Apr 2010 19:41:23 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 27 Apr 2010 22:41:10 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 27 Apr 2010 22:41:10 -0400 From: Hadriel Kaplan To: Spencer Dawkins , "Elwell, John" , Hans Erik van Elburg Date: Tue, 27 Apr 2010 22:41:09 -0400 Thread-Topic: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) Thread-Index: AcrmVcSyVyb5EVm6Syyk24VwXmXVzAAJem1g Message-ID: <430FC6BDED356B4C8498F634416644A91A8A5F1353@mail> References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org><074.debd425b495e8a8c4dd7f096b02116ed@tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 02:41:25 -0000 +1. #15 and #16 seem like good desireables to me, and I think Hans Erik's propo= sed language captures that. -hadriel > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Spencer Dawkins > Sent: Tuesday, April 27, 2010 6:05 PM > To: Elwell, John; Hans Erik van Elburg >=20 > After chatting with my co-chair... >=20 > Bernard and I are sympathetic to these requirements. >=20 > We don't want to cycle on closing/reopening them. >=20 > We are seeing people doing analysis for these requirements (see OLIVE, as > a > start). >=20 > We don't want to stall on delivering a solution that meets the scope we > were > chartered for, because we accepted these as requirements. >=20 > We propose that we accept both #15 and #16 for Section 5, "Desireables". >=20 > There is no penalty for delivering a solution that provides this support. >=20 > Please feel free to express opinions about this, of course. >=20 > Spencer, as co-chair >=20 From john.elwell@siemens-enterprise.com Wed Apr 28 01:12:05 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05A4C3A686C for ; Wed, 28 Apr 2010 01:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHYjbWZAgVZN for ; Wed, 28 Apr 2010 01:12:03 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id B40F23A6835 for ; Wed, 28 Apr 2010 01:12:02 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1699698; Wed, 28 Apr 2010 10:11:48 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id C8C2923F0294; Wed, 28 Apr 2010 10:11:48 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 28 Apr 2010 10:11:48 +0200 From: "Elwell, John" To: Dean Willis , Spencer Dawkins Date: Wed, 28 Apr 2010 10:11:47 +0200 Thread-Topic: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) Thread-Index: AcrmbGSFJgwIRmCISheMxxWRxgfKtwALafBw Message-ID: References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org><074.debd425b495e8a8c4dd7f096b02116ed@tools.ietf.org> <66FAD263-C930-4D8C-99B3-0EB6619DC554@softarmor.com> In-Reply-To: <66FAD263-C930-4D8C-99B3-0EB6619DC554@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 08:12:05 -0000 =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 28 April 2010 01:47 > To: Spencer Dawkins > Cc: Elwell, John; Hans Erik van Elburg; martini@ietf.org > Subject: Re: [martini] #15 and #16 (was RE: #15: support for=20 > non E.164 numbers) >=20 >=20 > On Apr 27, 2010, at 5:04 PM, Spencer Dawkins wrote: >=20 > > After chatting with my co-chair... > > > > Bernard and I are sympathetic to these requirements. > > > > We don't want to cycle on closing/reopening them. > > > > We are seeing people doing analysis for these requirements (see =20 > > OLIVE, as a start). > > > > We don't want to stall on delivering a solution that meets=20 > the scope =20 > > we were chartered for, because we accepted these as requirements. > > > > We propose that we accept both #15 and #16 for Section 5, =20 > > "Desireables". > > > > There is no penalty for delivering a solution that provides this =20 > > support. > > > > Please feel free to express opinions about this, of course. >=20 > That works for documentary purposes, but I'd like to see somewhere a =20 > commitment to getting the things done "at some point" that=20 > GIN doesn't =20 > do. Olive is a good start, of course; it shows that we know=20 > that there =20 > is more work to do and are working on in a reasonable incremental =20 > fashion. >=20 > The cleanest solution would probably be to structure the=20 > requirements =20 > into phases inside the actual requirements draft. That's also=20 > a pretty =20 > heavy solution. [JRE] Also the inclusion of requirements for a second phase, populated by #= 15 and #16, would seem to imply we already know the total set of additional= requirements for the second phase. When we come to work on the second phas= e, there might be more requirements we haven't yet thought of (perhaps aris= ing from implementation experience with phase 1). So I believe we should st= ate phase 2 requirements when we are ready to start work on phase 2. I pref= er the chairs' proposal of introducing #15 and #16 as desirables. >=20 > Another approach would be to add a preamble to the requirements that =20 > says something about eventually finding solutions to all the =20 > requirements but not anticipating that a single mechanism or=20 > draft is =20 > likely to solve everything. With this route, we could keep=20 > 15 and 16 =20 > "in place" as requirements, but be able to advance a draft like Gin =20 > without somebody saying "You can't advance this draft, it=20 > doesn't meet =20 > all the requirements in the requirements draft!" This approach lets =20 > next-step drafts refer back to the requirements with something like =20 > "This draft addresses Requirements 15 and 16, which were not=20 > addressed =20 > by draft-gin..." [JRE] The problem with this approach is that the vagueness introduced by su= ch a preamble would extend to all requirements, not just #15 and #16. John >=20 > -- > Dean >=20 > = From ietf.hanserik@gmail.com Wed Apr 28 05:20:03 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD6503A6BC1 for ; Wed, 28 Apr 2010 05:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlQsRhTYZoZe for ; Wed, 28 Apr 2010 05:20:02 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 3EB303A6BEB for ; Wed, 28 Apr 2010 05:19:51 -0700 (PDT) Received: by ewy24 with SMTP id 24so4516831ewy.13 for ; Wed, 28 Apr 2010 05:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=C0U/4YcC1K7tq5q8smsme9PZ1yC/ZoHc9Wm1ZlzuHBM=; b=NnMSHxrVPQuKzZQPUChNKH7JT9fnLSen6+SRAjRnJRMG2RaCzTZV6j2e0dsbDv4qIj xfJ0FS+p1TAsWklQr8oTnO8KeXmb2bZTxyRFVffq8FReTNa2OuzN3dI3ktmU1EvztbMi oluOppthgowJj+r8ooEDWqrpye6s7Sir/PLeE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rhZNfWZu2a+VOxN4NOktNb+rUefxYEKkyZULAYuChHTYNxVobxHJLFFjmYuXCu+8w6 Cc1IDNqnJww6dUj+yunG62/ZcbHK07sZy2D27Dn+ApfrcvjNQbjtHern/cl6AxW63gXV OB9tYAiI3o4RMCHyNHzS+h7QAgspCzSr8rNKQ= MIME-Version: 1.0 Received: by 10.213.15.17 with SMTP id i17mr2670220eba.62.1272457175872; Wed, 28 Apr 2010 05:19:35 -0700 (PDT) Received: by 10.213.15.138 with HTTP; Wed, 28 Apr 2010 05:19:35 -0700 (PDT) In-Reply-To: <66FAD263-C930-4D8C-99B3-0EB6619DC554@softarmor.com> References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org> <074.debd425b495e8a8c4dd7f096b02116ed@tools.ietf.org> <66FAD263-C930-4D8C-99B3-0EB6619DC554@softarmor.com> Date: Wed, 28 Apr 2010 14:19:35 +0200 Message-ID: From: Hans Erik van Elburg To: Dean Willis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: martini@ietf.org Subject: Re: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 12:20:04 -0000 On Wed, Apr 28, 2010 at 2:47 AM, Dean Willis wr= ote: > Another approach would be to add a preamble to the requirements that says > something about eventually finding solutions to all the requirements but = not > anticipating that a single mechanism or draft is likely to solve everythi= ng. > =A0With this route, we could keep 15 and 16 "in place" as requirements, b= ut be > able to advance a draft like Gin without somebody saying "You can't advan= ce > this draft, it doesn't meet all the requirements in the requirements draf= t!" > This approach lets next-step drafts refer back to the requirements with > something like "This draft addresses Requirements 15 and 16, which were n= ot > addressed by draft-gin..." > I do think that would be a good approach. The intention is not to stall work on GIN, but recognise that these are important requirements that martini would need to solve before disolving the wg. BR, /Hans Erik From ietf.hanserik@gmail.com Wed Apr 28 13:52:22 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D1F33A6A0E for ; Wed, 28 Apr 2010 13:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNwevbbIXn-q for ; Wed, 28 Apr 2010 13:52:21 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 5ABEF3A6860 for ; Wed, 28 Apr 2010 13:52:21 -0700 (PDT) Received: by ewy24 with SMTP id 24so4799767ewy.13 for ; Wed, 28 Apr 2010 13:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=D94+h0UymU2BBBHeVfC9pHDmicdzNmPfIbxLuANUCKw=; b=hAniyN8OYo0ETXefRCc0IDQZwaPV8Yvw7dpHiHPqubvKvNVAGfg90krA39OEdwsteR zXdpmgJKgt1K1JR0muJa/83iv18xfVIDUJEebmEzKQrE5oFxwQJS/GN6hHxCrvp08org kxqvjQ8UF3vdkexqkbYpPgS1WB3GCxIpL/LxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=RHJiFaxebG52Fs0S0OkO5U2P4W6zdKrq5O+KkIw5dHDmhGE/NI70XrgUOsULF3szE8 woKebE5Br1WvWglFZiQETcp7FGc/wXuTLqCv+PxsNtu+BdV6gtcAeK+Ef83Z5sD0sbfS sjfbQnoc/3+QgWxPLyaI1QF0hXv9bqjZKwIXc= MIME-Version: 1.0 Received: by 10.213.63.13 with SMTP id z13mr1235717ebh.21.1272487923922; Wed, 28 Apr 2010 13:52:03 -0700 (PDT) Received: by 10.213.15.138 with HTTP; Wed, 28 Apr 2010 13:52:03 -0700 (PDT) Date: Wed, 28 Apr 2010 22:52:03 +0200 Message-ID: From: Hans Erik van Elburg To: martini@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [martini] new draft-vanelburg-martini-friends-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 20:52:22 -0000 Please find the new friends draft on the server: http://www.ietf.org/id/draft-vanelburg-martini-friends-00.txt This sketches a solution on how to extend martini solution so that it adresses the needs of the market. Best Regards, /Hans Erik van Elburg From adam@nostrum.com Wed Apr 28 14:32:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4153A6860 for ; Wed, 28 Apr 2010 14:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XUdMv8lF+Cw for ; Wed, 28 Apr 2010 14:32:22 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 1344D3A659C for ; Wed, 28 Apr 2010 14:32:20 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o3SLW5jY017513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Apr 2010 16:32:06 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BD8A955.4010508@nostrum.com> Date: Wed, 28 Apr 2010 16:32:05 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hans Erik van Elburg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] new draft-vanelburg-martini-friends-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 21:32:23 -0000 On 4/28/10 3:52 PM, Hans Erik van Elburg wrote: > Please find the new friends draft on the server: > http://www.ietf.org/id/draft-vanelburg-martini-friends-00.txt > > This sketches a solution on how to extend martini solution so that it > adresses the needs of the market. > You might want to consider the following guidance: http://www.rfc-editor.org/policy.html#policy.authlist I doubt you actually have 8 authors who wrote approximately 200 words each. /a From dean.willis@softarmor.com Wed Apr 28 16:41:22 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A50E3A69DB for ; Wed, 28 Apr 2010 16:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjNeSt8S-Tsj for ; Wed, 28 Apr 2010 16:41:21 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 590FC3A68C3 for ; Wed, 28 Apr 2010 16:41:21 -0700 (PDT) Received: from [192.168.2.115] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o3SNf5s3011089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Apr 2010 18:41:06 -0500 Message-Id: <994F99EB-49C0-4E83-ACD7-E5D74DECC5AC@softarmor.com> From: Dean Willis To: Adam Roach In-Reply-To: <4BD8A955.4010508@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Apr 2010 18:40:59 -0500 References: <4BD8A955.4010508@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] new draft-vanelburg-martini-friends-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 23:41:22 -0000 On Apr 28, 2010, at 4:32 PM, Adam Roach wrote: > On 4/28/10 3:52 PM, Hans Erik van Elburg wrote: >> Please find the new friends draft on the server: >> http://www.ietf.org/id/draft-vanelburg-martini-friends-00.txt >> >> This sketches a solution on how to extend martini solution so that it >> adresses the needs of the market. >> > > You might want to consider the following guidance: > > http://www.rfc-editor.org/policy.html#policy.authlist > > I doubt you actually have 8 authors who wrote approximately 200 > words each. They certainly wrote as much on-list, however! But probably one name as Editor and the rest in Acknowledgements would suffice. -- Dean From ietf.hanserik@gmail.com Thu Apr 29 00:41:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4883028C1B0 for ; Thu, 29 Apr 2010 00:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tgDpL1MIh9S for ; Thu, 29 Apr 2010 00:41:17 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 613E63A6A6B for ; Thu, 29 Apr 2010 00:41:15 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so1040983eyf.51 for ; Thu, 29 Apr 2010 00:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=LO6nop4YisDoqndg7xvSFAQZULq5+OumyOyhq9XNomc=; b=QiT0LelOKel8b6PhT+DpvaPTfutkVoeC0XTtKPco6Sz41/cDUdoDD6O3xduirhtaCJ BT5wNI4nFITfQPTscOi+N3CDa5U3OwYUf+3cyGtprK7WhqL5Fm+MaA3HlWoV3ylgTsvm tuV8Cs5HxeLMCKOIiJo4SdccObCKQHRkV7drg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OS0GHThhb+frv8y9S6GjyTFRieKfDPDL7lShkG5Q9vSpU1V2mfr6BXFPQlQo/+KXDy IjjVCqf7s6QkbyrAo7NwIz2doQoDNujsU13u38euo+IfiOgZyHKzvD2NIv/6hHuuehQw CCCR0eZcAa/MRnaTvLjt1SPoIT52Vl7jrK0jw= MIME-Version: 1.0 Received: by 10.213.68.129 with SMTP id v1mr3166479ebi.1.1272526855915; Thu, 29 Apr 2010 00:40:55 -0700 (PDT) Received: by 10.213.15.138 with HTTP; Thu, 29 Apr 2010 00:40:55 -0700 (PDT) In-Reply-To: <4BD8A955.4010508@nostrum.com> References: <4BD8A955.4010508@nostrum.com> Date: Thu, 29 Apr 2010 09:40:55 +0200 Message-ID: From: Hans Erik van Elburg To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Cc: martini@ietf.org Subject: Re: [martini] new draft-vanelburg-martini-friends-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 07:41:18 -0000 Thanks Adam for pointing this out. I will fix this in a future version. As the policy applies to RFC's and not to drafts I think that there is no problem to discuss the drafts contents. I take that you already see this developing into an RFC ;-) BR, /Hans Erik van Elburg On Wed, Apr 28, 2010 at 11:32 PM, Adam Roach wrote: > On 4/28/10 3:52 PM, Hans Erik van Elburg wrote: >> >> Please find the new friends draft on the server: >> http://www.ietf.org/id/draft-vanelburg-martini-friends-00.txt >> >> This sketches a solution on how to extend martini solution so that it >> adresses the needs of the market. >> > > You might want to consider the following guidance: > > http://www.rfc-editor.org/policy.html#policy.authlist > > I doubt you actually have 8 authors who wrote approximately 200 words each. > > /a > From trac@tools.ietf.org Fri Apr 30 07:56:50 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B09A3A6A62 for ; Fri, 30 Apr 2010 07:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NG3ak3DikpY8 for ; Fri, 30 Apr 2010 07:56:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 33AF93A699E for ; Fri, 30 Apr 2010 07:56:49 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O7rdr-0007cw-HB; Fri, 30 Apr 2010 07:56:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Fri, 30 Apr 2010 14:56:35 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/39#comment:2 Message-ID: <076.0b89444233e6cda89822346bda4470ba@tools.ietf.org> References: <067.f3a7b7aa7fd51ebcf25b5734dc877c4d@tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <067.f3a7b7aa7fd51ebcf25b5734dc877c4d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #39: Section 1 Explanatory Text X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 14:56:50 -0000 #39: Section 1 Explanatory Text ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: john.elwell@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Comment(by john.elwell@…): Discussion during the interim meetings 2010-04-29 suggested that, in the context of the 'olive' draft, at least some of the text in question is wrong. Furthermore the 'olive' draft covers the points expressed in this text, and given the likelihood of progressing work on 'olive', we can indeed delete the text from 'reqs'. My intention is to close this as 'fixed' if no objections. -- Ticket URL: martini From trac@tools.ietf.org Fri Apr 30 08:01:12 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4FCC3A6895 for ; Fri, 30 Apr 2010 08:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJ5WQC+GbSeG for ; Fri, 30 Apr 2010 08:01:12 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 08B233A6822 for ; Fri, 30 Apr 2010 08:01:11 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O7ri4-0007jZ-MO; Fri, 30 Apr 2010 08:00:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: bernard_aboba@hotmail.com, john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Fri, 30 Apr 2010 15:00:56 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/16#comment:4 Message-ID: <074.f66465e47c828a7d3993876d66592d92@tools.ietf.org> References: <065.111f925a59a8643c429a6e1e5e86d2da@tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <065.111f925a59a8643c429a6e1e5e86d2da@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #16: Extensibility to support any AOR X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 15:01:12 -0000 #16: Extensibility to support any AOR -------------------------------------+-------------------------------------- Reporter: ietf.hanserik@… | Owner: Type: enhancement | Status: reopened Priority: critical | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------+-------------------------------------- Changes (by john.elwell@…): * status: closed => reopened * resolution: wontfix => Comment: Reopened due to ongoing discussion on the list. Discussion during the MARTINI interim meeting 2010-04-29 revealed support for accepting this change. If there are no objections I will close this as 'fixed' -- Ticket URL: martini From trac@tools.ietf.org Fri Apr 30 08:03:48 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEAF93A6822 for ; Fri, 30 Apr 2010 08:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkxuClm2WcIY for ; Fri, 30 Apr 2010 08:03:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 14A213A6939 for ; Fri, 30 Apr 2010 08:03:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O7rkc-0007o4-PL; Fri, 30 Apr 2010 08:03:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Fri, 30 Apr 2010 15:03:34 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/15#comment:2 Message-ID: <074.ebb4a3094b410cb67bdf1424b8795605@tools.ietf.org> References: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <065.0881de899bd9e7c8fe255eb1b2119130@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #15: support for non E.164 numbers X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 15:03:48 -0000 #15: support for non E.164 numbers -------------------------------------+-------------------------------------- Reporter: ietf.hanserik@… | Owner: Type: defect | Status: reopened Priority: critical | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------+-------------------------------------- Changes (by john.elwell@…): * status: closed => reopened * resolution: wontfix => Comment: Reopened due to ongoing discussion on the list. Discussion during the MARTINI interim meeting 2010-04-29 revealed support for accepting this change with rewording along the lines of "The mechanism MUST be extensible to allow..." (i.e. similar to ticket #16). If there are no objections I will close this as 'fixed' (subject to that wording change). -- Ticket URL: martini From john.elwell@siemens-enterprise.com Fri Apr 30 08:07:59 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7610D3A68BE for ; Fri, 30 Apr 2010 08:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUZrGKnoCbL6 for ; Fri, 30 Apr 2010 08:07:58 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 915163A6822 for ; Fri, 30 Apr 2010 08:07:55 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-20318 for martini@ietf.org; Fri, 30 Apr 2010 17:07:40 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id E575D1EB82AE for ; Fri, 30 Apr 2010 17:07:40 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 30 Apr 2010 17:07:40 +0200 From: "Elwell, John" To: "martini@ietf.org" Date: Fri, 30 Apr 2010 17:07:39 +0200 Thread-Topic: Consensus call - requirements issues #15, #16 and #39 Thread-Index: AcroduAj3hp2mdqqRPCifSgzviZ4xQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [martini] Consensus call - requirements issues #15, #16 and #39 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 15:07:59 -0000 See latest changes to these issues, arising from the interim meeting (posti= ngs during last few minutes). Unless there are objections by Monday (2010-0= 5-03) I will make the changes, submit reqs-05 and close these issues. John= From spencer@wonderhamster.org Fri Apr 30 15:21:12 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 364253A69F5 for ; Fri, 30 Apr 2010 15:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qQncaW4bcGM for ; Fri, 30 Apr 2010 15:20:58 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 77A753A679C for ; Fri, 30 Apr 2010 15:20:58 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MHGpv-1OBZ3z3Y7H-00E4JG; Fri, 30 Apr 2010 18:20:44 -0400 Message-ID: From: "Spencer Dawkins" To: "Bernard Aboba" , References: Date: Fri, 30 Apr 2010 17:20:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+8cn+DuBcdwDu6EYIEXHJXkW6rjlYS0mzmG19 XYuww4ROwwWUxjFHwThMqEBgj8DbS3NCWWywWOxlZcWqCabtbq 5qbq6Xu2PfszvEIjAp5DpmvZSDudUHdrdV9llZyAFk= Subject: Re: [martini] MARTINI Virtual Interim V Doodle Poll - Take Two X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 22:21:12 -0000 Ok, as co-chair, I was a slug and didn't fill in my availability on this doodle poll until just now, and it looks like a lot of other people are also being slugs, too! So far, we have five responses, including both co-chairs. We're going to be using at least one more interim before IETF 78 - we are hoping it's only one more interim - and it would be very helpful for us to get our next interim scheduled, before we start running into vacation plans, other meeting conflicts that didn't show up in the doodle poll, etc. So, please click enthusiastically, so Bernard and I can make a call on this. Thanks, Spencer, as co-chair ----- Original Message ----- From: Bernard Aboba To: martini@ietf.org Sent: Sunday, April 25, 2010 4:49 PM Subject: [martini] MARTINI Virtual Interim V Doodle Poll - Take Two Given the conflicts discovered during the week of May 17, we are going to try another Doodle Poll for MARTINI Virtual Interim V, this time for the week of June 14, 2010. Let us know your availability for the new set of potential dates/times by responding to the new Doodle Poll: http://www.doodle.com/8wcp4a2ye7bbq42v _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From bernard_aboba@hotmail.com Fri Apr 30 15:30:31 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C67E3A6944 for ; Fri, 30 Apr 2010 15:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.684 X-Spam-Level: X-Spam-Status: No, score=0.684 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_50=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfATtS0y8kMg for ; Fri, 30 Apr 2010 15:30:30 -0700 (PDT) Received: from blu0-omc2-s11.blu0.hotmail.com (blu0-omc2-s11.blu0.hotmail.com [65.55.111.86]) by core3.amsl.com (Postfix) with ESMTP id BEA643A68E9 for ; Fri, 30 Apr 2010 15:30:29 -0700 (PDT) Received: from BLU137-DS17 ([65.55.111.73]) by blu0-omc2-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Apr 2010 15:30:16 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Fri, 30 Apr 2010 15:30:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrodCQ1/ssYfcSMRGqnknUW296hXgAFOC9wAAruNgA= Content-Language: en-us X-OriginalArrivalTime: 30 Apr 2010 22:30:16.0282 (UTC) FILETIME=[B50DD3A0:01CAE8B4] Subject: [martini] FW: Notes from Martini Virtual Interim IV X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 22:30:31 -0000 -----Original Message----- From: David Hancock [mailto:D.Hancock@CableLabs.com] Sent: Friday, April 30, 2010 1:25 PM To: Spencer Dawkins Cc: Bernard Aboba Subject: RE: Notes from Martini Spencer -- in the spirit of favoring timeliness over cleanliness, here are my pretty rough notes... David --------------------------------------------------------- Meeting started -- agenda OK. 1. Requirements discussion led by John Elwell John Elwell - Do we keep issue#39, or does it go in a solutions draft? Spencer - would prefer to keep it in Req's draft, since we're not sure what sol'n draft it goes in. Bernard - could it go in Olive Hadriel? Hadriel will look at. Slide-4: issues 15 & 16 are addressed (or at least discussed) in Olive. These requirements are in-line with the MARTINI charter, but they are not required by the charter (i.e., charter mandates support of AORs based on E.164 numbers, but does not preclude support of other forms of AORs) Slide-5: Lists 5 options for handling issues 15 & 16 1. don't adopt at all, and lose phase-2 req's 2. adopt as requirements, but do them in phase-2 3. adopt as desirables 4. restructure req's doc - ph-1 vs. 2 Adam - there is a 6th option - constrain the current doc to phase-1 requirements - with understanding to do a follow-up phase. Martin - there was support for option-2 on MARTINI reflector. Hadriel - I thought these were desirable. At least 16 - the extensibility one. Dean - we specifically excluded #15 for phase-1 - to limit to E.164 numbers. Keith - if we do this - how do we meet/handle these requirement in the solutions draft? Adam - by demonstrating in another draft (e.g., olive) how the extension could be supported. Spencer - understand that everyone on group supports the requirement for non-e.164 numbers. John Elwell - yes, would like 15/16 to be supported eventually, just not in phase-1. Spencer (as chair) would not want to ignore these. Should address them as required or desirable. So, should the working group continue advancing Olive? Martin - there was a contingent of folks that saw the need to address these now - as in phase-1. Dean - does that mean stop working on GIN until we figure out how it can support 15/16. Martin - a requirement is a requirement. There is never a question of phasing requirements. If you choose to defer meeting a requirement, then it is still a requirement, just at a later date. Adam - what I'm hearing is to reverse the MARTINI-II meeting agreement to limit phase-1 to E.164 numbers. Dean - no, Martin is just saying these are requirements, we just need to decide schedule. Keith - there is also a desire that these requirements can be supported by MARTINI GIN extension, and not a whole new solution. Bernard - such a change would require a MARTINI charter change. Someone - (who?) doesn't agree this is a charter change. John - adding a requirement that soln should be extensible is within charter. Dean and Bernard agree. Dean - charter says must support E.164, may support others. John - am hearing that we add req's for 15 & 16, reworded to say soln "must be extensible". Spencer, Adam, agree. ** General Agreement - Add requirement(s) that the phase-1 solution must be extensible to support 15 & 16. Looping back to issue#39: Hadriel - 1st paragraph of issue is actually wrong. Propose that we remove this issue. John - don't mind deleting it, but was asked to add it by Jon Peterson at IETF#77 mtg. Propose taking this to the list - and give reasons and get consensus to remove it. Spencer - if list decides that it should be somewhere - would that place be the olive draft (or whatever document addresses solution for the 15/16 requirements). Hadriel - the Olive draft does cover this already, so that's covered [John] ** General agreement -- Will take 15/16 & 39 to the list. 2. Adam - GIN slides Someone: There is a 4th option, which is to let the SSP decide whether "user=phone" is required. Martin - we expect the PBX to support user=phone in the Request-URI of INVITE. Doug - if you do option-1, then have trouble reconciling with Olive; for example, PBX specifies user=phone in REGISTER request, and at the same time wants to support non-E.164 numbers that wouldn't have user=phone Adam - I thought there were some implementations that required user=phone. Hadriel - yes and there are some implementations that require it for E.164 numbers, and other implementations that ignore this parameter. Martin - there is a difference between not dropping call, vs. requiring it. (editor's note -- I may have misquoted Martin here -- looking at it now I'm not sure what it means, so remove if you see fit) Hadriel - the problem the 1st option is that it is treating u=p an opaque parm in the contact. The problem is that it really isn't opaque - it has meaning in the INVITE. Hadriel - A 5th option is to not mention user=phone at all, either in examples, normative text, etc. Adam - the fact that this has caused so much confusion - the document should talk about it at least to say something. John - likes option-2 - let the SSP decide whether or not to put u=p in request URI (based on what is stored in location db). The u=p is really an extension of the user part, and since the user part is the expansion of the template provided in the bulk REGISTER Contact URI, the u=p parm should be configured in the SSP as part of that expansion. I.E. Whether it is there or not is based on provisioning. It's possible for two diff users to have an AOR - same E.164 - one with u=p and one without. Doug (Sauder?) - propose adding an indicator/parametersomewhere in the REGISTER indicating that the PBX requires u=p for AORs containing E.164 numbers. Similar to option 1 , but PBX is making it explicit - I need a u=p for E.164 numbers. Adam/Hadriel - this may be a good option. Martin - want to emphasize that user=phone is required. Adam - this means that if you're testing a PBX in your lab that claims compliance with GIN (and we make proposed change), you would expect to see it indicate that it needs the user=phone parameter. Keith - solution should state what is mandatory vs, optional for the PBX and SSP to support. Multiple people agree. ** Agreement -- Adam will propose text for this new user=phone option. Slide Ticket#36. Keith - is there a use-case we have in mind, where the SSP needs to respond to reg-event when PBX is offline? And would it work any different than other packages such as dialog-event? Hadriel - the reg-event package routing is differently than other packages. The reg-event SUBSCRIBE is routed to the registrar of the AOR in the Request URI. Therefore, since the enterprise-user AORs belong to the SSP, the reg-event SUBSCRIBE is routed to the SSP. Having it go to the SSP makes sense -- say the target AOR can be registered simultaneously to the PBX and directly to the SSP. Adam : case where same AOR is registered to the SSP directly, and to the PBX, is a corner case. Adam: To header in REGISTER represents the PBX. You can subscribe reg-ev to it to get its registration state. But if you subscribe to the actual enterprise user AOR, then you want the actual registration state on the PBX of the enterprise user. What if my phone is registered to two PBXs for redundancy? Adam - this supports it - you get two separate answers. Hadriel - reg-event SUBSCRIBE request URI is owned by the SSP - therefore the SSP should respond. It shouldn't goto the PBX. In fact there may be no registration at the PBX; e.g., the PBX supports non-SIP endpoints. Adam : But sending the SWUBSCRIBE to the SSP doesn't provide any valuable information, since the it only reflects whether the PBX is registered or not, and 99.99% of the time it will be registered. Spencer - suggest taking this to the list. Agreed. Final slide - need a volunteer for outbound analysis. Dean suggests Paul Kyzivat. Spencer & Bernard will follow up with Paul. 3. Hadriel's olive presentation Keith - we would have avoided the whole subscribe to reg-event if we had followed the IMS implicit registration model. Adam, Dean - no - the problem would still be there, basically because RFC3261 does not have a good model for transitive registration, which is what both IMS and GIN bulk registration are. Dean - this is still broken for reg-event. Adam - agree. Solving it for GIN will solve it for olive as well. In fact Hadriel's solution is the GIN draft extended to none.164 numbers. Keith - not sure if you would ever explicitly register a local number. In IMS it would only be implicitly registered. Register global explicitly, and register local implicitly. Hadriel - but GIN is a compression/decompression rule for explicitly registrations. So what would an explicit registration of a local number look like? Keith - where is the lack-of-uniqueness problem? Adam - we were trying to make user-names globally unique to avoid the ambiguity that occurs when two PBXs have overlapping private numbers. Hadriel solves this problem by adding context to make local numbers unique. Hadriel - problem is a PBX could have both a public and private numbers. There are two ways to handle this - either two separate logical trunks, or something in the actual URI portion that makes local numbers unique. 4. Spencer - next steps Spencer enumerates agreements for moving (disposition of issues 15,16,39, Paul K reviews outbound, etc) Keith - is it possible for Hadriel to submit a draft-01 of Olive? Hadriel - yes. Keith - therefore we'll hold discussion until we see 01. John - req draft - assuming there is no pushback on 15,16,39 from list - are we going to progress the requirements draft? Bernard/Spencer - yes, progress the requirements draft? Meeting adjourned... > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: Friday, April 30, 2010 8:48 AM > To: David Hancock > Cc: Bernard Aboba > Subject: Notes from Martini > > Hi, David, > > Just in case you're doing your typically consciencious thing and working > over your notes from MARTINI yesterday - I also have notes from Dean, and > my > own notes, so you don't need to do much cleanup, and I'd like to get draft > notes out quickly, so that we can get mailing list concurrence with > directions that (I think) are pretty positive :-) > > Have a great weekend! > > Spencer From bernard_aboba@hotmail.com Fri Apr 30 15:30:56 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7C6C3A698C for ; Fri, 30 Apr 2010 15:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.683 X-Spam-Level: X-Spam-Status: No, score=0.683 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_50=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULyNJBaOvsOg for ; Fri, 30 Apr 2010 15:30:55 -0700 (PDT) Received: from blu0-omc2-s32.blu0.hotmail.com (blu0-omc2-s32.blu0.hotmail.com [65.55.111.107]) by core3.amsl.com (Postfix) with ESMTP id 633783A6911 for ; Fri, 30 Apr 2010 15:30:55 -0700 (PDT) Received: from BLU137-DS6 ([65.55.111.73]) by blu0-omc2-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Apr 2010 15:30:41 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Fri, 30 Apr 2010 15:31:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrn2TUz5LpBxH3kSsi2cVP7WnhotAA25nzA Content-Language: en-us X-OriginalArrivalTime: 30 Apr 2010 22:30:41.0859 (UTC) FILETIME=[C44C9130:01CAE8B4] Subject: [martini] FW: MARTINI notes X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 22:30:56 -0000 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, April 29, 2010 1:19 PM To: Bernard Aboba; Spencer Dawkins Subject: MARTINI notes Notes on Martini IV Notes by Dean WiIlis Callins include Martin Dolly, David Hancock, David something else, and another party. (Several more added later). Topic: Martini Requirements Led by John Elwell Current status reviewed. Issue #39, explanatory text in Section 1. Would this be more appropriate elsewhere, such as Olive? Spencer prefers it stay in the requirements draft, since we're producing only one of these and it'll be easier to find. Discussion moved on while Hadriel reviewed text. On review, Hadriel believes the first paragraph is just wrong (Background on the Issues), and needs to be tailored to unique contacts, not unique AORs. Hadriel proposes removing this text. Noted that this was added in response to Jon Peterson's input during IETF 77, so we might need to take such changes to the list. John will take this to list. Issue #15, #16 non-E.164 and extensibility to any AOR 5 alternative paths have been proposed. John proposes #1 or #3 (nothing or add as desirable). Adam suggests 6th option to be phase 1 deliverable, with a plan to do a second phase 2 requirements document for phase 2 deliverables. Noted that several people from list supported adopting requirements as they stand. Discussion of 2 phase approach and meaning of requirements followed. John proposed that we could reword #15 to talk about extensibility to non-E.164 numbers, then accept #15 and #16. This approach seemed to achieve consensus in the discussion. Keith asked to clarify the implication of "must be extensible" -- how do we handle this in the solutions draft? Adam responded that the draft(s) must include discussion of how the extensibility is provided. John Elwell said that he would like to see #15 and #16 done eventually, but that they aren't as urgent as E.164. Discussion continued on the question of whether the existence of Olive satisfies the requirements. Does this mean we should stop work on gin until we meet the requirements? Proposed by Keith that we need an existence proof that phase 2 is achievable based on phase 1 before we lock in phase 1. Bernard noted that the charter describes what the scope is with respect to E.164 numbers, and noted that we may need to modify the charter to encompass #15 and #16. Discussion followed, and we believe extensibility is within the charter. Solutions MAY be, as well; further discussion is indicated. Poll: Do have have consensus on including #15 and #16 in requirements, but adjusting #15 to "must be extensible". No one appeared to be opposed to this proposal. John will take this to the list for confirmation. Topic: GIN led by Adam Roach Changes reviewed. Issue: Ticket 28 user=phone Proposed at Anaheim to say if pbx needs user=phone, it registers user=phone. Question from Doug Sauder: The SSP is the one who knows whether this is a phone number or not, so it should be the one to add it. Martin noted that they expect to see user=phone on the INVITE and require PBXes to support it. Since PBXes do not currently register, it is less certain. Hadriel noted that surrogate registration currently does NOT include user=phone it. Discussion followed. Noted that there is a 5th option (proposed by Hadriel), where user=phone is a feature of the registration. If you register with you get only phone numbers; without you get all URIs. Some devices fail with user=phone, some require it. Extended discussion on contact routing, GRUU, etc, followed. Question: Is there any text suggesting that user=phone can be used in the current draft? Proposed that we pull user=phone out of the examples. John Elwell spoke in favor of option 2, which forbids user=phone on BNC URIs in REGISTER and requires SSP to add it on INVITE. How does this compare to a normal registration? If there is no user=phone on registered Contact and one comes back in the INVITE, what happens. (it depends...) Debate continued between Hadriel, Olle, John, and Adam. Then broadened. Doug proposed adding another flag to the REGISTER request that tells the SSP that the PBX expects to have user=phone added for phone number URIs, but not for non-phone-number URIs. Concluded that Adam will work this into the draft. Issue: Ticket #36 regevent handling Who serves the regevent subscription -- SSP or PBX? Question: Is the SSP knowledge ever useful information, or does it just show whether or not the PBX is online. Yes; there may be multiple registrations for a user at the SSP. Question: How does this apply to dialog event? Adam says what he is expecting to work here is when an external user wants to use regevent in communication to with a PBX user. Debate inconclusive and to be taken to the list. Issue: Other open tickets Still need expert analysis on interacttion with draft-ietf-sip- outbound. Chairs will work on a victim. Topic: Olive draft Led by Hadriel Kaplan Noted by Spencer that he had recently asked list about wether the result of bulk registration is the same as the result of multiple individual registrations. Is the right place inside Olive? Keith noted that this assumption is part of why gin is fundamentally broken; we need something that works differently from conventional contact- routing. Debate ensued; inconclusive. Issue: Parameterized routing for domain aliases, or something. Too confusing for notetaker. Issue: Local Numbers ala RFC 3966 Question: Where is the lack of uniqueness problem? In what entity does it manifest? Answer: Systemic, but the SSP proxy is the one that needs to be able to differentiate. Noted that the result is still a URI to URI translation in the SSP proxy. Phone-context is an independent issue from domain name, but correlation between them can make life easier. When we say "user parameters", what do we mean? All of them; trunk group, etc. They become user parameters when converted to a SIP URI. Summary: Chairs repeated summary from preceding discussion. Question: Will we continue on this version of olive, or R&R? Hadriel reports that he is about to ship -01, so we should hold off on discussion until then. Process question: The requirements draft has some things to take to list, following this, will we try to progress it? The chairs believe "yes".