You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
Version 1
Next »
In one downstream forking scenario where RTP streams are generated by multiple early dialogs and SBC needs to cut through only one stream, the Downstream Forking employs “Early Dialog Media Selection Profile” to control SBC behavior. Support is based on the PEM value of the 18x or UPDATE or the first/last provisional response.
The following options are available:
- Receipt of RTP (Deferred)—The first/last RTP stream is cut-thru. A flag controls whether Local Ringback Tone generated by SBC counts as RTP stream for an early dialog. RTP Server Profile is also distinguishes between allowed/disallowed streams. Disallowed streams will not qualify for the decision process.
- Receipt of Provisional Response—RTP stream for the first/last sender of a provisional response is cut-thru. RTP Server Profile distinguishes between allowed/disallowed streams. Disallowed streams will not qualify for the decision process.
- Use P-Early-Media Header—P-Early-Media header value is used for selection the RTP streams according to the following rules:
- The last sent P-Early-Media value for each early dialog is used for comparison purposes.
- The precedence order of the values will, from highest to lowest, “sendrecv”, “sendonly”, “recvonly” and “inactive”.
- If two early dialogs have the same P-Early-Media value, media for the early dialog which last sent a reply with P-Early-Media header will cut through.
- A P-Early-Media value update on the early dialog with the currently active RTP stream will not trigger a new comparison but will impact the media cut-through behavior.
When using P-Early-Media for cut-through, do not enable P-Early-Media header transparency.
Frequent changes to RTP cut-through is not desirable, thus multiple early-dialogs capability is best suited in environments where it is known that all early dialogs use the same codec or the number of early dialogs is limited.