[martini] FW: MARTINI drafts

"Bernard Aboba" <bernard_aboba@hotmail.com> Wed, 15 September 2010 02:50 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: martini@core3.amsl.com
Delivered-To: martini@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id DC1E03A67E6 for <martini@core3.amsl.com>; Tue, 14 Sep 2010 19:50:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.558
X-Spam-Status: No, score=-100.558 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_40=-0.185, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id M4K7wzANYCRP for <martini@core3.amsl.com>; Tue, 14 Sep 2010 19:50:15 -0700 (PDT)
Received: from blu0-omc3-s13.blu0.hotmail.com (blu0-omc3-s13.blu0.hotmail.com []) by core3.amsl.com (Postfix) with ESMTP id 97FFA3A6867 for <martini@ietf.org>; Tue, 14 Sep 2010 19:50:14 -0700 (PDT)
Received: from BLU137-DS17 ([]) by blu0-omc3-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Sep 2010 19:50:40 -0700
X-Originating-IP: []
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU137-DS17F82D3EBC53CFC162116393790@phx.gbl>
From: "Bernard Aboba" <bernard_aboba@hotmail.com>
To: <martini@ietf.org>
References: <9B2BE1B8C409EB41A7264357CC018CAC015AF0096D@PACORPEXCMB04.cable.comcast.com> <8FEA8178F3F3DE48833125C9F9DAD4ED048B8754@PACORPEXCMB04.cable.comcast.com>
In-Reply-To: <8FEA8178F3F3DE48833125C9F9DAD4ED048B8754@PACORPEXCMB04.cable.comcast.com>
Date: Tue, 14 Sep 2010 19:50:38 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A11_01CB5446.1B3FEFD0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHjJItlBr73IKtuOhHP+f3mCO9VuwGg+0v6ktWwk3A=
Content-Language: en-us
X-OriginalArrivalTime: 15 Sep 2010 02:50:40.0607 (UTC) FILETIME=[C8785EF0:01CB5480]
Subject: [martini] FW: MARTINI drafts
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Sep 2010 02:50:28 -0000



From: Khan, Sohel [mailto:Sohel_Khan@cable.comcast.com] 
Sent: Tuesday, September 14, 2010 8:24 AM
To: Khan, Sohel; adam@nostrum.com; hkaplan@acmepacket.com; Bernard Aboba;
Spencer Dawkins
Subject: RE: MARTINI drafts


One more input:

Section 5.1:

These parameters will be echoed back by the SSP in any requests bound

   for the SIP-PBX.


Did you mean to say the “response” to the REGISTER message.

You are not including the bnc and gin parameters in an INVITE coming to the
SIP-PBX. Is it correct?


From: Khan, Sohel 
Sent: Tuesday, September 14, 2010 11:01 AM
To: adam@nostrum.com; hkaplan@acmepacket.com; Bernard Aboba; Spencer Dawkins
Subject: MARTINI drafts


(Please do not include me in the mailing list discussion). 



Not clear to me from the draft what will happen when a new AoR is activated
and it registers with the SIP-PBX.

May be we have to say somewhere (if I did not miss it) that if the AoR to
SIP-PBX registration is a local procedure and registry request will not
transverse to the SSP.  Document implies it but not clear.


In section 4, it will be nice to write the mechanism something as follows
for clarity and understanding:

·         Mechanism:

o   The SSP provisions in its SIP-PBX and Registrar's location service
database  the list of AoRs associated with the SIP-PBX .

o    SIP-PBX registers a set of E.164 AoRs in “bulk” precluding REGISTER
requests for every E.164 AoRs that a SIP-PBX supports

o   SIP-PBX sends REGISTER request with a “bnc” (bulk number contact)
Contact URI parameter

§  This parameter indicates that Contact URI needs to be expanded in the
Registrar's location service database

§  The Register request causes the Registrar to populate “bulk” (the set of
AoRs) to contact binding

·         Each E.164 user number becomes the user portion of the Registered
Contact URI, one for each implicitly Registered E.164-based AoRs

§  SIP request routing to the registered AoR  follows RFC3261 procedures
after resolving the location of the SIP-PBX from Registrar's location
service database.

·         Replace the Request  URI with the (expanded) Registered Contact

§  Add Path information as a  Route etc




Thank You




Sohel Khan, Ph.D.

Product Engineering, Comcast

Comcast Center, 39th Floor, Philadelphia, PA 19103, Ph: (215) 286-4853(o),
(215)-828-6896 (m)

This message and any attachments to it may contain PROPRIETARY AND
CONFIDENTIAL INFORMATION exclusively for intended recipients. Please DO NOT
FORWARD OR DISTRIBUTE to anyone else. If you are not the intended recipient,
please contact the sender and delete all copies of this e-mail from your

P please don't print this e-mail if you can