[SIPForum-techwg] Options in draft SIPconnect 1.1

[David Hancock]

John,

I agree that your proposal to re-org the document around the
subscription-based vs. peering-based modes of operation would simplify
things. Here's a 1st pass proposal of what the re-org might look like.

Section 1 through 6 are unchanged (note, I inserted some level-1
sections that are missing from the v00 version). 

1	Introduction	
2	Conventions and Terminology	
3	Reference Architecture
{Assume that both modes be described by a single architecture diagram.}	
4	Definitions	
5	Key Assumptions and Limitations of Scope	
6	Standards Support	

7 	Subscription-based Mode
{... general description of this mode...}
7.1	Locating SIP Servers
7.1.1 Enterprise Requirements
7.1.1.1 Providing Enterprise Address to SP
  {...using SIP registration as specified in 7.5}
7.1.1.2 Obtaining SP Address
  {Configured in IP-PBX, or discovered using RFC3263}
7.1.2 SP Requirements
7.1.2.1 Providing SP address to Enterprise
  {...using DNS}
7.1.2.2 Obtaining Enterprise Address
  {...using SIP registration as specified in 7.5}
7.2	Supported Signaling Transport Protocols
  {Maybe this section is common to both modes?}
7.3	Signaling Security
7.4	Firewall and NAT Traversal
7.5	Registration
7.6	Failover and Recovery
7.7	Authentication, Authorization and Accounting

8	Peering-based Mode
{... general description of this mode...}
8.1	Locating SIP Servers
  {Similar layout to 7.1, but with different content.}
8.2	Supported Signaling Transport Protocols
8.3	Signaling Security
8.4	Firewall and NAT Traversal
8.5	Failover and Recovery
8.6	Authentication, Authorization and Accounting

{These next three sections currently contain some text that applies to
one or the other of the two modes. Need to determine whether text can be
generalized such that it applies to both models, or text needs to be
split up between the two model sections...}
9	Enterprise Public Identities
10	Enterprise URI Formatting and Addressing Rules
11	Service Provider URI Formatting and Addressing Rules	

{Hopefully the text in the remaining subsections already apply to both
models...}
12	Incoming Calls from the Service Provider to the Enterprise	
13	Outgoing Calls from the Enterprise to the Service Provider	
14	Media Attributes and Minimum Requirements	
15	Service Provider Session Interactions	


If we have consensus that such a re-org should be done, then CableLabs
can propose a more detailed outline with 1st-pass content for each
section. For this initial phase I propose that we maintain existing text
(moved to the appropriate new subsection), and then add changes
resulting from the other review comments later.

This will be a fair amount of work, so before going further I would like
to know whether there is general consensus that such a re-org is a good
thing, and if the above section layout is in the right direction. I'm
very open to alternate proposals.

Thanks

David


-----Original Message-----
From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Elwell, John
Sent: Monday, September 01, 2008 12:13 AM
To: Richard Shockey; Spencer Dawkins; techwg at sipforum.org
Subject: [SIPForum-techwg] Options in draft SIPconnect 1.1

I just posted a set of comments on sections 1-10 of the draft (see my
previous message). A recurring theme concerned the options around use of
TLS, use of mutual versus server authentication, use of registration,
use of DNS, publicly reachable IPPBX addresses, digest authentication,
etc..

It seems to me there are two basic modes of operation possible:
- registration-based
- DNS-based

These refer to the mechanism by which the SP delivers requests to the
IPPBX. With registration-based, the IPPBX has to create and maintain a
registration to the SP, thereby creating and maintaining a path by which
inbound requests can be delivered to the IPPBX. With DNS-based, inbound
requests use RFC 3263 procedures to reach the IPPBX.

Incidentally, these correspond closely to the two mechanisms identified
in ETSI TISPAN (known there as subscription-based and peering-based).

It seems both mechanisms have pros and cons (some are documented in the
draft), and it does not seem possible to eliminate either of these.

Depending on which of these you deploy, that seems to close a number of
other options within the draft.

For registration-based:
- registration is used;
- digest authentication is used;
- TLS is desirable (not necessary);
- there seems to be a presumption that TCP connections (and similar TLS
sessions, if used) are established only in the direction IPPBX to SP and
are maintained (using a keep-alive mechanism);
- assuming above, TLS mutual authentication may not be necessary (server
authentication might suffice, since digest is used to achieve client
authentication);
- the IPPBX does not need to have an IP address reachable from the SP;
- sip-outbound appears to be necessary or at least desirable to achieve
the above (provides keep-alive, provides NAT traversal if needed).

For DNS-based:
- registration is not used;
- digest authentication is not used;
- TLS is necessary;
- TLS mutual authentication is necessary;
- connections are not maintained (does not preclude connection-reuse,
however);
- it needs to be possible to establish connections in either direction;
- the IPPBX must have an IP address reachable from the SP;
- SIP outbound is not applicable.

If there is substantial agreement on this, then the document (or at
least sections 4.1 through 10) really needs restructuring to identify
these two options, decide which are mandatory and which are optional for
each side, and then spell out for each separately the consequent
requirements concerning IP addresses, TLS, authentication, outbound,
registration, etc..

Comments?

John


_______________________________________________
techwg mailing list
Send mail to: techwg at sipforum.org
Unsubscribe or edit options at:
http://sipforum.org/mailman/listinfo/techwg