Subject: [Sipping] New draft on grouping of AoRs

From: "Jesus Javier Arauz \(MI/EEM\)" <[email-masked]>
Date: Mon, 20 Nov 2006 12:21:54 +0100

Hi,

Some weeks ago I submitted the draft
draft-jarauz-sipping-grouping-reg-event-00 to the IETF drafts archive.

As many of you know, within the IMS application of SIP a user can have
his/her AoRs grouped in so-called Implicit Registration Sets (IRS). The
goal of this grouping is to allow bootstrapping a SIP UA that knows only
one of the AoRs in an IRS, so the UA gets all the AoRs within that IRS
simultaneously registered (and deregistered) in an implicit way.

Within the context of the latest IMS release (Rel-7) a finer-grained
mechanism for grouping AoRs has been introduced. The need to have
"aliases", or sets of fully equivalent AoRs, was identified. The IRS
mechanism was evaluated as a means to fulfill this need and the
conclusion was that the goals of the IRS (i.e. bootstrapping) and the
AoR aliasing are orthogonal and thus problems could arise if the same
mechanism is used for both purposes. Therefore a new mechanism has been
introduced that allows defining groups of alias AoRs that are fully
equivalent from a network perspective, i.e. any AoR within one group
receives the very same treatment from the network as any other AoR
within that group. In order to simplify network handling of these groups
the limitation was introduced that any group of alias AoRs must not span
more than one IRS, i.e. a group of alias AoRs is always a subset of a
containing IRS.

There are situations where it is convenient that other network entities
different from the registrar are aware of the existence and composition
of groups of alias AoRs. The three situations that have been identified
so far are:

1) The UA needs to know about the groups of alias AoRs within an IRS in
order for it to know that it can use any of those alias in a SIP
procedure when there is no indication from the user otherwise. For
instance if the UA has a local call barring feature, if the barring is
active for a given AoR it must be implicitly active also for any other
AoR belonging to the same group of alias AoRs as the former.

2) The first-hop proxy (P-CSCF) needs to know about the groups of alias
AoRs within an IRS in order to provide them to the access network's
policy decision point (PCRF), which may then apply common policies to
all the alias AoRs within a group. This simplifies policy management in
the access network, allowing to define group-wide policies instead of
policies per AoR.

3) A proxy of B2BUA providing services to the user (AS in IMS
terminology) needs to be able to know about the groups of alias AoRs in
order to provide the same services with the same service parameters to
all the alias AoRs within a group.

There is a mechanism in the IMS network to notify any interested party
about the composition of a user's IRS, based on the registration event
notification mechanism defined in RFC3680. The draft I've submitted
extends this mechanism to include the group or groups of alias AoRs that
exist within those IRS. The mechanism is mandatorily supported by the
IMS UA and first-hop proxy and can also be leveraged by proxy/B2BUA
entities so it fulfills the three requirements outlined above.

I'd like to know what are the sipping community's views on the draft?.

Thanks and regards,
/Javier

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Steve Langstaff" <[email-masked]>
Date: Mon, 20 Nov 2006 08:31:52 -0800

> From: Jesus Javier Arauz (MI/EEM)
[mailto:[email-masked]] 
> Sent: 20 November 2006 11:22
> To: [email-masked]
> Subject: [Sipping] New draft on grouping of AoRs
>
> Hi, 
>

(Please forgive me if this appears to be a question that has been
answered many times before.)

If the AoRs are 'fully equivalent' why can't they be replaced by a
single AoR?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Nov 2006 12:22:47 -0500

Steve,

At least one reason for the aliases is that they may be of different 
forms that are better suited to use with different devices or modes of 
access. For instance:

   sip:[email-masked]
   sip:[email-masked]

	Paul

---

From: "Jesus Javier Arauz \(MI/EEM\)" <[email-masked]>
Date: Tue, 21 Nov 2006 10:35:02 +0100

Steve, Paul has given you the key reason.

Another, less relevant reason is to be able to use 'nicknames', i.e.
'sip:[email-masked]' and 'sip:[email-masked]'. The
latter will be easier to type in if it's not in the caller's phonebook.

Regards,
/Javier

Paul Kyzivat wrote:
> forms that are better suited to use with different devices or modes
> of access. For instance:  
> 
>> his/her AoRs grouped in so-called Implicit Registration Sets (IRS).
>> The goal of this grouping is to allow bootstrapping a SIP UA that
>> knows only one of the AoRs in an IRS, so the UA gets all the AoRs
>> within that IRS simultaneously registered (and deregistered) in an
>> implicit way. 
>> mechanism is used for both purposes. Therefore a new mechanism has
>> been introduced that allows defining groups of alias AoRs that are
>> fully equivalent from a network perspective, i.e. any AoR within one
>> group receives the very same treatment from the network as any other
>> AoR within that group. In order to simplify network handling of these
>> groups the limitation was introduced that any group of alias AoRs
>> must 
>> not span more than one IRS, i.e. a group of alias AoRs is always a
>> subset of a containing IRS.
>> 
>> This list is for NEW development of the application of SIP Use
>> [email-masked] for questions on current sip Use
>> [email-masked] for new developments of core SIP

---

From: "Steve Langstaff" <[email-masked]>
Date: Tue, 21 Nov 2006 01:50:22 -0800

Fair enough - I was thinking that the users device(s) could register
with a single AoR and let the network perform any alias translation
required for incoming requests, but I guess that's putting a bit too
much control in the network.

> -----Original Message-----
> Sent: 21 November 2006 09:35
> To: Paul Kyzivat; Steve Langstaff
> Cc: [email-masked]
> Subject: RE: [Sipping] New draft on grouping of AoRs
> 
> 'sip:[email-masked]' and 
> 'sip:[email-masked]'. The latter will be easier to type in 
> if it's not in the caller's phonebook.
> 
> Regards,
> /Javier
> 
> Paul Kyzivat wrote:
> > Steve,
> > 
> >> must not span more than one IRS, i.e. a group of alias 
> AoRs is always 
> >> a subset of a containing IRS.
> >> 
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping