Avaya 555-245-600 사용자 설명서
Traffic engineering
214 Avaya Application Solutions IP Telephony Deployment Guide
usual. Direct media shuffling between SIP stations and IP trunks is not supported. Therefore,
SIP calling between Communication Manager systems connected by IP TIE trunks always
require allocation of VoIP media resources.
SIP calling between Communication Manager systems connected by IP TIE trunks always
require allocation of VoIP media resources.
C-LAN allocation and SIP trunks
The Communication Manager server communicates to the SES server over administered SIP
trunks, which are finite software entities similar to H.323 IP TIE trunks. Communication
Manager organizes SIP trunks into trunk groups just like other trunks of any type. Each SIP
trunk group signals through a C-LAN or PC-LAN socket as a single signaling group. A SIP trunk
group may contain up to 255 trunk members.
Each leg of a SIP call in progress takes up one SIP trunk member for the duration of the call.
Thus, a SIP-SIP call takes up two trunk members, although those trunk members
corresponding to the two SIP endpoints need not be in the same trunk group, C-LAN, or SES.
Provisioning SIP trunks is then a process similar to provisioning IP and PSTN trunks, a matter
of accounting for traffic load and application of the standard Erlang calculations outlined in
previous sections. Calls routing to (terminating at) SIP endpoints can go through any C-LANs
with SIP trunks administered to the endpoint’s home SES. But calls originated by a SIP
endpoint can only route to a specific C-LAN according to the administered routing table in the
home SES; if all trunk members on that C-LAN are in use, the SIP endpoint-originated call is
blocked. Therefore, the prudent but somewhat conservative way to allocate SIP trunks is to
treat each C-LAN as a distinct trunk resource for both SIP endpoint-originated and
endpoint-terminated calls. In other words, allocate enough trunk members on each C-LAN to
achieve the desired grade of service within each C-LAN, not treating all trunk members in all
C-LANs as a pool.
Systems that use C-LANs to provide the signaling sockets for SIP trunks require additional
traffic engineering. Each C-LAN and IPSI circuit pack has finite processing capacity, which
translates into a finite message handling throughput. Each SIP call, just like an H.323 or an
H.248 call, involves some amount of upstream (endpoint to server) and downstream (server to
endpoint) message traffic through intermediate components like C-LAN and IPSI. Therefore,
finite message throughput for IPSI and C-LAN means finite call volume signaled through those
components. Being a text based protocol, SIP signaling involves much larger messages
compared to binary protocols. Generally, each C-LAN can handle signaling for 4000 to 10,000
SIP calls per hour (a call between two SIP phones signaled through the same C-LAN counts as
two calls), depending on the complexity of the call. IPSI has 3 to 4 times the signaling
throughput capacity of C-LAN.
trunks, which are finite software entities similar to H.323 IP TIE trunks. Communication
Manager organizes SIP trunks into trunk groups just like other trunks of any type. Each SIP
trunk group signals through a C-LAN or PC-LAN socket as a single signaling group. A SIP trunk
group may contain up to 255 trunk members.
Each leg of a SIP call in progress takes up one SIP trunk member for the duration of the call.
Thus, a SIP-SIP call takes up two trunk members, although those trunk members
corresponding to the two SIP endpoints need not be in the same trunk group, C-LAN, or SES.
Provisioning SIP trunks is then a process similar to provisioning IP and PSTN trunks, a matter
of accounting for traffic load and application of the standard Erlang calculations outlined in
previous sections. Calls routing to (terminating at) SIP endpoints can go through any C-LANs
with SIP trunks administered to the endpoint’s home SES. But calls originated by a SIP
endpoint can only route to a specific C-LAN according to the administered routing table in the
home SES; if all trunk members on that C-LAN are in use, the SIP endpoint-originated call is
blocked. Therefore, the prudent but somewhat conservative way to allocate SIP trunks is to
treat each C-LAN as a distinct trunk resource for both SIP endpoint-originated and
endpoint-terminated calls. In other words, allocate enough trunk members on each C-LAN to
achieve the desired grade of service within each C-LAN, not treating all trunk members in all
C-LANs as a pool.
Systems that use C-LANs to provide the signaling sockets for SIP trunks require additional
traffic engineering. Each C-LAN and IPSI circuit pack has finite processing capacity, which
translates into a finite message handling throughput. Each SIP call, just like an H.323 or an
H.248 call, involves some amount of upstream (endpoint to server) and downstream (server to
endpoint) message traffic through intermediate components like C-LAN and IPSI. Therefore,
finite message throughput for IPSI and C-LAN means finite call volume signaled through those
components. Being a text based protocol, SIP signaling involves much larger messages
compared to binary protocols. Generally, each C-LAN can handle signaling for 4000 to 10,000
SIP calls per hour (a call between two SIP phones signaled through the same C-LAN counts as
two calls), depending on the complexity of the call. IPSI has 3 to 4 times the signaling
throughput capacity of C-LAN.
Combining both traffic considerations of trunk member allocation and signaling throughput,
C-LAN provisioning is thus an iterative process:
C-LAN provisioning is thus an iterative process:
1. Allocate an initial guessed number of C-LANs.
Quick rule: 1000 to 4000 users per C-LAN, depending on assumed complexity of each SIP
call (more complex implies fewer users per C-LAN).
call (more complex implies fewer users per C-LAN).
2. Assign SIP endpoints to C-LANs.
Can uniformly distribute or allocate according to user community, if such information exists.