This Working Group did not meet
NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.
Last Modified: 2004-01-30
Examples of such transport include:
- transport of signaling between a Signaling Gateway and Media Gateway or Media Gateway Controller - transport of signaling ("backhaul") from a Media Gateway to a Media Gateway Controller - transport of TCAP between a Signaling Gateway and other IP nodes
Applications include:
- Internet dial-up remote access - IP telephony interworking with PSTN - Other services as identified
Specific goals are:
1. Architecture and Performance Requirements: The working group will produce an informational RFC identifying functionality and performance requirements to support signaling over IP. Signaling messages have very stringent loss and delay requirements in the existing telephone networks that need to be supported.
2- Transport: The working group will produce a standards track proposal or proposals defining transport of signaling protocols using SCTP, based on the requirements identified above.
These proposals will identify the method of encapsulation of different signaling protocols. This will include differentiating between different protocols being carried, and what components are transported, translated or terminated at the SG. Security and resilience must be addressed.
Note: TCAP is a transaction protocol with different functions and requirements than call control signaling. This will need to be taken into account in its mapping to IP networks.
This work will be done in conjunction with other IETF working groups looking at similar issues. The working group will also ensure that good information conduits exist with groups in other standards groups with expertise in the relevant signaling protocols or in the network requirements for the transport of the relevant signaling protocols.
The group will make use of existing IETF QoS and security technology and will not address creation of new QoS or security functions for IP networks. Nor will the working group work on defining new call control or device control protocols.
Done | Submit Initial draft of Signaling Architecture and Performance Requirements document as an Internet-Draft | |
Done | Issue initial IDs on Transport Layer Protocols and Encapsulation of Signaling Protocols | |
Done | Submit requirements document to IESG for publication as an RFC | |
Done | Submit revised version of drafts incorporating discussions and early implementation experience. | |
Done | Submit IP-based transport protocol draft to IESG for publication as a Standards-track RFC | |
Done | Submit initial adaptation drafts to IESG for consideration as a Proposed Standard | |
Done | Submit protocol Applicability Statements draft to IESG for consideration as an Informationl RFC | |
Done | Submit protocol MIB draft to IESG for consideration as an Proposed Standard | |
Done | Submit security framework to IESG for consideration as Proposed Standard | |
Done | Resubmit updated IUA specification to IESG for consideration as proposed standard | |
Done | Submit remaining adaptation drafts to IESG for consideration as a Proposed Standard | |
Mar 04 | Submit implementation guidelines and other extensions based on testing to IESG for consideration as Proposed Standard |
RFC | Status | Title |
---|---|---|
RFC2719 | I | Architectural Framework for Signaling Transport |
RFC2960 | PS | Stream Control Transmission Protocol |
RFC3057 | PS | ISDN Q.921-User Adaptation Layer |
RFC3257 | I | Stream Control Transmission Protocol Applicability Statement |
RFC3331 | PS | Signaling System 7 (SS7) Message Transfer Part (MTP)2 - User Adaption Layer |
RFC3332 | PS | SS7 MTP3-User Adaptation Layer (M3UA) |