Ad-Hoc conferences with Cisco Telepresence

Recently I’ve been troubleshooting an issue with ad-hoc videoconferences in Cisco Telepresence.
Cisco Telepresence as described in this document http://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/conductor/config_guide/xc3-0_docs/TelePresence-Conductor-Unified-CM-Deployment-Guide-XC3-0.pdf
is an infrastructure for creating ad-hoc, rendezvous and scheduled tightly coupled (that is controlled by a central call processing engine/mixer entity) conferences (opposed to loosely coupled conferences using built-in bridges).
Configuration of this system introduces a second B2B user agent – TelePresence Conductor (the first one is CallManager). Moreover, apart from communicating via SIP CallManager (CM), Conductor (TC) and Telepresence Servers (TS) (audio/video mixers themselves) communicate via XML RCP and exchange system parameters and Conference URIs.

In my setup ad-hoc conferences were shutting down in a couple of seconds after starting. So I decided to investigate how they are formed.
According to RFC 4579, when there is an active call between endpoint A and endpoint B and A wants to transfer this call into conference with endpoint C the following occur
1) While on call with B, A sends SIP INVITE to the focus (a conference mixer) with unique conference URIs
2) Focus replies with 200 OK and isfocus suffix in Contact field
3) Then after exchanging some information regarding the conference by SUBSCRIBE/NOTIFY (usually SUBSCRIBE package allows the exchange of conference names and connected parties in a form of XML) A sends SIP REFER to the focus and asks it to Refer-to B and replace B‘s calls with the new one
4) The focus replies with 202 Accepted and 100 Trying and send INVITE to B with Conference URI and asks to replace its current call with the new one.

5) The same steps are repeated for a call from A to С, thus inviting endpoint C to the same ad-hoc conference

Another way to do extend a call of A is to instruct the focus to send INVITE to B from a conference which is already started by A. This procedure can be repeated to extent this ad-hoc conference to C.

The implementation by Cisco looks like this
1) A is on a call with B. A in my case is a Cisco Jabber for Windows.
2) A wants to add a concurrent call to C to an ad-hoc conference (for A,B and C to be in one conference room)
3) A sends REFER to CM with Content-Type application/x-cisco-remotecc-request+xml which states that conference softkey was pressed and transmit A-B and A-C call IDs.
4) CM make a XML RPC (remote procedure call) to TC for a conrefence.create function and gets Conference URI.
5) CM sends in-dialog INVITE to B with delayed-offer SDP connection info 0.0.0.0 thus putting this endpoint on hold.
6) CM sends UPDATE to B with Contact parameter isfocus
7) CM sends INVITE to TC with conference URI it got from XML RPC. TC chooses available TS and relays INVITE to it. When it gets the responce from TS, TC relays it to CM
8) CM sends in-dialog INVITE to B with delayed-offer SDP connection info of TS IP thus connecting B to the mixer.
9) Asyncronously CM send INFO to B with XML which lists all connected parties with their respective Caller IDs
10) Steps from 6 to 9 are repeated for C at the same time.
11) TS periodically re-INVITES endpoint A,B,C with updated SDP if needed.

So Cisco Telepresence uses its own API to get conference URI and relies on the package application/x-cisco-remotecc-request+xml for signalling of conference start.
The issue with shutting down of ad-hoc after 10s was caused by software bug in TC, which terminated session in step 7 when KPML as a method of sending DTMF was signalled to it by CM instead of RFC2833.

PS. I’ve found a wonderful blog https://andrewjprokop.wordpress.com/ with a lot of posts describing SIP building blocks.