|
Home > Archive > Voice over IP Cisco > June 2005 > signaling very average bandwidth
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
signaling very average bandwidth
|
|
| Vladimir Litovka \(vlitovka\) 2005-06-02, 5:45 pm |
| Hello,
I have a question, which seems to be strange at a first glance - I need _average_ MGCP/SIP/H.323 bandwidth requirements for various operator categories (mobile, fixed) and for residential/business customers, dependently on 'calls per second' value. I unde
rstand, that question is not quite correct, because signaling bandwidth highly depends on various factors, such as calls complexity (switching to faxes and backward, etc), but I think, that there are some statistics, which more or less reflect real situat
ion.
For example, my calculation for MGCP gives me at least such values:
CRCX ~200 bytes (includes request itself and payload)
DLCX ~100 bytes
plus IP/UDP headers (2x24 bytes)
it is possible MDCX ~200 bytes, let us give average 1 MDCX per call (some calls may contain few MDCXes, some - no one). This adds 200+24 bytes per call. By multiplying this value (572 bytes) by CPS we get required bandwidth. For example, for 10CPS we get
10*572/8 = ~46Kbps.
As I understand, SIP generally is bigger and more complex, than MGCP and I can't even imagine something similar to calculation above  Same for H.323.
So, the question is - is there very very average statistics for these protocols?
Thank you.
--
/doka
| |
| Jared Mauch 2005-06-02, 5:45 pm |
| On Thu, Jun 02, 2005 at 03:37:42PM +0200, Vladimir Litovka (vlitovka) wrote:
> Hello,
>
> So, the question is - is there very very average statistics for these protocols?
Speaking to SIP (which is my primary experience space)
the SIP messages aren't very compact at all, since they're primarily
ascii headers combined with a sdp suffix/body in most cases.
These headers vary widely based on the SIP Proxy, SIP User-Agent,
etc..
Some devices take a minimalist approach to these headers, others
provide lots of extra data. Eg: a 7940/60 running a SIP image will
log more data when "call_stats: 1" is specified.
I think it's more of a value question, with call_stats enabled,
i'm able to diagnose more of what is going on with a phone.
Rx/ Dur=17,Pkt=706,Oct=112960,LatePkt=0,Lost
Pkt=0,AvgJit=1
Tx/Dur=17,Pkt=832,Oct=133120
Knowing that there were no lost packets in my media is far more
important than the signaling overhead. In most cases the signaling
doesn't need to be immediate (eg: 60ms vs 600ms) doesn't matter.
If you're trying to get an idea, i'd look at the options
messages which are frequently used as keepalives during NAT
operations. Here's an example:
SIP Proxy: (~445 bytes msg, not counting udp overhead)
OPTIONS sip:1101@120.0.0.188:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK22a3b940
From: "asterisk" <sip:asterisk@10.10.10.10>;tag=as3352c042
To: <sip:1101@120.0.0.188:5060>
Contact: <sip:asterisk@10.10.10.10>
Call-ID: 1aed267476f9b6501a2b05d929fb1c97@10.10.10.10
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Date: Thu, 02 Jun 2005 13:57:22 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE
Content-Length: 0
Phone: (~668 bytes msg, not counting udp overhead)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.10.10:5060;branch=z9hG4bK22a3b940
From: "asterisk" <sip:asterisk@10.10.10.10>;tag=as3352c042
To: <sip:1101@120.0.0.188:5060>;tag=000f230009a67a6605b8928e-1296d1b6
Call-ID: 1aed267476f9b6501a2b05d929fb1c97@10.10.10.10
Date: Thu, 02 Jun 2005 13:57:22 GMT
CSeq: 102 OPTIONS
Server: CSCO/7
Content-Type: application/sdp
Content-Length: 243
Allow: OPTIONS,INVITE,BYE,CANCEL,REGISTER,ACK,N
OTIFY,REFER
v=0
o=Cisco-SIPUA (null) (null) IN IP4 120.0.0.188
s=SIP Call
c=IN IP4 120.0.0.188
t=0 0
m=audio 1 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
--
Jared Mauch | pgp key available via finger from jared@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
| |
| Vladimir Litovka \(vlitovka\) 2005-06-10, 5:45 pm |
|
> Knowing that there were no lost packets in my media is far more
> important than the signaling overhead. In most cases the signaling
> doesn't need to be immediate (eg: 60ms vs 600ms) doesn't matter.
My customer is going to build a kind of cutted network, when voice payload goes through PSTN, but signaling - over IP, through centralized SPS. It isn't good idea, but I think they know, what they are doing. In this case all bandwidth will be dedicated to
signaling.
> If you're trying to get an idea, i'd look at the options
> messages which are frequently used as keepalives during NAT
> operations.
An idea is simple. If don't look at relatively rarely used requests (REGISTER, CANCEL, SUBSCRIBE/NOTIFY, etc), which don't make weather on link (this is as I think :-) ), then there are few another commands, which is in frequent use: INVITE, ACK, BYE, PRA
CK, INFO (?), UPDATE and responces (200 OK, etc), which, as I think, give average size from 400 to 600 bytes not counting ip/udp overhead. Lets think about 500 bytes per message
So, in the simpliest case
1) INVITE / 200 OK - 2 times (to central SPS and backward)
2) ACK
3) BYE / 200 OK
4) INFO (to SPS about session finish)
where 2nd and 3rd steps don't use WAN link.
which supposed to be 1000 bytes (1st step) + 500 bytes (4th step). For 5cps this gives required bandwidth 60Kbps. More complex cooperation between users will give much more bandwidth requiremens... Not bad :-)
I feel, that I've missed somewhere. Any comments?
/doka
|
|
|
|
|