Avaya 555-245-600 IP Phone User Manual


 
Resource sizing
Issue 6 January 2008 215
3. Allocate enough trunk members to each C-LAN to achieve desired grade of service, based
on the known or assumed call traffic.
4. Check SIP message throughput based on the call traffic.
5. If SIP message traffic exceeds desirable threshold for any C-LAN, either add more C-LANs
or re-distribute users, if excess capacity exists in any C-LAN.
Return to Step 2. Otherwise, continue to Step 6.
6. Assign C-LANs to port networks and IPSIs.
Estimate IPSI loading; add more PN and IPSI, if necessary.
SIP specific features
SIP deals with much more than just traditional voice communication. Any traffic analysis must
incorporate considerations of the following essential SIP features:
Registration
When large numbers of endpoints start up nearly simultaneously, the system must handle the
resulting flood of registration traffic in a robust and timely manner. The requirements and issues
are similar to the case for H.323 endpoints, except that SIP deals with two servers: SES and the
Communication Manager server.
Subscription and notification
Endpoint subscriptions to events, such as presence, features, message indicator, and bridges,
can potentially generate a large signaling load from the resulting notification message traffic.
Consider that, if each SIP user has average of "S" subscriptions (other users) subscribing to its
presence, then "U" users averaging "P" presence changes (off-hook, on-hook, unavailable, etc.)
per hour generates "S x U x P" notifications per hour.
Instant messaging
The Avaya SIP SoftPhone supports instant messaging (IM) over SIP. Experience and data on
average usage patterns for IM (average session time, message size, frequency, etc.) is
currently somewhat sparse. This could be a minor part of SIP traffic, at least for near future
deployments. But judging by the proliferation and popularity of IM among the consumer public,
its future potential cannot be discounted.
These are just some of the SIP features not considered in the traditional call traffic models.
Given that SIP is a constantly evolving and expanding standard, more non-call related SIP
traffic can be expected in the future. Some traffic, such as registration and subscription/
notification, involve both the SES and Communication Manager servers, and thus affect load on
such message bearing components as C-LAN and IPSI. Others, such as IM, will only affect
SES. Therefore, a SIP traffic model must account for the various types of traffic, their respective
flow patterns, and resulting loads on components.