Parameter: Use RTP no-anchoring
| Line 1: | Line 1: | ||
| − | + | ===What is "RTP no-anchoring?"=== | |
| + | RTP no-anchoring is a variant of low-delay media relay where the RTP packets are not "anchored" to the SBC (not going through the SBC). | ||
| − | RTP | + | Instead the RTP path is established directly between the two legs of a call (which send RTP to each other). |
| − | + | ||
| − | + | This greatly reduces the IP bandwidth required by the SBC, while the SBC continues to be involved in SIP signaling and call routing. | |
| − | + | ===When should "RTP no-anchoring" be enabled?=== | |
| + | Make sure to enable this option only on profiles used for calls that can reach each other directly, otherwise RTP packets will be lost and users won't hear each other. | ||
| + | For example, it may not work if call legs are behind NATs, or if call legs are on separate networks. | ||
| + | |||
| + | We recommend to configure "no-anchoring" per [[Tmedia_Routing|route]] (each route may override the NAP's default [[Toolpack:Modify_Profile_Sbc_A|profile]]). Profiles with "RTP no-anchoring" enabled should only be used on routes that are known to bridge call legs that can directly send RTP to each other. | ||
| + | |||
| + | ===When will "RTP no-anchoring" be actually used?=== | ||
| + | Enabling this option on a profile does not mean all calls using this profile will use "no-anchoring" mode. | ||
| + | |||
| + | In fact, RTP no-anchoring mode is possible if both call legs of a call have the "RTP no-anchoring" option enabled in their assigned [[Toolpack:Modify_Profile_Sbc_A|profile]]. If one of the call legs does not have this option, standard "low-delay" mode will be used (RTP will go through the SBC). | ||
| + | |||
| + | ===Synonyms of "RTP no-anchoring" | ||
| + | "RTP no-anchoring" is also sometimes called "Media no-anchoring", "Media pass-around" or "media bypass". | ||
[[Category: Parameters]] | [[Category: Parameters]] | ||
Revision as of 11:29, 19 January 2018
What is "RTP no-anchoring?"
RTP no-anchoring is a variant of low-delay media relay where the RTP packets are not "anchored" to the SBC (not going through the SBC).
Instead the RTP path is established directly between the two legs of a call (which send RTP to each other).
This greatly reduces the IP bandwidth required by the SBC, while the SBC continues to be involved in SIP signaling and call routing.
When should "RTP no-anchoring" be enabled?
Make sure to enable this option only on profiles used for calls that can reach each other directly, otherwise RTP packets will be lost and users won't hear each other. For example, it may not work if call legs are behind NATs, or if call legs are on separate networks.
We recommend to configure "no-anchoring" per route (each route may override the NAP's default profile). Profiles with "RTP no-anchoring" enabled should only be used on routes that are known to bridge call legs that can directly send RTP to each other.
When will "RTP no-anchoring" be actually used?
Enabling this option on a profile does not mean all calls using this profile will use "no-anchoring" mode.
In fact, RTP no-anchoring mode is possible if both call legs of a call have the "RTP no-anchoring" option enabled in their assigned profile. If one of the call legs does not have this option, standard "low-delay" mode will be used (RTP will go through the SBC).
===Synonyms of "RTP no-anchoring" "RTP no-anchoring" is also sometimes called "Media no-anchoring", "Media pass-around" or "media bypass".
