Re: Help in understanding why concurrent video calls limit in my system is 80

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



hi Scott

thanks for the input.

I actually had
A: Radvision  viaIp 400 20 ports (19 used),
B, C: 2 radvision Scopia 24 ports (22 ports each used),
D: 1 Radvision Scopia 12 ports (7 used),
E: 1 Tandberg 16 ports (10 used).

All of the mcus are registered on the same Gk, and only the first
three are on the same LAN (same as the gatekeeper).

Calls were 256kbps/384kbps, all mcus transcoding except for A fixed
@384 4CIF (it's oooold). Others mcus does not have problems going full
capacity when transcoding. So max call rate should be roughly
32000kbps among 5 mcus, and it was surely less cos half participants
joined @ 256.

Clients (all Aethra hardware codecs) are all registered on the same
GnuGk which showed the limit. There is another GnuGk, neighboured to
the first one, which manages 4 Spranto softphones which also were
joining the conference.

Cascading was done D -> B <- A -> C <- E resulting in a big 4cif voice
switched videoconference (-> indicates who calls who).

So i guess it not bandwidth related (except I'm doing my math wrong),
amd not port related too.

Thanks for any idea you can come up with.

p.


On Thursday, April 14, 2011, Scott Hipsak  wrote:
> If you are using Codian Bridges they have a limit of 80 participants per blade.  It is my understanding that this should only affect a single blade at a time and not carry over to other blades or MCU's.  I do not believe it should affect cascaded conferences, but since you ran into a hard limit of 80 it is possible it may be the issue.
>
> I put this out there just as an thought.  Maybe someone from Tandberg can clarify.  As for GnuGK, the only thing I think might affect the calls is bandwidth limitation.  Typically the bandwidth is set to 100,000 kbps so some endpoints would have to request more than 1024 per call. What was the bandwidth of the calls to the bridges?
>
> Scotth
>
> -----Original Message-----
> From: pierlu [mailto:pierlu@xxxxxxxxx]
> Sent: Thursday, April 14, 2011 10:48 AM
> To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
> Subject:  Help in understanding why concurrent video calls limit in my system is 80
>
> Hi,
>
> today I run in a limit I was not prepared to encounter.
>
> I was managing a large videoconference and I could not go past 80
> concurrent calls. I understood that because I had one set top box who
> could not join the conference: I tried everything that I could to make
> it so but it succeeded only when I had the idea of disconnecting my
> own client, the one I use for monitoring. Once the set top box was
> able to join the conference, it was the turn for my endpoint to be
> unable to join the conference.
> The error I received back was "Error Q.931" and on the status port it
> was listed that the call was normally dropped.
>
> I cannot read the log file to give more precise insight about the
> problem cos it's 446Megs (I guess it's becouse I had some issues with
> an ISDN gateway which resulted in massive output to the status port
> and so to the log file) and any software I normally use to view log
> files refuse to open it due to memory limits.
>
> May it be something related to GnuGk configuration? As far as I can
> tell, it's set so that only signalling is routed thru the GnuGk (to be
> able to disconnect calls between endpoints via telnet), so I don't
> think it's bandwidth related (moreover cos there were 5 mcus cascaded
> in the conference so that connections were balanced among them and I
> had troubles with connecting to any of the 5 mcus once concurrent
> calls reached the 80 limit).
>
> Do you have any suggestion of what I may look into to go past this
> limit? I can reproduce this situation only during a real meeting, it's
> impossible to arrange a test with more than 80 clients, so I need to
> have an idea of what this problem may be before allowing again a
> conference with more than 80 clients.
>
> I'm using GnuGk 2.3.3 (it works well and I try to stick to the "if it
> ain't broke don't fix it" rule).
>
> The relevant sections of the ini file are listed below. I have to
> mention that I am no expert in h.323 so I have taken the routed
> directives from the examples found in the online manual.
>
> Thanks for any help.
>
> Cheers, pierlu
>
> ----------------------------------------------------------------------------------------------------------
>
> [Gatekeeper::Main]
> FortyTwo=42
> Name=GnuGk
> Home=10.1.12.43
> Bind=10.1.12.43
> TimeToLive=600
> StatusTraceLevel=2
> TraceLevel=5
>
> [RoutedMode]
> ; enable gatekeeper signaling routed mode, route H.245 channel only if
> neccessary (for NATed endpoints)
> GKRouted=1
> H245Routed=1
> AcceptNeighborsCalls=1
> AcceptUnregisteredCalls=1
> CallSignalPort=1720
>
> ; proxy calls only for NATed endpoints
> [Proxy]
> Enable=0
> ; if port forwarding is correctly configured for each endpoint, you
> can disable ProxyForNAT
> ProxyForNAT=1
> ProxyForSameNAT=0
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________________
>
> Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
> Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
> Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
> Homepage: http://www.gnugk.org/
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________________
>
> Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
> Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
> Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
> Homepage: http://www.gnugk.org/
>

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________________

Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/



[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux