Subject: [Sipping] RE: SBC architectures document

From: "Khan, Sohel Q [NTK]" <[email-masked]>
Date: Sat, 23 Jul 2005 22:52:27 -0500

Because there are some works on SBC related functions as specified in
the
http://www.ietf.org/internet-drafts/draft-camarillo-sipping-sbc-funcs-01
.txt, we thought it is a good idea to bring border architecture (or SBC
deployment scenario) at the same time so that you can see the providers'
perspective. The document will help the SIPPING community to understand
that S/BC functions and SIP protocol extensions need to be studied in
holistic 
border protection architecture approach and can be deployed in the
network in scalable fashion. We may need to develop SIP extensions to
communicate between various functional components described in
draft-sohel-sipping-s-bc-concept-arch-00.txt. 

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Saturday, July 23, 2005 6:06 PM
To: Khan, Sohel Q [NTK]
Cc: sipping WG; Rohan Mahy; Dean Willis; Gonzalo Camarillo
Subject: SBC architectures document

Hi,

I read your SBC architecture document and noticed your agenda request.  
I don't immediately understand the relevance of this draft to our 
charter in SIPPING.  We have generally avoided discussion specific 
decomposition approaches in SIP and SIPPING, and frequently we have 
left this decomposition work to other groups, as was the case for media 
servers (speechsc), conferencing (xcon), and media gateways (megaco). 
Is there some specific action that is relevant to the group, for 
example requirements on the SIP protocol?

thanks,
-rohan

Rohan Mahy
co-chair SIPPING WG

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 23 Jul 2005 21:08:45 -0700

Hi,

As I stated previously, I don't believe it is within our scope to  
define the protocol or protocol extensions that would be used between  
individual components of a decomposed SBC.

thanks,
-rohan