Conferencing Using the IP Multimedia (IM) Core Network (CN) Subsystem
|
|
|
- Winifred Warner
- 10 years ago
- Views:
Transcription
1 GPP X.S00-0 Version.0 Version Date: May 00 Conferencing Using the IP Multimedia (IM) Core Network (CN) Subsystem Revision: 0 COPYRIGHT GPP and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the GPP Secretariat at [email protected]. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See for more information.
2 Revision History Revision Content Changes Date Rev. 0 Initial Publication May 00 0 ii
3 X.S00-0 v.0 Conferencing Service; Stage- Contents Contents ii List of Figures...v Foreword vi Foreword vi Scope... Normative References... Definitions, symbols and abbreviations.... Definitions.... Abbreviations... Conferencing overview... Protocol using SIP and SIP events for conferencing.... Introduction.... Functional entities..... User Equipment (UE)..... Media Resource Function Controller (MRFC)..... Conferencing Application Server (Conferencing AS)..... Media Gateway Control Function (MGCF).... Role..... Conference Participant General Subscription for conference event package Conference creation General Conference creation with a conference factory URI Three-way session creation Joining a conference User joining a conference by using a conference URI User joining a conference after receipt of a REFER request Inviting other users to a conference General User invites other user to a conference by sending a REFER request to the other user User invites other user to a conference by sending a REFER request to the conference focus... Leaving a conference Conference participant leaving a conference Conference focus removes conference participant from a conference Removing a conference participant from a conference..... Conference focus General Generic procedures for all conference related methods at the conference focus Conference focus originating case Conference focus terminating case Conference creation Conference creation with a conference factory URI Conference creation with a conference URI User joining a conference User joining a conference by using a conference URI Invitation of users to a conference General Request from a user to invite another user to a conference... ii 0
4 X.S00-0 v.0 Conferencing Service; Stage Inviting a user to a conference by sending an INVITE request Inviting a user to a conference by sending a REFER request Leaving a conference Conference participant leaving a conference Removing a conference participant from a conference Conference termination..... Conference notification service General Subscription to conference event package Leaving a conference Conference termination... Protocol using SDP for conferencing.... Introduction.... Functional entities..... User Equipment (UE)..... Media Resource Function Controller (MRFC)..... Conferencing Application Server (Conferencing AS)..... Media Gateway Control Function (MGCF).... Role..... Conference participant..... Conference Focus... Void... Void... Annex A (informative): Example signalling flows of conferencing operation... A. Scope of signalling flows... A. Introduction... A.. General... A.. Key required to interpret signalling flows... A.. Overview of signalling flows related to PSI routeing... A. Flows demonstrating the creation of a conference...0 A.. Introduction...0 A.. User automatically creating a conference with a conference factory URI... A... MRFC/AS is located in user's home network... A... MRFC/AS is not located in user's home network... A.. User automatically creating a conference with a conference URI... A.. User creating a conference by manually dialling... A.. User creating a conference from two existing connections (Three-way session), users in different networks... A. Flows demonstrating a user joining a conference... A.. Introduction... A.. User calling into a conference... A... MRFC/AS is not located in user's home network... A... Conference URI resolved by the terminating home network... A... Conference URI can be resolved by the originating home network... A.. User getting invited to a conference... A... MRFC/AS is not located in user's home network... A... Conference Participant referring another user to a conference... A... User getting referred to a conference by a conference participant... A... MRFC/AS invites a user to a conference... A... MRFC/AS refers a user to a conference... A.. User requesting IMS to join another user... A... MRFC/AS is located in user's home network... A.. User joins a private conversation to a conference... A... User in a different network... A. Flows demonstrating a user subscribing to the conference event package... A.. Introduction... iii
5 X.S00-0 v.0 Conferencing Service; Stage- A.. User subscribing to the conference event package... A... MRFC/AS is not located in user's home network... A. Flows demonstrating a user leaving a conference... A.. Introduction... A.. User leaving the conference... A... MRFC/AS is located in user's home network... A.. User requesting to remove another user from conference... A.. MRFC/AS drops a user from a conference... A... MRFC/AS is located in user's home network... A. Flows demonstrating conference termination... A.. General... A. Flows demonstrating usage of hold and resume during conferences... iv 0
6 X.S00-0 v.0 Conferencing Service; Stage- 0 List of Figures Figure A...-: User automatically creating a conference with a conference factory URI MRFC/AS is located in user s home network... Figure A...-: User automatically creating a conference with a conference factory URI MRFC/AS is not located in user s home network... Figure A...-: User calling into a conference network MRFC/AS is not located in user s home network conference URI resolved by the terminating home network... Figure A...-: User calling into a conference MRFC/AS is not located in user's home network conference URI can be resolved by the originating home network... Figure A...-: User inviting another user to a conference by sending a REFER request to the other user... Figure A...-: User getting invited to a conference by receiving a REFER request.... Figure A...-: MRFC/AS inviting a user to a conference MRFC/AS routes directly to I-CSCF... Figure A...-: MRFC/AS inviting another user to a conference by sending a REFER request to UE#.... Figure A...-: User inviting another user to a conference by sending a REFER request to MRFC/AS... Figure A...-: User subscribing to conference event package MRFC/AS is not located in user s home network... Figure A...-: User leaving a conference... Figure A...-: MRFC/AS dropping a user from a conference... v
7 X.S00-0 v.0 Conferencing Service; Stage- Foreword This Technical Specification has been produced by the rd Generation Partnership Project (GPP) based on material contained in GPP specification TS...0. This document contains portions of material copied from GPP document number(s) TS.. The copyright on the GPP document is owned by the Organizational Partners of GPP (ARIB - Association of Radio Industries and Businesses, Japan; CCSA China Communications Standards Association, China; ETSI European Telecommunications Standards Institute; Committee T, USA; TTA Telecommunications Technology Association, Korea; and TTC Telecommunication Technology Committee, Japan), which have granted license for reproduction and for use by GPP and its Organizational Partners. vi 0
8
9 X.S00-0 v.0 Conferencing Service; Stage- 0 Scope The present document provides the protocol details for conferencing within the IP Multimedia Core Network Subsystem (IMS) based on the Session Initiation Protocol (SIP), SIP Events and the Session Description Protocol (SDP). The functionalities for conference policy control and for floor control (with respective standardised protocols) are felt to be essential for a complete IMS conferencing service but are not specified in this version of IMS conferencing and are for further study. The present document does not cover the signaling between a MRFC and a MRFP. Where possible, the present document specifies the requirements for this protocol by reference to specifications produced by the IETF within the scope of SIP, SIP Events and SDP, either directly, or as modified by GPP X.S00-00-A. Where this is not possible, extensions to SIP are defined within the present document. The document has therefore been structured in order to allow both forms of specification. The present document is applicable to Application Servers (ASs), Multimedia Resource Function Controllers (MRFCs), Multimedia Resource Function Processors (MRFP), Media Gateway Control Functions (MGCFs) and to User Equipment (UE) providing conferencing capabilities.
10 X.S00-0 v.0 Conferencing Service; Stage- Normative References The following standards and documents contain provisions which, through reference in this text, constitute provisions of this document. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. ANSI and TIA maintain registers of currently valid national standards published by them. References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. In the case of a reference to a GPP document, a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document [] GPP S.R00: IP Network Architecture Model for cdma000 Spread Spectrum Systems, Version.0, September 00. [] Void. [] GPP X.S00-00-A v.0: "IP Multimedia (IM) Session Handling; IP Multimedia (IM) Call Model; Stage ". [] GPP TS. Release : "Signalling flows for the IP multimedia call control based on SIP and SDP; Stage ". [] GPP X.S00-00-A v.0: "IP Multimedia Call Control Protocol Based on SIP and SDP; Stage ". [] GPP X.S00-00-A v.0: "IP Multimedia Subsystem (IMS); Stage ". [] RFC (March 00): "SIP: Session Initiation Protocol". [] RFC (February 00): "A Framework for Conferencing with the Session Initiation Protocol (SIP)". [] RFC (August 00): "Session Initiation Protocol Call Control Conferencing for User Agents". [] RFC (March 00): "Session Initiation Protocol Specific Event Notification". [] RFC (August 00): "A Session Initiation Protocol (SIP) Event Package for Conference State". [] GPP X.S00-00-A v.0: "IP Multimedia (IM) Subsystem Cx interface; Signaling Flows and Message Contents". [] RFC (May 00): "A Privacy Mechanism for the Session Initiation Protocol (SIP)". [] RFC (May 00): "Extensions to the Session Initiation Protocol (SIP) for Network Asserted Identity within Trusted Networks". [] Void. [] RFC (May 000): " RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals". 0
11 X.S00-0 v.0 Conferencing Service; Stage- 0 [] RFC (April 00): "The Session Initiation Protocol (SIP) REFER Method". [] Void. [] RFC (August 00): "Indicating user agent capabilities in the Session Initiation Protocol (SIP)". [0] RFC (September 00): "The Session Initiation Protocol (SIP) Referred-By Mechanism". [] Void. [] Void. [] Void. [] Void. [] Void. [] Void. [] Void. [] Void. [] Void. [] Void. [] Void. [] Void. Definitions, symbols and abbreviations. Definitions Conferencing AS: For the purposes of the present document, the following terms and definitions apply. For the purposes of the present document, the terms and definitions defined in [] apply: An Application Server that supports functionality specific to a SIP conference focus. The following terms and definitions given in [] apply (unless otherwise specified): Public Service Identity Three-way session For the purposes of the present document, the following terms and definitions given in [] subclause.: IP-Connectivity Access Network (IP-CAN) The following terms and definitions given in [] apply (unless otherwise specified): Conference Conference-Aware Participant
12 X.S00-0 v.0 Conferencing Service; Stage- Conference notification service Conference Policy Conference Policy Control Protocol Conference-Unaware Participant Conference URI Focus Media Policy Media policy server Membership Policy Mixer Participant Tightly Coupled Conference The following terms and definitions given in [] apply (unless otherwise specified): Conference Factory URI Feature parameter For the purposes of the present document, the following terms and definitions given in [] apply: For the purposes of the present document, the following terms and definitions given in []: Call Session Control Function (CSCF) Home Subscriber Server (HSS) Media Gateway Control Function (MGCF) Multimedia Resource Function Controller (MRFC) Multimedia Resource Function Processor (MRFP) For the purposes of the present document, the following terms and definitions given in [] subclause. apply: Filter criteria Initial filter criteria Initial request Subsequent request For the purposes of the present document, the following terms and definitions given in [] subclause... and subclause. apply: Interrogating-CSCF (I-CSCF) Policy Charging Rule Function (PCRF) Proxy-CSCF (P-CSCF) Public user identity Serving-CSCF (S-CSCF) For the purposes of the present document, the following terms and definitions given in [] apply: User Equipment (UE). Abbreviations AS CN CSCF For the purposes of the present document, the following abbreviations apply: Application Server Core Network Call Session Control Function 0
13 X.S00-0 v.0 Conferencing Service; Stage- 0 EVRC FQDN HSS I-CSCF IM IMS IP IP-CAN MGCF MRFC MRFP P-CSCF PSI S-CSCF SIP TLS UE Enhanced Variable Rate Codec Fully Qualified Domain Name Home Subscriber Server Interrogating CSCF IP Multimedia IP Multimedia CN Subsystem Internet Protocol IP-Connectivity Access Network Media Gateway Control Function Multimedia Resource Function Controller Multimedia Resource Function Processor Proxy CSCF Public Service Identity Serving CSCF Session Initiation Protocol Transport Layer Security User Equipment Conferencing overview The basic services for the IP Multimedia core network Subsystem (IMS), as defined in [], allow a user to initiate, modify and terminate media sessions based on the Session Initiation Protocol, as defined in []. Although these basic mechanisms already allow multi party calls, more sophisticated services for communication between multiple parties can be made available by the network. The conferencing service provides the means for a user to create, manage, terminate, join and leave conferences. It also provides the network with the ability to give information about these conferences to the involved parties. The network operator or the user may apply membership and media policies to a conference by using a conference policy control protocol. The functionality for conference policy control (with a respective standardised protocol) is felt to be essential for a complete IMS conferencing service but is not specified in this version of IMS conferencing and is for further study. Conferencing applies to any kind of media stream by which users may want to communicate, this includes e.g. audio and video media streams as well as instant message based conferences or gaming. Floor control, as part of the conferencing service offers control of shared conference resources at the MRFP. The functionality for floor control (with a respective standardised protocol) is felt to be essential for a complete IMS conferencing service but is not specified in this version of IMS conferencing and is for further study. The framework for SIP conferences is specified in []. The architecture for the GPP conference service is specified in [] and []. The present document specifies the usage of SIP and SDP, to realize GPP conference service based on the protocols specified by the IETF defined conference service as per RFCs listed in clause. However, since the IETF conference service has various scenarios and features as described in [], GPP conference service is a subset of the above IETF defined conference service. Loosely coupled conferencing is outside the scope of this release of the IMS conferencing service.
14 X.S00-0 v.0 Conferencing Service; Stage- Protocol using SIP and SIP events for conferencing. Introduction Void.. Functional entities.. User Equipment (UE) For the purpose of SIP based conferences, the UE shall implement the role of a Conference participant as described in subclause..... Media Resource Function Controller (MRFC) As the functional split between the MRFC and the conferencing AS is out of scope of this document, the procedures for the MRFC are described together with those for the conferencing AS in subclause... For the purpose of SIP based conferences, the MRFC shall regard the MRFP as a mixer, as described in [] and []... Conferencing Application Server (Conferencing AS) As the functional split between the conferencing AS and the MRFC is out of scope of this specification, the procedures are described for a combined conferencing AS and MRFC. The AS and MRFC may either be collocated, or interoperate using a proprietary protocol and a proprietary functional split. For the purpose of SIP based conferences, the conferencing AS/MRFC shall implement the role of a conference focus, as described in subclause.. and as a conference notification service, as described in subclause... The conferencing AS/MRFC may implement the role of a conference participant as described in subclause..... Media Gateway Control Function (MGCF). Role For the purpose of SIP based conference, the MGCF shall implement the role of conference participant as described in subclause..... Conference Participant... General In addition to the procedures specified in subclause.., the conference participant shall support the procedures specified in [] appropriate to the functional entity in which the conference participant is implemented. 0
15 X.S00-0 v.0 Conferencing Service; Stage Subscription for conference event package The conference participant may subscribe to the conference event package, as described in [].... Conference creation... General NOTE: A conference can be created by means of SIP, as described in subclause... or subclause... Additionally, creation of a conference can be provided by other means. The conference participant shall make use of the procedures for session establishment as described in subclause..a and subclause.. of [] when creating conferences by means of SIP.... Conference creation with a conference factory URI Upon a request to create a conference with a conference factory URI, the conference participant shall ) generate an initial INVITE request in accordance with subclause... of []; and ) set the Request-URI of the INVITE request to the conference factory URI. On receiving a 00 (OK) response to the INVITE request with the "isfocus" feature parameter indicated in Contact header, the conference participant shall store the content of the received Contact header as the conference URI. In addition to this, the conference participant may subscribe to the conference event package as described in [] by using the stored conference URI. NOTE : A conference participant can decide not to subscribe to the conference event package for conferences with a large number of attendees, due to, e.g., the signalling traffic caused by the notifications about users joining or leaving the conference. NOTE : A conference can also be created with a conference URI. The procedures for this case at the conference participant are identical to those for joining a conference, as described in sub-clause... It is not assumed that the conference participant is aware that the conference gets created in this case. NOTE : Discovery mechanisms for the conference factory URI are outside the scope of this specification.... Three-way session creation When a conference participant is participating in two or more SIP sessions and wants to join together two or more of these active sessions to a so-called three-way session, the conference participant shall perform the following steps: ) create a conference at the conference focus by sending an INVITE request with the conference factory URI for the three-way session towards the conference focus, as described in subclause...; ) decide and perform for each of the active sessions that are requested to be joined to the three-way session, how the remote user shall be invited to the three-way session, which can either be: a) by performing the procedures for inviting a user to a conference by sending an REFER request to the user, as described in subclause...; or b) by performing the procedures for inviting a user to a conference by sending a REFER request to the conference focus, as described in subclause...;
16 X.S00-0 v.0 Conferencing Service; Stage- ) release the active session with a user, by applying the procedures for session release in accordance with [], after a NOTIFY request has been received from that user, indicating that the user has successfully joined the three-way session, i.e. including: a) a body of content-type "message/sipfrag" that indicates a "00 OK" response; and, b) a Subscription-State header set to the value "terminated"; and, ) treat the created three-way session as a normal conference, i.e. the conference participant shall apply the applicable procedures of subclause.. for it.... Joining a conference... User joining a conference by using a conference URI Upon generating an initial INVITE request to join a conference for which the conference URI is known to the conference participant, the conference participant shall ) set the Request-URI of the INVITE request to the conference URI; and ) send the INVITE request towards the conferencing AS that is hosting the conference. NOTE : The initial INVITE request is generated in accordance with []. NOTE : The conference participants may get the conference URI as described in subclause... Other mechanisms may also be used by the conference participant to get aware of the conference URI, but they are out of scope of this specification. On receiving a 00 (OK) response to the INVITE request with the "isfocus" feature parameter indicated in Contact header, the conference participant shall store the contents of the received Contact header as the conference URI. In addition to that, the conference participant may subscribe to the conference event package as described in [] by using the stored conference URI. NOTE : A conference participant can decide not to subscribe to the conference event package for conferences with a large number of attendees, due to the signaling traffic caused by the notifications about e.g. users joining or leaving the conference.... User joining a conference after receipt of a REFER request Upon receipt of a REFER request that includes a Refer-To header which includes the "method" uri parameter set to INVITE, the conference participant shall: ) handle the REFER request in accordance with []; ) perform the actions as described in subclause... for a user joining a conference; and ) if the received REFER request included a Referred-By header, include the Referred-By header in accordance with [0] in the INVITE request that is sent for joining the conference.... Inviting other users to a conference... General Upon inviting another user to a conference, the conference participant has to decide which of the following procedures has to be applied: ) inviting an user to a conference by sending a REFER request to the user directly, as described in subclause...; or ) inviting a user to a conference by sending a REFER request to the conference focus, as described in subclause...; 0
17 X.S00-0 v.0 Conferencing Service; Stage- 0 NOTE: Additionally, users can be invited to a conference by other means. It is out of the scope of this specification, how the UE decides which of the above procedures shall be applied.... User invites other user to a conference by sending a REFER request to the other user Upon generating a REFER request that is destined to a user in order to invite that user to a specific conference, the conference participant shall: ) set the Request-URI of the REFER request to the address of the user who is invited to the conference; ) set the Refer-To header of the REFER request to the conference URI of the conference that the other user shall be invited to, including the "method" parameter set to "INVITE"; and NOTE: Other headers of the REFER request will be set in accordance with []. ) send the REFER request towards the user who is invited to the conference. The UE may additionally include the Referred-By header to the REFER request and set it to the URI of the conference participant that is sending the REFER request. Afterwards the UE shall treat incoming NOTIFY requests that are related to the previously sent REFER request in accordance with [] and may indicate the received information to the user.... User invites other user to a conference by sending a REFER request to the conference focus Upon generating a REFER request that is destined to the conference focus in order to invite another user to a specific conference, the conference participant shall: ) set the Request-URI of the REFER request to the conference URI to which the user is invited to; ) set the Refer-To header of the REFER request to the SIP URI or tel URL of the user who is invited to the conference; ) include the "method" parameter with the value "INVITE" in the Refer-To header; and NOTE: Other headers of the REFER request will be set in accordance with []. ) send the REFER request towards the conference focus that is hosting the conference. The UE may additionally include the Referred-By header to the REFER request and set it to the URI of the conference participant that is sending the REFER request. Afterwards the UE shall treat incoming NOTIFY requests that are related to the previously sent REFER request in accordance with [] and may indicate the received information to the user.... Leaving a conference... Conference participant leaving a conference When leaving a conference, the conference participant shall: ) generate a BYE request on the dialog that was established when joining or creating the conference, in accordance to the procedures described in [] and []; ) if the conference participant is subscribed to the conference state event information of that conference, the conference participant shall not renew this subscription and let the related subscription
18 X.S00-0 v.0 Conferencing Service; Stage- timer expire. When a related NOTIFY request is received which does not include a Subscription-State header set to the value "terminated", the conference participant shall: a) wait for an implementation dependant time, if a related NOTIFY request with the Subscription-State header set to the value "terminated" is received; and b) afterwards, if no such NOTIFY request is received, unsubscribe from the conference state event information by performing the procedures as described in [] and []. NOTE : A conference participant leaving a conference will cause the conference notification service to send a NOTIFY request with updated conference event information to all conference participants, including the participant who just left. Therefore the time between sending the BYE request and receiving the next NOTIFY request is very short. The conference participant does not immediately unsubscribe from the conference event package in order not to cause unnecessary traffic on the air interface. NOTE : After the conference participant leaves the conference, it can receive NOTIFY requests that cross the BYE request sent by the conference participant. In this case, the NOTIFY request will not include a Subscription-State header with the value "terminated", as it was issued before the conference focus / conference notification service got aware of the conference participant leaving the conference. Due to this another NOTIFY request may be received within a short period of time (see NOTE ), that carries the Subscription-State header set to "terminated".... Conference focus removes conference participant from a conference Upon receipt of a BYE request on the dialog that was established when joining or creating a conference, the conference participant shall: ) respond to the BYE request as described in [] and []; and ) if the conference participant is subscribed to the conference state event information of that conference, perform the actions for not renewing the subscription to the conference state event information as described for the conference participant leaving a conference in subclause Removing a conference participant from a conference Upon generating a REFER request to remove a conference participant from a conference, the removing conference participant shall: ) set the Request-URI of the REFER request to the conference URI of the conference from which the conference participant shall be removed ) set the Request-URI of the REFER request: a) to the address of the conference participant who should be removed from the conference if a single conference participant should be removed from the conference; or b) to the conference URI, to remove one or all conference participants from the conference. ) set the Refer-To header of the REFER request to a) the address of the conference participant to be removed from the conference, if a single conference participant is to be removed from the conference; b) the address of the conference URI, if all conference participants are to be removed from the conference; in both cases, include the method parameter set to BYE in the Refer-To header; and NOTE : Other headers of the REFER request will be set in accordance with []. 0
19 X.S00-0 v.0 Conferencing Service; Stage- 0 NOTE : The removal of all conference participants from the conference will terminate the conference if the conference policy is set accordingly. ) send the REFER request as per procedures defined in [] and []. Afterwards the removing conference participant shall treat incoming NOTIFY requests that are related to the previously sent REFER request in accordance with [] and may indicate the received information to the user. NOTE : Additionally, a conference participant can be removed from a conference by other means... Conference focus... General In addition to the procedures specified in subclause.., the conference focus shall support the procedures specified in [] appropriate to the functional entity in which the conference focus is implemented. When performing rd party call control, the conference focus shall follow the procedures of subclause.. of [].... Generic procedures for all conference related methods at the conference focus... Conference focus originating case The conference focus shall follow the procedures of [] subclause.. when acting as an originating UA.... Conference focus terminating case Upon receipt of a conference related initial request, the conference focus shall follow the procedures of [] subclause... in relation to the contents of the P-Charging-Function-Addresses header and the P-Charging-Vector header. When creating the first response for this initial request, the conference focus shall: ) include the P-Charging-Vector header including a) the value of the icid parameter as received in the initial request; b) the value of the orig-ioi parameter as received in the initial request; and c) the term-ioi parameter, indicating the network of the conference focus; and ) include the P-Charging-Function-Addresses header as received in the initial request or, if the P- Charging-Function-Addresses header was not received in the initial request, indicate the values applicable for the conference in the P-Charging-Function-Addresses header. When creating responses for an initial INVITE request, the conference focus shall additionally send the 00 (OK) response to the initial INVITE request only after the resource reservation has been completed.... Conference creation... Conference creation with a conference factory URI Upon receipt of an INVITE request that includes a conference factory URI in the Request-URI, the conference focus shall:
20 X.S00-0 v.0 Conferencing Service; Stage- NOTE: ) check if the conference factory URI is allocated and reject the request in accordance with [] if it is not allocated. The following actions in this subclause shall only be performed if the conference factory URI is allocated; The mechanism by which the conference focus gets aware whether a URI is a conference factory URI is out of the scope of this specification. One possibility would be that an operator uses a specific user part (e.g. [email protected]) or host part (e.g. conference-factory.home.net) for identification of conference factory URIs. ) verify the identity of the user as described in subclause... of [] and authorize the request as described in subclause... of []. The following actions in this subclause shall only be performed if the request has been authorized; ) allocate a conference URI and if needed, a temporary conference URI; and ) if "preconditions" were indicated as required in the INVITE request and the preconditions are not satisfied, generate a first reliable provisional response to the INVITE request, indicating the temporary conference URI in the Contact header if allocated, else the conference URI. At the same time, resources will also be requested from the mixer. If the conference focus generates any xx or xx response to the INVITE request, the conference focus shall include the "isfocus" feature parameter in accordance with the procedures of []. Upon receipt of an indication from the mixer that conference resources have been through-connected, the conference focus shall generate a 00 (OK) response to the INVITE request, indicating the "isfocus" feature parameter as a parameter to the conference URI in the Contact header.... Conference creation with a conference URI Upon receipt of an INVITE request that includes a conference URI in the Request-URI and the conference has not been created yet, the conference focus shall: ) check if the conference URI is allocated and reject the request in accordance with [] if it is not allocated. The following actions in this subclause shall only be performed if the conference URI is allocated; ) verify the identity of the user as described in subclause... of [] and authorize the request as described in subclause... of []. The following actions in this subclause shall only be performed if the request has been authorized; and ) if "preconditions" were indicated as required in the INVITE request and the preconditions are not satisfied, generate a first reliable provisional response to the INVITE request, indicating the conference URI in the Contact header. At the same time, resources will also be requested from the mixer. If the conference focus generates any xx or xx response to the INVITE request, the conference focus shall include the "isfocus" feature parameter in accordance with the procedures of []. Upon receipt of an indication from the conference mixer that conference resources have been throughconnected, the conference focus shall generate a 00 (OK) response to the INVITE request, indicating the conference URI in the Contact header. 0
21 X.S00-0 v.0 Conferencing Service; Stage User joining a conference... User joining a conference by using a conference URI Upon receipt of an INVITE request that includes a conference URI in the Request-URI, the conference focus shall: ) check if the conference URI is allocated. If the conference URI is not allocated, the conference focus shall reject the request in accordance with []. The following actions shall only be performed if the conference URI is allocated; ) verify the identity of the user as described in subclause... of [] and authorize the request as described in subclause... of []. The following actions in this subclause shall only be performed if the request has been authorized; and ) if preconditions were indicated as required in the INVITE request and the preconditions are not satisfied, generate a reliable provisional response to the INVITE request, indicating the conference URI in the Contact header. At the same time, resources will also be requested from the mixer. If the conference focus generates any xx or xx response to the INVITE request, the conference focus shall include the "isfocus" feature parameter in accordance with the procedures of []. Upon receipt of an indication from the mixer that conference resources have been through-connected, the conference focus shall generate a 00 (OK) response to the INVITE request, indicating the conference URI in the Contact header.... Invitation of users to a conference... General NOTE: The conference focus can invite users to a conference by sending an INVITE request to the user, as described in subclause... This procedure will be triggered at the conference focus by a REFER request received from authorized users, that request the conference focus to invite other users to the conference, as described in subclause... Additionally, invitation of users to a conference can be triggered by other means. Additionally, the conference focus can invite users to a conference by sending a REFER request to the user, as described in subclause... How these procedures are triggered is outside the scope of this specification.... Request from a user to invite another user to a conference Upon receipt of an REFER request that includes: a) a conference URI in the Request-URI; and, b) a Refer-To header including: - a valid SIP URI or tel URL; and, - the "method" parameter set to "INVITE"; the conference focus shall: ) check if the conference URI is allocated. If the conference URI is not allocated, the conference focus shall reject the request in accordance with []. The following actions in this subclause shall only be performed if the conference URI is allocated;
22 X.S00-0 v.0 Conferencing Service; Stage- ) verify the identity of the user as described in subclause... of [] and authorize the request as described in subclause... of []. The following actions in this subclause shall only be performed if the request has been authorized; ) generate a final response to the REFER request in accordance with []; ) invite the user indicated in the Refer-To header by performing the procedures as described in subclause...; ) if the received REFER request included a Referred-By header, include the Referred-By header in accordance with [0] in the INVITE request that is sent for inviting the user to join the conference; and ) based on the progress of this invitation, send NOTIFY messages in accordance with the procedures of [] towards the user who sent the REFER request.... Inviting a user to a conference by sending an INVITE request When generating an INVITE request in order to invite a user to a specific conference, the conference focus shall: ) set the Request-URI of the INVITE request to the address of the user who is invited to the conference; ) set the P-Asserted-Identity header of the INVITE request to the conference URI of the conference that the user shall be invited to; ) set the Contact header of the INVITE request to the conference URI of the conference that the user shall be invited to, including the "isfocus" feature parameter; ) if the INVITE request is generated due to a received REFER request from another conference participant and that received REFER request included a Referred-By header, include the Referred-By header in accordance with [] in the INVITE request; ) request the resources required for the new user from the conference mixer; and ) send the INVITE request towards the user who is invited to the conference. NOTE: Requests are generated in accordance with []. Afterwards the conference focus shall proceed the session establishment as described in ].... Inviting a user to a conference by sending a REFER request When generating a REFER request in order to invite a user to a specific conference, the conference focus shall: ) set the Request-URI of the REFER request to the address of the user who is invited to the conference; ) set the P-Asserted-Identity header of the REFER request to the conference URI of the conference that the user shall be invited to; ) set the Refer-To header of the REFER request to the conference URI of the conference that the other user shall be invited to, including the "method" uri parameter set to "INVITE"; and NOTE : Other headers of the REFER request will be set in accordance with []. ) send the REFER request towards the user who is invited to the conference. NOTE : Requests are generated in accordance with []. 0
23 X.S00-0 v.0 Conferencing Service; Stage- 0 Afterwards the conference focus shall treat incoming NOTIFY requests that are related to the previously sent REFER request in accordance with [].... Leaving a conference... Conference participant leaving a conference Upon receipt of a BYE message from a conference participant, the conference focus shall: ) respond to the BYE request as described in [] and []; and ) release the resources, related to the conference participant from the conference mixer.... Removing a conference participant from a conference... General NOTE: The conference focus can remove a conference participant from a conference by terminating the dialog with the conference participant. This is done by sending a BYE request to the participant, as described in subclause... The removal of a conference participant by the conference focus will be triggered ) by a REFER request received from authorized users, that request the conference focus to remove the conference participant from the conference, as described in subclause...; or ) by local administration procedures. Additionally, a conference participant may be removed from a conference by other means.... Request from a conference participant to remove another conference participant from a conference Upon receipt of a REFER request that includes: a) a conference URI in the Request-URI; and, b) a Refer-To header including: - a valid SIP URI or tel URL; and, - the method parameter set to BYE ; the conference focus shall: ) check if the conference URI is allocated. If the conference URI is not allocated, the conference focus shall reject the request in accordance with []. The following actions in this subclause shall only be performed if the conference URI is allocated; ) check if the SIP URI or tel URL of the Refer-To header is identical to the conference URI or belongs to a user who is currently a participant of the referenced conference. If this verification fails, then reject the request in accordance with [] and []; ) verify the identity of the user as described in subclause... of [] and authorize the request as described in subclause... of []. The following actions in this subclause shall only be performed if the request has been authorized; ) generate a final response to the REFER request in accordance with []; ) if a single conference participant is indicated in the Refer-To header, remove this conference participant from the conference according to subclause... If the Refer-To header includes the
24 X.S00-0 v.0 Conferencing Service; Stage- conference URI, remove all conference participants from the conference by performing the procedures described in subclause... for each conference participant individually; and ) based on the progress of this removal, send NOTIFY messages in accordance with the procedures of [] towards the conference participant who sent the REFER request.... Conference focus removes conference participant from a conference When removing a conference participant from a conference, the conference focus shall ) generate a BYE request on the dialog that was established when the conference participant joined or created the conference, in accordance to the procedures described in [] and []; ) release the resources, related to the conference participant from the conference mixer.... Conference termination NOTE: A conference shall be terminated by the conference focus: ) when the conference policy dictates it; or ) when no dedicated rules for conference termination exist in the conference policy and - either the conference was created with a conference factory URI and the conference creator has left the conference; or - the last conference participant has left or has been removed from the conference. How the conference policy can be created or changed is out of the scope of this specification. To terminate an existing conference, the conference focus shall: ) remove all present conference participants from the conference by performing the procedures as described in subclause... for each participant individually; and ) deallocate the conference URI... Conference notification service... General In addition to the procedures specified in subclause.., the conference notification service shall support the procedures specified in [] appropriate to the functional entity in which the conference notification service is implemented.... Subscription to conference event package Upon receipt of a SUBSCRIBE request that includes a conference URI in the Request-URI and the "conf" tag in the Event header, the conference notification service shall: ) check if the conference URI is allocated and reject the request in accordance with [] if it is not allocated. The following actions in this subclause shall only be performed if the conference URI is allocated; ) verify the identity of the user as described in subclause... of [] and authorize the request as described in subclause... of []. The following actions shall only be performed if the request can be authorized; and ) establish the subscription to the conference state event information as described in [] and []. 0
25 X.S00-0 v.0 Conferencing Service; Stage Leaving a conference When generating a NOTIFY request with conference state event information that is destined to a subscriber that has either left the conference or was removed from it, the conference notification service shall include in the NOTIFY request a Subscription-State header with the value "terminated" in accordance with [].... Conference termination The conference notification service shall terminate all subscriptions to the conference event package in accordance with [] when the conference is terminated, as described in subclause... Protocol using SDP for conferencing. Introduction Void.. Functional entities.. User Equipment (UE) For the purpose of SIP based conferences, the UE shall implement the role of a conference participant as described in subclause..... Media Resource Function Controller (MRFC) As the function split between the MRFC and the conferencing AS is out of scope of this document, the procedures for the MRFC are described together with those for the conferencing AS in subclause..... Conferencing Application Server (Conferencing AS) As the function split between the conferencing AS and the MRFC is out of scope of this specification, only the procedures are described for a combined conferencing AS and MRFC. The AS and MRFC may either be collocated, or interoperate using a proprietary protocol and a proprietary functional split. For the purpose of SIP-based conferences, the conferencing AS shall act as a conference focus, as described in subclause... The conferencing AS/MRFC may implement the role of a conference participant as described in subclause..... Media Gateway Control Function (MGCF) The MGCF implements the role of conference participant (as described in subclause..).
26 X.S00-0 v.0 Conferencing Service; Stage-. Role.. Conference participant The conference participant shall support the procedures specified in [] appropriate to the functional entity in which the conference participant is implemented... Conference Focus Void Void In addition to the procedures specified in subclause.., the conference focus shall support the procedures specified in [] appropriate to the functional entity in which the conference focus is implemented. When the conference focus receives any SIP request or response containing SDP, the conference focus shall examine the media parameters in the received SDP. Provided that the INVITE request received by the conference focus contains an SDP offer including one or more "" media descriptions, the SDP answer shall: - reflect the media capabilities and policies as available for the conference; and - contain a request confirmation for the result of the resource reservation at the originating end point for every "" media line if preconditions were required by the originator. During session establishment procedure for a conference, SIP messages shall only contain SDP payload if that is intended to modify the session description. For "video" and "audio" media types that utilize the RTP/RTCP, the conference focus shall specify the proposed bandwidth for each media stream utilizing the "" media descriptor in the SDP. For other media streams the "" media descriptor may be included. The value or absence of the "" parameter will affect the assigned QoS. The conference focus shall include the DTMF media format at the end of the "" media descriptor in the SDP for audio media flows that support both audio codec and DTMF payloads in RTP packets as described in []. Upon receipt of a SDP answer or sending a SDP answer that changes the resource requirements for the conference, the conference focus shall provide the corresponding changes of conference resources. Upon receipt of a SDP offer during conference creation, that confirms that the conference participant has reserved the required resources, the conference focus shall through-connect the conference resources. 0
27 X.S00-0 v.0 Conferencing Service; Stage- 0 Annex A (informative): Example signalling flows of conferencing operation A. Scope of signalling flows This annex gives examples of signalling flows for conferencing within the IP Multimedia CN Subsystem (IMS) based on the Session Initiation Protocol (SIP), SIP Events and the Session Description Protocol (SDP). These signalling flows provide detailed signalling flows, which expand on the overview information flows provided in []. A. Introduction A.. A.. A.. General This annex breaks down the signalling flows for establishing sessions into a number of individual procedures, following the same principles as [] subclause... For the purposes of this document, a further breakdown has been necessary, and therefore a number of signalling flows have been given an (a) or (b) suffix, so that the signalling flows for establishing sessions where configuration independence is applied may be distinguished from those where it is not, e.g.: - (MO#a) Mobile origination, roaming, without I-CSCF providing configuration independence. - (MO#b) Mobile origination, roaming, with I-CSCF in home network providing configuration independence. Key required to interpret signalling flows The key to interpret signalling flows specified in [] subclause. applies with the additions specified below. As in [], in order to differentiate between SIP methods and other protocol messages, the message name is preceded with the associated protocol for all non-sip messages. Each flow table contains descriptions for headers where the content of the header is new to that flow, as is already performed in []. However, [] includes extensive descriptions for the contents of various headers following each of the tables representing the contents of the flows. Where the operation of the header is identical to that shown in [], then such text is not reproduced in this document. Additional text may also be found on the contents of headers within [] in addition to the material shown in this document. Overview of signalling flows related to PSI routeing The flows in this annex reflect examples for some of the PSI specific routing scenarios. This subclause gives a list of the PSI scenarios and indicates which flows specifically cover them.
28 X.S00-0 v.0 Conferencing Service; Stage- ) User originating a dialog towards a PSI. a) PSI is hosted by the originating users home network. i) S-CSCF of originating user can directly route towards the AS hosting the PSI. ii) This case is shown in subclause A... and subclause A... PSI is statically pre-configured, i.e. S-CSCF of the originating user routes towards the S-CSCF assigned to the PSI, which afterwards routes towards the AS hosting the PSI. This case is not covered by this specification. b) PSI is hosted by a network different from the originating users home network. i) PSI can be resolved directly by the S-CSCF located in the originating users home network. ii) ) Dialog originates from a PSI. This case is shown in subclause A... and subclause A... S-CSCF in originating users home network can only resolve an I-CSCF of the network that is hosting the PSI. - I-CSCF can directly route towards the AS hosting the PSI. This case is shown in subclause A... and subclause A... - PSI is statically pre-configured, i.e. I-CSCF routes first to S-CSCF in the network that hosts the PSI, the S-CSCF afterwards routes towards the AS hosting the PSI This case is not covered by this specification. a) AS routes directly to the I-CSCF of the terminating users home network. This case is shown in subclause A... b) AS routes first to a S-CSCF in the network hosting the PSI, which then routes to the I- CSCF of the terminatings users home network. This case is shown in subclause A... ) Dialog originating from a PSI and terminating at a different PSI. This case is not covered by this specification. A. Flows demonstrating the creation of a conference A.. Introduction Subclause A. covers the flows that show how a user can create conferences at a MRFC/AS. 0 0
29 X.S00-0 v.0 Conferencing Service; Stage- 0 A.. A... User automatically creating a conference with a conference factory URI MRFC/AS is located in user's home network UE# P-CSCF S-CSCF MRFC/AS MRFP. Resource Reservation Visited Network. INVITE. 0 Trying. INVITE. 0 Trying. Session Progress. Authorize QoS resources. Session Progress. PRACK. 00 OK. UPDATE. 00 OK. PRACK OK. UPDATE. 00 OK. 00 OK. Approval of QoS Commit. 00 OK. ACK. ACK. Evaluation of initial Filter Criteria. INVITE. 0 Trying. Session Progress. PRACK. 00 OK. UPDATE. 00 OK. 00 OK. ACK Home Network. Allocate Conference URI. H. interaction to create conference connection resources for UE#. H. interaction to modify conference connection resources for UE#. H. interaction to connect through conference connection resources for UE# Figure A...-: User automatically creating a conference with a conference factory URI MRFC/AS is located in user s home network
30 X.S00-0 v.0 Conferencing Service; Stage- Figure A...- shows an user creating a conference by using a conference-factory URI. The conference is created at a MRFC/AS of the users home network. The details of the flows are as follows:. INVITE request (UE to P-CSCF) - see example in table A...- A UE wants to create a conference. For this purpose the UE is aware of a conference-factory URI that was obtained by means outside this specification (e.g. due to pre-configuration or via other protocols, such as http) The UE determines the complete set of codecs that it is capable of supporting for this conference. It builds a SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for each possible media flow. Multiple media flows may be offered, and for each media flow ( line in SDP), there may be multiple codec choices offered. For this example, it is assumed that UE# is willing to establish a multimedia session comprising a video stream and an audio stream. The video stream supports two codecs, either H. or MPEG- Visual. The audio stream supports the EVRC codec. The UE sends the INVITE request to the P-CSCF. 0
31 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: INVITE request (UE to P-CSCF) INVITE sip:[email protected] SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:[email protected];lr> P-Preferred-Identity: "John Doe" <sip:[email protected]> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Privacy: none <sip:[email protected]>; tag= <sip:[email protected]> cb0a0s0asdfglkj Cseq: INVITE Require: precondition, sec-agree Proxy-Require: sec-agree Supported: 0rel Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= Contact: <sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::aaa:bbb:ccc:ddd t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos none remote sendrecv rtpmap: H fmtp: profile-level-id=0 rtpmap::mpvmpv-es audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos none remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event Request-URI: contains the conference factory URI.. 0 (Trying) response (P-CSCF to UE) - see example in table A...- The P-CSCF responds to the INVITE request () with a 0 (Trying) provisional response. Table A...-: 0 (Trying) response (P-CSCF to UE) SIP/.0 0 Trying Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds 0. INVITE request (P-CSCF to S-CSCF) - see example in table A...- The P-CSCF forwards the INVITE request to the S-CSCF.
32 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: INVITE request (P-CSCF to S-CSCF) INVITE SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Route: Record-Route: <sip:pcscf.visited.net;lr> P-Asserted-Identity: "John Doe" P-Access-Network-Info: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00" Privacy: Cseq: Require: precondition Supported: Contact: Allow: Content-Type: ( ) v= o= s= c= t=. 0 (Trying) response (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF responds to the INVITE request () with a 0 (Trying) provisional response. Table A...-: 0 (Trying) response (S-CSCF to P-CSCF) SIP/.0 0 Trying Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds 0. Evaluation of initial filter criteria The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 0
33 X.S00-0 v.0 Conferencing Service; Stage- 0. INVITE request (S-CSCF to MRFC/AS) - see example in table A...- The S-CSCF forwards the INVITE request to the MRFC/AS that is indicated in the host part of the Request-URI. The S-CSCF does not re-write the Request-URI. Table A...-: INVITE request (S-CSCF to MRFC/AS) INVITE sip:[email protected] SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: "John Doe" <sip:[email protected]>, <tel:+--> P-Access-Network-Info: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Privacy: Cseq: Require: Supported: Contact: Content-Type: (...) v= o= s= c= t=. 0 (Trying) response (MRFC/AS to S-CSCF) - see example in table A...- (related to table A...- ) The MRFC/AS responds to the INVITE request () with a 0 (Trying) provisional response.
34 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 0 (Trying) response (MRFC/AS to S-CSCF) SIP/.0 0 Trying Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds 0. Allocate conference URI The MRFC/AS allocates a conference URI, based on local information and information gained from the conference-factory URI, as well as information gained from other elements of the SIP signalling.. H. interaction to create connection The MRFC initiates a H. interaction to create an IMS connection point for UE# in MRFP and to determine media capabilities of the MRFP.. (Session Progress) response (MRFC/AS to S-CSCF) - see example in table A...- (related to table A...-) The MRFC determines the complete set of codecs that it is capable of supporting for this conference. It determines the intersection with those appearing in the SDP in the INVITE request. The media stream capabilities of the destination are returned along the signalling path, in a (Session Progress) provisional response (to ). 0
35 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: (Session Progress) response (MRFC/AS to S-CSCF) SIP/.0 Session Progress Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: "Conference Server" <sip:mrfc.home.net> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net; term-ioi=home.net P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Privacy: none <sip:[email protected]>; tag= Require: 0rel Contact: <sip:[email protected]>;isfocus Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY RSeq: 0 Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::eee:fff:aaa:bbb t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: H fmtp: profile-level-id=0 rtpmap: MPV-ES audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event Contact: contains the IP address or FQDN of the MRFC/AS and a temporary identifier of the conference being created in the user part. The URI for the allocated conference is not indicated yet. The "isfocus" feature parameter is included, as this temporary contact is still a conference URI. P-Charging-Vector: The MRFC/AS inserts this header and populates the icid parameters with a unique value and populates the term-ioi parameter with the identifier of its own network. P-Charging-Function-Address: The MRFC/AS stores the P-Charging-Function-Addresses header field to be passed to the S-CSCF.. (Session Progress) response (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF forwards the (Session Progress) response to the P-CSCF.
36 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: (Session Progress) response (S-CSCF to P-CSCF) SIP/.0 Session Progress Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00" P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Privacy: Require: Contact: Allow: RSeq: Content-Type: v= o= s= c= t=. Authorize QoS Resources The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens at this stage or after the 00 (OK) response of INVITE request () based on operator local policy. (Session Progress) response (P-CSCF to UE) see example in table A...- The P-CSCF forwards the (Session Progress) response to the originating endpoint. 0
37 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: (Session Progress) response (P-CSCF to UE) SIP/.0 Session Progress Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net:;lr;comp=sigcomp> P-Asserted-Identity: Privacy: P-Media-Authorization: eee00c00 Require: Contact: Allow: RSeq: Content-Type: v= o= s= c= t=. PRACK request (UE to P-CSCF) - see example in table A...- The UE determines which media flows should be used for this session, and which codecs should be used for each of those media flows. If there was any change in media flows, or if there was more than one choice of codec for a media flow, then UE includes a new SDP offer in the PRACK request sent to the MRFC/AS. For this example, assume the UE chooses H. as the codec to use for the single video stream. Therefore, UE# sends a new SDP offer in the PRACK request.
38 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: PRACK request (UE to P-CSCF) PRACK SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr> <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj Cseq: PRACK Require: precondition, sec-agree Proxy-Require: sec-agree Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= RAck: 0 INVITE Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::aaa:bbb:ccc:ddd t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event. Resource reservation After determining the final media streams in step #, the UE initiates the reservation procedures for the resources needed for this session.. PRACK request (P-CSCF to S-CSCF) see example in table A...- The P-CSCF forwards the PRACK request to the S-CSCF. 0
39 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: PRACK request (P-CSCF to S-CSCF) PRACK sip:[email protected] SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: P-Access-Network-Info: Route: <sip:scscf.home.net;lr> Cseq: Require: precondition RAck: Content-Type: v= o= s= c= t=. PRACK request (S-CSCF to MRFC/AS) see example in table A...- The S-CSCF forwards the PRACK request to the MRFC/AS.
40 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: PRACK request (S-CSCF to MRFC/AS) PRACK SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: P-Access-Network-Info: Cseq: Require: RAck: Content-Type: v= o= s= c= t=. 00 (OK) response (MRFC/AS to S-CSCF) see example in table A...- (related to table A...- ) The MRFC/AS acknowledges the PRACK request () with a 00 (OK) response. 0
41 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (MRFC/AS to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::eee:fff:aaa:bbb t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event. H. interaction to modify connection MRFC initiates a H. interaction to modify the connection established in step # and instructs MRFP to reserve the multimedia processing resources for UE# according to the preceding resource negotiation between the UE# and the MRFC (OK) response (S-CSCF to P-CSCF) - see example in table A...-0 The S-CSCF forwards the 00 (OK) response to the P-CSCF.
42 X.S00-0 v.0 Conferencing Service; Stage- Table A...-0: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. 00 (OK) response (P-CSCF to UE) - see example in table A...- The P-CSCF forwards the 00 (OK) response to the UE. 0
43 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (P-CSCF to UE) SIP/.0 00 OK Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. UPDATE request (UE to P-CSCF) see example in table A...- When the resource reservation is completed, the UE sends the UPDATE request to the MRFC/AS, via the signalling path established by the INVITE request.
44 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: UPDATE request (UE to P-CSCF) UPDATE SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj Cseq: UPDATE Require: sec-agree Proxy-Require: sec-agree Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::aaa:bbb:ccc:ddd t=0 0 video 0 RTP/AVP AS: curr:qos local sendrecv curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local sendrecv curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: EVRC/000 rtpmap: telphone-event. UPDATE request (P-CSCF to S-CSCF) see example in table A...- The P-CSCF forwards the UPDATE request to the S-CSCF. 0
45 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: UPDATE request (P-CSCF to S-CSCF) UPDATE sip:[email protected] SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: P-Access-Network-Info: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; ggsn=[::b:c:d:e]; pdp-sig=no; gcid=; auth-token=; flowid= Route: <sip:scscf.home.net;lr> Cseq: Content-Type: v= o= s= c= t=. UPDATE request (S-CSCF to MRFC/AS) - see example in table A...- The S-CSCF forwards the UPDATE request to the MRFC/AS.
46 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: UPDATE request (S-CSCF to MRFC/AS) UPDATE SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: P-Access-Network-Info: Cseq: Content-Type: v= o= s= c= t=. 00 (OK) response (MRFC/ASto S-CSCF) see example in table A...- (related to table A...- ) The MRFC/AS acknowledges the UPDATE request () with a 00 (OK) response. 0
47 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (MRFC/AS to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::eee:fff:aaa:bbb t=0 0 video 0 RTP/AVP AS: curr:qos local sendrecv curr:qos remote sendrecv des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local sendrecv curr:qos remote sendrecv des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event The SDP indicates that the resource reservation was successful both in the local and the remote segment.. H. interaction to modify connection MRFC initiates a H. interaction to connect through the multimedia processing resources for UE# in MRFP.. 00 (OK) response (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF forwards the 00 (OK) response to the P-CSCF.
48 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. 00 (OK) response (P-CSCF to UE) see example in table A...- The P-CSCF forwards the 00 (OK) response to the UE. 0
49 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (P-CSCF to UE) SIP/.0 00 OK Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. 00 (OK) response (MRFC/AS to S-CSCF) see example in table A...- (related to table A...- ) After the success modification of the session (), the MRFC/AS sends a 00 (OK) response final response to the INVITE request () to the S-CSCF. Table A...-: 00 (OK) response (MRFC/AS to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> INVITE Contact: <sip:[email protected]>;isfocus Allow-Events: conference 0 Contact: Allow-Events: Contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter. The MRFC/AS indicates support for the "conference" event package. 00 (OK) response (S-CSCF to P-CSCF) see example in table A...- The S-CSCF sends a 00 (OK) response final response along the signalling path back to the P-CSCF.
50 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: Contact: Allow-Events:. Approval of QoS commit The P-CSCF approves the commitment of the QoS resources if it was not approved already in step ().. 00 (OK) response (P-CSCF to UE) see example in table A...- The P-CSCF forwards the 00 (OK) response final response to the session originator.the UE can start the media flow(s) for this session. Table A...-: 00 (OK) response (P-CSCF to UE) SIP/.0 00 OK Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net:;lr;comp=sigcomp> Contact: Allow-Events:. ACK request (UE to P-CSCF) see example in table A...- The UE starts the media flow for this session, and responds to the 00( OK) response () with an ACK request sent to the P-CSCF. Table A...-: ACK request (UE to P-CSCF) ACK SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr> <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj Cseq: ACK 0. ACK request (P-CSCF to S-CSCF) see example in table A...- The P-CSCF forwards the ACK request to the S-CSCF. 0
51 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: ACK request (P-CSCF to S-CSCF) ACK sip:[email protected]: SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Route: <sip:scscf.home.net;lr> Cseq:. ACK request (S-CSCF to MRFC/AS) - see example in table A...- A... The S-CSCF forwards the ACK request to the MRFC/AS. Table A...-: ACK request (S-CSCF to MRFC/AS) ACK sip:[email protected]: SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Cseq: MRFC/AS is not located in user's home network Figure A...- shows an user creating a conference by using a conference-factory URI. The conference is created at a MRFC/AS located in a different network than user s S-CSCF.
52 X.S00-0 v.0 Conferencing Service; Stage- Visited Network Home Network Conference AS home network UE# P-CSCF S-CSCF I-CSCF MRFC/AS MRFP. Resource Reservation. INVITE. 0 Trying. INVITE. 0 Trying. Session Progress. Authorize QoS resources. Session Progress. PRACK. 00 OK. UPDATE. 00 OK. 00 OK. ACK 0. PRACK. 00 OK. UPDATE. 00 OK. 00 OK. Approval of QoS Commit. ACK. Evaluation of initial Filter Criteria. INVITE. 0 Trying. Session Progress. 00 OK. PSI location query. PRACK. 00 OK. UPDATE. 00 OK. ACK. INVITE. 0 Trying. Session Progress. 00 OK. Allocate Conference URI. H. interaction to create conference connection resources for UE#. H. interaction to modify conference connection resources for UE#. H. interaction to connect through conference connection resources for UE# Figure A...-: User automatically creating a conference with a conference factory URI MRFC/AS is not located in user s home network 0
53 X.S00-0 v.0 Conferencing Service; Stage- 0 The details of the flows are as follows:. INVITE request (UE to P-CSCF) - see example in table A...- A UE wants to create a conference to a MRFC/AS in other network. For this purpose the UE is aware of a conference-factory URI that was obtained by means outside this specification (e.g. due to preconfiguration or via other protocols, such as http) The UE determines the complete set of codecs that it is capable of supporting for this conference. It builds a SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for each possible media flow. Multiple media flows may be offered, and for each media flow ( line in SDP), there may be multiple codec choices offered. For this example, it is assumed that UE# is willing to establish a multimedia session comprising a video stream and an audio stream. The video stream supports two codecs, either H. or MPEG- Visual. The audio stream supports the EVRC codec. The UE sends the INVITE request to the P-CSCF. Table A...-: INVITE request (UE to P-CSCF) INVITE sip:[email protected] SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:[email protected];lr> P-Preferred-Identity: "John Doe" <sip:[email protected]> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Privacy: none <sip:[email protected]>; tag= <sip:[email protected]> cb0a0s0asdfglkj Cseq: INVITE Require: precondition, sec-agree Proxy-Require: sec-agree Supported: 0rel Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= Contact: <sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::aaa:bbb:ccc:ddd t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos none remote sendrecv rtpmap: H fmtp: profile-level-id=0 rtpmap::mpvmpv-es audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos none remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event Request-URI: contains the conference factory URI.. 0 (Trying) response (P-CSCF to UE) - see example in table A...-
54 X.S00-0 v.0 Conferencing Service; Stage- The P-CSCF responds to the INVITE request () with a 0 (Trying) response provisional response. Table A...-: 0 (Trying) response (P-CSCF to UE) SIP/.0 0 (Trying) response Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds 0. INVITE request (P-CSCF to S-CSCF) - see example in table A...- The P-CSCF forwards the INVITE request to the S-CSCF. Table A...-: INVITE request (P-CSCF to S-CSCF) INVITE sip:[email protected] SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Route: <sip:[email protected];lr> Record-Route: <sip:pcscf.visited.net;lr> P-Asserted-Identity: "John Doe" <sip:[email protected]> P-Access-Network-Info: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00" Privacy: Cseq: Require: precondition Supported: Contact: Allow: Content-Type: ( ) v= o= s= c= t=. 0 (Trying) response (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF responds to the INVITE request () with a 0 (Trying) response provisional response. 0
55 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 0 (Trying) response (S-CSCF to P-CSCF) SIP/.0 0 (Trying) response Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds 0. Evaluation of initial filter criteria The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.. INVITE request (S-CSCF to I-CSCF) - see example in table A...- S-CSCF determines the network where the INVITE request should be forwarded. The S-CSCF resolves the I-CSCF as the next hop for this request. Table A...-: INVITE request (S-CSCF to I-CSCF) INVITE sip:[email protected] SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: "John Doe" <sip:[email protected]>, <tel:+--> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net Privacy: Cseq: Require: Supported: Contact: Content-Type: (...) v= o= s= c= t=
56 X.S00-0 v.0 Conferencing Service; Stage-. 0 (Trying) response (I-CSCF to S-CSCF) - see example in table A...- The I-CSCF responds to the INVITE request () with a 0 (Trying) response provisional response. Table A...-: 0 (Trying) response (I-CSCF to S-CSCF) SIP/.0 0 (Trying) response Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds 0. Public service identity (PSI) location query The I-CSCF resolves the conference-factory URI. In this example the I-CSCF queries HSS to resolve the MRFC/AS PSI to be contacted. The HSS responds with the address of the MRFC/AS. For detailed message flows see []. Table A...-a provides the parameters in the SIP INVITE request, which are sent to the HSS. Table A...-a Cx: User location query procedure (I-CSCF to HSS) Message source & destination I-CSCF to HSS Cx: Information element name Public Service Identity (PSI) Information source in SIP INVITE Request-URI: Description This information element indicates the public user identity Table A...-b provides the parameters sent from the HSS that need to be mapped to SIP INVITE and sent to MRFC/AS. Table A...-b Cx: User location query procedure (HSS to I-CSCF) Message source & destination Cx: Information element name Mapping to SIP header in SIP INVITE HSS to I-CSCF MRFC/AS address IP packet destination address. INVITE request (I-CSCF to MRFC/AS) - see example in table A...- Description This information element indicates the MRFC/AS address which serves the PSI. I-CSCF forwards the INVITE request to the MRFC/AS. The I-CSCF does not add itself to the Record- Route header since it does not need to stay on the signalling path for subsequent requests. 0
57 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: INVITE request (I-CSCF to MRFC/AS) INVITE sip:[email protected] SIP/.0 Via: SIP/.0/UDP icscf.home.net;branch=zhgbkf., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net Privacy: Cseq: Require: Supported: Contact: Content-Type: (...) v= o= s= c= t=. 0 (Trying) response (MRFC/AS to I-CSCF) - see example in table A...- (related to table A...-) The MRFC/AS responds to the INVITE request () with a 0 (Trying) response provisional response. Table A...-: 0 (Trying) response (MRFC/AS to I-CSCF) SIP/.0 0 (Trying) response Via: SIP/.0/UDP icscf.home.net;branch=zhgbkf., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds 0. Allocate conference URI
58 X.S00-0 v.0 Conferencing Service; Stage- MRFC/AS allocates a conference URI, based on local information and information gained from the conference-factory URI, as well as information gained from other elements of the SIP signalling.. H. interaction to create connection MRFC initiates a H. interaction to create an connection point for UE# in MRFP and to determine media capabilities of MRFP.. (Session Progress) response (MRFC/AS to I-CSCF) - see example in table A...- (related to table A...-) The MRFC determines the complete set of codecs that it is capable of supporting for this conference. It determines the intersection with those appearing in the SDP in the INVITE request. The media stream capabilities of the destination are returned along the signalling path, in a (Session Progress) provisional response (to ). Table A...-: (Session Progress) response (MRFC/AS to I-CSCF) SIP/.0 Session Progress Via: SIP/.0/UDP icscf.home.net;branch=zhgbkf., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: "Conference Server" <sip:mrfc.home.net> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; orig-ioi=home.net; term-ioi=home.net P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Privacy: none <sip:[email protected]>; tag= Require: 0rel Contact: <sip:[email protected]>;isfocus Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY RSeq: 0 Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::eee:fff:aaa:bbb t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: H fmtp: profile-level-id=0 rtpmap: MPV-ES audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event 0
59 X.S00-0 v.0 Conferencing Service; Stage- 0 Contact: contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter. P-Charging-Vector: The MRFC/AS inserts the originating IOI parameter received and populates the terminating IOI parameter with its own network. P-Charging-Function-Addresses: The MRFC/AS inserts the P-Charging-Function-Addresses header field to be passed to the I-CSCF.. (Session Progress) response (I-CSCF to S-CSCF) - see example in table A...- The I-CSCF forwards the (Session Progress) response to the P-CSCF. Table A...-: (Session Progress) response (I-CSCF to S-CSCF) SIP/.0 Session Progress Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; orig-ioi=home.net; term-ioi=home.net Privacy: Require: Contact: Allow: RSeq: Content-Type: v= o= s= c= t=. (Session Progress) response (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF forwards the (Session Progress) response to the P-CSCF.
60 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: (Session Progress) response (S-CSCF to P-CSCF) SIP/.0 Session Progress Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; Privacy: Require: Contact: Allow: RSeq: Content-Type: v= o= s= c= t=. Authorize QoS Resources The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens at this stage or after 00 (OK) response of INVITE request () based on operator local policy.. (Session Progress) response (P-CSCF to UE) see example in table A...- The P-CSCF forwards the (Session Progress) response to the originating endpoint. 0
61 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: (Session Progress) response (P-CSCF to UE) SIP/.0 Session Progress Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net:;lr;comp=sigcomp> P-Asserted-Identity: Privacy: P-Media-Authorization: eee00c00 Require: Contact: RSeq: Content-Type: v= o= s= c= t=. PRACK request (UE to P-CSCF) - see example in table A...- The UE determines which media flows should be used for this session, and which codecs should be used for each of those media flows. If there was any change in media flows, or if there was more than one choice of codec for a media flow, then UE includes a new SDP offer in the PRACK request sent to the MRFC/AS. For this example, assume the UE chooses H. as the codec to use for the single video stream. Therefore, UE# sends a new SDP offer in the PRACK request.
62 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: PRACK request (UE to P-CSCF) PRACK SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr> <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj Cseq: PRACK Require: precondition, sec-agree Proxy-Require: sec-agree Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= RAck: 0 INVITE Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::aaa:bbb:ccc:ddd t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event. Resource reservation After determining the final media streams in step #, the UE initiates the reservation procedures for the resources needed for this session. 0. PRACK request (P-CSCF to S-CSCF) see example in table A...-0 The P-CSCF forwards the PRACK request to the S-CSCF. 0
63 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-0: PRACK request (P-CSCF to S-CSCF) PRACK sip:[email protected] SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: P-Access-Network-Info: Route: <sip:scscf.home.net;lr> Cseq: Require: precondition RAck: Content-Type: v= o= s= c= t=. PRACK request (S-CSCF to MRFC/AS) see example in table A...- The S-CSCF resolves the Request-URI and forwards the PRACK request directly to the MRFC/AS.
64 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: PRACK request (S-CSCF to MRFC/AS) PRACK SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Cseq: Require: RAck: Content-Type: v= o= s= c= t=. 00 (OK) response (MRFC/AS to S-CSCF) see example in table A...- (related to table A...- ) The MRFC/AS acknowledges the PRACK request (0) with a 00 (OK) response. 0
65 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (MRFC/AS to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::eee:fff:aaa:bbb t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event. H. interaction to modify connection MRFC initiates a H. interaction to modify the connection established in step # and instructs MRFP to reserve the multimedia processing resources for UE# according to the preceding resource negotiation between the UE# and the MRFC.. 00 (OK) response (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF forwards the 00 (OK) response to the P-CSCF.
66 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. 00 (OK) response (P-CSCF to UE) - see example in table A...- The P-CSCF forwards the 00 (OK) response to the UE. 0
67 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (P-CSCF to UE) SIP/.0 00 OK Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. UPDATE request (UE to P-CSCF) see example in table A...- When the resource reservation is completed, the UE sends the UPDATE request to the MRFC/AS, via the signalling path established by the INVITE request.
68 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: UPDATE request (UE to P-CSCF) UPDATE SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj Cseq: UPDATE Require: sec-agree Proxy-Require: sec-agree Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::aaa:bbb:ccc:ddd t=0 0 video 0 RTP/AVP AS: curr:qos local sendrecv curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local sendrecv curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event. UPDATE request (P-CSCF to S-CSCF) see example in table A...- The P-CSCF forwards the UPDATE request to the S-CSCF. 0 0
69 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: UPDATE request (P-CSCF to S-CSCF) UPDATE sip:[email protected] SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: P-Access-Network-Info: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; ggsn=[::b:c:d:e]; pdp-sig=no; gcid=; auth-token=; flowid= Route: <sip:scscf.home.net;lr> Cseq: Content-Type: v= o= s= c= t=. UPDATE request (S-CSCF to MRFC/AS) - see example in table A...-
70 X.S00-0 v.0 Conferencing Service; Stage- The S-CSCF forwards the UPDATE request to the MRFC/AS. Table A...-: UPDATE request (S-CSCF to MRFC/AS) UPDATE SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Cseq: Content-Type: v= o= s= c= t=. 00 (OK) response (MRFC/ASto S-CSCF) see example in table A...- (related to table A...- ) The MRFC/AS acknowledges the UPDATE request () with a 00 (OK) response. 0
71 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (MRFC/AS to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::eee:fff:aaa:bbb t=0 0 video 0 RTP/AVP AS: curr:qos local sendrecv curr:qos remote sendrecv des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local sendrecv curr:qos remote sendrecv des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event The SDP indicates that the resource reservation was successful both in the local and the remote segment.. H. interaction to modify connection MRFC initiates a H. interaction to connect through the multimedia processing resources for UE# in MRFP.. 00 (OK) response (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF forwards the 00 (OK) response to the P-CSCF.
72 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 (OK) Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. 00 (OK) response (P-CSCF to UE) see example in table A...- The P-CSCF forwards the 00 (OK) response to the UE. 0
73 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (P-CSCF to UE) SIP/.0 00 OK Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. 00 (OK) response (MRFC/AS to I-CSCF) see example in table A...- (related to table A...- ) After the success modification of the session (), the MRFC/AS sends a 00 (OK) response final response to the INVITE request () to the I-CSCF. Table A...-: 00 (OK) response (MRFC/AS to I-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP icscf.home.net;branch=zhgbkf., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> INVITE Contact: <sip:[email protected]>;isfocus Allow-Events: conference 0 Contact: Allow-Events: Contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter. The MRFC/AS indicates support for the "conference" event package. 00 (OK) response (I-CSCF to S-CSCF) see example in table A...- The I-CSCF forwards the 00(OK) response to the S-CSCF
74 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (I-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: Contact: Allow-Events: (OK) response (S-CSCF to P-CSCF) see example in table A...- The S-CSCF sends a 00 (OK) response final response along the signalling path back to the P-CSCF. Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: Contact: Allow-Events:. Approval of QoS commit The P-CSCF approves the commitment of the QoS resources if it was not approved already in step ().. 00 (OK) response (P-CSCF to UE) see example in table A...- The P-CSCF forwards the 00 (OK) response final response to the session originator.the UE can start the media flow(s) for this session. Table A...-: 00 (OK) response (P-CSCF to UE) SIP/.0 00 OK Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net:;lr;comp=sigcomp> Contact: Allow-Events:. ACK request (UE to P-CSCF) see example in table A...- The UE starts the media flow for this session, and responds to the 00 (OK) response () with an ACK request sent to the P-CSCF. 0
75 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: ACK request (UE to P-CSCF) ACK sip:[email protected] SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr> <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj Cseq: ACK 0. ACK request (P-CSCF to S-CSCF) see example in table A...- The P-CSCF forwards the ACK request to the S-CSCF. Table A...-: ACK request (P-CSCF to S-CSCF) ACK sip:[email protected] SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Route: <sip:scscf.home.net;lr> Cseq:. ACK request (S-CSCF to MRFC/AS) - see example in table A...- A.. A.. The S-CSCF forwards the ACK request to the MRFC/AS. Table A...-: ACK request (S-CSCF to MRFC/AS) ACK sip:[email protected] SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Cseq: User automatically creating a conference with a conference URI The call flows for a user automatically creating a conference with a conference URI look identical to the call flows for conference creation with a conference-factory URI (see subclause A..), besides the URIs carried in the Request-URI and Contact header fields. User creating a conference by manually dialling The call flows for a user creating a conference by manually dialling into the IMS look identical to the call flows for conference creation with a conference-factory URI (see subclause A..), besides the URIs carried in the Request-URI and Contact header fields.
76 X.S00-0 v.0 Conferencing Service; Stage- A.. User creating a conference from two existing connections (Three-way session), users in different networks Subclause... of this specification shows that the creation of a Three-way session is a local issue at the UE which results in a combination of other procedures (conference creation, conference participant invitation to conference, session release). 0
77 X.S00-0 v.0 Conferencing Service; Stage- 0 A. Flows demonstrating a user joining a conference A.. A.. A... A... Introduction User calling into a conference MRFC/AS is not located in user's home network Conference URI resolved by the terminating home network Visited Network UE# P-CSCF S-CSCF I-CSCF HSS MRFC/AS MRFP. Resource Reservation. INVITE. 0 Trying. INVITE. 0 Trying. Session Progress. Authorize QoS resources. Session Progress. PRACK. 00 OK. UPDATE. 00 OK. 00 OK. ACK. PRACK. 00 OK. UPDATE. 00 OK. 00 OK. Approval of QoS Commit. ACK UE# Home Network. Evaluation of initial Filter Criteria. INVITE. 0 Trying. Session Progress 0. PRACK. 00 OK. UPDATE. 00 OK. 00 OK. ACK. PSI location query MRFC/AS Home Network. INVITE. 0 Trying. Session Progress. PRACK. 00 OK. UPDATE. 00 OK. 00 OK. H. interaction to create conference connection resources for UE#. H. interaction to modify conference connection resources for UE#. H. interaction to connect through conference connection resources for UE# Figure A...-: User calling into a conference network MRFC/AS is not located in user s home network conference URI resolved by the terminating home network. ACK
78 X.S00-0 v.0 Conferencing Service; Stage- Figure A...- shows an user calling into a conference by using a conference URI. The focus of that conference is at a MRFC/AS which are located in another network. The conference URI in this example cannot be resolved by the originating home network. The details of the flows are as follows:. INVITE request (UE to P-CSCF) - see example in table A...- A UE wants to join a conference. For this purpose the UE is aware of the related conference URI that was obtained by means outside this specification (e.g. via other protocols, such as http) The UE determines the complete set of codecs that it is capable of supporting for this conference. It builds a SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for each possible media flow. Multiple media flows may be offered, and for each media flow ( line in SDP), there may be multiple codec choices offered. For this example, it is assumed that UE# is willing to establish a multimedia session comprising a video stream and an audio stream. The video stream supports two codecs, either H. or MPEG- Visual. The audio stream supports the EVRC codec capable of sending two simultaneous video streams, either H or The UE sends the INVITE request to the P-CSCF. 0 0
79 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: INVITE request (UE to P-CSCF) INVITE sip:[email protected] SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:[email protected];lr> P-Preferred-Identity: "John Doe" <sip:[email protected]> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Privacy: none <sip:[email protected]>; tag= <sip:[email protected]> cb0a0s0asdfglkj Cseq: INVITE Require: precondition, sec-agree Proxy-Require: sec-agree Supported: 0rel Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= Contact: <sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::aaa:bbb:ccc:ddd t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos none remote sendrecv rtpmap: H fmtp: profile-level-id=0 rtpmap::mpvmpv-es audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos none remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event Request-URI: contains the conference URI.. 0 (Trying) response (P-CSCF to UE) - see example in table A...- The P-CSCF responds to the INVITE request () with a 0 (Trying) response provisional response. Table A...-: 0 (Trying) response (P-CSCF to UE) SIP/.0 0 (Trying) response Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds 0. INVITE request (P-CSCF to S-CSCF) - see example in table A...- The P-CSCF forwards the INVITE request to the S-CSCF.
80 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: INVITE request (P-CSCF to S-CSCF) INVITE SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Route: Record-Route: <sip:pcscf.visited.net;lr> P-Asserted-Identity: "John Doe" P-Access-Network-Info: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00" Privacy: Cseq: Require: precondition Supported: Contact: Allow: Content-Type: ( ) v= o= s= c= t=. 0 (Trying) response (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF responds to the INVITE request () with a 0 (Trying) response provisional response. Table A...-: 0 (Trying) response (S-CSCF to P-CSCF) SIP/.0 0 (Trying) response Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds 0. Evaluation of initial filter criteria The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 0
81 X.S00-0 v.0 Conferencing Service; Stage- 0. INVITE request (S-CSCF to I-CSCF) - see example in table A...- The S-CSCF performs an analysis of the destination address, and determines the network operator to whom the destination subscriber belongs. Since the originating operator does not desire to keep their internal configuration hidden, the S-CSCF forwards the INVITE request directly to the the I-CSCF in the destination network. As the S-CSCF does not know whether the I-CSCF at home.net is a loose router or not, it does not introduce a Route header. Table A...-: INVITE request (S-CSCF to I-CSCF) INVITE sip:[email protected] SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: "John Doe" <sip:[email protected]>, <tel:+--> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net Privacy: Cseq: Require: Supported: Contact: Content-Type: (...) v= o= s= c= t=. 0 (Trying) response (I-CSCF to S-CSCF) - see example in table A...- (related to table A...- ) The I-CSCF responds to the INVITE request () with a 0 (Trying) response provisional response.
82 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 0 (Trying) response (MRFC/AS to S-CSCF) SIP/.0 0 (Trying) response Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds 0. Public service identity (PSI) location query The I-CSCF sends a query to the HSS to find out the MRFC/AS at which the conference has been created. The HSS responds with the address of the MRFC/AS at which the conference is hosted. The HSS responds with the address of the MRFC/AS. For detailed message flows see []. Table A...-a provides the parameters in the SIP INVITE request, which are sent to the HSS. Table A...-a Cx: User location query procedure (I-CSCF to HSS) Message source & destination I-CSCF to HSS Cx: Information element name Public Service Identity (PSI) Information source in SIP INVITE Request-URI: Description This information element indicates the public user identity Table A...-b provides the parameters sent from the HSS that need to be mapped to SIP INVITE and sent to MRFC/AS. Table A...-b Cx: User location query procedure (HSS to I-CSCF) Message source & destination Cx: Information element name Mapping to SIP header in SIP INVITE HSS to I-CSCF MRFC/AS address IP packet destination address. INVITE request (I-CSCF to MRFC/AS) - see example in table A...- Description This information element indicates the MRFC/AS address which serves the PSI. I-CSCF forwards the INVITE request to the MRFC/AS that was resolved during the PSI location query (). The I-CSCF does not re-write the Request-URI. 0
83 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: INVITE request (I-CSCF to MRFC/AS) INVITE sip:[email protected] SIP/.0 Via: SIP/.0/UDP icscf_s.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net Privacy: Cseq: Require: Supported: Contact: Content-Type: (...) v= o= s= c= t=. 0 (Trying) response (MRFC/AS to I-CSCF) - see example in table A...- (related to table A...-) The MRFC/AS responds to the INVITE request () with a 0 (Trying) response provisional response. Table A...-: 0 (Trying) response (MRFC/AS to I-CSCF) SIP/.0 0 (Trying) response Via: SIP/.0/UDP icscf_s.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds 0. H. interaction to create conference connection resources for UE#
84 X.S00-0 v.0 Conferencing Service; Stage- MRFC initiates a H. interaction to create an connection point for UE# in MRFP.. (Session Progress) response (MRFC/AS to I-CSCF) - see example in table A...- (related to table A...-) The media stream capabilities of the conference are returned along the signalling path, in a (Session Progress) provisional response (to ). Table A...-: (Session Progress) response (MRFC/AS to I-CSCF) SIP/.0 Session Progress Via: SIP/.0/UDP icscf_s.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: "Conference Server" <sip:mrfc.home.net> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net; term-ioi=home.net P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Privacy: none <sip:[email protected]>; tag= Require: 0rel Contact: <sip:[email protected]>;isfocus Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY RSeq: 0 Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::eee:fff:aaa:bbb t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: H fmtp: profile-level-id=0 rtpmap: MPV-ES audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event Contact: contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter. P-Charging-Vector: The MRFC/AS inserts this header and populates the icid parameters with an unique value and the terminating Inter Operator Identifier (IOI) for the home network of the MRFC/AS and puts back the originating IOI. 0
85 X.S00-0 v.0 Conferencing Service; Stage- 0 P-Charging-Function-Addresses: The MRFC/AS populates the P-Charging-Function-Addresses header field to be passed to the I-CSCF.. (Session Progress) response (I-CSCF to S-CSCF) - see example in table A...- The I-CSCF forwards the (Session Progress) response to the S-CSCF. Table A...-: (Session Progress) response (I-CSCF to S-CSCF) SIP/.0 Session Progress Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net; term-ioi=home.net Privacy: Require: Contact: Allow: RSeq: Content-Type: v= o= s= c= t=. (Session Progress) response (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF forwards the (Session Progress) response to the P-CSCF.
86 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: (Session Progress) response (S-CSCF to P-CSCF) SIP/.0 Session Progress Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00" P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Privacy: Require: Contact: Allow: RSeq: Content-Type: v= o= s= c= t=. Authorize QoS Resources The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens at this stage or after 00 (OK) response of INVITE request () based on operator local policy.. (Session Progress) response (P-CSCF to UE) see example in table A...- The P-CSCF forwards the (Session Progress) response to the originating endpoint. 0
87 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: (Session Progress) response (P-CSCF to UE) SIP/.0 Session Progress Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net:;lr;comp=sigcomp> P-Asserted-Identity: Privacy: P-Media-Authorization: eee00c00 Require: Contact: RSeq: Content-Type: v= o= s= c= t=. PRACK request (UE to P-CSCF) - see example in table A...- The UE determines which media flows should be used for this session, and which codecs should be used for each of those media flows. If there was any change in media flows, or if there was more than one choice of codec for a media flow, then UE includes a new SDP offer in the PRACK request sent to the MRFC/AS. For this example, assume the UE chooses H. as the codec to use for the single video stream. Therefore, UE# sends a new SDP offer in the PRACK request.
88 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: PRACK request (UE to P-CSCF) PRACK SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr> <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj Cseq: PRACK Require: precondition, sec-agree Proxy-Require: sec-agree Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= RAck: 0 INVITE Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::aaa:bbb:ccc:ddd t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event Request-URI:. Resource reservation takes the value of the Contact header of the received (Session Progress) response. After determining the final media streams in step #, the UE initiates the reservation procedures for the resources needed for this session.. PRACK request (P-CSCF to S-CSCF) see example in table A...- The P-CSCF forwards the PRACK request to the S-CSCF. 0 0
89 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: PRACK request (P-CSCF to S-CSCF) PRACK sip:[email protected] SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: P-Access-Network-Info: Route: <sip:scscf.home.net;lr> Cseq: Require: precondition RAck: Content-Type: v= o= s= c= t= 0. PRACK request (S-CSCF to I-CSCF) see example in table A...-0 The S-CSCF performs an analysis of the destination address, and determines the network operator to whom the destination subscriber belongs. Since the originating operator does not desire to keep their internal configuration hidden, the S-CSCF forwards the PRACK request directly to the I-CSCF in the destination network. As the S-CSCF does not know whether the I-CSCF at home.net is a loose router or not, it does not introduce a Route header.
90 X.S00-0 v.0 Conferencing Service; Stage- Table A...-0: PRACK request (S-CSCF to I-CSCF) PRACK SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Cseq: Require: RAck: Content-Type: v= o= s= c= t=. PRACK request (I-CSCF to MRFC/AS) see example in table A...- I-CSCF forwards the PRACK request to the MRFC/AS that was resolved during the PSI location query (). 0
91 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: PRACK request (I-CSCF to MRFC/AS) PRACK sip:[email protected] SIP/.0 Via: SIP/.0/UDP icscf_s.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Cseq: Require: RAck: Content-Type: v= o= s= c= t=. 00 (OK) response (MRFC/AS to I-CSCF) see example in table A...- (related to table A...-) The MRFC/AS acknowledges the PRACK request () with a 00 (OK) response.
92 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (MRFC/AS to I-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP icscf_s.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::eee:fff:aaa:bbb t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event. H. interaction to modify connection for UE# MRFC initiates a H. interaction to modify the connection established in step # and instructs MRFP to reserve the multimedia processing resources for UE# according to the preceding resource negotiation between the UE# and the MRFC.. 00 (OK) response (I-CSCF to S-CSCF) - see example in table A...- The I-CSCF forwards the 00 (OK) response to the S-CSCF. 0
93 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (I-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP icscf_s.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. 00 (OK) response (S-CSCF to P-CSCF) - see example in table A...- S-CSCF forwards the 00 (OK) response to the P-CSCF.
94 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. 00 (OK) response (P-CSCF to UE) - see example in table A...- The P-CSCF forwards the 00 (OK) response to the UE. 0
95 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (P-CSCF to UE) SIP/.0 00 OK Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. UPDATE request (UE to P-CSCF) see example in table A...- When the resource reservation is completed, the UE sends the UPDATE request to the MRFC/AS, via the signalling path established by the INVITE request.
96 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: UPDATE request (UE to P-CSCF) UPDATE SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj Cseq: UPDATE Require: sec-agree Proxy-Require: sec-agree Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::aaa:bbb:ccc:ddd t=0 0 video 0 RTP/AVP AS: curr:qos local sendrecv curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local sendrecv curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event Request-URI: takes the value of the Contact header of the received (Session Progress) response.. UPDATE request (P-CSCF to S-CSCF) see example in table A...- The P-CSCF forwards the UPDATE request to the S-CSCF. 0
97 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: UPDATE request (P-CSCF to S-CSCF) UPDATE sip:[email protected] SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: P-Access-Network-Info: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; ggsn=[::b:c:d:e]; pdp-sig=no; gcid=; auth-token=; flowid= Route: <sip:scscf.home.net;lr> Cseq: Content-Type: v= o= s= c= t=. UPDATE request (S-CSCF to I-CSCF) - see example in table A...- The S-CSCF performs an analysis of the destination address, and determines the network operator to whom the destination subscriber belongs. Since the originating operator does not desire to keep their internal configuration hidden, the S-CSCF forwards the UPDATE request directly to the I-CSCF in the destination network. As the S-CSCF does not know whether the I-CSCF at home.net is a loose router or not, it does not introduce a Route header.
98 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: UPDATE request (S-CSCF to I-CSCF) UPDATE SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Cseq: Content-Type: v= o= s= c= t=. UPDATE request (I-CSCF to MRFC/AS) - see example in table A...- I-CSCF forwards the UPDATE request to the MRFC/AS that was resolved during the PSI location query (). The I-CSCF does not re-write the Request-URI. 0 0
99 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: UPDATE request (I-CSCF to MRFC/AS) UPDATE sip:[email protected] SIP/.0 Via: SIP/.0/UDP icscf_s.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Cseq: Content-Type: v= o= s= c= t=. 00 (OK) response (MRFC/AS to I-CSCF) see example in table A...- (related to table A...-) The MRFC/AS acknowledges the UPDATE request () with a 00 (OK) response.
100 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (MRFC/AS to I-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP icscf_s.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::eee:fff:aaa:bbb t=0 0 video 0 RTP/AVP AS: curr:qos local sendrecv curr:qos remote sendrecv des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local sendrecv curr:qos remote sendrecv des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event The SDP indicates that the resource reservation was successful both in the local and the remote segment.. H. interaction to modify connection MRFC initiates a H. interaction to connect through the multimedia processing resources for UE# in MRFP.. 00 (OK) response (I-CSCF to S-CSCF) see example in table A...- The I-CSCF forwards the 00 (OK) response to the S-CSCF. 0
101 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (I-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: application/sdp ( ) v= o= s= c= t=. 00 (OK) response (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF forwards the 00 (OK) response to the P-CSCF.
102 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. 00 (OK) response (P-CSCF to UE) see example in table A...- The P-CSCF forwards the 00 (OK) response to the UE. 0
103 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (P-CSCF to UE) SIP/.0 00 OK Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. 00 (OK) response (MRFC/AS to I-CSCF) see example in table A...- (related to table A...-) After the success modification of the session (), the MRFC/AS sends a 00 (OK) response final response to the INVITE request () to the I-CSCF. Table A...-: 00 (OK) response (MRFC/AS to I-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP icscf_s.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> INVITE Contact: <sip:[email protected]>;isfocus Allow-Events: conference 0 Contact: Allow-Events: Contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter. The MRFC/AS indicates support for the "conference" event package. 00 (OK) response (I-CSCF to S-CSCF) see example in table A...- The I-CSCF sends a 00 (OK) response final response along the signalling path back to the S-CSCF.
104 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (I-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: Contact: Allow-Events:. 00 (OK) response (S-CSCF to P-CSCF) see example in table A...- The S-CSCF sends a 00 (OK) response final response along the signalling path back to the P-CSCF. Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: Contact: Allow-Events:. Approval of QoS commit The P-CSCF approves the commitment of the QoS resources if it was not approved already in step ().. 00 (OK) response (P-CSCF to UE) see example in table A...- The P-CSCF forwards the 00 (OK) response final response to the session originator.the UE can start the media flow(s) for this session. Table A...-: 00 (OK) response (P-CSCF to UE) SIP/.0 00 OK Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net:;lr;comp=sigcomp> Contact: Allow-Events:. ACK request (UE to P-CSCF) see example in table A...- The UE starts the media flow for this session, and responds to the 00( OK) response () with an ACK request sent to the P-CSCF. 0
105 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: ACK request (UE to P-CSCF) ACK sip:[email protected]: SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr> <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj Cseq: ACK 0. ACK request (P-CSCF to S-CSCF) see example in table A...- The P-CSCF forwards the ACK request to the S-CSCF. Table A...-: ACK request (P-CSCF to S-CSCF) ACK sip:[email protected]: SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Route: <sip:scscf.home.net;lr> Cseq:. ACK request (S-CSCF to I-CSCF) - see example in table A...- The S-CSCF performs an analysis of the destination address, and determines the network operator to whom the destination subscriber belongs. Since the originating operator does not desire to keep their internal configuration hidden, the S-CSCF forwards the ACK request directly to the I-CSCF in the destination network. As the S-CSCF does not know whether the I-CSCF at home.net is a loose router or not, it does not introduce a Route header. Table A...-: ACK request (S-CSCF to I-CSCF) ACK sip:[email protected]: SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Cseq:. ACK request (I-CSCF to MRFC/AS) - see example in table A...- I-CSCF forwards the ACK request to the MRFC/AS that was resolved during the PSI location query (). The I-CSCF does not re-write the Request-URI.
106 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: ACK request (I-CSCF to MRFC/AS) ACK SIP/.0 Via: SIP/.0/UDP icscf_s.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Cseq: 0
107 X.S00-0 v.0 Conferencing Service; Stage- 0 A... Conference URI can be resolved by the originating home network UE#. Resource Reservation Visited Network. INVITE. 0 Trying P-CSCF. INVITE. 0 Trying. Session Progress. Authorize QoS resources. Session Progress. PRACK OK. UPDATE. 00 OK. 00 OK. ACK. PRACK. 00 OK. UPDATE. 00 OK. 00 OK. Approval of QoS Commit. ACK UE# Home Network S-CSCF. Evaluation of initial Filter Criteria. INVITE. 0 Trying. Session Progress. PRACK. 00 OK. UPDATE. 00 OK. 00 OK. ACK MRFC/AS Home Network MRFC/AS MRFP. H. interaction to create conference connection resources for UE#. H. interaction to modify conference connection resources for UE#. H. interaction to connect through conference connection resources for UE# Figure A...-: User calling into a conference MRFC/AS is not located in user's home network conference URI can be resolved by the originating home network
108 X.S00-0 v.0 Conferencing Service; Stage- Figure A...- shows an user calling into a conference by using a conference URI. The focus of that conference is at a MRFC/AS which are located in another network. The conference URI in this example can be resolved by the originating home network. The details of the flows are as follows:. INVITE request (UE to P-CSCF) - see example in table A...- A UE wants to join a conference. For this purpose the UE is aware of the related conference URI that was obtained by means outside this specification. The UE determines the complete set of codecs that it is capable of supporting for this conference. It builds a SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for each possible media flow. Multiple media flows may be offered, and for each media flow ( line in SDP), there may be multiple codec choices offered. For this example, it is assumed that UE# is willing to establish a multimedia session comprising a video stream and an audio stream. The video stream supports two codecs, either H. or MPEG- Visual. The audio stream supports the EVRC codec. 0 0
109 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: INVITE request (UE to P-CSCF) INVITE sip:[email protected] SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:[email protected];lr> P-Preferred-Identity: "John Doe" <sip:[email protected]> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Privacy: none <sip:[email protected]>; tag= <sip:[email protected]> cb0a0s0asdfglkj Cseq: INVITE Require: precondition, sec-agree Proxy-Require: sec-agree Supported: 0rel Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= Contact: <sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::aaa:bbb:ccc:ddd t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos none remote sendrecv rtpmap: H fmtp: profile-level-id=0 rtpmap::mpv-es audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos none remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event Request-URI: contains the conference URI.. 0 (Trying) response (P-CSCF to UE) - see example in table A...- The P-CSCF responds to the INVITE request () with a 0 (Trying) response provisional response. Table A...-: 0 (Trying) response (P-CSCF to UE) SIP/.0 0 (Trying) response Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds 0. INVITE request (P-CSCF to S-CSCF) - see example in table A...- The INVITE request is forwarded to the S-CSCF.
110 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: INVITE request (P-CSCF to S-CSCF) INVITE SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Route: Record-Route: <sip:pcscf.visited.net;lr> P-Asserted-Identity: "John Doe" P-Access-Network-Info: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00" Privacy: Cseq: Require: precondition Supported: Contact: Allow: Content-Type: ( ) v= o= s= c= t=. 0 (Trying) response (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF responds to the INVITE request () with a 0 (Trying) response provisional response. Table A...-: 0 (Trying) response (S-CSCF to P-CSCF) SIP/.0 0 (Trying) response Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds 0. Evaluation of initial filter criteria The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 0
111 X.S00-0 v.0 Conferencing Service; Stage- 0. INVITE request (S-CSCF to MRFC/AS) - see example in table A...- S-CSCF forwards the INVITE request to the MRFC/AS based on the Request-URI of the INVITE request. The S-CSCF does not re-write the Request-URI. Table A...-: INVITE request (S-CSCF to MRFC/AS) INVITE sip:[email protected] SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: "John Doe" <sip:[email protected]>, <tel:+--> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Privacy: Cseq: Require: Supported: Contact: Content-Type: (...) v= o= s= c= t=. 0 (Trying) response (MRFC/AS to S-CSCF) - see example in table A...- (related to table A...-) The MRFC/AS responds to the INVITE request () with a 0 (Trying) response provisional response.
112 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 0 (Trying) response (MRFC/AS to S-CSCF) SIP/.0 0 (Trying) response Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds 0. H. interaction to create conference connection resources for UE# MRFC initiates a H. interaction to create an connection point for UE# in MRFP.. (Session Progress) response (MRFC/AS to S-CSCF) - see example in table A...- (related to table A...-) The media stream capabilities of the conference are returned along the signalling path, in a (Session Progress) provisional response (to ). 0
113 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: (Session Progress) response (MRFC/AS to S-CSCF) SIP/.0 Session Progress Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: "Conference Server" <sip:mrfc.home.net> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net; term-ioi=home.net P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Privacy: none <sip:[email protected]>; tag= Require: 0rel Contact: <sip:[email protected]>;isfocus Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY RSeq: 0 Content-Type: application/sdp ( ) v=0 o=- IN IP ::::: s=c=in IP ::::: t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: H fmtp: profile-level-id=0 rtpmap: MPV-ES audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event Contact: contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter. P-Charging-Vector: The MRFC/AS inserts this header and populates the icid parameters with an unique value and the terminating Inter Operator Identifier (IOI) for the home network of the MRFC/AS and puts back the originating IOI. P-Charging-Function-Addresses: The MRFC/AS populates the P-Charging-Function-Addresses header field to be passed to the S-CSCF.. (Session Progress) response (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF forwards the (Session Progress) response to the P-CSCF.
114 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: (Session Progress) response (S-CSCF to P-CSCF) SIP/.0 Session Progress Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00" P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Privacy: Require: Contact: Allow: RSeq: Content-Type: v= o= s= c= t=. Authorize QoS Resources The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens at this stage or after 00( OK) response to the INVITE request () based on operator local policy.. (Session Progress) response (P-CSCF to UE) see example in table A...- The P-CSCF forwards the (Session Progress) response to the originating endpoint. 0
115 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: (Session Progress) response (P-CSCF to UE) SIP/.0 Session Progress Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net:;lr;comp=sigcomp> P-Asserted-Identity: Privacy: P-Media-Authorization: eee00c00 Require: Contact: RSeq: Content-Type: v= o= s= c= t=. PRACK request (UE to P-CSCF) - see example in table A...- The UE determines which media flows should be used for this session, and which codecs should be used for each of those media flows. If there was any change in media flows, or if there was more than one choice of codec for a media flow, then UE includes a new SDP offer in the PRACK request sent to the MRFC/AS. For this example, assume the UE chooses H. as the codec to use for the single video stream. Therefore, UE# sends a new SDP offer in the PRACK request.
116 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: PRACK request (UE to P-CSCF) PRACK SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr> <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj Cseq: PRACK Require: precondition, sec-agree Proxy-Require: sec-agree Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= RAck: 0 INVITE Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::aaa:bbb:ccc:ddd t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event Request-URI:. Resource reservation takes the value of the Contact header of the received (Session Progress) response. After determining the final media streams in step #, the UE initiates the reservation procedures for the resources needed for this session.. PRACK request (P-CSCF to S-CSCF) see example in table A...- The P-CSCF forwards the PRACK request to the S-CSCF. 0
117 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: PRACK request (P-CSCF to S-CSCF) PRACK sip:[email protected] SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: P-Access-Network-Info: Route: <sip:scscf.home.net;lr> Cseq: Require: precondition RAck: Content-Type: v= o= s= c= t=. PRACK request (S-CSCF to MRFC/AS) see example in table A...- S-CSCF forwards the PRACK request to the MRFC/AS based on the Request-URI of the PRACK request. The S-CSCF does not re-write the Request-URI.
118 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: PRACK request (S-CSCF to MRFC/AS) PRACK SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Cseq: Require: RAck: Content-Type: v= o= s= c= t=. 00 (OK) response (MRFC/AS to S-CSCF) see example in table A...- (related to table A...-) The MRFC/AS acknowledges the PRACK request () with a 00 (OK) response. 0
119 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (MRFC/AS to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::eee:fff:aaa:bbb t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event. H. interaction to modify connection for UE# MRFC initiates a H. interaction to modify the connection established in step # and instructs MRFP to reserve the multimedia processing resources for UE# according to the preceding resource negotiation between the UE# and the MRFC.. 00 (OK) response (S-CSCF to P-CSCF) - see example in table A...- S-CSCF forwards the 00 (OK) response to the P-CSCF.
120 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t= (OK) response (P-CSCF to UE) - see example in table A...-0 The P-CSCF forwards the 00 (OK) response to the UE. 0
121 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-0: 00 (OK) response (P-CSCF to UE) SIP/.0 00 OK Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. UPDATE request (UE to P-CSCF) see example in table A...- When the resource reservation is completed, the UE sends the UPDATE request to the MRFC/AS, via the signalling path established by the INVITE request.
122 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: UPDATE request (UE to P-CSCF) UPDATE SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj Cseq: UPDATE Require: sec-agree Proxy-Require: sec-agree Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::aaa:bbb:ccc:ddd t=0 0 video 0 RTP/AVP AS: curr:qos local sendrecv curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local sendrecv curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event Request-URI: takes the value of the Contact header of the received (Session Progress) response.. UPDATE request (P-CSCF to S-CSCF) see example in table A...- The P-CSCF forwards the UPDATE request to the S-CSCF. 0
123 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: UPDATE request (P-CSCF to S-CSCF) UPDATE sip:[email protected] SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: P-Access-Network-Info: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; ggsn=[::b:c:d:e]; pdp-sig=no; gcid=; auth-token=; flowid= Route: <sip:scscf.home.net;lr> Cseq: Content-Type: v= o= s= c= t=. UPDATE request (S-CSCF to MRFC/AS) - see example in table A...- S-CSCF forwards the UPDATE request to the MRFC/AS based on the Request-URI of the UPDATE request. The S-CSCF does not re-write the Request-URI.
124 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: UPDATE request (S-CSCF to MRFC/AS) UPDATE SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Cseq: Content-Type: v= o= s= c= t=. 00 (OK) response (MRFC/AS to S-CSCF) see example in table A...- (related to table A...-) The MRFC/AS acknowledges the UPDATE request () with a 00 (OK) response. 0
125 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (MRFC/AS to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: application/sdp ( ) v=0 o=- IN IP ::aaa:bbb:ccc:ddd s=c=in IP ::eee:fff:aaa:bbb t=0 0 video 0 RTP/AVP AS: curr:qos local sendrecv curr:qos remote sendrecv des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local sendrecv curr:qos remote sendrecv des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event The SDP indicates that the resource reservation was successful both in the local and the remote segment.. H. interaction to modify connection MRFC initiates a H. interaction to connect through the multimedia processing resources for UE# in MRFP.. 00 (OK) response (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF forwards the 00 (OK) response to the P-CSCF.
126 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. 00 (OK) response (P-CSCF to UE) see example in table A...- The P-CSCF forwards the 00 (OK) response to the UE. 0
127 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (P-CSCF to UE) SIP/.0 00 OK Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Content-Type: v= o= s= c= t=. 00 (OK) response (MRFC/AS to S-CSCF) see example in table A...- (related to table A...-) After the success modification of the session (), the MRFC/AS sends a 00 (OK) response final response to the INVITE request () to the I-CSCF. Table A...-: 00 (OK) response (MRFC/AS to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> INVITE Contact: <sip:[email protected]>;isfocus Allow-Events: conference 0 Contact: Allow-Events: Contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter. The MRFC/AS indicates support for the "conference" event package. 00 (OK) response (S-CSCF to P-CSCF) see example in table A...- The S-CSCF sends a 00 (OK) response final response along the signalling path back to the P-CSCF.
128 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: Contact: Allow-Events:. Approval of QoS commit The P-CSCF approves the commitment of the QoS resources if it was not approved already in step ().. 00 (OK) response (P-CSCF to UE) see example in table A...- The P-CSCF forwards the 00 (OK) response final response to the session originator.the UE can start the media flow(s) for this session. Table A...-: 00 (OK) response (P-CSCF to UE) SIP/.0 00 OK Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net:;lr;comp=sigcomp> Contact: Allow-Events:. ACK request (UE to P-CSCF) see example in table A...- The UE starts the media flow for this session, and responds to the 00 (OK) response () with an ACK request sent to the P-CSCF. Table A...-: ACK request (UE to P-CSCF) ACK SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr> <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj Cseq: ACK 0 Cseq: is required to be the same value as Cseq contained in original INVITE request ().. ACK request (P-CSCF to S-CSCF) see example in table A...- The P-CSCF forwards the ACK request to the S-CSCF. 0 0
129 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: ACK request (P-CSCF to S-CSCF) ACK sip:[email protected]: SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Route: <sip:scscf.home.net;lr> Cseq:. ACK request (S-CSCF to MRFC/AS) - see example in table A...- A.. A... A... S-CSCF forwards the ACK request to the MRFC/AS based on the Request-URI of the ACK request. The S-CSCF does not re-write the Request-URI. Table A...-: ACK request (S-CSCF to MRFC/AS) ACK sip:[email protected]: SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Cseq: User getting invited to a conference MRFC/AS is not located in user's home network Conference Participant referring another user to a conference Figure A...- shows how UE# refers UE# to a conference. UE# has created a conference by using the mechanisms described in subclause., and UE# has learned the conference URI that identifies this conference.
130 X.S00-0 v.0 Conferencing Service; Stage- Visited Network UE# Home Network UE# Home Network UE#. REFER. 0 Accepted. NOTIFY. 00 OK 0. NOTIFY. 00 OK P-CSCF#. REFER S-CSCF#. UE# creates a conference. 0 Accepted. NOTIFY. 00 OK. NOTIFY. 00 OK. Evaluation of initial Filter Criteria MRFC/AS. REFER. 0 Accepted. UE# joins the conference. NOTIFY. 00 OK. NOTIFY. 00 OK I-CSCF#. REFER. 0 Accepted Figure A...-: User inviting another user to a conference by sending a REFER request to the other user The details of the flows are as follows:. UE# creates a conference UE# creates a conference as described in subclause... Once the conference creation is accomplished, UE# has learned the conference URI allocated for this conference.. REFER request (UE to P-CSCF) - see example in table A...- 0
131 X.S00-0 v.0 Conferencing Service; Stage- 0 A UE has created a conference and learned the conference URI. Now the UE wants to invite another UE to that conference. Table A...-: REFER request (UE to P-CSCF) REFER sip:[email protected] SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:[email protected];lr> P-Preferred-Identity: "John Doe" <sip:[email protected]> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Privacy: none <sip:[email protected]>; tag= <sip:[email protected]> cb0a0s0asdfglkj Cseq: REFER Require: sec-agree Refer- <sip:[email protected];method=invite> Referred-By: <sip:[email protected]> Proxy-Require: sec-agree Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= Contact: <sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp> 0 Request-URI: Via: Refer- Referred-By: contains the public user identity of UE#. contains the IP address or FQDN of the originating UE. contains the conference URI as learned during the conference establishment. Additionally the "method" uri parameter indicates that the other user is requested to send an INVITE request to this conference URI. contains the public user identity of the referring user, as in this example the referring user has decided to indicate its own identity to the referred user.. REFER request (P-CSCF to S-CSCF) - see example in table A...- The P-CSCF forwards the REFER request to the S-CSCF. Table A...-: REFER request (P-CSCF to S-CSCF) REFER sip:[email protected] SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Route: <sip:[email protected];lr> Record-Route: <sip:pcscf.visited.net;lr> P-Asserted-Identity: "John Doe" <sip:[email protected]> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" P-Access-Network-Info: Privacy: Cseq: Refer- Referred-By: Contact:. Evaluation of initial Filter Criteria The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.
132 X.S00-0 v.0 Conferencing Service; Stage-. REFER request (S-CSCF to I-CSCF in UE# home network) - see example in table A...- The S-CSCF performs an analysis of the destination address, and determines the network operator to whom the destination subscriber belongs. Since the originating operator does not desire to keep their internal configuration hidden, the S-CSCF forwards the REFER request directly to the destination network. Table A...-: REFER request (S-CSCF to I-CSCF) REFER sip:[email protected] SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: "John Doe" <sip:[email protected]>, <tel:+--> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; origioi=home.net Privacy: Cseq: Refer- Referred-By: Contact:. REFER request (I-CSCF towards S-CSCF of UE#) - see example in table A...- The I-CSCF performs a Cx location query to the HSS (not shown in this flow) to find out the S-CSCF of UE#. The I-CSCF then forwards the REFER request to that S-CSCF that will handle the session termination. Table A...-: REFER request (I-CSCF towards S-CSCF of UE#) REFER sip:[email protected] SIP/.0 Via: SIP/.0/UDP icscf.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Route: <sip:scscf.home.net;lr> Record-Route: P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; origioi=home.net Privacy: Cseq: Refer- Referred-By: Contact:. 0 (Accepted) response (S-CSCF of UE# to I-CSCF) - see example in table A...- UE# home network indicates that it has received the REFER request by sending a 0 (Accepted) response. This means that UE# home network has begun to process the request. This does not mean, however, that the referred-to resource would have been contacted. 0
133 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 0 (Accepted) response (S-CSCF of UE# to I-CSCF) SIP/.0 0 Accepted Via: SIP/.0/UDP icscf.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:pcscf.visited.net;lr>, <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: "John Smith" <sip:[email protected]>, <tel:+---> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; icid-generatedat=[::ff:ee:dd:cc]; orig-ioi=home.net; term-ioi=home.net P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Privacy:none <sip:[email protected]>;tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj REFER Contact: <sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp> 0. 0 (Accepted) response (I-CSCF to S-CSCF) - see example in table A...- The I-CSCF forwards the response to the S-CSCF. Table A...-: 0 (Accepted) response (I-CSCF to S-CSCF) SIP/.0 0 Accepted Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0";; origioi=home.net; term-ioi=home.net Privacy: Contact:. 0 (Accepted) response (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF forwards the response to the P-CSCF. Table A...-: 0 (Accepted) response (S-CSCF to P-CSCF) SIP/.0 0 Accepted Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" Privacy: Contact:
134 X.S00-0 v.0 Conferencing Service; Stage-. 0 (Accepted) response (P-CSCF to UE#) - see example in table A...- The P-CSCF forwards the response to the UE. Table...-: 0 (Accepted) response (P-CSCF to UE#) SIP/.0 0 Accepted Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:pcscf.visited.net;lr>, <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr>, <sip:pcscf.visited.net:;lr;comp=sigcomp> P-Asserted-Identity: Privacy: Contact: 0. NOTIFY request (from S-CSCF of UE# to S-CSCF) - see example in table A...- S-SCSF receives a NOTIFY request corresponding the the REFER request. The NOTIFY request contains information about the progress of the REFER request processing. The body of the NOTIFY request contains a fragment of the response as received by the notifying UE for the request that was initiated due to the REFER request. The NOTIFY request is forwarded to the P-CSCF. Table A...-: NOTIFY request (from S-CSCF of UE# to S-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch= zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; origioi=home.net Max-Forwards: Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> <sip:[email protected]>;tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj NOTIFY Subscription-State: active;expires:00 Event: refer Contact: sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp ( ) Content-Type: message/sipfrag SIP/.0 0 (Trying) response. NOTIFY request (from S-CSCF to P-CSCF) - see example in table A...- The S-CSCF forwards the message to the P-CSCF. 0
135 X.S00-0 v.0 Conferencing Service; Stage- 0 Table: A...-: NOTIFY request (from S-CSCF to P-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP scscf.home.net;branch=zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Max-Forwards: Route: <sip:pcscf.visited.net;lr> Subscription-State: Event: Contact: ( ) Content-Type: (...). NOTIFY request (from P-CSCF to UE#) - see example in table A...-. The P-CSCF forwards the message to UE#. Table A...-: NOTIFY request (from P-CSCF to UE#) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP scscf.home.net;branch=zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. Max-Forwards: Subscription-State: Event: Contact: ( ) Content-Type: (...). 00 (OK) response (UE to P-CSCF) see example in table A...-. The UE acknowledges the NOTIFY request with a 00 (OK) response to the P-CSCF.
136 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (UE to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP scscf.home.net;branch=zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Access-Network-Info: GPP-X-HRPD; ci-gpp= (OK) response (P-CSCF to S-CSCF) see example in table A...-. The P-CSCF forwads the 00 (OK) response to the S-CSCF. Table A...-: 00 (OK) response (P-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP scscf.home.net;branch=zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Access-Network-Info: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" (OK) response (S-CSCF to S-CSCF of UE#) see example in table A...-. The S-CSCF forwards the 00 (OK) response to the S-CSCF of UE# according to the information in the Via field. Table A...-: 00 (OK) response (S-CSCF to S-CSCF of UE#) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; orig-ioi=home.net; term-ioi=home.net 0. UE# joins the conference. UE# joins the conference. The message flows are depicted in subclause.... NOTIFY request (from S-CSCF of UE# to S-CSCF) - see example in table A...-. S-SCSF receives a NOTIFY request corresponding the the REFER request. 0
137 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: NOTIFY request (from S-CSCF of UE# to S-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkd., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; origioi=home.net Max-Forwards: Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj NOTIFY Subscription-State: terminated Event: refer Contact: ( ) Content-Type: message/sipfrag SIP/.0 00 OK Subscription-State: indicates that the implicit subscription to the refer event has been terminated.. NOTIFY request (from S-CSCF to P-CSCF) - see example in table A...-. The S-CSCF forwards the NOTIFY request to the P-CSCF. Table A...-: NOTIFY request (from S-CSCF to P-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP scscf.home.net;branch=zhgbkd., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Charging Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Max-Forwards: Route: <sip:pcscf.visited.net;lr> Subscription-State: Event: Contact: ( ) Content-Type: (...) 0. NOTIFY request (from P-CSCF to UE#) - see example in table A...-. The P-CSCF forwards the NOTIFY request to UE#.
138 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: NOTIFY request (from P-CSCF to UE#) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP scscf.home.net;branch=zhgbkd., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. Max-Forwards: Subscription-State: Event: Contact: ( ) Content-Type: (...). 00 (OK) response (UE to P-CSCF) see example in table A...-. The UE acknowledges the NOTIFY request with a 00 (OK) response to the P-CSCF. Table A...-: 00 (OK) response (UE to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP scscf.home.net;branch=zhgbkd., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Access-Network-Info: GPP-X-HRPD; ci-gpp= (OK) response (P-CSCF to S-CSCF) see example in table A...-. The P-CSCF forwads the 00 (OK) response to the S-CSCF. Table A...-: 00 (OK) response (P-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP scscf.home.net;branch=zhgbkd., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Access-Network-Info: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" (OK) response (S-CSCF to S-CSCF of UE#) see example in table A The S-CSCF forwards the 00 (OK) response to the home network of UE# according to the information in the Via field. 0
139 X.S00-0 v.0 Conferencing Service; Stage- 0 A... Table A...-0: 00 (OK) response (S-CSCF to S-SCSF of UE#) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkd., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; orig-ioi=home.net; term-ioi=home.net 0 User getting referred to a conference by a conference participant Figure A...- shows how UE# gets referred to a conference by receiving a REFER request from a conference participant. The REFER request contains the conference URI where UE# should use when joining the conference. UE# Home Network MRFC/AS. REFER. 0 Accepted. UE# joins the conference. NOTIFY. 00 OK 0. NOTIFY. 00 OK I-CSCF.HSS query UE# Home Network. REFER. 0 Accepted S-CSCF. Evaluation of initial Filter Criteria. REFER. 0 Accepted. NOTIFY. 00 OK. NOTIFY. 00 OK P-CSCF UE# Visited Network. REFER. 0 Accepted. NOTIFY. 00 OK. UE# joins the conference. NOTIFY. 00 OK Figure A...-: User getting invited to a conference by receiving a REFER request. The details of the flows are as follows:. REFER request (S-CSCF of UE# to I-CSCF) - see example in table A...- UE#
140 X.S00-0 v.0 Conferencing Service; Stage- REFER request is sent by the S-CSCF of UE# to UE# home network. S-SCSF of UE# has resolved the address of I-CSCF as the entry point to UE# home network. See subclause... for originating side of the call flow. Table A...-: REFER request (S-CSCF of UE# to I-CSCF) REFER SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: "John Doe" <tel:+--> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; origioi=home.net Privacy: none tag= cb0a0s0asdfglkj Cseq: REFER Refer- Referred-By: Contact: <sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp> 0 Request-URI: Refer- Referred-By: contains the public user identity of UE#. contains the conference URI as learned during the conference establishment. Additionally the "method" uri parameter indicates that the other user is requested to send an INVITE request to this conference URI. contains the public user identity of the referring user, as in this example the referring user has decided to indicate its own identity to the referred user.. The I-CSCF performs HSS query The I-CSCF performs HSS query to find out the S-CSCF serving UE#.. REFER request (I-CSCF to S-CSCF) - see example in table A...- After finding out the S-CSCF assigned to UE#, the I-CSCF forwards the REFER request to that S-CSCF.The I-CSCF does not add itself to the Record-route since it does not have to remain on the signalling path for subsequent requests within the same dialog. 0
141 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: REFER request (I-CSCF to S-CSCF) REFER sip:[email protected] SIP/.0 Via: SIP/.0/UDP icscf.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Record-Route: Route: <sip:scscf.home.net;lr> P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; origioi=home.net Privacy: Cseq: Refer- Referred-By Contact: (...). Evaluation of initial Filter Criteria The S-CSCF validates the service profile of this subscriber, and evaluates the initial Filter Criteria.. REFER request (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF remembers (from registration procedures) the contact address of UE# and determins the P- CSCF assigned for UE# and routes the REFER request there. Table A...-: REFER request (S-CSCF to P-CSCF) REFER sip:[::eeee:ffff:aaaa:bbbb]:0;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbk., SIP/.0/UDP icscf.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Record-Route: <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> Route: <pcscf.visited.net;lr> P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" P-Charging Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Privacy: Cseq: Refer- Referred-By: Contact: P-Called-Party-ID: <sip:[email protected]> (...). REFER request (P-CSCF to UE#) - see example in table A...-
142 X.S00-0 v.0 Conferencing Service; Stage- The P-CSCF forwards the request to UE#. Table A...-: REFER request (P-CSCF to UE#) REFER sip:[::eeee:ffff:aaaa:bbbb]:0;comp=sigcomp SIP/.0 Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbk., SIP/.0/UDP icscf.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Record-Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: Privacy: Cseq: Refer- Referred-By: Contact: P-Called-Party-ID: (...). 0 (Accepted) response (UE# to P-CSCF) - see example in table A...- UE# accepts the REFER request by sending a 0 (Accepted) response. Table A...-: 0 (Accepted) response (UE# to P-CSCF) SIP/.0 0 Accepted Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbk., SIP/.0/UDP icscf.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Privacy:none <sip:[email protected]>;tag= Contact: <sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp> 0. 0 (Accepted) response (P-CSCF to S-CSCF) - see example in table A...- The P-CSCF forwards the 0 (Accepted) response to the S-CSCF. 0
143 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 0 (Accepted) response (P-CSCF to S-CSCF) SIP/.0 0 Accepted Via: scscf.home.net;branch=zhgbk., SIP/.0/UDP icscf.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:pcscf.visited.net;lr>, <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: "John Smith" <sip:[email protected] P-Access-Network-Info: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" Privacy: Contact: 0. 0 (Accepted) response (S-CSCF to I-CSCF) - see example in table A...- The S-CSCF forwards the 0 (Accepted) response to the I-CSCF. Table A...-: 0 (Accepted) response (S-CSCF to I-CSCF) SIP/.0 0 Accepted Via: SIP/.0/UDP icscf.home.net;branch=zhgbky., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: P-Asserted-Identity: "John Smith" <sip:[email protected]>, <tel:+---> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; origioi=home.net term-ioi=visited.net P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Privacy: Contact: 0. 0 (Accepted) response (I-CSCF to UE# home network) - see example in table A...- The I-CSCF forwards the 0 (Accepted) response to S-CSCF of UE#.
144 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 0 (Accepted) response (I-CSCF to S-CSCF of UE#) SIP/.0 0 Accepted Via: scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; origioi=home.net term-ioi=visited.net Privacy: Contact: 0. NOTIFY request (from UE# to P-CSCF) - see example in table A...- UE# creates a subscription and sends a notification of the status of the refer event. Table A...-: NOTIFY request (from UE# to P-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. Max-Forwards: 0 Route: <sip:pcscf.home.net:;lr>,<sip:scscf.home.net;lr>, <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= <sip:[email protected]>;tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj NOTIFY Subscription-State: active;expires:00 Event: refer Contact: sip:[::eeee:ffff:aaaa:bbbb]:0;comp=sigcomp ( ) Content-Type: message/sipfrag SIP/.0 0 (Trying) response. NOTIFY request (from P-CSCF to S-CSCF) - see example in table A...- The P-CSCF forwards the NOTIFY request to the S-CSCF. 0
145 X.S00-0 v.0 Conferencing Service; Stage- 0 Table: A...-: NOTIFY request (from P-CSCF to S-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. Max-Forwards: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" Route: <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Access-Network-Info: Subscription-State: Event: Contact: ( ) Content-Type: (...). NOTIFY request (from S-CSCF to UE# home network) - see example in table A...-. The S-CSCF forwards the NOTIFY request to UE# home network (S-CSCF#). Table A...-: NOTIFY request (from S-CSCF to UE# home network) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; origioi=home.net Max-Forwards: Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> Subscription-State: Event: Contact: ( ) Content-Type: (...). 00 (OK) response (S-CSCF of UE# to S-CSCF) see example in table A...-. The S-CSCF receives a 00 (OK) response to the NOTIFY request from UE#'s home network.
146 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (S-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; orig-ioi=home.net term-ioi=home.net (OK) response (S-CSCF to P-CSCF) see example in table A...-. The S-CSCF forwards the 00 (OK) response to the P-CSCF. Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" (OK) response (P-CSCF to UE#) see example in table A...-. The P-CSCF forwards the 00 (OK) response to UE#. Table A...-: 00 (OK) response (P-CSCF to UE#) SIP/.0 00 OK Via: SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. 0. UE# joins the conference. UE# joins the conference. The message flows are depicted in subclause.... NOTIFY request (from UE# to P-CSCF) - see example in table A...-. P-SCSF receives a NOTIFY request from UE# indicating the status of the refer event. 0
147 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: NOTIFY request (from UE# to P-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr>,<sip:scscf.home.net;lr>, <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj NOTIFY Subscription-State: terminated Event: refer Contact: ( ) Content-Type: message/sipfrag SIP/.0 00 OK. NOTIFY request (from P-CSCF to S-CSCF) - see example in table A...-. The P-CSCF forwards the NOTIFY request to the S-CSCF. Table A...-: NOTIFY request (from P-CSCF to S-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" Max-Forwards: Route: <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Access-Network-Info: Subscription-State: Event: Contact: ( ) Content-Type: (...) 0. NOTIFY request (from S-CSCF to S-CSCF of UE#) - see example in table A...-. The S-CSCF forwards the NOTIFY request to UE#'s home network.
148 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: NOTIFY request (from S-CSCF to S-CSCF of UE#) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkd., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; origioi=home.net Max-Forwards: Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> Subscription-State: Event: Contact: ( ) Content-Type: (...). 00 (OK) response (S-CSCF of UE# to S-CSCF) see example in table A...-. The S-CSCF receives a 00 (OK) response to the NOTIFY request from UE# home network. Table A...-: 00 (OK) response (S-CSCF of UE# to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkd., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; orig-ioi=home.net term-ioi=home.net (OK) response (P-CSCF to S-CSCF) see example in table A...-. The S-CSCF forwards the 00 (OK) response to the P-CSCF. Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" (OK) response (P-CSCF to UE#) see example in table A The P-CSCF forwards the 00 (OK) response to UE#. 0
149 X.S00-0 v.0 Conferencing Service; Stage- 0 A... Table A...-0: 00 (OK) response (P-CSCF UE#) SIP/.0 00 OK Via: SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. 0 MRFC/AS invites a user to a conference Figure A...- shows an MRFC/AS inviting a user to a conference. The invitation is sent as a result of [email protected] sending a REFER request to the MRFC/AS. The MRFC/AS is located in a different network than user s S-CSCF.
150 X.S00-0 v.0 Conferencing Service; Stage- UE# Home Network UE# Home Network UE# Visited Network MRFC/AS. INVITE. 0 Trying. Session Progress. H. interaction to create conference connection resources for UE#. H. interaction to connect through the conference resources for UE#. 00 OK I-CSCF.HSS query. PRACK. 00 OK. UPDATE. 00 OK. ACK. INVITE. 0 Trying. Session Progress. 00 OK S-CSCF. Evaluation of initial Filter Criteria. INVITE. 0 Trying P-CSCF. INVITE. 0 Trying. Session Progress. Authorize QoS resources. Session Progress. PRACK. 00 OK. UPDATE. 00 OK. 00 OK. ACK. Approval of QoS commit. PRACK OK. UPDATE. 00 OK. 00 OK. ACK Figure A...-: MRFC/AS inviting a user to a conference MRFC/AS routes directly to I-CSCF. UE# 0
151 X.S00-0 v.0 Conferencing Service; Stage- 0 The details of the flows are as follows:. INVITE request (MRFC/AS to I-CSCF) - see example in table A...-. In this example, the MRFC/AS is capable of resolving the terminating users I-CSCF address for this request. As a result of a DNS query, it has received the address of the I-CSCF as the next hop. The MRFC/AS invites a user to a conference as it received a REFER request from another user. The MRFC/AS determines the codecs that are applicable for this conference. It builds a SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for each possible media flow. Multiple media flows may be offered, and for each media flow ( line in SDP). In this example, there is only one codec per media offered. For this example, it is assumed that MRFC/AS is willing to establish a multimedia session comprising a video stream and an audio stream. The video stream supports H.. The audio stream supports the EVRC codec. Table A...-: INVITE request (MRFC/AS to I-CSCF) INVITE sip:[email protected] SIP/.0 Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: 0 P-Asserted-Identity: <sip:[email protected]> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net Privacy: none <sip:[email protected]>;tag= <sip:[email protected]> cb0a0s0asdfglkj Cseq: INVITE Require: precondition Supported: 0rel Referred-By: <sip:[email protected]> Contact: <sip:[email protected]>;isfocus Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY Allow-Events: conference Content-Type: application/sdp ( ) v=0 o=- IN IP ::abc:def:abc:abc s=c=in IP ::abc:def:abc:def t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos none remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos none remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event Request-URI: contains the public user identity of UE#. P-Asserted-Identity: contains the asserted identity as configured in the MRFC/AS.
152 X.S00-0 v.0 Contact: Conferencing Service; Stage- contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter. Allow-Events: Referred-By: The MRFC/AS indicates support for the "conference" event package. contains the same value as received in the Referred-By in the REFER request that was received from the user that requested the MRFC/AS send the INVITE request.. 0 (Trying) response (I-CSCF to MRFC/AS) - see example in table A...- The I-CSCF responds to the INVITE request with a 0 (Trying) provisional response. Table A...-: 0 (Trying) response (I-CSCF to MRFC/AS) SIP/.0 0 Trying Via: SIP/.0/UDP [email protected];branch=zhgbk 0. Cx: User Location Query procedure The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the address of the current S-CSCF for the terminating subscriber. For detailed message flows see [].. INVITE request (I-CSCF to S-CSCF) - see example in table A...- The INVITE request is forwarded to the S-CSCF. 0
153 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: INVITE request (I-CSCF to S-CSCF) INVITE sip:[email protected] SIP/.0 Via: SIP/.0/UDP icscf.home.net;branch=zhgbkd., SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: P-Asserted-Identity: P-Charging-Vector: Privacy: Cseq: Require: Supported: Referred-By: Contact: Allow: Allow-Events: Content-Type: ( ) v= o= s= c= t=. 0 (Trying) response (S-CSCF to I-CSCF) - see example in table...- The S-CSCF responds to the INVITE request () with a 0 (Trying) provisional response. Table...-: 0 (Trying) response (S-CSCF to I-CSCF) SIP/.0 0 Trying Via: SIP/.0/UDP icscf.home.net;branch=zhgbkf., SIP/.0/UDP mrfc.home.net;branch=zhgbk 0. Evaluation of initial filter criteria The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.. INVITE request (S-CSCF to P-CSCF) - see example in table A...-
154 X.S00-0 v.0 Conferencing Service; Stage- S-CSCF remembers (from registration procedures) the contact address of UE# and determins the P- CSCF assigned for UE# and routes message there. Table A...-: INVITE request (S-CSCF to P-CSCF) INVITE sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP icscf.home.net;branch=zhgbkd., SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: Record-Route: <sip:scscf.home.net;lr> P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00" Privacy: Cseq: Require: Supported: Referred-By: Contact: Allow: Allow-Events: P-Called-Party-ID: Content-Type: (...) v= o= s= c= t=. 0 (Trying) response (P-CSCF to S-CSCF) - see example in table A...- The P-CSCF responds to the INVITE request () with a 0 (Trying) provisional response. 0
155 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 0 (Trying) response (P-CSCF to S-CSCF) SIP/.0 0 Trying Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP icscf.home.net;branch=zhgbkd., SIP/.0/UDP mrfc.home.net;branch=zhgbk 0. INVITE request (P-CSCF to UE#) - see example in table A...- P-CSCF forwards the request to UE#.
156 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: INVITE request (P-CSCF to UE#) INVITE sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp SIP/.0 Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbkf. SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP icscf.home.net;branch=zhgbkd., SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: Record-Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr> P-Asserted-Identity: Privacy: P-Media-Authorization: efdee00c00 Cseq: Require: Supported: Referred-By: Contact: Allow: Allow-Events: P-Called-Party-ID: Content-Type: (...) v= o= s= c= t=. 0 (Trying) response (UE# to P-CSCF) - see example in table A...- UE# responds to the INVITE request () with a 0 (Trying) provisional response. 0
157 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 0 (Trying) response (UE# to P-CSCF) SIP/.0 0 Trying Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbkf. SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP icscf.home.net;branch=zhgbkd., SIP/.0/UDP mrfc.home.net;branch=zhgbk 0. (Session Progress) response (UE# to P-CSCF) - see example in table A...- UE# determines the complete set of codecs that it is capable of supporting for this session. It determines the intersection with those appearing in the SDP in the INVITE request. The UE responds with a (Session Progress) response containing SDP back to the originator. This response is sent to the P-CSCF.
158 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: (Session Progress) response (UE# to P-CSCF) SIP/.0 Session Progress Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbkf., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP icscf.home.net;branch=zhgbkd., SIP/.0/UDP mrfc.home.net;branch=zhgbk Record-Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Privacy: none tag= Require: 0rel Contact: <sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY RSeq: 0 Content-Type: application/sdp ( ) v=0 o=- IN IP ::eee:fff:aaa:bbb s=c=in IP ::eee:fff:aaa:bbb t=0 0 video 00 RTP/AVP AS: curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local none curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv conf:qos remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event. Authorize QoS resources The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens at this stage or after 00 (OK) response of INVITE request () based on operator local policy.. (Session Progress) response (P-CSCF to S-CSCF) - see example in table A...- The P-CSCF forwards the (Session Progress) response to the S-CSCF. 0
159 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: (Session Progress) response (P-CSCF to S-CSCF) SIP/.0 Session Progress Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP icscf.home.net;branch=zhgbkd., SIP/.0/UDP mrfc.home.net;branch=zhgbk Record-Route: <sip:pcscf.visited.net;lr>, <sip:scscf.home.net;lr> P-Asserted-Identity: "John Smith" <sip:[email protected]> P-Access-Network-Info: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00" Privacy: Require: Contact: Allow: RSeq: Content-Type: v= o= s= c= t=. (Session Progress) response (S-CSCF to I-CSCF) - see example in table A...- The S-CSCF forwards the (Session Progress) response to I-CSCF.
160 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: (Session Progress) response (S-CSCF to I-CSCF) SIP/.0 Session Progress Via: SIP/.0/UDP icscf.home.net;branch=zhgbkd., SIP/.0/UDP mrfc.home.net;branch=zhgbk Record-Route: P-Asserted-Identity: "John Smith" <tel:+---> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net; term-ioi=home.net P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Privacy: Require: Contact: Allow: RSeq: Content-Type: v= o= s= c= t=. (Session Progress) response (I-CSCF to MRFC/AS) see example in table A...- The I-CSCF forwards the (Session Progress) response to the MRFC/AS. 0
161 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: (Session Progress) response (I-CSCF to MRFC/AS) SIP/.0 Session Progress Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk Record-Route: P-Asserted-Identity: Privacy: Require: Contact: Allow: RSeq: Content-Type: v= o= s= c= t=. PRACK request (MRFC/AS to S-CSCF) - see example in table A...- The MRFC/AS determines which media flows should be used for this session, and which codecs should be used for each of those media flows. Since there is no change in the media characteristics, the MRFC/AS does not include any new SDP offer in the PRACK request sent to UE#. The MRFC/AS sends the PRACK request to the S-CSCF of UE# according to the Record-Route header received in Session progress ().
162 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: PRACK request (MRFC/AS to S-CSCF) PRACK sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp SIP/.0 Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: 0 Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj Cseq: PRACK RAck: 0 INVITE 0 Request-URI:. Resource reservation takes the value of the Contact header of the received (Session Progress) response. After determining the media streams, the MRFC/AS initiates the reservation procedures for the resources needed for this session.. PRACK request (S-CSCF to P-CSCF) see example in table A...- The P-CSCF forwards the PRACK request to the P-CSCF. Table A...-: PRACK request (S-CSCF to P-CSCF) PRACK sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: Route: <sip:pcscf.visited.net;lr> Cseq: RAck:. PRACK request (P-CSCF to UE#) see example in table A...- The P-CSCF forwards the PRACK request to UE#. Table A...-: PRACK request (P-CSCF to UE#) PRACK sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp SIP/.0 Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbkf., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: Cseq: RAck: (OK) response (UE# to P-CSCF) see example in table A...-0 (related to table A...-) UE# acknowledges the PRACK request () with a 00 (OK) response. 0
163 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-0: 00 (OK) response (UE# to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbkf., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk P-Access-Network-Info: GPP-X-HRPD; ci-gpp= (OK) response (P-CSCF to S-CSCF) - see example in table A...- The P-CSCF forwards the 00 (OK) response to the S-CSCF. Table A...-: 00 (OK) response (P-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk Content-Type:. 00 (OK) response (S-CSCF to MRFC/AS) - see example in table A...- The S-CSCF forwards the 00 (OK) response to the MRFC/AS. Table A...-: 00 (OK) response (S-CSCF to MRFC/AS) SIP/.0 00 OK Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk P-Access-Network-Info: Content-Type:. UPDATE request (MRFC/AS to S-CSCF) see example in table A...- When the resource reservation in step () is completed, the MRFC/AS sends the UPDATE request to UE#.
164 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: UPDATE request (MRFC/AS to S-CSCF) UPDATE sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp SIP/.0 Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: 0 Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj Cseq: UPDATE Content-Type: application/sdp ( ) v=0 o=- IN IP ::abc:def:abc:abc s=c=in IP ::abc:def:abc:def t=0 0 video 0 RTP/AVP AS: curr:qos local sendrecv curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local sendrecv curr:qos remote none des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event Request-URI: takes the value of the Contact header of the received (Session Progress) response.. UPDATE request (S-CSCF to P-CSCF) see example in table A...- The S-CSCF forwards the UPDATE request to the P-CSCF. 0
165 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: UPDATE request (S-CSCF to P-CSCF) UPDATE sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: Route: <sip:pcscf.visited.net;lr> Cseq: Content-Type: v= o= s= c= t=. UPDATE request (P-CSCF to UE#) - see example in table A...- The P-CSCF forwards the UPDATE request to UE#.
166 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: UPDATE request (P-CSCF to UE#) UPDATE sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp SIP/.0 Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbkf., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: Cseq: Content-Type: v= o= s= c= t=. 00 (OK) response (UE# to P-CSCF) see example in table A...- (related to table A...-) UE# acknowledges the UPDATE request () with a 00 (OK) response. 0
167 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (UE# to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbkf., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Content-Type: application/sdp ( ) v=0 o=- IN IP :: aaa:bbb:ccc:ddd s=c=in IP ::aaa:bbb:ccc:ddd t=0 0 video 0 RTP/AVP AS: curr:qos local sendrecv curr:qos remote sendrecv des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: H fmtp: profile-level-id=0 audio RTP/AVP AS:. curr:qos local sendrecv curr:qos remote sendrecv des:qos mandatory local sendrecv des:qos mandatory remote sendrecv rtpmap: EVRC/000 rtpmap: telephone-event. 00 (OK) response (P-CSCF to S-CSCF) - see example in table A...- The P-CSCF forwards the 00 (OK) response to the S-CSCF.
168 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (P-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk P-Access-Network-Info: Content-Type: v= o= s= c= t=. 00 (OK) response (S-CSCF to MRFC/AS) see example in table A...- The S-CSCF forwards the 00 (OK) response to the MRFC/AS. 0 0
169 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (S-CSCF to MRFC/AS) SIP/.0 00 OK Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk Content-Type: v= o= s= c= t=. H. interaction to modify connection MRFC initiates a H. interaction to connect through the multimedia processing resources for UE# in MRFP.. 00 (OK) response (UE# to P-CSCF) see example in table A...- (related to table A...-) UE# sends a 00 (OK) response final response to the INVITE request () to the P-CSCF. Table...-: 00 (OK) response (UE# to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbkf. SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP icscf.home.net;branch=zhgbkd., SIP/.0/UDP mrfc.home.net;branch=zhgbk Record-Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= INVITE Contact: <sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp> 0. Approval of QoS commit The P-CSCF approves the commitment of the QoS resources if it was not approved already in step ().. 00 (OK) response (P-CSCF to S-CSCF) see example in table A...-
170 X.S00-0 v.0 Conferencing Service; Stage- The P-CSCF forwards the 00 (OK) response to the S-CSCF Table A...-: 00 (OK) response (P-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP icscf.home.net;branch=zhgbkd., SIP/.0/UDP mrfc.home.net;branch=zhgbk Record-Route: <sip:pcscf.visited.net;lr>, <sip:scscf.home.net;lr> P-Access-Network-Info: Contact: (OK) response (S-CSCF to I-CSCF) see example in table A...- The S-CSCF sends a 00 (OK) response final response along the signalling path back to I-CSCF. Table A...-: 00 (OK) response (S-CSCF to I-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP icscf.home.net;branch=zhgbkd., SIP/.0/UDP mrfc.home.net;branch=zhgbk Record-Route: Contact:. 00 (OK) response (I-CSCF to MRFC/AS) see example in table A...- The I-CSCF forwards the 00 (OK) response final response to the session originator. Table...-: 00 (OK) response (I-CSCF to MRFC/AS) SIP/.0 00 OK Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk Record-Route: Contact:. ACK request (MRFC/AS to S-CSCF) see example in table A...- The MRFC/AS responds to the 00 (OK) response () with an ACK request sent to the S-CSCF. 0
171 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: ACK request (MRFC/AS to S-CSCF) ACK sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp SIP/.0 Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: 0 Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj Cseq: ACK 0. ACK request (S-CSCF to P-CSCF) see example in table A...- The S-CSCF forwards the ACK request to the P-CSCF. Table A...-: ACK request (S-CSCF to P-CSCF) ACK sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: Route: <sip:pcscf.visited.net;lr> Cseq:. ACK request (P-CSCF to UE#) - see example in table A...- A... The P-CSCF forwards the ACK request to the UE#. Table A...-: ACK request (P-CSCF to UE#) ACK sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp SIP/.0 Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbkf., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: Cseq: MRFC/AS refers a user to a conference Figure A...- shows how MRFC/AS refers UE# to a conference by sending a REFER request to UE#.The MRFC/AS has created a conference and allocated a conference URI. In this example, the MRFC/AS is not capable of resolving the Request-URI and therefore routes the request first to the S-CSCF in its own network.
172 X.S00-0 v.0 Conferencing Service; Stage- MRFC/AS network UE# Home Network UE# Visited Network MRFC/AS. REFER. 0 Accepted. NOTIFY. 00 OK. NOTIFY. 00 OK S-CSCF. REFER. 0 Accepted I-CSCF. HSS query. NOTIFY. 00 OK. REFER. 0 Accepted S-CSCF. Evaluation of initial Filter Criteria UE# joins conference. NOTIFY. 00 OK. REFER. 0 Accepted. NOTIFY. 00 OK. NOTIFY. 00 OK P-CSCF. REFER. 0 Accepted. NOTIFY 0 00 OK. NOTIFY. 00 OK Figure A...-: MRFC/AS inviting another user to a conference by sending a REFER request to UE#. The details of the flows are as follows:. REFER request (MRFC/AS to S-CSCF) - see example in table A...- The MRFC/AS wants to invite another user to a conference by sending a REFER request to that user. UE# 0
173 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: REFER request (MRFC/AS to S-CSCF) REFER sip: [email protected] SIP/.0 Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: 0 Route: <sip:scscf.home.net;lr> P-Asserted-Identity: <sip:[email protected]> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net Privacy: none <sip:[email protected]>; tag= <sip:[email protected]> cb0a0s0asdfglkj Cseq: REFER Refer- <[email protected];method=invite> Referred-By: <sip:[email protected]> Contact: <sip:[email protected]>;isfocus 0 Request-URI: contains the public user identity of UE#. P-Asserted-Identity: contains the asserted identity as configured in the MRFC/AS. P-Charging-Vector: The MRFC/AS inserts this header and populates the icid parameters with a globally unique value and includes the originating network identifier. Refer- Referred-By: Contact: contains the conference URI. Additionally the method uri parameter indicates that the UE# shall send an INVITE request to this URI. contains the public user identity of the user, on which behalf the MRFC/AS sends the REFER message. contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter.. REFER request (S-CSCF to I-CSCF) - see example in table A...- The REFER request is forwarded to the I-CSCF. Table A...-: REFER request (S-CSCF to I-CSCF) REFER sip:[email protected] SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: Record-Route: <sip:scscf.home.net;lr> P-Asserted-Identity: <sip:[email protected]> P-Charging-Vector: Privacy: Cseq: Refer- Contact:. Cx: User Location Query procedure The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the address of the current S-CSCF for the terminating subscriber. For detailed message flows see []
174 X.S00-0 v.0 Conferencing Service; Stage-. REFER request (I-CSCF to S-CSCF) - see example in table A...- The I-CSCF forwards the REFER request to the address obtained during HSS query.the I-CSCF adds itself to the Via, but not to the Record-Route header as it will not need to stay on the signalling path for subsequent requests. Table A...-: REFER request (I-CSCF to S-CSCF) REFER sip:[email protected] SIP/.0 Via: SIP/.0/UDP icscf.home.net;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: Record-Route: <sip:scscf.home.net;lr> P-Asserted-Identity: P-Charging-Vector: Privacy: Cseq: Refer- Referred-By: Contact:. Evaluation of Initial Filter criteria S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.. REFER request (S-CSCF to P-CSCF) see example in table A...- The S-CSCF remembers (from registration procedures) the contact address of UE# and determins the P- CSCF assigned for UE# and routes the message there. The S-CSCF adds itself to the Via and Record- Route headers. Table A...-: REFER request (S-CSCF to P-CSCF) REFER sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbk., SIP/.0/UDP icscf.home.net;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: Record-Route: <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr> P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00" Privacy: Cseq: Refer- Referred-By: Contact: P-Called-Party-ID: <sip:[email protected]>. REFER request (P-CSCF to UE#) see example in table A...- The P-CSCF forwards the request to UE#. 0
175 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: REFER request (P-CSCF to UE#) REFER sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp SIP/.0 Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbk., SIP/.0/UDP icscf.home.net;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: Record-Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr> P-Asserted-Identity: Privacy: Cseq: Refer- Referred-By: Contact: P-Called-Party-ID:. 0 (Accepted) response (UE# to P-CSCF) - see example in table A...- UE# accepts the REFER request by sending a 0 (Accepted) response. Table A...-: 0 (Accepted) response (UE# to P-CSCF) SIP/.0 0 Accepted Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbk., SIP/.0/UDP icscf.home.net;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk Record-Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Privacy:none <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj REFER Contact: <sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp> 0. 0 (Accepted) response (P-CSCF to S-CSCF) - see example in table A...- The P-CSCF forwards the response to the S-CSCF.
176 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 0 (Accepted) response (P-CSCF to S-CSCF) SIP/.0 0 Accepted Via: SIP/.0/UDP scscf.home.net;branch=zhgbk., SIP/.0/UDP icscf.home.net;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk Record-Route: <sip:pcscf.visited.net;lr>, <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr> P-Access-Network-Info: P-Asserted-Identity: <sip:[email protected]> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00" Privacy: Contact:. 0 (Accepted) response (S-CSCF to I-CSCF) - see example in table A...- The S-CSCF forwards the response to the I-CSCF. Table A...-: 0 (Accepted) response (S-CSCF to I-CSCF) SIP/.0 0 Accepted Via: SIP/.0/UDP icscf.home.net;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk Record-Route: P-Asserted-Identity: "John Smith" <sip:[email protected]; <tel:+---> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net; term-ioi=home.net P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Privacy: Contact:. 0 (Accepted) response (I-CSCF to S-CSCF) - see example in table A...- The I-CSCF forwards the response to the S-CSCF. Table A...-: 0 (Accepted) response (I-CSCF to S-CSCF) SIP/.0 0 Accepted Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk Record-Route: P-Asserted-Identity: P-Charging-Vector: Privacy: Contact: 0
177 X.S00-0 v.0 Conferencing Service; Stage (Accepted) response (S-CSCF to MRFC/AS) - see example in table A...- The S-CSCF forwards the response to the MRFC/AS. Table A...-: 0 (Accepted) response (S-CSCF to MRFC/AS) SIP/.0 0 Accepted Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk Record-Route: P-Asserted-Identity: P-Charging-Vector: Privacy: Contact:. NOTIFY request (UE# to P-CSCF) - see example in table A...- According to [], UE# creates a subscription and sends a notification of the status of the refer. Table A...-: NOTIFY request (from UE# to P-CSCF) NOTIFY sip:[email protected] SIP/.0 Via: SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr>, <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= <sip:[email protected] >;tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj NOTIFY Subscription-State: active;expires:00 Event: refer Contact: sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp ( ) Content-Type: message/sipfrag SIP/.0 0 Trying. NOTIFY request (from P-CSCF to S-CSCF) - see example in table A...- The P-CSCF forwards the message to the S-CSCF.
178 X.S00-0 v.0 Conferencing Service; Stage- Table: A...-: NOTIFY request (from P-CSCF to S-CSCF) NOTIFY SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. Max-Forwards: Route: <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr> P-Access-Network-Info: Subscription-State: Event: Contact: ( ) Content-Type: (...). NOTIFY request (from S-CSCF to S-CSCF - see example in table A...- The S-CSCF forwards the message to the S-CSCF. Table A...-: NOTIFY request (from S-CSCF to S-CSCF) NOTIFY sip:[email protected] SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. Max-Forwards: Route: <sip:scscf.home.net;lr> Subscription-State: Event: Contact: ( ) Content-Type: (...). NOTIFY request (from S-CSCF to MRFC/AS- see example in table A...- The S-CSCF forwards the message to the MRFC/AS. 0
179 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: NOTIFY request (from S-CSCF to MRFC/AS) NOTIFY sip:[email protected] SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP scscf.home.net;branch=zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. Max-Forwards: Subscription-State: Event: Contact: ( ) Content-Type: (...). 00 (OK) response (MRFC/AS to S-CSCF) see example in table A...- The MRFC/AS acknowledges the NOTIFY request with a 00 (OK) response to the S-CSCF. Table A...-: 00 (OK) response (MRFC/AS to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP scscf.home.net;branch=zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh (OK) response (S-CSCF to S-CSCF) see example in table A...- The S-CSCF forwards the 00 (OK) response to the S-CSCF. Table A...-: 00 (OK) response (S-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh (OK) response (S-CSCF to P-CSCF) see example in table A...- The S-CSCF forwards the 00 (OK) response to the P-CSCF.
180 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh (OK) response (P-CSCF to UE#) see example in table A...-0 The P-CSCF forwards the 00 (OK) response to UE#. Table A...-0: 00 (OK) response (P-CSCF to UE#) SIP/.0 00 OK Via: SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. 0. UE# joins the conference. UE# joins the conference as described in subclause.... NOTIFY request (UE# to P-CSCF) - see example in table A...- The P-CSCF receives a NOTIFY request from UE# indicating the status of the refer. Table A...-: NOTIFY request (from UE# to P-CSCF) NOTIFY sip:[email protected] SIP/.0 Via: SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr>, <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= <sip:[email protected] >;tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj NOTIFY Subscription-State: terminated Event: refer Contact: sip:[::eee:fff:aaa:bbb]:0;comp=sigcomp ( ) Content-Type: message/sipfrag SIP/.0 00 OK. NOTIFY request (from P-CSCF to S-CSCF) - see example in table A...- The P-CSCF forwards the message to the S-CSCF. 0
181 X.S00-0 v.0 Conferencing Service; Stage- 0 Table: A...-: NOTIFY request (from P-CSCF to S-CSCF) NOTIFY sip:[email protected] SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. Max-Forwards: P-Access-Network-Info: Route: <sip:scscf.home.net;lr>, <sip:scscf.home.net;lr> Subscription-State: Event: Contact: ( ) Content-Type: (...). NOTIFY request (from S-CSCF to S-CSCF - see example in table A...- The S-CSCF forwards the message to the S-CSCF. Table A...-: NOTIFY request (from S-CSCF to S-CSCF) NOTIFY sip:[email protected] SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. Max-Forwards: Route: <sip:scscf.home.net;lr> Subscription-State: Event: Contact: ( ) Content-Type: (...). NOTIFY request (from S-CSCF to MRFC/AS- see example in table A...- The S-CSCF forwards the message to the MRFC/AS.
182 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: NOTIFY request (from S-CSCF to MRFC/AS) NOTIFY SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP scscf.home.net;branch=zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. Max-Forwards: Subscription-State: Event: Contact: ( ) Content-Type: (...). 00 (OK) response (MRFC/AS to S-CSCF) see example in table A...- The MRFC/AS acknowledges the NOTIFY request with a 00 (OK) response to the S-CSCF. Table A...-: 00 (OK) response (MRFC/AS to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP scscf.home.net;branch=zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh (OK) response (S-CSCF to S-CSCF) see example in table A...- The S-CSCF forwards the 00 (OK) response to the S-CSCF. Table A...-: 00 (OK) response (S-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkz., SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh (OK) response (S-CSCF to P-CSCF) see example in table A...- The S-CSCF forwards the 00 (OK) response to the P-CSCF. 0
183 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbk., SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh (OK) response (P-CSCF to UE#) see example in table A...- A.. A... The P-CSCF forwards the 00 (OK) response to UE#. Table A...-: 00 (OK) response (P-CSCF to UE#) SIP/.0 00 OK Via: SIP/.0/UDP [::eee:fff:aaa:bbb]:0;comp=sigcomp;branch=zhgbkdh. 0 User requesting IMS to join another user MRFC/AS is located in user's home network Figure A...- shows how UE# invites UE# to a conference by sending a REFER request to MRFC/AS. UE# has created a conference by using the mechanisms described in subclause..., and UE# has learned the conference URI that identifies this conference.
184 X.S00-0 v.0 Conferencing Service; Stage- Visited Network UE# Home Network UE#. REFER. 0 Accepted. NOTIFY. 00 OK. NOTIFY OK P-CSCF#. REFER S-CSCF#. UE# creates a conference. 0 Accepted. NOTIFY. 00 OK. NOTIFY. 00 OK. Evaluation of initial Filter Criteria. REFER. 0 Accepted. NOTIFY. 00 OK. NOTIFY. 00 OK MRFC/AS. Invite user to conference.. Referred user joins the conference. Figure A...-: User inviting another user to a conference by sending a REFER request to MRFC/AS. The details of the flows are as follows:. UE# creates a conference UE# creates a conference as described in subclause... Once the conference creation is accomplished, UE# has learned the conference URI allocated for this conference.. REFER request (UE to P-CSCF) - see example in table A...- 0
185 X.S00-0 v.0 Conferencing Service; Stage- 0 A UE has created a conference and learned the conference URI. Now the UE wants to join another UE to that conference. Table A...-: REFER request (UE to P-CSCF) REFER sip: [email protected] SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:[email protected];lr> P-Preferred-Identity: "John Doe" <sip:[email protected]> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Privacy: none <sip:[email protected]>; tag= <sip: [email protected]> cb0a0s0asdfglkj Cseq: REFER Require: sec-agree Refer- <sip:[email protected];method=invite> Proxy-Require: sec-agree Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= Contact: <sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp> 0 Request-URI: contains the conference URI as learned during the conference establishment.. REFER request (P-CSCF to S-CSCF) - see example in table A...- The REFER request is forwarded to the S-CSCF. Table A...-: REFER request (P-CSCF to S-CSCF) REFER sip: [email protected] SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Route: <sip:[email protected];lr> Record-Route: <sip:pcscf.visited.net;lr> P-Asserted-Identity: "John Doe" <sip:[email protected]> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00" P-Access-Network-Info: Privacy: Cseq: Refer- Contact:. Evaluation of initial Filter Criteria The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.. REFER request (S-CSCF to MRFC/AS) - see example in table A...- The S-CSCF forwards the REFER request to the address obtained by adns query.the S-CSCF adds itself to the Record-Route header.
186 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: REFER request (S-CSCF to MRFC/AS) REFER SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: "John Doe" <tel:+--> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net Privacy: Cseq: Refer- Contact:. 0 (Accepted) response (MRFC/AS to S-CSCF) - see example in table A...- The MRFC/AS indicates that it has received the REFER request by sending a 0 (Accepted) response. This means that MRFC/AS has accepted the REFER request and has begun to process the request. This does not mean, however, that the referred-to resource would have been contacted. Table A...-: 0 (Accepted) response (MRFC/AS to S-CSCF) SIP/.0 0 Accepted Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> P-Asserted-Identity: <[email protected]> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; origioi=home.net; term-ioi=home.net Privacy:none <sip:[email protected]>;tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj REFER Contact: <sip:[email protected]>;isfocus 0 Contact: contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter.. INVITE request user to conference The MRFC/AS invites the user, who is indicated in the Refer-To header of the received REFER request. It does apply the procedures as shown in sublcause A... of this annex.. 0 (Accepted) response (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF forwards the response to the P-CSCF. 0
187 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 0 (Accepted) response (S-CSCF to P-CSCF) SIP/.0 0 Accepted Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; Privacy: Contact:. 0 (Accepted) response (P-CSCF to UE#) - see example in table A...- The P-CSCF forwards the response to UE#. Table A...-: 0 (Accepted) response (P-CSCF to UE#) SIP/.0 0 Accepted Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: P-Asserted-Identity: Privacy: Contact:. NOTIFY request (MRFC/AS to S-CSCF) - see example in table A...- The MRFC/AS sends a NOTIFY request to inform the S-CSCF about the progress of the REFER request processing. The body of the NOTIFY request contains a fragment of the response as received by the notifying UE for the request that was initiated due to the REFER request. Table A...-: NOTIFY request (from MRFC/AS to S-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: 0 Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> <sip:[email protected]>;tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj NOTIFY Subscription-State: active;expires:00 Event: refer Contact: <sip:[email protected]>;isfocus ( ) Content-Type: message/sipfrag SIP/.0 0 Trying. NOTIFY request (from S-CSCF to P-CSCF) - see example in table A...- The S-CSCF forwards the message to the P-CSCF.
188 X.S00-0 v.0 Conferencing Service; Stage- Table: A...-: NOTIFY request (from S-CSCF to P-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP mrfc.home.net;branch= zhgbk Max-Forwards: Route: <sip:pcscf.visited.net;lr> Subscription-State: Event: Contact: ( ) Content-Type: (...). NOTIFY request (from P-CSCF to UE#) - see example in table A...-. The P-CSCF forwards the message to UE#. Table A...-: NOTIFY request (from P-CSCF to UE#) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: Subscription-State: Event: Contact: ( ) Content-Type: (...). 00 (OK) response (UE to P-CSCF) see example in table A...-. The UE acknowledges the NOTIFY request with a 00 (OK) response to the P-CSCF. Table A...-: 00 (OK) response (UE to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP mrfc.home.net;branch=zhgbk P-Access-Network-Info: GPP-X-HRPD; ci-gpp= (OK) response (P-CSCF to S-CSCF) see example in table A...-. The P-CSCF forwads the 00 (OK) response to the S-CSCF. 0
189 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (P-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP mrfc.home.net;branch=zhgbk P-Access-Network-Info: (OK) response (S-CSCF to MRFC/AS) see example in table A...-. The S-CSCF forwards the 00 (OK) response to MRFC/AS. Table A...-: 00 (OK) response (S-CSCF to MRFC/AS) SIP/.0 00 OK Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk 0. Referred user joins the conference. The referred user joins the conference as described in subclause.... NOTIFY request (from MRFC/AS to S-CSCF) - see example in table A...-. The MRFC/AS sends a NOTIFY request that indicates that the referred party has joined the conference. Table A...-: NOTIFY request (from MRFC/AS to S-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP mrfc.home.net;branch= zhgbk Max-Forwards: 0 Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> <sip:[email protected]>; tag= <sip:[email protected]>;tag= cb0a0s0asdfglkj NOTIFY Subscription-State: terminated Event: refer ( ) Content-Type: message/sipfrag SIP/.0 00 OK Subscription-State: indicates that the implicit subscription to the refer event has been terminated.. NOTIFY request (from S-CSCF to P-CSCF) - see example in table A...-. The S-CSCF forwards the message to the P-CSCF.
190 X.S00-0 v.0 Conferencing Service; Stage- Table...-: NOTIFY request (from S-CSCF to P-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP mrfc.home.net;branch= zhgbk Max-Forwards: Route: <sip:pcscf.visited.net;lr> Subscription-State: Event: ( ) Content-Type: (...). NOTIFY request (from P-CSCF to UE#) - see example in table A...-. The P-CSCF forwards the message to UE#. Table A...-: NOTIFY request (from P-CSCF to UE#) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP mrfc.home.net;branch=zhgbk Max-Forwards: Subscription-State: Event: ( ) Content-Type: (...) (OK) response (UE to P-CSCF) see example in table A The UE acknowledges the NOTIFY request with a 00 (OK) response to the P-CSCF. Table A...-0: 00 (OK) response (UE to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbk., SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP mrfc.home.net;branch=zhgbk P-Access-Network-Info: GPP-X-HRPD; ci-gpp= (OK) response (P-CSCF to S-CSCF) see example in table A...-. The P-CSCF forwads the 00 (OK) response to the S-CSCF. 0
191 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (P-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbks., SIP/.0/UDP mrfc.home.net;branch=zhgbk P-Access-Network-Info: (OK) response (S-CSCF to MRFC/AS) see example in table A...-. A.. A... The S-CSCF forwards the 00 (OK) response to the MRFC/AS. Table A...-: 00 (OK) response (S-CSCF to MRFC/AS) SIP/.0 00 OK Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk 0 User joins a private conversation to a conference User in a different network Void. A. Flows demonstrating a user subscribing to the conference event package A.. A.. A... Introduction User subscribing to the conference event package MRFC/AS is not located in user's home network
192 X.S00-0 v.0 Conferencing Service; Stage- Visited Network UE# Home Network MRFC/AS Home Network UE# P-CSCF S-CSCF MRFC/AS. SUBSCRIBE. 00 OK. NOTIFY. 00 OK. SUBSCRIBE. 00 OK. NOTIFY. 00 OK. Evaluation of initial Filter Criteria. SUBSCRIBE. 00 OK. NOTIFY. 00 OK Figure A...-: User subscribing to conference event package MRFC/AS is not located in user s home network Figure A...- shows an user subscribing to the conference state event for a specific conference that is provided at a MRFC/AS located in another network. The conference URI, which is used for subscription to the conference event package, does include a FQDN in the host part in this example. The details of the flows are as follows:. SUBSCRIBE request (UE to P-CSCF) - see example in table A...- A UE wants to get informed about the state of a certain conference, the involved users and their related media states. The conference is identified by a conference URI. In order to initiate a subscription to the MRFC/AS, the UE generates a SUBSCRIBE request containing the 'conference' event, together with the length of time this periodic subscription should last. 0
193 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: SUBSCRIBE request (UE to P-CSCF) SUBSCRIBE sip:[email protected] SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:[email protected];lr> P-Preferred-Identity: <sip:[email protected]> Privacy: none <sip:[email protected]>;tag= <sip:[email protected]> brjhnedlrfjflslja SUBSCRIBE Require: sec-agree Proxy-Require: sec-agree Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= Event: conference Expires: 00 Accept: application/conference-info+xml Contact: <sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp> 0 Request-URI: contains the conference URI.. SUBSCRIBE request (P-CSCF to S-CSCF) - see example in table A...- The SUBSCRIBE request is forwarded to the S-CSCF. Table A...-: SUBSCRIBE request (P-CSCF to S-CSCF) SUBSCRIBE sip:[email protected] SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds P-Access-Network-Info: Max-Forwards: P-Asserted-Identity: <sip:[email protected]> P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00" Privacy: Route: <sip:[email protected];lr> Record-Route: <sip:pcscf.visited.net;lr> Event: Expires: Accept: Contact:. Evaluation of initial filter criteria The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.. SUBSCRIBE request (S-CSCF to MRFC/AS) - see example in table A...- S-CSCF forwards the SUBSCRIBE request to the MRFC/AS based on the Request-URI of the SUBSCRIBE request. The S-CSCF does not re-write the Request-URI.
194 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: SUBSCRIBE request (S-CSCF to MRFC/AS) SUBSCRIBE SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkg., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: P-Asserted-Identity: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; orig-ioi=home.net Privacy: Record-Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited;lr> Event: Expires: Accept: Contact:. 00 (OK) response (MRFC/AS to S-CSCF) see example in table A...- (related to table A...-) The MRFC/AS performs the necessary authorisation checks on the originator to ensure that he/she is allowed to subscribe to this specific conference. In this example the conditions have been met, so the MRFC/AS acknowledges the SUBSCRIBE request () with a 00 (OK) response. Table A...-: 00 (OK) response (MRFC/AS to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkg., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00"; orig-ioi=home.net; term-ioi=home.net <sip:[email protected]>;tag= Event: Expires: Contact: <sip:[email protected]>. 00 (OK) response (S-CSCF to P-CSCF) - see example in table A...- S-CSCF forwards the 00 (OK) response to the P-CSCF. 0
195 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=00" Event: Expires: Contact:. 00 (OK) response (P-CSCF to UE) - see example in table A...- The P-CSCF forwards the 00 (OK) response to the UE. Table A...-: 00 (OK) response (P-CSCF to UE) SIP/.0 00 OK Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Record-Route: Event: Expires: Contact:. NOTIFY request (MRFC/AS to S-CSCF) see example in table A...- The MRFC/AS generates a NOTIFY request that includes information about all participants that the subscribing user is allowed to see. The information about one participant includes - the SIP URI identifying the user; - the dialog state associated for that users attachment to the conference; and - the users status in terms of media in the conference.
196 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: NOTIFY request (MRFC/AS to S-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk. Max-Forwards: 0 P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; orig-ioi=home.net Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> <sip:[email protected]>;tag= <sip:[email protected]>;tag= brjhnedlrfjflslja NOTIFY Subscription-State: active ;expires=00 Event: conference;recurse Contact: <sip:[email protected]> Content-Type: application/conference-info+xml (...) <?xml version=".0" encoding="utf-"?> <conference-info version="0" state="full" entity="[email protected]" xmlns="urn:ietf:params:xml:ns:conference-info"> <user uri="sip:[email protected]" display-name="john Doe"> <status>connected</status> <media-stream media-type="audio"> <proto> RTP/AVP </proto> <ssrc> </ssrc> </media-stream> </user> <user uri="sip:[email protected]" display-name="simon Moon"> <status>on-hold</status> </user> </conference-info> P-Charging-Vector: The MRFC/AS populates the icid parameter with a globally unique value and populates the identifier of its own network to the terminating Inter Operator Identifier (IOI) parameter of this header. The message body in the NOTIFY request that carries the conference state information of the conference participants is formed as indicated in [.].. NOTIFY request (S-CSCF to P-CSCF) see example in table A...- The S-CSCF forwards the NOTIFY request to the P-CSCF. 0
197 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: NOTIFY request (S-CSCF to P-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk. Max-Forwards: P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Route: <sip:pcscf.visited.net;lr> Subscription-State: Event: Contact: Content-Type: (...). NOTIFY request (P-CSCF to UE) see example in table A...- The P-CSCF forwards the NOTIFY request to the UE. Table A...-: NOTIFY request (P-CSCF to UE) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UPD scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk. Max-Forwards: Subscription-State: Event: Contact: Content-Type: (...). 00 (OK) response (UE to P-CSCF) see example in table A...- (related to table A...-) The UE acknowledges the NOTIFY request with a 00 (OK) response to the P-CSCF. Table A...-: 00 (OK) response (UE to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UPD scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk. P-Access-Network-Info: GPP-X-HRPD; ci-gpp= (OK) response (P-CSCF to S-CSCF) see example in table A...-
198 X.S00-0 v.0 Conferencing Service; Stage- The P-CSCF forwards the 00 (OK) response to the S-CSCF. Table A...-: 00 (OK) response (P-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UPD scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" P-Access-Network-Info:. 00 (OK) response (S-CSCF to MRFC/AS) see example in table A...- The S-CSCF forwards the 00 (OK) response to the MRFC/AS. Table A...-: 00 (OK) response (S-CSCF to MRFC/AS) SIP/.0 00 OK Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; orig-ioi=home.net; term-ioi=home.net A. Flows demonstrating a user leaving a conference A.. A.. A... Introduction User leaving the conference MRFC/AS is located in user's home network Figure A...- shows an user leaving a conference. The example shows the flow for the user, who created the conference with a conference-factory URI. For this example it is assume that the user is subscribed to the conference state event package at the MRFC/AS. 0
199 X.S00-0 v.0 Conferencing Service; Stage- 0 Visited network UE# Home network UE# P-CSCF S-CSCF MRFC/AS. BYE. 00 OK. NOTIFY. 00 OK. Remove resource reservation. BYE. 00 OK. NOTIFY. 00 OK. BYE. 00 OK. NOTIFY. 00 OK. NOTIFY to other conference participants Figure A...-: User leaving a conference The details of the flows are as follows. MRFP. H. interaction to release connection resources for UE#
200 X.S00-0 v.0 Conferencing Service; Stage-. BYE (UE to P-CSCF) see example in table A...- A UE wants to leave a conference. For this purpose the UE sends a BYE message to the P-CSCF with the Conference-URI as the Request-URI. Table A...-: BYE (UE to P-CSCF) BYE sip:[email protected] SIP/.0 Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: 0 Route: <sip:pcscf.visited.net:;lr;comp=sigcomp>, <sip:[email protected];lr> P-Access-Network-Info: GPP-X-HRPD; ci-gpp= <sip:[email protected]>; tag= <sip:[email protected]>; tag= cb0a0s0asdfglkj Require: sec-agree Proxy-Require: sec-agree Security-Verify: ipsec-gpp; q=0.; alg=hmac-sha--; spi-c=; spi-s=; port-c=; port-s= Cseq: BYE 0 Request-URI:. Remove resource reservation contains the value of the Conference-URI as learned during conference creation. The P-CSCF removes the authorization for resources that had previously been issued for this endpoint for this session. This step will also result in a release indication to the access network to confirm that the IP bearers associated with the session have been deleted.. BYE (P-CSCF to S-CSCF) - see example in table A...- The P-CSCF removes the Security-Verify header, and the "sec-agree" option tag from the Require and Proxy-Require headers. As the Require and Proxy-Require headers are empty, it removes these headers completely. Table A...-: BYE (P-CSCF to S-CSCF) BYE sip:[email protected] SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Max-Forwards: Route: <sip:[email protected];lr> P-Access-Network-Info: Cseq: 0. BYE (S-CSCF to MRFC/AS) - see example in table A...- The S-CSCF forwards the BYE to the MRFC/AS. 0
201 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: BYE (S-CSCF to MFRC/AS) BYE sip:[email protected] SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds P-Access-Network-Info: Max-Forwards: Cseq:. H. interaction to release resources The MRFC/AS interacts with the MRFP to release the resources reserved for UE# in this conference.. 00 (OK) response (MRFC/AS to S-CSCF) - see example in table A...- After successfully releasing the resources from the MRFP, the MRFC/AS sends a 00 (OK) response request to the S-CSCF. Table A...-: 00 (OK) response (MRFC/AS to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Cseq: (OK) response (S-CSCF to P-CSCF) - see example in table A...- S-CSCF forwards the 00 (OK) response to the P-CSCF. Table A...-: 00 (OK) response (S-CSCF to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Cseq: (OK) response (P-CSCF to UE) - see example in table A...- P-CSCF forwards the message to the UE.
202 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (P-CSCF to UE) SIP/.0 00 OK Via: SIP/.0/UDP [::aaa:bbb:ccc:ddd]:;comp=sigcomp;branch=zhgbknashds Cseq: 0. NOTIFY request (MRFC/AS to S-CSCF) see example in table A...- The MRFC/AS generates a NOTIFY request to indicate that UE# has left the conference and automatically unsubscribes UE# from its subscription to the conference event package. Table A...-: NOTIFY request (MRFC/AS to S-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk. Max-Forwards: 0 P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; orig-ioi=home.net Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> <sip:[email protected]>;tag= <sip:[email protected]>;tag= brjhnedlrfjflslja NOTIFY Subscription-State: terminated Event: conference Contact: <sip:[email protected]> Content-Type: application/conference-info+xml (...) <?xml version=".0" encoding="utf-"?> <conference-info version="0" state="full" entity="[email protected]" xmlns="urn:ietf:params:xml:ns:conference-info"> <user uri="sip:[email protected]" display-name="john Doe"> <status>departed</status> <media-status> <media-stream media-type="audio"/> </media-status> </user> <user uri="sip:[email protected]" display-name="simon Moon"> <status>active</status> </user> </conference-info> P-Charging-Vector: The MRFC/AS populates the icid parameter with a globally unique value and populates the identifier of its own network to the originating Inter Operator Identifier (IOI) parameter of this header. P-Charging-Function-Addresses: The MRFC/AS populates the P-Charging-Function-Addresses header field to be passed to the S-CSCF. Subscription-State: Value of terminated indicates that the UE has been unsubscribed from the conference event package. The message body in the NOTIFY request that carries the conference state information of the conference participants is formed as indicated in [.].. Other conference participants are notified 0
203 X.S00-0 v.0 Conferencing Service; Stage- 0 MRFC/AS similarly notifies other conference participants that have subscribed to the conference event package that UE# has left the conference.. NOTIFY request (S-CSCF to P-CSCF) see example in table A...- The S-CSCF forwards the NOTIFY request to the P-CSCF. Table A...-: NOTIFY request (S-CSCF to P-CSCF) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" P-Charging-Function-Addresses: ccf=[::b:c:d:e]; ccf=[::a:b:c:d]; ecf=[::ff:ee:dd:cc]; ecf=[::aa:bb:cc:dd] Max-Forwards: Route: <sip:pcscf.visited.net;lr> Subscription-State: Event: Contact: Content-Type: (...). NOTIFY request (P-CSCF to UE) see example in table A...- The P-CSCF forwards the NOTIFY request to the UE. Table A...-: NOTIFY request (P-CSCF to UE) NOTIFY sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbkf., SIP/.0/UPD scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk. Max-Forwards: Subscription-State: Event: Contact: Content-Type: (...). 00 (OK) response (UE to P-CSCF) see example in table A...- (related to table A...-) The UE acknowledges the NOTIFY request with a 00 (OK) response to the P-CSCF.
204 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: 00 (OK) response (UE to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net:;comp=sigcomp;branch=zhgbkf., SIP/.0/UPD scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk. P-Access-Network-Info: GPP-X-HRPD; ci-gpp= (OK) response (P-CSCF to S-CSCF) see example in table A...- The P-CSCF forwards the 00 (OK) response to the S-CSCF. Table A...-: 00 (OK) response (P-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UPD scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0" P-Access-Network-Info:. 00 (OK) response (S-CSCF to MRFC/AS) see example in table A...- A.. A.. A... The S-CSCF forwards the 00 (OK) response to the MRFC/AS. Table A...-: 00 (OK) response (S-CSCF to MRFC/AS) SIP/.0 00 OK Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk. P-Charging-Vector: icid-value="ayretyu0dm+oirttafrbhlso=0"; orig-ioi=home.net; term-ioi=home.net P-Access-Network-Info: User requesting to remove another user from conference The call flows for a user requesting the removal of another user from a conference are basically identical to the call flows for a user requesting IMS to join another user (see subclause A..). The call flows only differ in the Refer-To header of the REFER request, namely in the method parameter which is set to BYE instead of INVITE and the tasks performed by the MRFC/AS before sending the NOTIFY requests. MRFC/AS drops a user from a conference MRFC/AS is located in user's home network Figure A...- shows an MRFC/AS dropping a user from a conference. 0
205 X.S00-0 v.0 Conferencing Service; Stage- 0 Visited network UE# Home network UE# P-CSCF S-CSCF MRFC/AS. BYE. 00 OK. Remove resource reservation. BYE. 00 OK. Event notification messages. BYE. 00 OK Figure A...-: MRFC/AS dropping a user from a conference The details of the flows are as follows.. BYE (MRFC/AS to S-CSCF) see example in table A...- MRFP. H. interaction to release connection resources for UE# MRFC/AS decides to drop a user from a conference. The decision may be based on a change in the conference policy, because the conference lifetime is exceeded, or some other reason. The MRFC/AS issues a BYE request to the S-CSCF. Table A...-: BYE (MRFC/AS to S-CSCF) BYE sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk. Max-Forwards: 0 Route: Route: <sip:scscf.home.net;lr>, <sip:pcscf.visited.net;lr> <sip:[email protected]>; tag= <sip:[email protected]>; tag= cb0a0s0asdfglkj Cseq: BYE 0 Request-URI: contains the Contact address of the dropped user.. BYE (S-CSCF to P-CSCF) - see example in table A...- The S-CSCF forwards the BYE request to the P-CSCF.
206 X.S00-0 v.0 Conferencing Service; Stage- Table A...-: BYE (S-CSCF to P-CSCF) BYE sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk. Max-Forwards: Route: <sip:pcscf.visited.net;lr> Cseq: 0. Remove resource reservation The P-CSCF removes the authorization for resources that had previously been issued for this endpoint for this session. This step will also result in a release indication to the access network to confirm that the IP bearers associated with the session have been deleted.. BYE (P-CSCF to UE) - see example in table A...- The P-CSCF forwards the BYE to the UE. Table A...-: BYE (P-CSCF to UE) BYE sip:[::aaa:bbb:ccc:ddd]:;comp=sigcomp SIP/.0 Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk. Max-Forwards: Cseq:. 00 (OK) response (UE to P-CSCF) - see example in table A...- After successfully releasing the resources from the MRFP, the MRFC/AS sends a 00 (OK) response to the S-CSCF. Table A...-: 00 (OK) response (UE to P-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP pcscf.visited.net;branch=zhgbkf., SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk. P-Access-Network-Info: GPP-X-HRPD; ci-gpp= Cseq: (OK) response (P-CSCF to S-CSCF) - see example in table A...- P-CSCF forwards the 00 (OK) response to the S-CSCF. 0
207 X.S00-0 v.0 Conferencing Service; Stage- 0 Table A...-: 00 (OK) response (P-CSCF to S-CSCF) SIP/.0 00 OK Via: SIP/.0/UDP scscf.home.net;branch=zhgbkb., SIP/.0/UDP mrfc.home.net;branch=zhgbk. P-Access-Network-Info: Cseq: (OK) response (S-CSCF to MRFC/AS) - see example in table A...- S-CSCF forwards the 00 (OK) response to the MRFC/AS. Table A...-: 00 (OK) response (S-CSCF to MRFC/AS) SIP/.0 00 OK Via: SIP/.0/UDP mrfc.home.net;branch=zhgbk. P-Access-Network-Info: Cseq: 0. H. interaction to release resources MRFC/AS interacts with the MRFP to release the resources reserved for UE# in this conference.. Conference event package messages The MRFC/AS also terminates the user's subscription to the conference state event package. The message flow is identical to messages...- to...- in subclause... for an user leaving a conference. A. Flows demonstrating conference termination A.. General The SIP based flows for conference termination look identical to the call flows for a user leaving a conference (see subclause A..) / a user being removed from a conference (see subclause A..). The termination of the conference itself, after the last user has left / has been removed from the conference does not result in any exchange of SIP messages. A. Flows demonstrating usage of hold and resume during conferences The hold- and resume-service is already described in [] and the related call flows can be readily applied for the IMS conferencing service. The handling of a conference put on hold by one user is a local matter at the MRFC.
ETSI TS 124 147 V6.8.0 (2008-04) Technical Specification
TS 124 147 V6.8.0 (2008-04) Technical Specification Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Conferencing using the IP Multimedia (IM) Core
3GPP TS 24.147 V8.4.0 (2011-12)
TS 24.147 V8.4.0 (2011-12) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Conferencing using the IP Multimedia (IM) Core Network (CN)
3GPP TS 24.605 V8.1.0 (2008-09)
TS 24.605 V8.1.0 (2008-09) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Conference (CONF) using IP Multimedia (IM) Core Network
IMS Conference (IMS Conference Call) Calling UE IMS Network Called UE Caller User Equipment
IMS (IMS Call) MRFC-AS MRFP 18-May-08 10:40 (Page 1) This sequence diagram was generated with (http://www.eventhelix.com/eventstudio). Copyright 2008 EventHelix.com Inc. All Rights Reserved. The EventStudio
3GPP TS 24.604 V8.2.0 (2008-12)
TS 24.604 V8.2.0 (2008-12) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Communication Diversion (CDIV) using IP Multimedia (IM)
ETSI TS 124 238 V8.2.0 (2010-01) Technical Specification
TS 124 238 V8.2.0 (2010-01) Technical Specification Universal Mobile Telecommunications System (UMTS); LTE; Session Initiation Protocol (SIP) based user configuration; Stage 3 (3GPP TS 24.238 version 8.2.0
ETSI TS 182 023 V2.1.1 (2009-01) Technical Specification
TS 182 023 V2.1.1 (2009-01) Technical Specification Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Core and enterprise NGN interaction scenarios; Architecture
HRPD Support for Emergency Services
GPP X.S000-0 Version.0 Date: July 00 HRPD Support for Emergency Services COPYRIGHT GPP and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright
ETSI TS 182 025 V3.3.1 (2011-03) Technical Specification
TS 182 025 V3.3.1 (2011-03) Technical Specification Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Business trunking; Architecture and functional description
This specification this document to get an official version of this User Network Interface Specification
This specification describes the situation of the Proximus network and services. It will be subject to modifications for corrections or when the network or the services will be modified. Please take into
Packet Switched Voice (over IP) and Video Telephony Services End-to-end System Design Technical Report
GPP X.R00-0 Version:.0 Date: November 00 Packet Switched Voice (over ) and Video Telephony Services End-to-end System Design Technical Report COPYRIGHT GPP and its Organizational Partners claim copyright
Request for Comments: 4579. August 2006
Network Working Group Request for Comments: 4579 BCP: 119 Category: Best Current Practice A. Johnston Avaya O. Levin Microsoft Corporation August 2006 Status of This Memo Session Initiation Protocol (SIP)
Alcatel OmniPCX Enterprise R11 Supported SIP RFCs
Alcatel OmniPCX Enterprise R11 Supported SIP RFCs Product & Offer Large & Medium Enterprise Ref: 8AL020033225TCASA ed3 ESD/ Mid & Large Enterprise Product Line Management October 2013 OmniPCX Enterprise
3GPP TS 24.623 V8.1.0 (2008-09)
TS 24.623 V8.1.0 (2008-09) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Extensible Markup Language (XML) Configuration Access Protocol
... Figure 2: Proposed Service Invocation Mechanism. AS Service invocation 2 SC invocation 2. Session/Call Control Function
Next Generation Network Service Architecture in the IP Multimedia Subsystem Anahita Gouya, Noël Crespi, Lina Oueslati, {anahita.gouya, noel.crespi, lina.oueslati}@int-evry.fr, Institut National des Télécommunications
SIP : Session Initiation Protocol
: Session Initiation Protocol EFORT http://www.efort.com (Session Initiation Protocol) as defined in IETF RFC 3261 is a multimedia signaling protocol used for multimedia session establishment, modification
IMS Release 10 Tutorial
IMS Release 10 Tutorial Silvia Scalisi University of Trento 1 Introduction The IP Multimedia Subsystem (IMS) is a network architecture that delivers services based upon the Internet protocols to mobile
Architectural Overview of IP Multimedia Subsystem -IMS
Architectural Overview of IP Multimedia Subsystem -IMS Presented by: Masood Khosroshahy June 2006 B E G I N N I N G 1 Project supervisor: Prof. Elie Najm Simplified view of the layered architecture in
Table of Content. Introduction Components Architectural Characteristics Concepts Protocols Service Examples Discussion. ToC
Danar Barzanji Marcel K Steffen Roger Trösch 22.06.2006 Communication Systems IMS www.packetizer.com Table of Content Introduction Components Architectural Characteristics Concepts Protocols Service Examples
3GPP TS 23.167 V9.4.0 (2010-03)
TS 23.167 V9.4.0 (2010-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS) emergency sessions (Release
Location in SIP/IP Core (LOCSIP)
in SIP/IP Core (LOCSIP) Conveyance with IMS: the OMA LOCSIP Service Enabler Mike Loushine / Don Lukacs Telcordia Applied Research 2009, Telcordia Technologies Inc. in SIP/IP Core (LOCSIP) Topics General
All-IP Network Emergency Call Support
GPP S.R0-0 Version.0 Version Date: October 00 All-IP Network Emergency Call Support Stage Requirements COPYRIGHT GPP and its Organizational Partners claim copyright in this document and individual Organizational
II. Service deployment
BULGARIAN ACADEMY OF SCIENCES CYBERNETICS AND INFORMATION TECHNOLOGIES Volume 9, No 3 Sofia 2009 Integration of Services Implemented on Different Service Platforms Evelina Pencheva, Ivaylo Atanasov Technical
Test Cases - IMS Profile for Voice and SMS
IMS Activity Group Test Cases - IMS Profile for Voice and SMS Version 1.0 29 December 2011 IMTC_Test_Cases IMTC IMS AG Page 1 of 34 History Version Date Name Reason 1.0 15-08-2011 Bo Jönsson Version 0.12
NGN NNI Signalling Profile
/ ATIS Workshop Next Generation Technology and Standardization NGN NNI Signalling Profile Takumi hba NTT Co-editor of Q.NNI_profile What is a signalling profile? o Purpose of signalling profile Higher
ETSI TS 184 011 V3.1.1 (2011-02) Technical Specification
TS 184 011 V3.1.1 (2011-02) Technical Specification Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Requirements and usage of E.164 numbers in NGN and
ETSI TS 124 390 V11.0.0 (2012-10)
TS 124 390 V11.0.0 (2012-10) Technical Specification Universal Mobile Telecommunications System (UMTS); LTE; Unstructured Supplementary Service Data (USSD) using IP Multimedia (IM) Core Network (CN) subsystem
Advanced SIP Series: SIP and 3GPP Operations
Advanced S Series: S and 3GPP Operations, Award Solutions, Inc Abstract The Session Initiation Protocol has been chosen by the 3GPP for establishing multimedia sessions in UMTS Release 5 (R5) networks.
A Proposed Model For QoS guarantee In IMSbased Video Conference services
International Journal of Intelligent Information Technology Application, 2009, 2(5):243-249 A Proposed Model For QoS guarantee In IMSbased Video Conference services Maryam Kiani Department of Electrical
Session Initiation Protocol (SIP) to ISDN User Part (ISUP) Interworking
GPP X.S000-0 Version:.0 Date: January 00 Session Initiation Protocol (SIP) to ISDN User Part (ISUP) Interworking COPYRIGHT GPP and its Organizational Partners claim copyright in this document and individual
Overview of GSMA VoLTE Profile. minimum required functions [3]. 2. Background
GSMA Overview of GSMA Profile It was agreed in the GSMA in February 2010 that voice services over LTE () shall use the platform standardized by the 3GPP with a view to maximizing international interoperability.
An Evaluation of Architectures for IMS Based Video Conferencing
An Evaluation of Architectures for IMS Based Video Conferencing Richard Spiers, Neco Ventura University of Cape Town Rondebosch South Africa Abstract The IP Multimedia Subsystem is an architectural framework
Advanced SIP Series: SIP and 3GPP
Advanced SIP Series: SIP and 3GPP, Award Solutions, Inc Abstract The Session Initiation Protocol has been selected as the main signaling protocol of the Third Generation Partnership Projects IP Multimedia
COPYRIGHTED MATERIAL. Contents. Foreword. Acknowledgments
Contents Foreword Preface Acknowledgments 1 Introduction 1 1.1 Motivation for Network Convergence 1 1.2 The Core Network 2 1.3 Legacy Service Requirements 4 1.4 New Service Requirements 5 1.5 Architectures
ETSI TS 129 162 V7.2.0 (2009-02) Technical Specification
TS 129 162 V7.2.0 (2009-02) Technical Specification Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Interworking between the IM CN subsystem
Implementing Conditional Conference Call Use Case over IMS and Non IMS Testbed an experimental results through comparison approach
Proceedings of the 6th WSEAS International Conference on Applications of Electrical Engineering, Istanbul, Turkey, May 27-29, 2007 109 Implementing Conditional Conference Call Use Case over IMS and Non
Chapter 10 Session Initiation Protocol. Prof. Yuh-Shyan Chen Department of Computer Science and Information Engineering National Taipei University
Chapter 10 Session Initiation Protocol Prof. Yuh-Shyan Chen Department of Computer Science and Information Engineering National Taipei University Outline 12.1 An Overview of SIP 12.2 SIP-based GPRS Push
AV@ANZA Formación en Tecnologías Avanzadas
SISTEMAS DE SEÑALIZACION SIP I & II (@-SIP1&2) Contenido 1. Why SIP? Gain an understanding of why SIP is a valuable protocol despite competing technologies like ISDN, SS7, H.323, MEGACO, SGCP, MGCP, and
ETSI TS 124 423 V8.4.0 (2012-01)
TS 124 423 V8.4.0 (2012-01) Technical Specification Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; TISPAN; PSTN/ISDN simulation services;
Delivery of Voice and Text Messages over LTE
Delivery of Voice and Text Messages over LTE 1. The Market for Voice and SMS! 2. Third Party Voice over IP! 3. The IP Multimedia Subsystem! 4. Circuit Switched Fallback! 5. VoLGA LTE was designed as a
TECHNICAL REPORT End to End Network Architectures (E2NA); Location of Transcoders for voice and video communications
TR 103 279 V1.1.1 (2014-08) TECHNICAL REPORT End to End Network Architectures (E2NA); Location of Transcoders for voice and video communications 2 TR 103 279 V1.1.1 (2014-08) Reference DTR/E2NA-00006-Loc-Transcoders
SIP Essentials Training
SIP Essentials Training 5 Day Course Lecture & Labs COURSE DESCRIPTION Learn Session Initiation Protocol and important protocols related to SIP implementations. Thoroughly study the SIP protocol through
NICC ND 1021 V1.4.1 (2009-11)
ND 1021 V1.4.1 (2009-11) Document Voice Line Control for UK Interconnect using TISPAN IMSbased PSTN/ISDN Emulation Standards Limited Michael Faraday House, Six Dials Way, Stevenage SG1 2AY Tel.: +44(0)
WHAT S BEHIND YOUR SMARTPHONE ICONS? A brief tour of behind-the-scenes signaling for multimedia services
WHAT S BEHIND YOUR SMARTPHONE ICONS? A brief tour of behind-the-scenes signaling for multimedia services Harry G. Perros Computer Science Department NC State University, Raleigh 27695 USA Email: [email protected]
3GPP TS 29.311 V9.1.0 (2011-09)
TS 29.311 V9.1.0 (2011-09) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Service Level Interworking (SLI) for Messaging Services
ETSI TS 132 454 V10.0.0 (2011-04) Technical Specification
TS 132 454 V10.0.0 (2011-04) Technical Specification Universal Mobile Telecommunications System (UMTS); LTE; Telecommunication management; Key Performance Indicators (KPI) for the IP Multimedia Subsystem
3GPP TS 31.220 V8.0.0 (2008-03)
TS 31.220 V8.0.0 (2008-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Characteristics of the Contact Manager for UICC applications
3GPP TS 32.141 V6.1.0 (2004-03)
TS 32.4 V6..0 (2004-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Subscription Management (SuM)
End-2-End QoS Provisioning in UMTS networks
End-2-End QoS Provisioning in UMTS networks Haibo Wang Devendra Prasad October 28, 2004 Contents 1 QoS Support from end-to-end viewpoint 3 1.1 UMTS IP Multimedia Subsystem (IMS)................... 3 1.1.1
3GPP TS 29.161 V6.3.0 (2007-12)
TS 29.161 V6.3.0 (2007-12) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Interworking between the Public Land Mobile Network (PLMN)
A Call Conference Room Interception Attack and its Detection
A Call Conference Room Interception Attack and its Detection Nikos Vrakas 1, Dimitris Geneiatakis 2 and Costas Lambrinoudakis 1 1 Department of Digital Systems, University of Piraeus 150 Androutsou St,
3GPP TS 29.231 V11.0.0 (2012-09)
TS 29.231 V11.0.0 (2012-09) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Application of SIP-I Protocols to Circuit Switched (CS)
TSGS#27(05)0115. Technical Specification Group Services and System Aspects Meeting #27, 14-17 March 2005,Tokyo, Japan
Technical Specification Group Services and System Aspects Meeting #27, 14-17 March 2005,Tokyo, Japan TSGS#27(05)0115 Source: TSG SA WG2 Title: CR(s) to 23.981 Agenda item: 7.2.3 Document for: APPROVAL
3GPP TS 32.593 V9.0.0 (2009-12)
TS 32.593 V9.0.0 (2009-12) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Home enode B (HeNB) Operations,
SIP and Mobility: IP Multimedia Subsystem in 3G Release 5
and Mobility: IP Multimedia Subsystem in 3G Release 5 Jörg Ott {sip,mailto}:[email protected] VDE / ITG Fachgruppe 5.2.4 Bremen 11 November 2002 2002JörgOtt TZI Digitale Medien und Netze 1 Overview IETF Conferencing
Session Initiation Protocol (SIP) The Emerging System in IP Telephony
Session Initiation Protocol (SIP) The Emerging System in IP Telephony Introduction Session Initiation Protocol (SIP) is an application layer control protocol that can establish, modify and terminate multimedia
Inter-Domain QoS Control Mechanism in IMS based Horizontal Converged Networks
Inter-Domain QoS Control Mechanism in IMS based Horizontal Converged Networks Mehdi Mani Wireless Networks and Multimedia Service Department GET-INT Evry, France [email protected] Noel Crespi Wireless
PacketCable 2.0. SIP Signaling Technical Report PKT-TR-SIP-V04-071106 RELEASED. Notice
PacketCable 2.0 SIP Signaling Technical Report RELEASED Notice This PacketCable technical report is the result of a cooperative effort undertaken at the direction of Cable Television Laboratories, Inc.
PacketCable. PacketCable Residential SIP Telephony Accounting Specification PKT-SP-RST-ACCT-I05-100527 ISSUED. Notice
PacketCable PacketCable Residential SIP ISSUED Notice This PacketCable specification is the result of a cooperative effort undertaken at the direction of Cable Television Laboratories, Inc. for the benefit
ARIB TR-T12-33.918 V7.0.0
ARIB TR-T12-33.918 V7.0.0 Generic Authentication Architecture (GAA); Early implementation of Hypertext Transfer Protocol over Transport Layer Security (HTTPS) connection between a Universal Integrated
Part II. Prof. Ai-Chun Pang Graduate Institute of Networking and Multimedia, Dept. of Comp. Sci. and Info. Engr., National Taiwan University
Session Initiation Protocol oco (SIP) Part II Prof. Ai-Chun Pang Graduate Institute of Networking and Multimedia, Dept. of Comp. Sci. and Info. Engr., National Taiwan University Email: [email protected]
3.1 SESSION INITIATION PROTOCOL (SIP) OVERVIEW
3.1 SESSION INITIATION PROTOCOL (SIP) OVERVIEW SIP is an application layer protocol that is used for establishing, modifying and terminating multimedia sessions in an Internet Protocol (IP) network. SIP
Presence SIMPLE Architecture
Presence SIMPLE Architecture Approved Version 1.1 27 Jun 2008 Open Mobile Alliance OMA-AD-Presence_SIMPLE-V1_1-20080627-A OMA-AD-Presence_SIMPLE-V1_1-20080627-A Page 2 (21) Use of this document is subject
Multimedia & Protocols in the Internet - Introduction to SIP
Information and Communication Networks Multimedia & Protocols in the Internet - Introduction to Siemens AG 2004 Bernard Hammer Siemens AG, München Presentation Outline Basics architecture Syntax Call flows
The FOKUS Open SIP AS - A Service Platform for NGN
The FOKUS Open SIP AS - A Service Platform for NGN Elmar Fasel, Karsten Knuettel, Thomas Magedanz {fasel knuettel magedanz}@fokus.fraunhofer.de TU Berlin, Lehrstuhl AV http://www.av.tu-berlin.de/ Fraunhofer
3GPP TS 23.207 V9.0.0 (2009-12)
TS 23.207 V9.0.0 (2009-12) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; End-to-end Quality of Service (QoS) concept and architecture
Three-Way Calling using the Conferencing-URI
Three-Way Calling using the Conferencing-URI Introduction With the deployment of VoIP users expect to have the same functionality and features that are available with a landline phone service. This document
Interoperability Test Plan for International Voice services (Release 6) May 2014
INTERNATIONAL INTERCONNECTION FORUM FOR SERVICES OVER IP (i3 FORUM) Workstream Technical Aspects Workstream Operations Interoperability Test Plan for International Voice services (Release 6) May 2014 Interoperability
SIP A Technology Deep Dive
SIP A Technology Deep Dive Anshu Prasad Product Line Manager, Mitel June 2010 Laith Zalzalah Director, Mitel NetSolutions What is SIP? Session Initiation Protocol (SIP) is a signaling protocol for establishing
NTP VoIP Platform: A SIP VoIP Platform and Its Services
NTP VoIP Platform: A SIP VoIP Platform and Its Services Speaker: Dr. Chai-Hien Gan National Chiao Tung University, Taiwan Email: [email protected] Date: 2006/05/02 1 Outline Introduction NTP VoIP
Linkbit IMS Master Advanced IMS simulation tool
Linkbit IMS Master Advanced IMS simulation tool The IP Multimedia Subsystem (IMS) is the next generation architecture which will enable fixed/mobile convergence in all-ip network. Linkbit IMS Master is
Service Identifier Comparison module Service Rule Comparison module Favourite Application Server Reinvocation Management module
Service Broker for Managing Feature Interactions in IP Multimedia Subsystem Anahita Gouya, Noël Crespi {anahita.gouya, noel.crespi @int-evry.fr}, Institut National des télécommunications (GET-INT) Mobile
TSIN02 - Internetworking
TSIN02 - Internetworking Lecture 9: SIP and H323 Literature: Understand the basics of SIP and it's architecture Understand H.323 and how it compares to SIP Understand MGCP (MEGACO/H.248) SIP: Protocol
Session Initiation Protocol (SIP) 陳 懷 恩 博 士 助 理 教 授 兼 計 算 機 中 心 資 訊 網 路 組 組 長 國 立 宜 蘭 大 學 資 工 系 Email: [email protected] TEL: 03-9357400 # 340
Session Initiation Protocol (SIP) 陳 懷 恩 博 士 助 理 教 授 兼 計 算 機 中 心 資 訊 網 路 組 組 長 國 立 宜 蘭 大 學 資 工 系 Email: [email protected] TEL: 03-9357400 # 340 Outline Session Initiation Protocol SIP Extensions SIP Operation
Research on Initial Filter Criteria of IP Multimedia Subsystem
Research on Initial Filter Criteria of IP Multimedia Subsystem Yafang WANG e-mail: [email protected] Xiaozhe ZHENG e-mail: [email protected] Leilei KANG e-mail: [email protected] Bingyang CHENG
Juha Heinänen [email protected]
From Voice over IP to Voice over Internet Juha Heinänen [email protected] From VoIP to VoINET VoIP replaced wires in PBX and PSTN backbones with IP preserves the traditional, centralized telephony service
Design Document. Offline Charging Server (Offline CS ) Version 1.0. - i -
Design Document Offline Charging Server (Offline CS ) Version 1.0 - i - Document Scope Objective The information provided in this document specifies the design details of Operations of Offline Charging
Proximus can't be held responsible for any damages due to the use of an outdated version of this specification.
This specification describes the situation of the Proximus network and services. It will be subject to modifications for corrections or when the network or the services will be modified. Please take into
ETSI TS 102 744-4-1 V1.1.1 (2015-10)
TS 102 744-4-1 V1.1.1 (2015-10) TECHNICAL SPECIFICATION Satellite Earth Stations and Systems (SES); Family SL Satellite Radio Interface (Release 1); Part 4: Enhanced Services and Applications; Sub-part
Session Initiation Protocol and Services
Session Initiation Protocol and Services Harish Gokul Govindaraju School of Electrical Engineering, KTH Royal Institute of Technology, Haninge, Stockholm, Sweden Abstract This paper discusses about the
AN IPTEL ARCHITECTURE BASED ON THE SIP PROTOCOL
AN IPTEL ARCHITECTURE BASED ON THE SIP PROTOCOL João Paulo Sousa Instituto Politécnico de Bragança R. João Maria Sarmento Pimentel, 5370-326 Mirandela, Portugal + 35 27 820 3 40 [email protected] Eurico Carrapatoso
IxLoad: Advanced VoIP
IxLoad: Advanced VoIP IxLoad in a typical configuration simulating SIP endpoints Aptixia IxLoad VoIP is the perfect tool for functional, performance, and stability testing of SIPbased voice over IP (VoIP)
TRIM: an Architecture for Transparent IMS-based Mobility
TRIM: an Architecture for Transparent IMS-based Mobility Ivan Vidal a,, Antonio de la Oliva a, Jaime Garcia-Reinoso a, Ignacio Soto b a Universidad Carlos III de Madrid. Avda. de la Universidad 30 28911
ETSI TS 123 517 V8.0.0 (2007-12) Technical Specification
TS 123 517 V8.0.0 (2007-12) Technical Specification Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Telecommunications and Internet converged Services
CHANGE REQUEST. 2 (GSM Phase 2) A (corresponds to a correction in an earlier release) R96 (Release 1996) B (addition of feature),
TSG-CN Meeting #25 Palm Springs, USA. 8 th to 10 th September 2004. Tdoc NP-040427 revision of Tdoc N1-041566 in NP-040380 TSG-CN1 Meeting #35 Sophia Antipolis, France, 16-20 August 2004 Tdoc N1-04xxxx
3GPP TR 23.981 V6.4.0 (2005-09)
TR 23.981 V6.4.0 (2005-09) Technical Report 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Interworking aspects and migration scenarios for based IMS Implementations
ETSI TS 182 024 V3.0.0 (2015-10)
TS 182 024 V3.0.0 (2015-10) TECHNICAL SPECIFICATION Network Technologies (NTECH); Hosted Enterprise Services; Architecture, functional description and signalling 2 TS 182 024 V3.0.0 (2015-10) Reference
ETSI TS 187 005 V3.1.1 (2012-06)
TS 187 005 V3.1.1 (2012-06) Technical Specification Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Lawful Interception; Stage 1 and Stage 2 definition
Analysis of Enterprise VoIP Traffic from a Wire line IMS System. Yu Bai Master Thesis Supervisor: Tord Westholm, EAB Supervisor: Dougherty Mark, DU
Analysis of Enterprise VoIP Traffic from a Wire line IMS System Yu Bai Master Thesis Supervisor: Tord Westholm, EAB Supervisor: Dougherty Mark, DU DEGREE PROJECT Computer Engineering Program Master of
SIP Trunking. Service Guide. www.megapath.com. Learn More: Call us at 877.634.2728.
Service Guide Learn More: Call us at 877.634.2728. www.megapath.com What is MegaPath SIP Trunking? SIP Trunking enables your business to reduce costs and simplify IT management by combining voice and Internet
Authentication and Authorisation for Integrated SIP Services in Heterogeneous Environments 1
Authentication and Authorisation for Integrated SIP Services in Heterogeneous Environments 1 Dorgham Sisalem, Jiri Kuthan Fraunhofer Institute for Open Communication Systems (FhG Fokus) Kaiserin-Augusta-Allee
SIP: Ringing Timer Support for INVITE Client Transaction
SIP: Ringing Timer Support for INVITE Client Transaction Poojan Tanna ([email protected]) Motorola India Private Limited Outer Ring Road, Bangalore, India 560 037 Abstract-The time for which the Phone
ETSI TS 184 009 V2.0.0 (2008-06) Technical Specification
TS 184 009 V2.0.0 (2008-06) Technical Specification Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Rules covering the use of TV URIs for the Identification
ETSI TS 183 036 V3.5.1 (2012-08)
TS 183 036 V3.5.1 (2012-08) Technical Specification Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); ISDN/SIP interworking; Protocol specification 2 TS
