Version 6.2 497 February 2011
SIP User's Manual 8. IP Telephony Capabilities
standard)
INVITE without SDP, offer in 180, and answer in PRACK
PRACK and UPDATE transactions can also be used for initiating subsequent
offer\answer transactions before the INVITE 200 OK response.
In a SIP dialog life time, media characteristics after originally determined by the first
offer\answer transaction can be changed by using subsequent offer\answer
transactions. These transactions may be carried either in UPDATE or ReINVITE SIP
transactions. The media handling is similar to the original offer/answer handling. If the
offer is rejected by the remote party, then no media changes occur (e.g. INVITE
without SDP, then 200 OK and ACK, offer\answer within an offer/answer, and Hold
ReINVITE with IP address of 0.0.0.0 - IP address is unchanged).
8.4.5.3 No Media Anchoring
The No Media Anchoring feature enables the use of SBC signaling capabilities without
handling the RTP/SRTP (media) flow between remote SIP user agents (UA). The RTP
packet flow does not traverse the device, instead, the two SIP UA's establish a direct
RTP/SRTP flow between one another. Signaling continues to traverse the device with
minimal intermediation and involvement to enable certain SBC abilities such as routing.
In contrast to the regular SBC implementation, the No Media Anchoring feature:
Does not perform any manipulation on SDP data (offer/answer transaction) such as
ports, IP address, coders.
Opening voice channels and allocation of IP media ports are not required.
The No Media Anchoring feature is typically implemented in the following scenarios:
SBC device is located within the LAN.
Calls between two SIP UA's in the same network (LAN) and signals are sent to a SIP
proxy server that is located in the WAN (as illustrated in the figure below).
Figure 8-56: SBC SIP Signaling without RTP Media Flow
The benefits of implementing the No Media Anchoring feature include the following:
Saves network bandwidth
Reduces CPU usage (no RTP/SRTP handling)
Avoids interference in SDP negotiation and header manipulation on RTP/SRTP
To Next Page
Loading...
