Back-to-Back User Agent Architecture
The architectural framework behind the back-to-back user agent feature is based on interactions between the Microsoft Unified Communications Managed API (UCMA) Call and MediaProvider abstract classes. Both call legs are associated with the same BackToBackMediaProvider instance.
Note
The BackToBackMediaProvider class is internal.
Signaling layer messages are exchanged at the Call level, while Session Description Protocol (SDP) exchange is carried out at the MediaProvider level. The BackToBackCall class provides the necessary infrastructure to combine Session Initiation Protocol (SIP) and SDP exchange.
Signaling-related messages are sent back-to-back between the Call objects. SDP offer/answer messages are sent back-to-back using media provider methods.
When messages are sent back-to-back across Calls, signaling headers that are configured using SetPassThroughHeaderNames are copied from one call leg to the others.
Header Passing Across Call Leg
A back-to-back user agent is not a proxy. RFC-3725 (Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)) does not define how signaling headers should be passed across the two call legs associated with a back-to-back user agent.
Note
RFC-3725 applies primarily to call-establish time.
The header fields shown in the following list are not passed through from one call leg to the other (independent of the previously listed points).
Call-ID
Contact
Content-Type
CSeq
From
History-Info
Max-Forwards
Ms-Conversation-ID
P-Asserted-Identity
P-Preferred-Identity
Record-Route
Refer-To
Referred-By
Replaces
RSeq
Target-Class
To
Via
Allow and Supported header fields are parsed for header values that are added by the platform’s signaling layer. Any such header values are reused on the outbound transaction.
Message Exchange on a BackToBackCall
A BackToBackCall instance performs back-to-back message transmission as follows.
Note
The UCMA 3.0 implementation does not permit an application to control individual message exchange behavior on an Incoming-Idle call (that is, when the State property on the first call leg is Incoming, and the same property on the second call leg is Idle). For more information, see CallState.
Pass-through headers (except the restricted headers listed in the previous section) received on an incoming call are sent to the outgoing call.
SDP MIME parts received in an offer on an incoming INVITE message appear in the Offer header on the outgoing call. Custom MIME parts must be set by the application in Accept options.
Non-reliable provisional responses received on an outgoing call are sent to the caller intact. No content body on non-reliable provisional responses is expected.
All reliable provisional responses (response code 183) that create early dialogs are returned to the incoming call with modified To tags, indicating a separate fork. SDP Answer responses received on 183 responses are passed unchanged. No other MIME parts are expected on 183 responses.
All messages received and responses to messages on one call leg are pushed to the other call leg unchanged with all pass-through headers (excluding restricted headers) and body.
Call Leg State and BackToBackCall.State
The value of the State property on a [BackToBackCall] instance is calculated from the State on each call leg. The following table summarizes the relationships of these properties.
Call leg 1 state |
Call leg 2 state |
BackToBackCall State |
|---|---|---|
Idle |
Idle |
Idle |
Incoming |
Idle |
Idle |
Incoming |
Establishing |
Establishing |
Establishing |
Establishing |
Establishing |
Established |
Establishing |
Establishing |
Establishing |
Established |
Establishing |
Established |
Established |
Established |
Established |
Terminating |
Terminating |
Terminating |
Terminating |
Terminating |
Terminated |
Terminating |
Terminating |
Terminating |
Terminated |
Terminating |
Terminated |
Terminated |
Terminated |