Ad Hoc Audio Conferencing

EP

Conference Server

INVITE (SDP Offer)

200 OK (Answer)

ACK

EP in the Conference

The following explains the flow illustrated in Figure 5-9:

1. The endpoint dials into the conference. Assume that this URI represents ad hoc conferences in the system. The endpoint sends the INVITE to the conference server with the SDP offer as follows:

o=san 1549546120 0 IN IP4 10.10.10.26

c=IN IP4 10.10.10.26 m=audio 49220 RTP/AVP 0 8

The conference server checks whether the mixer resources are available and creates a conference instance.

2. The conference server sends a 200 OK response with the SDP answer as follows:

o=CiscoSystemsSIP-GW-UserAgent 3402 403 IN IP4 10.10.10.2 s=SIP Call c=IN IP4 10.10.10.54 m=audio 20000 RTP/AVP 0

Note that some SIP endpoints and conference servers may send an optional 100 TRYING message before sending 200 OK.

3. The endpoint completes the transaction by sending the final ACK.

The following notes provide some insight into the message flow from an implementation point of view:

■ Static payload types such as PCMU (G.711 |>law)/PCMA (G.711 A-law) do not require rtpmap attributes in the SDP offer/answer. The rtpmap attribute is used to map the RTP payload type number to a media encoding name that identifies the payload format. An example is payload type number 34, which maps to payload format H.263.

■ The conference server can choose any payload type from the offer. Typically, the payload type is determined through a conference-wide policy. In the absence of such a policy, the conference server selects a payload type by giving preference to those appearing at the top of the list.

■ After the endpoint is in the conference, any change in the media property is communicated through the RE-INVITE message (also called mid-call INVITE). A RE-INVITE can be sent by either the conference server or the endpoint.

■ The default direction of the media stream is duplex (send and receive). If the endpoint just wants to receive the stream (examples include listen-only mode), it should include a=recvonly/a=sendonly in the SDP offer/answer.

■ A session-level attribute is applied to all the media in the SDP offer/answer. However, a media-level attribute (if present) overrides a session-level attribute.

■ The endpoint may add a session-expires header with a value in the initial INVITE to indicate how long this session is valid. The conference server can respond by adding the Session-Expires header back in the response. If the conference server does not support session expiry, it can respond in two ways:

— The conference server can omit the Session-Expires header in the response.

— The conference server can set a value of 0 in the Session-Expires header to indicate infinite session duration.

The endpoint starts an active session timer and sends a RE-INVITE or UPDATE message to extend the session upon each instance of session timer expiry. The absence of the Session-Expires header implies no expiration. Note that if the conference server does not set the Session-Expires header in response to a RE-INVITE or UPDATE, the endpoint should disable the session timer and assume an infinite session duration.

An endpoint can leave a conferencing session by sending a BYE. Alternatively, the administrator or conference chairman can disconnect a participant from a conference, in which case the conference server sends a BYE to the endpoint. The conference server deletes the ad hoc conference instance when the last endpoint drops out of the conference.

In some cases, the endpoint may initiate a delayed-offer INVITE. In that case, the conference server sends an SDP offer in the 200 OK response, and the endpoint sends the answer in the final ACK.