1. ACLI Configuration Guide
  2. SIP Signaling Services
  3. Early Media Support
  4. Early Media Support for Multiple Early Dialog Scenarios
  5. Merge Function within Early Dialog Support

Merge Function within Early Dialog Support

Dialog merge functionality allows the ESBC to manage media, handle potential transcoding change requirements, and accommodate complex PRACK and UPDATE scenarios for merged (single caller, multiple callee) call flows. You configure this support in conjunction with other configuration depending on your deployment. This merge requires that any forking proxy send only one final response to the ESBC, either a 200 OK or an error response. You configure the merge-early-dialogs parameter on the caller realm to support the merging of multiple early dialogs into a single dialog.

The ESBC aggregates all early dialogs on the calling party side using the same early dialog, identified via the presence of the same To-Tag identifier, consistent CSeq, RSeq, SDP session and so forth. If there are provisional responses containing SDP, the associated provisional responses towards the ingress leg contain the same unique SDP, as created by the ESBC.

The final response sent by the ESBC also belongs to the same dialog (same To-Tag identifier). If a former provisional response sent contained SDP, the final response contains the exact same SDP. If PRACK is activated for this dialog, however, the response would not contain SDP.

There is no need to drop messages coming from the calling party side, although the first early dialog received from the calling side determines the codec used for the call. The ESBC also performs transcoding and PRACK interworking on a per call leg basis. Furthermore, the ESBC does not increment the SDP version on the merged leg unless there is a renegotiation on that leg.

Operational behavior of this merging includes:

  • The ESBC maintains consistency of RTP parameters regardless of whether or not there is transcoding. These parameters include Seq Number, Timestamp, SSRC and so forth. This support includes on-the-fly transcoding setup as new early dialogs are received.
  • There is only one dialog on the caller side even if there are multiple early dialogs on the called side.
  • The ESBC forwards every provisional message received to the caller with a single to-tag.
  • The ESBC sends an ACK for 200OK/INVITE to the correct dialog, which is the dialog with the to-tag in the 200OK/INVITE message.
  • The ESBC sends a BYE message to the correct dialog, which is the dialog with the to-tag in the 200OK/INVITE message.
  • The ESBC maintains the same SDP Version Number in all messages to the caller.

Consider the following configuration rules:

  • You should configure HMU to maintain RTP consistency.
  • When enabled, dialog-transparency disables this merging.
  • You should configure transcoding resources and at least one codec policy on the ingress and/or egress side. This could be as simple as a codec policy configured to allow all.

This merge function does not support:

  • Offerless call
  • Preconditions interworking
  • SRVCC
  • multiple audio or video m-line
  • p-early-media-header with 'add' and 'modify' options

The call flow below presents an example of the ESBC supporting a merge scenario with an UPDATE message received from the calling party. The ESBC hairpins a 200OK in response to the UPDATEs locally towards the merged (single) dialog side.

This call flow depicts a multi-dialog merge operation performed by the OCSBC.

The call flow below presents an example of the ESBC supporting a merge scenario with an UPDATE message received from the called party. The ESBC forwards the UPDATEs and associated 200OKs maintaining the same To-Tag for the calling platform.

This call flow depicts a multi-dialog merge operation performed by the OCSBC.