Subject: RE: [Sipping] Session Border Control Deployment Scenario

From: "Khan, Sohel Q [NTK]" <[email-masked]>
Date: Fri, 22 Jul 2005 10:19:18 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 21, 2005 2:39 PM
To: Khan, Sohel Q [NTK]
Cc: [email-masked]
Subject: Re: [Sipping] Session Border Control Deployment Scenario

A few thoughts:

>- RF appears to be referring to IP routing. How is this L3 function
tied >into all these other higher layer functions?

Two routers from two administrative domains need to exchange "some"
topology/routing information and mediate their routing protocols. I
thought this as RF. 

>- Hot Potato Routing - Since all IP routing is between S/BCs only, this
>seems to become a VoIP routing problem. You would ideally need
something >like TRIP to do the Cold Potato Routing. In the absence of
that, Hot Potato > is probably the simplest.

Hot Potato routing may cause two end users to experience different voice
quality, which is annoying in a conversation. Thus, this needs to be
addressed.

>- Distributed S/BC - I wouldn't expect any carriers to front-end their
>routers with FWs, especially not for a peering connection.

Some suggests that a SIP aware firewall at the front should perform
special security functions such as avoidance of DoS.

>- In general I would say that the MF and RF should be in the edge
routers. >By also placing SF in the edge routers you can deal with VPNs
in a more >scalable manner, there is no need for new control protocol
development on >the softswitches etc., and there is an extra layer of
control-plane >security. A centralized SF in the softswitch may be ok
but it would be good >to at least have the functionality available in
the edge router for certain >cases.

I agree with you on this. Actually, in our draft, MF and RF are located
in the edge routers of the semi-composed (section 5.2), Centralized S/BC
with MGCF (section 5.3), Centralized S/BC with CSCF (section 5.4)
architectures.
Note, that MF and RF are functions not entities. 

>- As far as extensions go, would there be any benefit to a standard
>parameter that allows media release ?

I think so...

Cheers,
James

On Tue, Jul 19, 2005 at 08:44:58AM -0500, Khan, Sohel Q [NTK] wrote:
> 
> 
> Please review various conceptual deployment scenarios presented in the
> draft-sohel-sipping-s-bc-concept-arch-00.txt and provide feedback. We
> would appreciate discussion on SIP extensions as interfaces between
> these devices.
>  
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-sohel-sipping-s-bc-concept-arc
> h-00.txt
> 
> Abstract: This document illustrates various conceptual deployment
> scenarios of Session/Border Controller (S/BC). The objective is to
> depict a provider's 
> architectural requirements of S/BC function deployment. The document
> will help the IETF community to understand that S/BC functions can be
> deployed in the network in scalable approach.
> 
> 
> _______________________________________________
> 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: Dean Willis <[email-masked]>
Date: Fri, 22 Jul 2005 17:26:19 -0500

> special security functions such as avoidance of DoS.

Others might suggest that a SIP-aware firewall is in and of itself a 
DOS.

If you're trying to peer at many-times OC-192 rates, doing per-flow 
stateful ANYTHING at a boundary just isn't going to work. Sure, we can 
make that sort of thing work on a T1/E1 or two, but I thought we were 
talking about carrier networks?

--
Dean