Skip to main content
Twilio models a conference as a Conference resource (CF… SID) with a nested Participant collection keyed by each leg’s CallSid. Vobiz models the same thing as a named room: every call that runs <Conference>RoomName</Conference> joins the room RoomName, and you control the room and its members by that name - so there is no separate SID to track. This page maps every Twilio conference call onto its Vobiz equivalent, in Python and Node.
Set your credentials once: AUTH_ID is your Vobiz Auth ID (MA_…), AUTH_TOKEN is your Auth Token. In the Vobiz SDK, api_key is the Auth ID, and every account-scoped method takes that auth_id explicitly. Members are addressed by conference_name + member_id.

Twilio → Vobiz mapping

Join a call to a conference

In Twilio you either dial into a room with <Dial><Conference> from an inbound call, or you push a new leg in with participants.create. In Vobiz the room name is the join key: return <Conference>RoomName</Conference> from an inbound call’s answer URL, and originate outbound legs with make_call pointing at an answer URL that returns the same room.
The answer URL returns the room in XML. TwiML nests <Conference> inside <Dial>; VobizXML uses <Conference> directly, with the room name as the element text.

Control members: mute, hold, kick

Twilio addresses a participant by its leg CallSid and mutates it with participants(sid).update(...). Vobiz gives each control its own verb, addressed by conference_name + member_id - you get the member IDs from get_conference.
For a whisper/coach flow, pair deaf_member/undeaf_member (control who a member hears) with mute_member/unmute_member (control who hears them) - the same effect Twilio’s coaching + muted combination produces, expressed as two explicit, composable verbs.

List, inspect, and end rooms

Record a conference

Twilio records via the record attribute (record-from-start) plus recordingStatusCallback. Vobiz records the whole room either declaratively (record="true" on <Conference>) or imperatively, starting and stopping on demand by room name.
The recording URL is delivered to your callbackUrl on the conference end event (and to callback_url on the recording API) - see Conference callbacks.

Key differences

  • Room name, not SID. Twilio tracks a Conference by its CF… SID and each participant by leg CallSid. Vobiz uses the human-readable room name plus a member_id for every operation, so you never fetch a SID before acting - the name you put in <Conference> is the same name you pass to every control method.
  • One call returns the whole room. get_conference returns the room’s details and its member list together, where Twilio’s fetch() and participants.list() are separate requests.
  • Ending rooms is explicit. Vobiz gives you delete_conference for one room and delete_all_conferences for every active room, versus Twilio’s update(status='completed') per SID.
  • One verb per control. Mute, hold, deaf, announce, kick, and hangup are each their own method (mute_member, play_audio_member, deaf_member, kick_member, hangup_member), so intent is explicit and composable rather than a bundle of flags on one participant.update().
  • Hold is “play to one member.” play_audio_member streams hold music to a single participant and stop_audio_member returns them to the room - the same outcome as Twilio’s hold/hold_url, expressed as an audio action you fully control.
  • On-demand recording. start_conference_recording/stop_conference_recording let you record any portion of an active room by name, in addition to the declarative record="true" attribute.
  • Same TwiML-shaped XML. VobizXML keeps startConferenceOnEnter, endConferenceOnExit, muted, beep, and maxParticipants under the same names - most <Conference> blocks port with only a waitUrlwaitSound and statusCallbackcallbackUrl rename.

See also