[SIPForum-techwg] SIPconnect 1.1 baseline - comment on architecture

David Hancock D.Hancock at CableLabs.com
Thu Sep 4 19:41:39 EDT 2008


John,

In the proposed v00 Reference Architecture diagram we maintained some of
the "internal" elements that were shown in the original SIPconnect 1.0
diagram in order to minimize impacts to the document (e.g., original
text places requirements on the App Server, so we kept it in the
diagram). However, I agree this is more detailed than necessary, and
would be happy to simplify the diagram down to the minimum required. 

Is the attached version closer to what you had in mind? If people are OK
with this version then obviously we would need to update the SIPconnect
1.1 text to match.

Thanks

David

-----Original Message-----
From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Elwell, John
Sent: Wednesday, August 13, 2008 1:06 AM
To: techwg at sipforum.org
Subject: [SIPForum-techwg] SIPconnect 1.1 baseline - comment on
architecture

The Reference Architecture in figure 1 is a step in the right direction,
in that it clearly separates signalling and media. However, on the
signalling side of the figure, I have to question the two proxy servers:
a) The SIP proxy server in the enterprise network. This is shown as an
optional entity between the IP-PBX and the SP. It is true that there
will often be some edge device, but frequently it is not a proxy, e.g.,
an SBC that has B2BUA characteristics. It would be preferable not to
show the internal signalling architecture of the enterprise network.
Just a single signalling entity (this could be called the IP-PBX) would
be sufficient. From the point of view of the service provider, the
internal signalling architecture of the enterprise network should be
unimportant.
b) Similar comments can be made about the service provider side. From
the point of view of the enterprise network, the internal signalling
architecture of the service provider should be unimportant.
c) There is an inconsistency between the service provider and enterprise
blocks, in that the signalling entities within the enterprise block are
connected by lines or broken lines, whereas in the service provider
block they are unconnected. What is the reader expected to understand
from this? By reducing each side to a single signalling entity (and a
single media entity), this issue would be resolved.
d) There are some inconsistencies throughout the document (e.g.,
concerning whether something is mandatory for the proxy or for the
IPPBX) and these are most easily resolved by simplifying the
architecture.

John


John Elwell
Head of Standardisation Strategy
Siemens Enterprise Communications GmbH & Co. KG
Office of the CTO
SEN ESY CTO IM
Hofmannstrasse 51
D-81379 Munich

Tel: +44 115 943 4989
Mob: +44 7711 877830
john.elwell at siemens.com <mailto:firstname.lastname at siemens.com> 

Siemens Enterprise Communications GmbH & Co. KG
Managing Directors: Reinhard Benditte, Gerhard Otterbach, Thomas
Zimmermann
Registered offices: Munich
Commercial registry: Munich, HRA 88546
WEEE-Reg.-No. DE 27980375
General Partner: Siemens Enterprise Communications Management GmbH
Registered offices: Munich
Commercial registry: Munich, HRB 163415

This email contains confidential information and is for the exclusive
use of the addressee. If you are not the addressee then any
distribution, copying, or use of this email is prohibited. If received
in error, please advise the sender and delete immediately. We accept no
liability for any loss or damage suffered by any person arising from use
of this email.


_______________________________________________
techwg mailing list
Send mail to: techwg at sipforum.org
Unsubscribe or edit options at:
http://sipforum.org/mailman/listinfo/techwg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Architecture Reference-v2.ppt
Type: application/vnd.ms-powerpoint
Size: 309760 bytes
Desc: Architecture Reference-v2.ppt
Url : http://sipforum.org/pipermail/techwg/attachments/20080904/cbbb91ba/attachment-0001.ppt 


More information about the techwg mailing list