Subject: RE: [Sipping] Draft: Functions of Current SBCs

From: Eric Burger <[email-masked]>
Date: Fri, 4 Mar 2005 18:10:50 -0500

And again, I'd go another step further.  As already pointed out, a B2BUA is
a B2BUA.  No restrictions on the "service" it offers.

My further step is to point out the ITU-T has been defining these kinds of
inter-operator architectures and profiles for many, many, many years longer
and with infinitely more experience than the MSF.  Why work with amateurs
when you can go with the pros? ;)

Either way, beyond JDR's call for "holes" in SIP, I don't see us doing much
other than publishing a BCP on how breaking End-to-End is not in the user's,
service provider's, or government's interest.

As pointed out elsewhere (I love queuing messages!), end points have become
so cheap that replacing them is much less expensive, in the long term, then
adding boxes to hack them into shape.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Tom Taylor
> Sent: Wednesday, March 02, 2005 10:47 AM
> To: Parolkar, Satish
> Cc: sipping
> Subject: Re: [Sipping] Draft: Functions of Current SBCs
> 
> 
> Nice formulation of policy issues.  I can answer your final 
> question: the 
> Multi-Service Forum (MSF) is working on the sort of policies 
> of which you speak.
> 
> Parolkar, Satish wrote:
> > I agree functions at network borders are business 
> relationships. Should
> > SBC functions be discussed in IETF forum at all?
> > 
> > I don't think the issue is of missing functionality in the 
> protocols or
> > lack of standardization. I believe the issue may be of 
> policy setting
> > between two VoIP networks. 
> > 
> > For example, consider the issue of security....There are 
> many ways that
> > two service provider domains can secure their networks.
> > 
> > (a) Should Security be established using IPSec between the 
> Edge Routers
> > so that VoIP call transport is secure across the public IP network? 
> > OR 
> > (b) Should security be established between proxy servers 
> using TLS to
> > secure SIP signaling? Do networks feel secure if only signaling is
> > protected?
> > OR
> > (c) Should IP end points based on their needs encrypt voice 
> using sRTP.
> > Who should be responsible to secure voice the end customer or the
> > service provider?
> > OR
> > (d) Should networks use Topology Hiding and strip or 
> encrypt some of the
> > SIP headers using Session Border Controllers that act as B2BUA.
> > OR
> > (e) Should networks use Media Relay to terminate and re-create RTP
> > streams at the edge of the networks using Session Border 
> Controllers.
> > 
> > Similarly, in regards to QOS. Two networks need to 
> establish policies to
> > determine if they want to use RSVP or DIffServ. Use MPLS 
> VPN with QOS
> > etc to establish QoS. Should Session Admission Control be 
> adopted? Once
> > again the protocols are established, it is just a matter of 
> policy and
> > agreement based on evaluations as to which approach helps 
> support voice
> > quality.
> > 
> > The SIP protocol, IPSec, TLS are all standardized. 
> Unfortunately there
> > are too many standards. So the issue is not at all about
> > standardization. It is about the policy two networks want 
> to establish
> > to ensure secure communications and that is a business relationship.
> > 
> > The issue that needs to be addressed is what security and 
> QoS policy is
> > optimum to provide secure and quality communications across peering
> > domains? Is there a forum that discusses the "policies" to establish
> > secure and quality VoIP communications across different 
> network domains?
> > 
> > 
> > Satish
> > SBC Labs.
> > 
> > 
> ...
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: [email-masked]
Date: Fri, 4 Mar 2005 17:43:50 -0600

>publishing a BCP on how breaking End-to-End is not in the user's, 

And also to keep the Internet working. This is the mission of the IETF.

>end points have become so cheap that replacing them is much less expensive,

>in the long term, then adding boxes to hack them into shape.

This is what P2P SIP will all be about. Just download the latest peer node
and use it on the Internet 'as is', without the ever more costly "VoIP
network infrastructure".

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eric Burger
Sent: Friday, March 04, 2005 5:11 PM
To: sipping
Subject: RE: [Sipping] Draft: Functions of Current SBCs

> Multi-Service Forum (MSF) is working on the sort of policies of which 
> you speak.
> 
> Parolkar, Satish wrote:
> 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
> 

_______________________________________________
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