Version 6.4 361 March 2012
SIP User's Manual 18. GW and IP to IP
UPDATE: terminated at each leg independently and may cause only changes in the
RTP flow - Hold\Retrieve are the only exceptions that traverse the two legs.
ReINVITE: terminated at each leg independently and may cause only changes in the
RTP flow - Hold\Retrieve are the only exceptions that traverse the two legs.
PRACK: terminated at each leg independently.
REFER (within a dialog): terminated at each leg independently.
3xx Responses: terminated at each leg independently.
401\407 Responses to initial INVITE: in case the B2B session is associated with an
Account, the responses is terminated at the receiving leg; in other cases, the
responses are passed transparently.
REGISTER: handled only in cases associated with a USER IP Group -
Contact\To\From specific parameters are omitted.
18.9.1 Theory of Operation
The device's IP-to-IP SIP session is performed by implementing Back-to-Back User Agent
(B2BUA). The device acts as a user agent for both ends (legs) of the SIP call (from call
establishment to termination). The session negotiation is performed independently for each
call leg, using global parameters such as coders or using IP Profiles associated with each
call leg to assign different configuration behaviors for these two IP-to-IP call legs.
If transcoding is required, the RTP streams for IP-to-IP calls traverse through the device
and two DSP channels are allocated per IP-to-IP session. Therefore, the maximum number
of media channels that can be designated for IP-to-IP call routing is 120 (corresponding to
60 IP-to-IP sessions). If transcoding is not needed, the device supports up to 150 IP-to-IP
SIP sessions (without using DSP channels).
RTP-to-SRTP interworking requires one DSP channel. Therefore, the device supports up
to 120 RTP-to-SRTP SIP sessions (same number as RTP-to-RTP SIP sessions).
The device also supports NAT traversal for SIP clients behind NAT, where the device is
defined with a global IP address.
The figure below provides a simplified illustration of the device's handling of IP-to-IP call
routing:
Figure 18-44: Basic Schema of the Device's IP-to-IP Call Handling
The basic IP-to-IP call handling process can be summarized as follows:
1. Incoming IP calls are identified as belonging to a specific logical entity in the network
(referred to as a Source IP Group), according to Inbound IP Routing rules.
2. The Source IP Group is associated with a specific IP Group (Destination IP Group),
and then sent to the appropriate destination address (defined by a Proxy Set)
associated with this Destination IP Group.
To Next Page
Loading...
