Subject: [dispatch] Fwd: I-D Action:draft-kaplan-dispatch-sip-implicit-registrations-00.txt

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 9 Jul 2009 13:37:06 -0400

Howdy,
As part of a discussion in the SIP Forum regarding a model for Registration we are using for IP-PBX's, I was asked by someone to submit an I-D describing it, in case it would be of any value.  Since I hadn't seen an I-D before on how 3GPP/ETSI did their model, and since their model is different from SIP-Forum's, I submitted one which describes the models for both SIP Forum's SIP-Connect v1.1 and 3GPP/ETSI.

NOTE: this draft was not sanctioned nor reviewed by the SIP-Forum nor 3GPP, and I am still talking with colleagues in 3GPP to make sure I got that part right.  This is purely an individual submission in all respects.

Forwarded message:
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Session Initiation Protocol (SIP) Implicit Registrations
	Author(s)       : H. Kaplan
	Filename        : draft-kaplan-dispatch-sip-implicit-registrations-00.txt
	Pages           : 12
	Date            : 2009-07-05

This document identifies several approaches to provide reachability information for a domain or multiple AoR's using a single SIP REGISTER method transaction, in ways not originally envisioned or documented by RFC 3261.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-sip-implicit-registrations-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 20 Jul 2009 16:38:35 +0200

Hi Hadriel,
Thanks for putting this together, this is useful.

- General
I think it would be good to add some informative references to the ETSI
TISPAN specification where the NGN/IMS way of performing business trunking
(SIP trunking) has been specified using the concept of implicitly registered
wildcarded public user identities (AORs)

The specification numbers are:
*ETSI TS 181 019 *V2.0.0 (2007-11)
Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN);*Business Communication Requirements*
*ETSI TS 182 023 V2.1.1* (2009-01)
Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN);*Core and enterprise NGN interaction
scenarios;Architecture and functional description*

*ETSI TS 182 025 V2.1.1 *(2008-09)
Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN);*Business trunking;Architecture and functional
description*

I think it would also be good to add informative references to the SIP
Connect specifications.

Further it might be good to say something about the different viewpoints
taken by the different bodies:
- ETSI TISPAN/3GPP Business Trunking are providing the viewpoint of the
service provider connecting IP-PBX's to its IMS/NGN infrastructure
- SIP Connect is more looking at the interconnect specifciation between the
an SSP and a IP-PBX.

Ideally both should match at some point to get an interoperable corporate
communication space.

- Section 6.2
The 3GPP/ETSI TISPAN mechanism does not add the notion of wildcarded
P-Associated-URI, but it adds the notion of wildcarded public user identity,
which generates so to speak the set of public user identioties to be
registered. This is not only visible on the P-Associated-URI header but also
makes configuration of such sets of public user identities easier.

3GPP and ETSI have extended the mechanism described here with the following
additions, for connected PBX's a subscription parameter can be set that
allows delivery of the target URI is kept in the request URI and the contact
address is added to the Route header after the stored path is inserted,
which means that in this case the P-Called-Party-ID is not strictly needed
for delivery of the target address.

Further this mechanism is extended to allow PBX/corporate proxies to use
P-Asserted-Identity instead of P-Preferred-Identity, which is a more natural
thing to do for corporate proxies.

Regarding the side note: This seems misleading as an SSP may very well serve
the domain name of  the enterprise, even if only for SIP traffic. This can
all be arranged with normal DNS infrastructure.

Best Regards,
/Hans Erik van Elburg

On Thu, Jul 9, 2009 at 7:37 PM, Hadriel Kaplan <[email-masked]>wrote:

