FW: [SIPForum-techwg] Remarkable progress so far....

Mon Sep 26 21:10:14 EDT 2005

IP PBX / SP Interop WG team members,

My post below was caught in "list moderator limbo" due to the attachment
putting the message over the 150 KB per-message limit. Since no list
moderator has approved the post as of yet, I've put up a web link instead
where you can view the new diagram:

http://data.memberclicks.com/bbattach/107549/SIP_Forum_IP_PBX_SP_Ref_Arch_2.
jpg

Look forward to hearing your comments.

--Chris

  _____  

From: Chris Sibley [mailto:Chris.Sibley at cbeyond.net] 
Sent: Monday, September 19, 2005 10:15 AM
To: Richard Shockey; Rohan Mahy
Cc: SIP Forum Tech WG; Chris Gatch
Subject: RE: [SIPForum-techwg] Remarkable progress so far....

IP PBX / SP Interop WG team members,

Please find attached an updated version of the reference architecture
drawing as promised. I do apologize for not getting this out on Friday - my
"real job" simply took more of my time last week than I planned. :-)

As discussed, I have attempted to better portray the logical / physical
demarcations between the SP and Enterprise networks, while at the same time
placing the main emphasis on the protocols used between the entities. Please
take a look over the drawing and let me know any comments, feedback,
suggestions, etc you may have. 

As soon as we all feel comfortable with the reference architecture, I will
start work on updating the textual portion of our document. If you haven't
had a chance to review my brief summary of resolved / open issues below,
please take some time over the coming days to do so if you possibly can. 

Thanks,

--Chris

  _____  

From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
Behalf Of Chris Sibley
Sent: Friday, September 09, 2005 2:32 PM
To: 'Richard Shockey'; 'Rohan Mahy'
Cc: 'SIP Forum Tech WG'; Chris Gatch
Subject: RE: [SIPForum-techwg] Remarkable progress so far....

Richard,

I also agree that we have made pretty fabulous progress and have almost
reached consensus on most of the major issues. At this point, I am working
on putting together a new high-level reference diagram as previously
discussed by the group. This new diagram will depict the enterprise and SP
as logical entities and will place the emphasis on the protocols used
between the two entities (as opposed to the older diagram which broke things
down to the component level).

I think this diagram will help spur further discussions, as well as serve as
a "checkpoint" of sorts that I am correctly capturing the major
architectural points discussed so far. 

I expect to have the diagram out to the group no later than next Friday
(9/16). Once we can reach consensus on the reference diagram, I should be
able to get the textual portion of the document re-worked for review by the
group pretty quickly afterwards (~ 1 - 2 weeks). 

I have also attempted to provide a short summary of where we are today.
Group members, please feel free to add to / elaborate on / disagree with
these bullet items:

Major Issues Solved

---------------------------------

[[ 1 - Definition of a PBX ]] 

-- Can be either a pure proxy solution or a B2BUA solution. Both are valid
implementations and must be supported by the specification.

[[ 2 - AOR "Ownership" ]] 

-- The PBX may be the authoritative entity for a registered domain (i.e.
acmerockets.com), or it may be "authoritative" for a sub-domain assigned by
the SP (i.e. acmerockets.cbeyond.net)

[[ 3 - NAT Traversal ]] 

-- The Enterprise and the SP are each responsible for "fixing-up" IP
addresses contained in SIP messages before sending to the other.

-- Symmetric NATs should not be used and explicitly discouraged.

-- Any NATs/firewalls in the transmission path must be STUN-friendly.

-- Any SIP ALGs in the transmission path must be disabled.

[[ 4 - Media / Capability Requirements ]] 

-- The specification will include guidelines and/or minimum requirement
levels for such things as echo cancellation, DTMF relay, DSCP markings, etc.

[[ 5 - Securing signaling traffic between the enterprise and SP ]] 

-- The general group consensus is that TLS will be the mechanism used to
secure signaling between the enterprise and SP.

-- The TLS tunnel may or may not terminate directly on the SP's SIP
application server (CCS).

-- The PBX may optionally choose to authenticate the SP using mutual TLS
authentication. For this draft, this is the only supported method for a PBX
to authenticate a SP.

[[ 6 - Call Flows ]]

-- Call flows should be outside the scope of the document and thus removed.

Semi-Resolved Issues

-----------------------------

