Skip to main content

Multiple AoR reachabiliTy InformatioN Indication
charter-ietf-martini-01

Document Charter Multiple AoR reachabiliTy InformatioN Indication WG (martini)
Title Multiple AoR reachabiliTy InformatioN Indication
Last updated 2011-03-08
State Approved
WG State Concluded
IESG Responsible AD Gonzalo Camarillo
Charter edit AD (None)
Send notices to (None)

charter-ietf-martini-01
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
  frequently.
  
  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
  registration.
  
  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.