Subject: [dispatch] Draft MARTINI charter with corrections incorporated

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 24 Nov 2009 12:35:19 -0800

Here is an updated version of the MARTINI charter with proposed corrections
incorporated:

=========================================================================

Multiple AoR reachabiliTy INformatIon (MARTINI)

Proposed Chair(s):

Spencer Dawkins <spencer at wonderhamster.org>

Bernard Aboba <bernard_aboba at hotmail.com>

Real-time Applications and Infrastructure Area Director(s):

Robert Sparks <rjsparks at nostrum.com>

Cullen Jennings <fluffy at cisco.com>

Real-time Applications and Infrastructure Area Advisor:

Cullen Jennings <fluffy at cisco.com>

Technical Advisor(s):

Mailing Lists:

General Discussion: martini at ietf.org

To Subscribe: martini-request at ietf.org

In Body: subscribe

Archive: http://www.ietf.org/mail-archive/web/martini/index.html

Description of Working Group

The MARTINI working group is chartered to specify a means by 

which an entity authoritative for SIP URIs can dynamically register 

reachability information for multiple AoRs with a service provider.

The SIP protocol [RFC 3261 and its extensions] supports 

multiple means of obtaining the connection information necessary 

to deliver out-of-dialog SIP requests to their intended targets.  

When a SIP Proxy needs  to send a request to a target address-of-record 

(AoR) within its domain, it can use a location service to obtain the 

registered contact URI, together with any associated path

information [RFC 3327], and build a route set to reach the 

target UA(s).  The SIP REGISTER method can be used to register contact 

URIs and path information. SIP-outbound [RFC 5626] enhances this mechanism 

to cater for UAs behind NATs and firewalls. When a SIP UA or Proxy needs to 

send a request to a target for which it is not authoritative, the UA/Proxy 

can use RFC 3263 procedures for using DNS to resolve the next-hop connection

information.

Practice has shown that existing mechanisms are not always sufficient for 

supporting SIP-PBXs for small/medium businesses (SMB). A SIP-PBX might serve

tens or hundreds of AoRs by acting as the registrar/proxy. UAs register with

the SIP-PBX on behalf of the AoRs concerned, and inbound requests to those 

AoRs need to be delivered to the SIP-PBX for onward delivery to registered
UAs. 

Where the SIP-PBX uses a SIP Service Provider (SSP) for external traffic,
the 

SIP-PBX needs to be reachable from the SSP for inbound requests to the AoRs 

concerned.

Since a single SSP may support multiple thousands of such SMB 

SIP-PBX's, it is impractical and cost-prohibitive to manually provision
their 

IP addresses in every SIP node along paths to those SIP-PBXs.  Furthermore, 

IP addresses can be dynamically assigned and therefore can potentially
change 

relatively frequently.

Today dynamic reachability mechanisms are commonly used, 

based on the SIP REGISTER method.  Effectively a single REGISTER request 

registers the AoR of the SIP-PBX, so that any out-of-dialog request targeted

at a SIP URI for which the SIP-PBX is authoritative can be delivered from
the 

SSP to the SIP-PBX. However, implementations of this mechanism vary in
details, 

leading to interoperability issues between SIP-PBXs and SSPs, and the need
for 

equipment to support different variants.

The task of this working group is to to standardize a multiple AoR
registration 

mechanism for SIP that can be widely deployed by service providers at large

scale. The solution will support AoRs with E.164 addresses at 

a minimum, although support for a broader class of AoRs may be included.

The solution will utilize existing SIP mechanisms to the extent possible, 

although it is anticipated that small protocol extensions are likely to be

required, and hence a standards track (rather than BCP) deliverable is

expected. The solution will accommodate existing SIP extensions relating to

registration (e.g., Path, Service-Route [RFC 3608] and SIP-outbound) by
ensuring

that they are not precluded from use in the context of multiple AoR

registrations. The solution will incorporate a compatibility mechanism to 

ensure a deterministic outcome when interworking with entities that 

do not support multiple AoR registration.

The working group will work coordinate with SIP Forum and other industry
groups 

on requirements and other IETF working groups including DRINKS and SIPCORE.

Goals and Milestones

Dec 2009     Draft solicitation

Jan 2010     Interim meeting

Feb 2010     First Working Group Last Call

Mar 2010     Second Working Group Last Call

Apr 2010     Multiple AoR Registration specification to IESG (PS)