Subject: [dispatch] MARTINI Charter based on DREGs ad-hoc

From: Cullen Jennings <[email-masked]>
Date: Fri, 20 Nov 2009 13:14:35 -0700

I plan to send the following charter to the IESG on monday unless someone catch significant problems with it. The IESG would discuss it on the Dec 3 call and would decide if it was ready for IETF LC. At that point it would be sent for a 2 week IETF Last Call where everyone could comment on it and then come back to the IESG for approval on the Dec 17 IESG call. 

Cullen <RAI AD>

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

Multiple AoR reachabiliTy InformatioN Indication (MARTINI)
 
Proposed Chair(s):
Spencer Dawkins <[email-masked]>
Bernard Aboba <[email-masked]>

Real-time Applications and Infrastructure Area Director(s):
Robert Sparks <[email-masked]>
Cullen Jennings <[email-masked]>

Real-time Applications and Infrastructure Area Advisor:
Cullen Jennings <[email-masked]>

Technical Advisor(s):

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
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 RFC3263
procedures for using DNS to resolve the next-hop connection information.

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 2010     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)

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 23 Nov 2009 09:42:33 +0100

Thanks, Cullen and others, for this initiative. Compared with DREGS, this seems to address the concerns raised during the ad hoc in Hiroshima. There does seem to be some text missing - see below: 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: 20 November 2009 20:15
> To: [email-masked]
> Subject: [dispatch] MARTINI Charter based on DREGs ad-hoc
> 
> 
> I plan to send the following charter to the IESG on monday 
> unless someone catch significant problems with it. The IESG 
> would discuss it on the Dec 3 call and would decide if it was 
> ready for IETF LC. At that point it would be sent for a 2 
> week IETF Last Call where everyone could comment on it and 
> then come back to the IESG for approval on the Dec 17 IESG call. 
> 
> Cullen <RAI AD>
> 
> ------------
> 
[JRE] There seems to be something missing prior to the text below. We need something to describe the problem, and we also need to introduce the terms "SSP" and "SIP-PBX". I propose we add a paragraph:

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

John

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