PROCEDIMIENTO DE DISEÑO DEL BALASTRO ELECTRÓNICO

H.2.2.1 Normal Procedures

A SIP user which is participant in a running conference may add another user to the conference using a REFER request. In the following it is assumed that a confirmed dialog1 between the Conference Participant UA A and the Conference Focus and another confirmed dialog2 between the Conference Participant and the new participant UA B (i.e. user B to be added to the conference) already exists.

In this architecture there is a B2BUA (OpenScape Voice) between UA A and UA B.

1. Procedures at UA A

Depending on local policy, UA A MAY put on hold either UA B or the Conference Focus or both (see Sect. H.6) below for Interactions with SIP Media Hold) previously. Then UA A SHALL send a SIP REFER request with a Refer-To: header RFC 3515 on dialog2 towards UA B

Therefore UA A SHALL copy the Conference URI (including any URI parameters) from the Contact: header field as received from the Conference Focus into the Refer-to: header field, but NOT any received Contact header parameters (such as 'isfocus').

The SIP REFER request SHALL contain the following headers: Request URI: Contact URI of user B

To: URI of user B, To-tag (as in dialog2) From: URI of user A, From-Tag (as in dialog 2),

Refer-to: Conference URI (URI of the Focus) [method=INVITE] Contact: Contact URI of user A (as in dialog2)

Referred-by: URI of user A, RFC 3892 (optional)

Call-ID, Via, Max-Forwards, CSeq, Content-Length according to RFC 3515

Note: The To: and the From: header field URIs are not necessarily those of

user A and user B respectively, but they reflect the URIs used during dialog establishment.

On receipt of a 202-Accepted response to the SIP REFER request on dialog2 or SIP NOTIFY requests indicating "Trying" and/or "Ringing", UA A SHOULD take no action. On receipt of a SIP NOTIFY request indicating "200 OK" on

dialog2, UA A SHALL send SIP BYE request towards UA B and both the REFER-initiated implicit subscription and dialog2 SHALL be terminated. However, this is standard REFER RFC 3515 behavior and is repeated here just for completeness. After terminating dialog2 UA A SHALL send a SIP reINVITE on dialog1 to re-establish the previously held connection to the Media Server.

2. Procedures at UA B

A SIP re-INVITE request with the Contact: header field containing the capability parameter 'isfocus' (and possibly including a Referred-By: header indicating the URI of user A), and a SDP offer from the B2BUA is received.

Note: If all conference participants have secure media sessions established

with the media server, the SDP offer from the Media Server and sent by the B2BUA will attempt to renegotiate the call to UA B as a secure media call (SRTP), and include an X-Siemens-Call-Type header field identifying the call as secure.

UA B then:

• SHALL return a SIP 200 OK response with the SDP answer

Note: If the B2BUA had offered to renegotiate the call with UA B as

secure media server SDP offer in the re-INVITE, the UA should provide an SDP answer with secure media (SRTP) selected. Additionally the UA should provide its ‘secure’ call indication in the X-Siemens-Call-Type header field in the 200 OK response.

• SHOULD indicate to the user that the dialog to user A is replaced and it is now participating in a conference,

and if in addition the Allow-Event: header indicating 'conference' is received in the SIP re INVITE request and UA B supports the conference event package RFC 4575, then UA B's Call Control Client SHALL instruct (e.g. via an internal message which is out of scope of this specification) its Notification Client to subscribe to the conference event package. The appropriate procedures are as described below in Sect. H.3.

3. Procedures at a OpenScape Voice

On receipt of a SIP REFER request indicating method=INVITE in the context of a dialog for an existing call, OpenScape Voice SHALL act in accordance with RFC 3515 and RFC 3892.

The Refer-To: header contains the Conference URI which is recognized by the OpenScape Voice performing the role of the Conference Focus.

Once a connection has been created at the Conference Server (Media Server), the OpenScape Voice SHALL send a SIP re-INVITE request to UA B. In the Contact: header the Conference URI and the capability parameter 'isfocus' RFC 3840 SHALL be indicated. In addition the SDP offer indication of the Conference Focus (i.e. the Media server) SHALL be included.

Note: If all conference participants have secure media sessions established

with the media server, the SDP offer from the Media Server and sent by the B2BUA will attempt to renegotiate the call with the UA as a secure media call (SRTP), and include an X-Siemens-Call-Type header field identifying the call as secure.

On receipt of a SIP 200 OK response from UA B and a SDP answer

indication, the OpenScape Voice SHALL send this SDP answer indication to the Media Server and return a SIP ACK response to UA B.

If the SIP 200 OK is received with the X-Siemens-Call-Type header having “secure” indication, then the participant is updated as secure. If the SIP 200 OK has “insecure” indication, then it updates the participant and the

conference as insecure and sends a SIP UPDATE to all other conference participants notifying them that the conference media is insecure. The SIP UPDATE contains in the Contact: header the Conference URI and the capability parameter 'isfocus' and, also includes the X-Siemens-Call-Type header with ‘insecure’ indication.

Towards UA A the OpenScape Voice SHALL send a 202-Accepted response to the SIP REFER request and appropriate SIP NOTIFY requests (indicating "Trying", "Ringing", "200 OK, 4xx responses) according to RFC 3515. On receipt of the SIP NOTIFY indicating "200 OK" UA A SHALL send a SIP BYE request to release its call to UA B and shall then send a SIP reINVITE to OpenScape Voice to re-establish the previously held connection with the Media Server. OpenScape Voice SHALL return a SIP 200 OK to UA A.

H.2.2.2 Exceptional Procedures

1. Procedures at UA A If either

• the REFER request on dialog2 is rejected, or

then UA A SHOULD indicate the failure to user A. Dialog2 still exists and it will be up to UA A how to proceed (e.g. reconnect user A with user B).

Note: In the case where a conference is full, and UA A nevertheless sends a

REFER request to add a new participant, then a NOTIFY request with a 486 Busy Here response will be received by UA A. In the case where addition to the conference is not authorized, a NOTIFY request with a 403 Forbidden response will be received by UA A.

If UA B clears dialog2 before the REFER procedure is completed then UA A SHOULD indicate the failure to user A.

2. Procedures at UA B

If the SIP REFER request cannot be accepted, UA B SHALL act in accordance with RFC 3515.

If the SIP re-INVITE request cannot be accepted, the failure handling SHALL be as described in RFC 3261 section 14.2.

3. Procedures at OpenScape Voice

If the SIP REFER request cannot be accepted, the OpenScape Voice SHALL act in accordance with RFC 3515.