> Howdy,
> As part of a discussion in the SIP Forum regarding a model for Registration
> we are using for IP-PBX's, I was asked by someone to submit an I-D
> describing it, in case it would be of any value.  Since I hadn't seen an I-D
> before on how 3GPP/ETSI did their model, and since their model is different
> from SIP-Forum's, I submitted one which describes the models for both SIP
> Forum's SIP-Connect v1.1 and 3GPP/ETSI.
>
> NOTE: this draft was not sanctioned nor reviewed by the SIP-Forum nor 3GPP,
> and I am still talking with colleagues in 3GPP to make sure I got that part
> right.  This is purely an individual submission in all respects.
>
> Forwarded message:
>        Filename        :
> draft-kaplan-dispatch-sip-implicit-registrations-00.txt
>        Pages           : 12
>        Date            : 2009-07-05
>
> This document identifies several approaches to provide reachability
> information for a domain or multiple AoR's using a single SIP REGISTER
> method transaction, in ways not originally envisioned or documented by RFC
> 3261.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 20 Jul 2009 16:49:22 -0400

Hi,
Thanks for the feedback!
Yes I agree I need to add the references explicitly into the reference section.
I also got some similar comments from other folks, so I'll update it with the consolidated set once the submission tool is open (and once we finalize this in SIP-Forum as well - it's still under debate).
-hadriel

________________________________
From: Hans Erik van Elburg [mailto:[email-masked]]
Sent: Monday, July 20, 2009 10:39 AM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [dispatch] Fwd: I-D Action:draft-kaplan-dispatch-sip-implicit-registrations-00.txt

Hi Hadriel,

- General
I think it would be good to add some informative references to the ETSI TISPAN specification where the NGN/IMS way of performing business trunking (SIP trunking) has been specified using the concept of implicitly registered wildcarded public user identities (AORs)

The specification numbers are:
ETSI TS 181 019 V2.0.0 (2007-11)
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);Business Communication Requirements

ETSI TS 182 023 V2.1.1 (2009-01)
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);Core and enterprise NGN interaction scenarios;Architecture and functional description
ETSI TS 182 025 V2.1.1 (2008-09)
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);Business trunking;Architecture and functional description

I think it would also be good to add informative references to the SIP Connect specifications.

Further it might be good to say something about the different viewpoints taken by the different bodies:
- ETSI TISPAN/3GPP Business Trunking are providing the viewpoint of the service provider connecting IP-PBX's to its IMS/NGN infrastructure
- SIP Connect is more looking at the interconnect specifciation between the an SSP and a IP-PBX.

Ideally both should match at some point to get an interoperable corporate communication space.

- Section 6.2
The 3GPP/ETSI TISPAN mechanism does not add the notion of wildcarded P-Associated-URI, but it adds the notion of wildcarded public user identity, which generates so to speak the set of public user identioties to be registered. This is not only visible on the P-Associated-URI header but also makes configuration of such sets of public user identities easier.

3GPP and ETSI have extended the mechanism described here with the following additions, for connected PBX's a subscription parameter can be set that allows delivery of the target URI is kept in the request URI and the contact address is added to the Route header after the stored path is inserted, which means that in this case the P-Called-Party-ID is not strictly needed for delivery of the target address.

Further this mechanism is extended to allow PBX/corporate proxies to use P-Asserted-Identity instead of P-Preferred-Identity, which is a more natural thing to do for corporate proxies.

Regarding the side note: This seems misleading as an SSP may very well serve the domain name of  the enterprise, even if only for SIP traffic. This can all be arranged with normal DNS infrastructure.

Best Regards,
/Hans Erik van Elburg

On Thu, Jul 9, 2009 at 7:37 PM, Hadriel Kaplan <[email-masked]<mailto:[email-masked]>> wrote:
Howdy,
As part of a discussion in the SIP Forum regarding a model for Registration we are using for IP-PBX's, I was asked by someone to submit an I-D describing it, in case it would be of any value.  Since I hadn't seen an I-D before on how 3GPP/ETSI did their model, and since their model is different from SIP-Forum's, I submitted one which describes the models for both SIP Forum's SIP-Connect v1.1 and 3GPP/ETSI.

Forwarded message:

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