7.2 Multiple AoR reachabiliTy InformatioN Indication (martini)

NOTE: This charter is a snapshot of the 77th IETF Meeting in Anaheim, California USA. It may now be out-of-date.

Last Modified: 2010-04-02


Bernard Aboba <Bernard_Aboba@hotmail.com>
Spencer Dawkins <spencer@wonderhamster.org>

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

Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Robert Sparks <rjsparks@nostrum.com>

* The Real-time Applications and Infrastructure Area Directors were seated during the IETF 65.

Real-time Applications and Infrastructure Area Advisor:

Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>

Mailing Lists:

General Discussion: martini@ietf.org
To Subscribe: https://www.ietf.org/mailman//listinfo/martini
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 that is authoritative for SIP URIs can dynamically register
reachability information for multiple Addresses of Record ("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 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.

In practice, many small and medium-sized businesses use a SIP-PBX that
is authoritative for tens or hundreds of SIP AoRs. This SIP-PBX acts as
a registrar/proxy for these AoRs for clients hosted by the SIP-PBX. UAs
register with the SIP-PBX on behalf of the AoRs concerned. A SIP Service
Provider (SSP) provides SIP peering/trunking capability to the SIP PBX.
The SIP-PBX must be reachable from the SSP so that the SSP can route
inbound SIP requests for the AoRs addressed to the SIP PBX, routing
these requests to the SIP-PBX itself for onward delivery to registered UAs.

Experience has shown that existing mechanisms are not always sufficient
to support SIP-PBXs for small/medium businesses. 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

In current deployments, dynamic reachability mechanisms based on the SIP
REGISTER method are commonly used. 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 other classes 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

The working group will coordinate with SIP Forum and other industry
groups on requirements and will coordinate its work with other IETF
working groups including DRINKS and SIPCORE.

Goals and Milestones:

Dec 2009  Solicit solution-space drafts
Jan 2010  Interim meeting
Jan 2010  Adopt Working Group draft
Feb 2010  First Working Group Last Call
Mar 2010  Second Working Group Last Call
Apr 2010  Multiple AoR Registration specification to IESG (PS)
Jul 2010  Close or recharter working group


  • draft-ietf-martini-reqs-07.txt
  • draft-ietf-martini-gin-03.txt

    No Request For Comments

    Meeting Minutes 07-01-2010

    Meeting Minutes 26-01-2010

    Slides 07-01-2010

    How We Got Here

    Slides 26-01-2010