ANÁLISIS DE ESTABILIDAD EN EL BALASTRO ELECTRÓNICO CON PT

The SIP Conference Server UAs compliant to this specification SHALL support

• SIP according to RFC 3261

• SDP according to RFC 3264 and RFC 4566

• SIP-Specific Event Notification according to RFC 3265 and the event package for conference state RFC 4575 and be able to act as notifier,

• the UA capabilities in SIP according to RFC 3840 as far as necessary for this specification, i.e. sending of the 'isfocus' parameter,

• the Allow-Event: header indicating 'conference' according to RFC 3265 and RFC 4575.

• the X-Siemens-Call-Type header indicating that the connected media stream is secure or insecure.

In addition the SIP Conference Server UAs compliant to this specification MAY optionally support

• receiving the SIP Referred-by: header according to RFC 3892.

In the following the SIP call control procedures for the Conference Focus and the Conference Notification Server are specified.

H.3.1 Creation of the Centralized Conference

H.3.1.1 Normal Procedures on the Conference Focus

On receipt of a SIP INVITE request according to Sect. H.2.1.1 the Conference Factory application SHALL route the SIP INVITE request to the Conference Focus. Details of this interface are out of scope of this specification. However, the Request URI received by the Conference Focus MAY already contain the Conference URI. Then the Conference Focus SHALL invoke authorisation procedures and MAY invoke authentication procedures for the INVITE initiated UA/user.

After successful authorization and possibly authentication the Conference Focus SHALL act in accordance with RFC 3261 and RFC 3264 and return a SIP 200 OK response including an SDP answer indication to the Conference Controller UA. If the original SIP INVITE from the UA creating the conference includes the X- Siemens-Call-Type header with security indication the SDP answer from the Media Server has selected the SRTP line, then OpenScape Voice sends 200 OK

answer from the Media Server has disabled the SRTP line, then OpenScape Voice sends 200 OK with insecure indication the X-Siemens-Call-Type header to the UA.

The 200 OK response SHALL contain the following headers: To: URI as received, To-Tag

From: as received from Conference Controller UA; From-Tag Contact: Conference URI; isfocus

Allow-Event: conference,

Authorization, Call-ID, Via, Max-Forwards, CSeq, Content-Length

Note: OpenScape Voice shall include an X-Siemens-Call-Type security

indication in the 200 OK response if the original SIP INVITE from the conference controller UA includes the same indication and the Media Server selects secure media (SRTP) for the SDP answer.

The Conference Focus SHALL inform via an internal message the Conference Notification Server about the established conference. However, this indication is out of scope of this specification.

H.3.1.2 Exceptional Procedures on the Conference Focus

If the SIP INVITE request is not acceptable, the Conference Focus SHALL send a 4xx response, as specified in RFC 3261, to the conference controller UA.

H.3.2 Subscription to the Conference Package

H.3.2.1 Normal Procedures on the Conference Notification

Server (OpenScape Voice)

Upon receipt of a SIP SUBSCRIBE request for the conference event package RFC 4575, the Conference Notification Server SHALL verify that the Contact URI in the SUBSCRIBE request equates to the UA in one of the conference INVITE- initiated dialogs. If the subscription checks are satisfactory according the SIP authentication procedures the Conference Notification Server SHALL return a SIP 200 OK and the initial SIP NOTIFY request to the appropriate UAs Notification Client.

The 200 OK response SHALL contain the following headers: To: URI as received, To-Tag

From: as received from Conference Controller UA; From-Tag Contact: Conference URI

Authorization, Call-ID, Via, Max-Forwards, CSeq, Content-Length.

The Request URI of the SIP NOTIFY request SHALL be set to the Contact URI of the conference participant (as received in the SIP SUBSCRIBE request) and the following headers SHALL be used (optional usage of other headers is not prohibited):

To: URI of the Subscriber, To-Tag (as From-Tag of the SUBSCRIBE) From: Conference URI; From-Tag (as sent in the To-Tag in 200 OK above) Contact: Conference URI

Event: conference

Subscription-State: active; expires (default value) Content-Type: application/conference-info+xml

Authorization, Call-ID, Via, Max-Forwards, CSeq, Allow, Accept, Content- Length

The body of the SIP NOTIFY request SHALL contain the XML encoded conference information document. This conference information document describes the state of the conference.

A conference notification server in conformance with this specification SHALL support as a minimum the <conference-description> element, the <users> element and <maximum-user-count> as specified in RFC 4575.

The <conference-description> element SHALL contain as a minimum element <display-text>, indicating the endpoint type and the line identity.

The <users> element SHALL contain a list of <user> elements. Each <user> element SHALL indicate the user identity or an indication of anonymous. The <maximum-user-count> element SHALL provide a value representing the overall number of users allowed to join the conference. This value is set by an administrator and can reflect the local conference policy. For a local conference the conference notification server SHOULD set the value of this element to 3, if it does not allow other members to add further members (even if it allows the conference controller to create conferences with more than 3 members).

Whenever there is a change in the state in any conference information (e.g. other participants were added to the conference) further SIP NOTIFY requests SHALL be sent to the Notification Client of the subscribed participant(s).

The initial SIP NOTIFY requests sent to the participants following subscription or refresh SHALL contain the full XML encoded conference information document, whereas all other SIP NOTIFY requests sent to the conference participants MAY

H.3.2.2 Exceptional Procedures on the Conference

Notification Server

If the SIP SUBSCRIBE request is not acceptable, the Conference Notification server SHALL send a 4xx response.