[VOIPSEC] SIP complexity, was VPNs and VoIP

[Philip Walenta]

That was (very indirectly) one of the points I was trying to get across.

SIP, H323, SCCP, MGCP all are lacking in what you've stated.  While attempts
have been made to help these protocols (RSVP, device level QoS), much of it
relies on the network configuration, and less on the protocol.  Trying to
properly QoS RTP/SRTP can be painful at times (are they using all of the
port range or only a fraction?  Is there another protocol in that same range
that is being accidentally marked as voice/video?)

I agree with you that SIP or any other real-time streaming protocol needs a
greater level of network awareness.  TCP has congestion control/windowing,
so I would think in this day and age we could find a way to give
RTP/SRTP/SIP etc this same ability without compromising its need for timely
delivery.  

While this does increase the complexity of the protocol, in the end it would
be incredibly beneficial, and IMHO very necessary if it wants to reach the
goal of five 9's.

Phil


> -----Original Message-----
> From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] On Behalf Of Geoff Devine
> Sent: Monday, July 31, 2006 8:53 AM
> To: Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] SIP complexity, was VPNs and VoIP
> 
> SS#7 implies one static architecture and a suite of protocols 
> that exist in that architecture.  SIP can be used in many 
> architectures.  Some keep state all over the place; some use 
> stateless proxies where only the endpoints have state.  
> 
> The biggest issue with SIP is that it has no inherent notion 
> of flow control, congestion control, or fault management.  
> When you are designing large five 9's networks, SIP creates 
> 'challenges'.
> 
> Geoff
>