1、 International Telecommunication Union ITU-T J.365TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (11/2006) SERIES J: CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS IPCablecom IPCablecom2 application manager interface ITU-T Recommendation J.365 ITU-T Rec.
2、 J.365 (11/2006) i ITU-T Recommendation J.365 IPCablecom2 application manager interface Summary This Recommendation defines an IPCablecom2 Application Manager (IPAM) interface which allows the Proxy Call Session Control Function (P-CSCF) to support Quality of Service (QoS) operations within an IPCab
3、lecom Multimedia-enabled DOCSIS-access network. Source ITU-T Recommendation J.365 was approved on 29 November 2006 by ITU-T Study Group 9 (2005-2008) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. J.365 (11/2006) FOREWORD The International Telecommunication Union (ITU) is the United Nat
4、ions specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunica
5、tions on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure
6、 laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommu
7、nication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these ma
8、ndatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draw
9、s attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or
10、 others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not repr
11、esent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2007 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T Rec. J.365 (11/20
12、06) iii CONTENTS Page 1 Scope 1 2 References. 1 2.1 Normative references 1 2.2 Informative references 2 3 Terms and definitions . 2 4 Abbreviations, acronyms and conventions. 2 4.1 Abbreviations and acronyms 2 4.2 Conventions 3 5 Technical overview. 3 5.1 Architecture 3 5.2 IPCablecom2 Application M
13、anager overview . 4 6 Interface description . 5 6.1 Operations. 5 6.2 Elements . 6 6.3 Messages. 9 6.4 Web Service profile 13 7 Application Manager requirements 13 7.1 Mapping SDP to FlowSpec 13 8 P-CSCF requirements . 17 9 Security requirements . 18 9.1 P-CSCF IPAM interface 18 9.2 IPAM Policy Serv
14、er interface . 18 Annex A XML schema . 19 Annex B WSDL specification. 21 Appendix I Example call flows. 23 I.1 On-net successful call. 23 I.2 On-net unsuccessful call. 25 I.3 Off-net (PSTN) successful call. 28 I.4 Re-invite scenarios (hold, media changes). 29 I.5 Call forking Single line extension .
15、 31 I.6 3PCC. 33 I.7 UEs behind same NAT. 44 ITU-T Rec. J.365 (11/2006) 1 ITU-T Recommendation J.365 IPCablecom2 application manager interface 1 Scope This Recommendation defines an IPCablecom2 Application Manager (IPAM) interface. This interface allows the Proxy Call Session Control Function (P-CSC
16、F) to support Quality of Service (QoS) operations within an IPCablecom Multimedia-enabled DOCSIS-access network. IPCablecom defines a framework to support SIP-based communication services. SIP messages may contain a Session Description Protocol (SDP) body that defines the attributes of the media str
17、eams being advertised. The interface defined in this Recommendation allows a P-CSCF to manage QoS resources by passing session identification information and SDP if available to an IPAM. It is the responsibility of the IPAM to translate the incoming messages into IPCablecom Multimedia messages and f
18、orward them to an IPCablecom Multimedia Policy Server. It is an important objective of this work that interoperability between IPCablecom 2.0 and 3GPP IMS is provided. IPCablecom 2.0 is based upon 3GPP IMS, but includes additional functionality necessary to meet the requirements of cable operators.
19、Recognizing developing converged solutions for wireless, wireline, and cable, it is expected that further development of IPCablecom 2.0 will continue to monitor and contribute to IMS developments in 3GPP, with the aim of alignment of 3GPP IMS and IPCablecom 2.0. 2 References 2.1 Normative references
20、 The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of
21、this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation
22、 does not give it, as a stand-alone document, the status of a Recommendation. ITU-T J.170 ITU-T Recommendation J.170 (2005), IPCablecom security specification. ITU-T J.179 ITU-T Recommendation J.179 (2005), IPCablecom support for multimedia. ITU-T J.361 ITU-T Recommendation J.361 (2006), IPCablecom2
23、 codec media. IETF RFC 3725 IETF RFC 3725 (2004), Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP). IETF RFC 3890 IETF RFC 3890 (2004), A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP). SOAP 1.1 W3C Note 08 May 2
24、000, Simple Object Access Protocol (SOAP) 1.1, http:/www.w3.org/TR/2000/NOTE-SOAP-20000508. SOAP 1.2 W3C Recommendation 24 June 2003, SOAP Version 1.2. Part 1: Messaging Framework, http:/www.w3.org/TR/2003/REC-soap12-part1-20030624/. Part 2: Adjuncts, http:/www.w3.org/TR/2003/REC-soap12-part2-200306
25、24/. XML 1.0 W3C Recommendation 04 February 2004, Extensible Markup Language (XML) 1.0 (Third Edition), http:/www.w3.org/TR/2004/REC-xml-20040204. 2 ITU-T Rec. J.365 (11/2006) 2.2 Informative references ITU-T J.360 ITU-T Recommendation J.360 (2006), IPCablecom2 architecture framework. ITU-T J.360 Ap
26、p.II ITU-T Recommendation J.360 (2006), IPCablecom2 architecture framework. Appendix II: Quality of Service architecture technical overview. IETF RFC 2327 IETF RFC 2327 (1998), SDP: Session Description Protocol. IETF RFC 2617 IETF RFC 2617 (1999), HTTP Authentication: Basic and Digest Access Authent
27、ication. IETF RFC 3264 IETF RFC 3264 (2002), An Offer/Answer Model with the Session Description Protocol (SDP). IETF RFC 3311 IETF RFC 3311 (2002), The Session Initiation Protocol (SIP) UPDATE Method. WSDL W3C Note 15 March 2001, Web Services Description Language (WSDL) 1.1. http:/www.w3.org/TR/wsdl
28、. 3 Terms and definitions This Recommendation defines the following terms: 3.1 application manager: A system that interfaces to Policy Server(s) for requesting QoS-based service on behalf of an end-user or network management system. 3.2 cable modem termination system: Device at a cable head-end whic
29、h implements the DOCSIS RFI MAC protocol and connects to CMs over an HFC network. 3.3 leg: A single segment of a session associated with a UE (e.g., calling UE or called UE). 3.4 policy server: A system that primarily acts as an intermediary between AM(s) and CMTS(s). It applies network policies to
30、AM requests and proxies messages between the AM and CMTS. 3.5 quality of service: Method used to reserve network resources and guarantee availability for applications. 3.6 request for comments: Technical policy documents approved by the IETF which are available at http:/www.ietf.org/rfc.html. 4 Abbr
31、eviations, acronyms and conventions 4.1 Abbreviations and acronyms This Recommendation uses the following abbreviations: AM Application Manager AS Application Server CMTS Cable Modem Termination System CSCF Call Session Control Function HTTP Hypertext Transfer Protocol IETF Internet Engineering Task
32、 Force IP Internet Protocol ITU-T Rec. J.365 (11/2006) 3 IPAM IPCablecom Application Manager (sometimes abbreviated as PAM) MAC Media Access Control P-CSCF Proxy Call Session Control Function PS Policy Server QoS Quality of Service RFC Request for Comments SIP Session Initiation Protocol SSL Secure
33、Socket Layer UA User Agent W3C World Wide Web Consortium WS Web Service WSDL Web Services Description Language XML Extensible Markup Language XSD XML Schema Definition 4.2 Conventions Throughout this Recommendation, the words that are used to define the significance of particular requirements are ca
34、pitalized. These words are: “MUST“ This word means that the item is an absolute requirement of this Recommendation. “MUST NOT“ This phrase means that the item is an absolute prohibition of this Recommendation. “SHOULD“ This word means that there may exist valid reasons in particular circumstances to
35、 ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. “SHOULD NOT“ This phrase means that there may exist valid reasons in particular circumstances when the listed behaviour is acceptable or even useful, but the full impl
36、ications should be understood and the case carefully weighed before implementing any behaviour described with this label. “MAY“ This word means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product,
37、 for example; another vendor may omit the same item. 5 Technical overview This clause provides a high-level overview of the IPAM and how it fits in the overall IPCablecom architecture. 5.1 Architecture The IPCablecom Multimedia Technical Report ITU-T J.179 describes an architecture framework and ref
38、erence model for IPCablecom Multimedia. The IPCablecom2 Architecture Framework Recommendation ITU-T J.360 provides an overview of IPCablecom2 Reference Architecture and description of the various components. Within this architecture, the IPCablecom2 Application Manager is responsible for managing th
39、e QoS resources on behalf of the IPCablecom network. 4 ITU-T Rec. J.365 (11/2006) Figure 1 illustrates the IPCablecom2 QoS architecture, and indicates the IPAM s interfaces. Figure 1/J.365 IPCablecom2 QoS architecture 5.2 IPCablecom2 Application Manager overview The IPAM enables a P-CSCF to manage Q
40、oS resources in the access network based on the Session Description Protocol (SDP) parameters contained in the offer and answer as defined in IETF RFC 3264. The IPAM uses the IPCablecom Multimedia pkt-mm-3 interface to communicate these requirements to an IPCablecom Multimedia Policy Server. A typic
41、al SIP session set-up involves a UE (the calling UE) attempting to signal another UE (the called UE) of its desire to establish a session. In the simple case the following occurs: 1) The calling UE sends an INVITE message, containing an SDP offer, to the P-CSCF. 2) The P-CSCF uses the IPAM interface
42、 to reserve resources for the calling UE and then forwards the INVITE to the IMS. The reservation will be based initially on the SDP offered. 3) The INVITE is routed to the called UEs P-CSCF. The P-CSCF signals to its IPAM that resources need to be reserved for the called UE. The reservation will be
43、 based initially on an estimation of resources required using the callers SDP (offer). The INVITE is then forwarded to the called UE. 4) When the called UE answers, a 200 OK message containing an SDP answer is sent back through the called UEs P-CSCF, routed through the IMS to the calling UEs P-CSCF,
44、 and then to the calling UE itself. During this process the P-CSCFs commit the previously reserved QoS, which is modified to reflect any changes in requirements based on the called UEs SDP (answer). 5) When the session completes, a BYE message is exchanged between the calling and called UEs through
45、their respective P-CSCFs. During this process each UEs P-CSCF releases the previously committed QoS resources. For each SIP offer/answer message received by a P-CSCF, the P-CSCF should signal the IPAM on behalf of the UE for which it is acting in processing the current message (e.g., the UE from whi
46、ch it received the SIP message or to which it will send the current SIP message received from the IMS). Intermediary proxies along the signalling path that are not directly responsible for any UEs involved ITU-T Rec. J.365 (11/2006) 5 in the dialog should not signal any IPAM. Each P-CSCF has to sign
47、al the IPAM with the offer and answer, as both are needed to have a full view of the sessions requirements. For each session leg, the IPAM interprets the SDP contained in both the offer and answer, parsing the SDP and reading the media information including the media type, media codecs, source and d
48、estination IP addresses and ports, and then formulates an IPCablecom Multimedia Gate-Set message that is forwarded to the IPCablecom Multimedia Policy Server. For each session leg, the IPAM creates IPCablecom Multimedia gate(s) for each media type specified. Based on the mode specified (sendonly, re
49、cvonly, sendrecv), the IPAM creates the appropriate upstream and downstream gates. For example, the SDP for a two-way video session would contain two media types: audio and video. For this type of session, the IPAM creates a total of four IPCablecom Multimedia gates consisting of an upstream gate for audio, a downstream gate for audio, an upstream gate for video and a downstream gate for video. While it is possible and may seem reasonable to create gates for the RTCP streams which are associated with the RTP streams, this i