[[ 1 - Conveying / determining Billing Identity on a per-call basis ]]

-- The choice of whether or not to use TLS to secure signaling is at the
discretion of the enterprise. The SP must support it.

-- The service provider may challenge INVITES received from the PBX if TLS
if desired.

-- If challenged on an INVITE, the enterprise PBX must respond with a
SP-supplied username and password valid in the SP's realm.

[[ 2 - Providing current PBX contact information to the SP ]] 

-- If the enterprise is authoritative for their domain (i.e. cisco.com),
they are responsible for updating the associated DNS records whenever their
public IP address changes. This can be done via DYNDNS or manual updating,
but the actual mechanism probably should be outside the scope of the
document.

-- If the SP is authoritative for the customer domain (i.e.
acmerockets.cbeyond.net), the SP is responsible for updating the associated
DNS record upon request by the customer. 

-- The PBX may optionally register zero or more AORs with the SP.

Ideas / RFCs to be Considered for Future Draft Versions

----------------------------------------------------------------------

[[ 1 - draft-ietf-sip-identity ]]

-- As a group, we want to keep a close eye on this draft and make sure that
any specification we release will be ultimately compatible with it.

[[ 2 - SAML ]]

-- As a group, we need to look closer into the application of SAML towards
our problem of identity verification / authentication.

[[ 3 - Carrying billing information within the SP network ]]

-- Standard methods of carrying billing information within the SP network
needs to be defined (i.e. OSP, etc.) This will also help facilitate SP-to-SP
interoperability later.

Thanks,

--Chris

________________________________________

From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
Behalf Of Richard Shockey

Sent: Thursday, September 08, 2005 9:23 AM

To: Rohan Mahy

Cc: SIP Forum Tech WG; Chris Gatch

Subject: [SIPForum-techwg] Remarkable progress so far....

Rohan Mahy wrote: 

> 

> On Sep 1, 2005, at 15:15, Chris Gatch wrote: 

> 

>> Rohan, 

>> 

>> Clipping from your e-mail a few days ago with call flow examples 

>> regarding identity and naming conventions, you wrote 

>> 

>>> Acme's LA PBX gets a call to DC.  The PBX opens a TLS connection to 

>>> provider.net and provides its client certificate.  Acme sends an 

>>> INVITE that looks like this: 

>>> 

>>> INVITE sip:+12025551222 at provider.net;user=phone SIP/2.0 

>>> From: "Alice Andrews" 

>>> <sip:+13105554233 at lax-pbx.acemwidgets.com;user=phone> 

>>> Identity: # appropriate hash here # 

>>> Identity-Info: 

>>> <https://sec.acmewidgets.com/acme-cert.pem>;alg=rsa-sha1 

>> 

>> 

>> Regarding the use of the Indentity and Identity-Info fields, are you 

>> suggesting that we require support for draft-ietf-sip-identity-05? 

> 

> 

> While I think it is a good idea to encourage use of the Identity 

> mechanism, I don't think it is essential that we use it in the first 

> version of our spec. 

I agree.  The idenity spec is still under discussion and there is no 

current field experience with its use. Consequently adding it in to the 

requirements could seriously affect  the "time to market" issues I'm 

personally worried about. In addition I'm not sure the idenity spec is 

really the last word on the subject I continue to believe there is a 

strong relationship between SAML and SIP that has yet to be fully played 

out in the IETF. 

I'm getting the sense of the list  that their is considerable consensus 

on the direction we're going and that we are starting to see resolution 

of some of the major issues. 

Chris what is your time table for a second rev of the document? 

What other issues do you feel need to be resolved?  I have the sense 

that the question of idenity as it relates to billing matters is not 

completely resolved here if certs are not used. 

-- 

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 

Richard Shockey, Director - Member of Technical Staff 

NeuStar Inc. 

46000 Center Oak Plaza  -   Sterling, VA  20166 

sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com 

ENUM +87810-13313-31331 

PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 

Fax: +1 815.333.1237 

<mailto:richard(at)shockey.us> or 

<mailto:richard.shockey(at)neustar.biz> 

<http://www.neustar.biz> ; <http://www.enum.org> 

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 

_______________________________________________ 

techwg mailing list 

Send mail to: techwg at sipforum.org 

Unsubscribe or edit options at:  http://sipforum.org/mailman/listinfo/techwg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20050926/1e2b65d5/attachment.html 