A Client should use the "bind" operation to start receiving signals directed to the authenticated user.
A Client can maintain one or several concurrent communication sessions ("calls"). Each call is identified with its callLeg identifier. The callLeg attribute is present in all call-related operation requests and in all Server data messages related to that call. Each call is independent.
For each call, a Client should be able to create one or several "media objects", which implement actual media (audio, video, etc.) communications. The media descrptor element ("SDP elements") are data elements (text or XML) that a Client retrieves from and sends to "media objects". As a minimum, it should be possible to perform the following operations on each media object:
If it is not possible to re-send an "offer" SDP to an already active media object, a new media object should be created, and the new "offer" SDP is sent to. If the "answer" SDP is successfully retrieved from the new media object, the old media object should be disposed of.
If it is not possible to re-retreive an "offer" SDP from an already active media object, a new media object should be created, and an "offer" SDP is retreieved from it. When the "answer" SDP received and sent to the new media object, the old media object should be disposed of.
A media object supports "forking" if it is possible to retrieve a single "offer" SDP from that media object, and then send several "answer" SDP elements to that media object, establishing several concurrent media communication channels.
Many messages and operation requests described in this section may contain an "SDP descriptor" as the XML body. The SDP descriptor may be specified using the XML presentation, or as an sdpText XML element with the SDP descriptor in the native SDP text format. The signalBind operation request specifies the format that the Server will be using in its messages (see below).
This operation allows the current XIMSS session to receive signals directed to the authenticated user.