[SIPForum-techwg] Options in draft SIPconnect 1.1

Tue Sep 23 14:09:23 EDT 2008

David, I like the proposed restructure. In practice, we are definitely
seeing two modes of operation in the field.  The peering model is
probably most applicable to service providers targeting large
enterprises -- while the registration model is best suited for the SME
market where the IP-PBX is smaller and has fewer lines.  If we can
rework the document to be clear about these two models, I think it would
help the readability.  

As it is written in your doc online as well as the outline below -
sections 10/11 overlap with sections 12/13.  I'm don't feel we need
both...nor am I sensitive to which one we keep :) (I'm not spec
writer...but I play one on TV).

Regards,
JBP

> -----Original Message-----
> From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On
> Behalf Of Elwell, John
> Sent: Monday, September 08, 2008 4:22 AM
> To: David Hancock
> Cc: techwg at sipforum.org; Richard Shockey
> Subject: Re: [SIPForum-techwg] Options in draft SIPconnect 1.1
> 
> David,
> 
> Thanks. This seems to be along the lines that I had in mind. Obviously
> the devil will be in the details, but if we start to draft text along
> these lines, we can make minor adjustments as we go.
> 
> John
> 
> > -----Original Message-----
> > From: David Hancock [mailto:D.Hancock at CableLabs.com]
> > Sent: 05 September 2008 22:20
> > To: Elwell, John
> > Cc: Richard Shockey; Spencer Dawkins; techwg at sipforum.org
> > Subject: RE: [SIPForum-techwg] Options in draft SIPconnect 1.1
> >
> > 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
> >
> 
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:
> http://sipforum.org/mailman/listinfo/techwg