1、 ETSI TR 183 052 V2.2.0 (2008-01)Technical Report Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);Solution for REFER interworking problemsETSI ETSI TR 183 052 V2.2.0 (2008-01) 2 Reference DTR/TISPAN-03101-NGN-R2 Keywords CONF, ECT, interworking ETSI
2、650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be dow
3、nloaded from: http:/www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the referen
4、ce shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is
5、 available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission.
6、 The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2008. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTM, TIPHONTM, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GP
7、PTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TR 183 052 V2.2.0 (2008-01) 3 Contents Intellectual Property Rights4 Foreword.4 1 Scope 5 2 References 5 2.1 Informative references5 3 Definitions and abbreviations.6 3.1 Definiti
8、ons6 3.2 Abbreviations .6 4 REFER interworking6 4.1 Introduction 6 4.1.1 Problem.6 4.1.2 Possible solutions6 4.2 Description of the solutions7 4.2.1 AS using 3rdparty call control procedures7 4.2.1.1 General description .7 4.2.1.2 Signalling requirements 7 4.2.1.2.1 Actions at the S-CSCF of the init
9、iator of the REFER request.7 4.2.1.2.2 Actions at the AS of the initiator of the REFER request .8 4.2.1.3 Charging9 4.2.1.4 Service impact.9 4.2.1.4.1 Origination Identification Restriction (OIR) .9 4.2.1.4.2 Anonymous Communication Rejection and Communication Barring (ACR/CB) 9 4.2.1.5 Parameter va
10、lues (timers)9 4.3 Conclusion10 Annex A (informative): Signalling flows 11 A.1 AS using 3rdparts call control procedures11 Annex B (informative): Example of filter criteria.17 B.1 AS using 3rdparty call control procedures .17 History 18 ETSI ETSI TR 183 052 V2.2.0 (2008-01) 4 Intellectual Property R
11、ights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essenti
12、al, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has be
13、en carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by ETSI Technica
14、l Committee Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN). ETSI ETSI TR 183 052 V2.2.0 (2008-01) 5 1 Scope The present documents purpose is to develop a solution for interworking problems of REFER based simulation services. This solution shall adju
15、st REFER interworking problems of the Release 1 NGN services ECT and CONF, and shall also take into account Release 2 services. NOTE: The results of the of the TR are included in ETSI TS 183 028 5 “Common Basic Communication procedures“. 2 References References are either specific (identified by dat
16、e of publication and/or edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. Non-specific reference may be made only to a complete document or a part thereof and only in the following cases: - if it is accepted that it will be possible to us
17、e all future changes of the referenced document for the purposes of the referring document; - for informative references. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.etsi.org/Reference. For online referenced documents, inf
18、ormation sufficient to identify and locate the source shall be provided. Preferably, the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the reference should, as far as possible, remain valid for the expected life of the document. The referenc
19、e shall include the method of access to the referenced document and the full network address, with the same punctuation and use of upper case and lower case letters. NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee their long term validit
20、y. 2.1 Informative references 1 IETF RFC 3515: “The Session Initiation Protocol (SIP) Refer Method“. 2 IETF RFC 3725: “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)“. 3 ETSI TS 183 029: “Telecommunications and Internet converged Services and Prot
21、ocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services: Explicit Communication Transfer (ECT); Protocol specification“. 4 ETSI TS 183 007: “Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services; Originating Ide
22、ntification Presentation (OIP) and Originating Identification Restriction (OIR); Protocol specification“. 5 ETSI TS 183 028: “Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Common Basic Communication procedures“. 6 ETSI TS 181 002: “Telecommunicati
23、ons and Internet converged Services and Protocols for Advanced Networking (TISPAN); Multimedia Telephony with PSTN/ISDN simulation services“. 7 ETSI ES 283 003: “Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IP Multimedia Call Control Protocol bas
24、ed on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3“. ETSI ETSI TR 183 052 V2.2.0 (2008-01) 6 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in TS 181 002 6 apply. 3.2 Abbreviations For the
25、purposes of the present document, the following abbreviations apply: AS Application Server CONF CONFerence callingHOLD Communication Hold IFC Initial Filter Criteria IP Internet Protocol ISDN Integrated Service Data Network MGCF Media Gateway Control function MPTY MultiParTY MPTY Multi ParTY Service
26、 NGN Next Generation Network OCB Outgoing Communication Barring OIP Originating Identification Presentation OIR Originating Identification Restriction PSTN Public Switch Telephone Network SIP Session Initiation Protocol UE User Equipment 4 REFER interworking 4.1 Introduction 4.1.1 Problem The TISPAN
27、 NGN services ECT and CONF are based on the usage of SIP REFER requests. When the SIP REFER request is sent to a user who is located in the PSTN/ISDN, the invocation of the service fails, because there is no interworking from a SIP REFER request to a regarding PSTN/ISDN message. For example at the i
28、nvocation of the CONF service, a dial-in conference can be realized by sending a SIP REFER request to the participant, referring an SIP INVITE request to the conference focus. When the participant is located in the PSTN/ISDN, the SIP REFER request will be routed to the MGCF, where it will be answere
29、d with a SIP 403 Forbidden response. In addition, there are many SIP terminals which lack the support to REFER because REFER is an optional extension to basic SIP. When the SIP REFER request is sent to such a terminal, the invocation of the service fails, too. 4.1.2 Possible solutions Only one solut
30、ion could be developed. It is proposed to use an Application Server, which can handle REFER requests by using 3rdparty call control procedures. NOTE: As there is no guarantee that 3rdparty call control will result in an established communication, this solution works on a best-effort basis. ETSI ETSI
31、 TR 183 052 V2.2.0 (2008-01) 7 4.2 Description of the solutions 4.2.1 AS using 3rdparty call control procedures 4.2.1.1 General description The communication is established with the involvement of an Application Server that acts as a B2BUA, so the AS has knowledge about the existing partial dialogs
32、he is involved in, especially of the media user for this communication. The REFER request is routed via this AS. When the AS receives a 403 Forbidden or a 501 Not Implemented response to the REFER request, it uses 3rdparty call control procedures to connect the REFER target and the Refer-to target.
33、This is done by sending re-INVITE requests in existing partial dialogs and by sending INVITE requests to establish new partial dialogs. Tables 1 and 2 give decision criteria when to start 3pcc procedures. Table 1: Terminating party of a communication sends a REFER request Content of the Allow header
34、 in the initial INVITE from A-B Action AS-B on the REFER from B Action that the AS-B does on the initial INVITE INVITE with Allow header with no REFER token Invoke the 3pcc procedure directly AS-B adds the REFER token to the Allow header INVITE with Allow header with a REFER token Forward the REFER
35、and if the 403 or 501 response is received, fall back to 3pcc procedure No modification needed in the Allow header INVITE without Allow header Forward the REFER and if the 403 or 501 response is received, fall back to 3pcc procedure No modification needed in the INVITE Table 2: Originating party of
36、a communication sends a REFER request Content of the Allow header in the 200 OK response on the initial INVITE (A-B dialog) Action AS-A on the REFER from A Action that the AS-A does on the 200 OK response on A-B dialog 200 (OK) with Allow header with no REFER token Invoke the 3pcc procedure directly
37、 AS-A adds the REFER token to the Allow header 200 (OK) with Allow header with a REFER token Forward the REFER and if the 403 or 501 response is received, fall back to 3pcc procedure No modification needed in the Allow header 200 (OK) response without Allow header Forward the REFER and if the 403 or
38、 501 response is received, fall back to 3pcc procedure No modification needed in the 200 (OK) response As a network option, the AS of the initiator of the REFER request may initiate 3rdparty call control procedures without sending the REFER to the REFER target and waiting for an error response, whic
39、h means tables 1 and 2 are not applicable in this case. To avoid a longer re-negotiation of the media, the media information of the existing partial dialogs are used for the INVITE requests or the first re-INVITE requests during the 3pcc procedures. 4.2.1.2 Signalling requirements Basic communicatio
40、n procedures according to ES 283 003 7 can apply, with the following additions. 4.2.1.2.1 Actions at the S-CSCF of the initiator of the REFER request Based on the Initial Filter Criteria (IFC) Rules a REFER request can be forwarded to the AS. NOTE: An example of the use of IFC is shown in annex B. E
41、TSI ETSI TR 183 052 V2.2.0 (2008-01) 8 4.2.1.2.2 Actions at the AS of the initiator of the REFER request 4.2.1.2.2.1 REFER is sent inside a dialog 4.2.1.2.2.1.1 Normal procedures If the AS receives a 403 Forbidden or a 501 Not implemented response, it can send a 202 Accepted response followed by a N
42、OTIFY request with a 100 Trying status line to the originator of the REFER request, according to the procedures of RFC 3515 1. The AS then can perform third party call control procedures according to Flow III or Flow IV of RFC 3725 2, with the following additions and clarifications: The AS should ve
43、rify if it is involved in the dialogs between the originator of the REFER on the one side and the REFER target and the Refer-to target on the other side. Then the AS can send an INVITE request to the Refer-to target if it is not involved in a dialog with the Refer-to target (e.g. Blind ECT), or the
44、AS can send a re-INVITE request to the Refer-to target if it is involved in a dialogue with the Refer-to target (e.g. Consultative ECT). The INVITE request can contain if available a P-Asserted-ID header field with a valid identity of the REFER target and a Referred-by header field matching the P-As
45、serted-Identity of the REFER request. When the partial dialog with the Refer-to target is acknowledged, the AS can send in the original partial dialog a NOTIFY request with a 100 Trying status line to the originator of the REFER request, according to the procedures of RFC 3515 1. After that the AS c
46、an send a re-INVITE request to the REFER target. The re-INVITE request shall contain if available a P-Asserted-ID header field with a valid identity of the REFER-to target and a Referred-by header field matching the P-Asserted-Identity of the REFER request. When the partial dialog with the REFER tar
47、get is acknowledged, the AS can send in the original partial dialog a NOTIFY request with a 200 OK status line to the originator of the REFER request, according to the procedures of RFC 3515 1. If a Replaces parameter is included in the Refer-To header field of the original REFER request and it refe
48、rs to the original partial dialog between the referor and the refer-to target, the AS can send a BYE request in the original partial dialog to the referor. When the 3rdparty call control procedures were successful, continued processing procedures according to subclause 7 of RFC 3725 2 can be applied
49、. As a network option, the AS could send a 202 Accepted response directly and initiate 3rdparty call control procedures without trying to forward the REFER request to the REFER target. NOTE: For example, when UE-A and UE-B establish a session, they will exchange their own capabilities for SIP methods by using “Allow“ header. If the AS lies in the signalling path between UE-A and UE-B, it can know whether the two UEs support REFER or not, and can initiate 3rdparty call control procedures. Another example is that a network operator doesnt want t
