# Buddy

Certain members of a conference are buddies or colleagues with each other. Each member or leg has a list of other members with whom they are buddies.

When none of the buddies are muted, they are normal participating members of the conference. They are selected for the conference mix just like the other members, and each hears the conference just like the other members.

However, when one of the buddies is muted from the conference (using the mute=buddies parameter of the buddies command), he is now coaching his buddies; that is, his audio is not being fed to the conference, but is being mixed with the audio sent to each of his buddies. So his buddies hear the conference mix, plus the muted (from the conference's point of view) buddy.

If multiple buddies are muted, they are all coaching the other buddies and each other. Each buddy hears the conference mix, plus the muted buddies. The muted buddies are not mixed into the conference.

If all buddies are muted, they are in a sidebar conference with each other. Each buddy hears the conference mix, plus all the other buddies. They can talk amongst themselves. Once one buddy un-mutes, the others are can still chat amongst themselves, and the un-muted member will still hear them. This becomes a multiple coach scenario.

Buddies are automatically reciprocal. If leg A is a buddy of leg B, then leg B is a buddy of leg A.

To implement this, each member has a buddy list. When it comes time to send the conference mix to that member, the audio from his muted buddies is added to the mix. So each member with at least one muted buddy gets a personalized audio mix. While there is no limit on the number of buddies a member may have, above a given number the mixer may have to order and select appropriate buddy talkers, rather than just mixing them all.

The buddy concept can implement coach/whisper and sidebar conferencing with very simple logic. To move from a sidebar and back is just un-muting. To switch roles from coach to member is just un-muting. To switch roles from coach to pupil is just mute the pupil, and un-mute the coach.

The buddy concept allows for multiple sidebars per conference, multiple coaches per conference, multiple coaches per pupil, and multiple pupils per coach. It also allows for sidebars of sidebars.

## XML Definition

<buddy identifier="<identifier>" appid="<appid>"
href=http://server/dialogicwebservice/mediacontrol/buddies/<identifier>
streamidentifier="<stream identifier>"
conferenceidentifier="<conference identifier>">
<mediastream identifier="<identifier>" action="<action>"/>
</buddy>

## Buddy Properties

Name | Description | Type | Input / Output | Optional / Mandatory
identifier | Unique identifier assigned to the specific instance of the resource. This identifier is used by the web service client when performing actions on the resource. | String | Output | N/A
appid | Unique application id included in the original HTTP POST creation process that is utilized by the web service such that clients only have access to resources that they created. | String | Output | N/A
href | An HTTP reference to the specific resource. | String | Output | N/A
streamidentifier | Unique identifier of the MediaStream that is to set the buddy list and is a participant of a conference. | String | Input / Output | Mandatory
conferenceidentifier | Unique identifier of the Conference. | String | Input / Output | Mandatory
mediastream identifier | Unique identifier of a MediaStream in the buddy list; it belongs to the conference. | String | Input / Output | Mandatory
mediastream action | Action to perform. Values: add, remove. Default: add | String | Input / Output | Optional

## Interaction Diagram

### Buddy Creation

The following diagram illustrates the Buddy creation process.

### Buddy Update

The following diagram illustrates the Buddy update process.

### Buddy Deletion

The following diagram illustrates the Buddy deletion process.

## Java Sample Code

public void CreateBuddy() {
logger.info("Buddy:: CreateBuddy - Entered.");
//Create a HttpURLConnection with the correct server
//Send request to create an empty conference and retrieve response
String requestBody = “<buddy streamidentifier=\"1234567\" conferenceidentifier=\"23424244">
<mediastream identifier="\6445454454\" action="add"/>
</buddy>”;
HttpURLConnection connection = utils.SendHTTPRequest("http://"
+ MainSipServlet.IPMSHost + ":81/DialogicWebService/mediacontrol/buddies",
"POST", requestBody);
if (connection != null) {
xmlDoc = utils.GetHTTPXMLResponse(connection);
}
//Retrieve response codes
int responseCode = 0;
try {
responseCode = connection.getResponseCode();
} catch (IOException ex) {
Logger.getLogger(MainSipServlet.class.getName()).log(Level.SEVERE, null, ex);
}
String responseMessage = "";
try {
responseMessage = connection.getResponseMessage();
} catch (IOException ex) {
Logger.getLogger(MainSipServlet.class.getName()).log(Level.SEVERE, null, ex);
}
String responseLocation = connection.getHeaderField("location");
//close the connection
connection.disconnect();
//log results
logger.info("Buddy:: CreateBuddy - Http response code =" + responseCode);
logger.info("Buddy:: CreateBuddy - Http response message =" + responseMessage);
logger.info("Buddy:: CreateBuddy - Http response location =" + responseLocation);
if (responseCode == 201) {
buddyRef = responseLocation;
identifier = ParseIdentifier();
}
logger.info("Buddy:: CreateBuddy - Exited.");
}