[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Protocol Action: 'Interworking between SIP and QSIG' to BCP
The IESG has approved the following document:
- 'Interworking between SIP and QSIG '
<draft-ietf-sipping-qsig2sip-04.txt> as a BCP
This document is the product of the Session Initiation Proposal Investigation
Working Group.
The IESG contact person is Allison Mankin.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-04.txt
Technical Summary
This document specifies interworking between the Session Initiation
Protocol (SIP) and QSIG within corporate telecommunication networks
(also known as enterprise networks). SIP is an Internet application-
layer control (signalling) protocol for creating, modifying, and
terminating sessions with one or more participants. These sessions
include, in particular, telephone calls. QSIG is a signaling
protocol for creating, modifying and terminating circuit-switched
calls, in particular telephone calls, within Private Integrated
Services Networks (PISNs). QSIG is specified in a number of Ecma
Standards and published also as ISO/IEC standards.
The approach taken in this document is similar to the approach used
in other SIP-PSTN interworking specifications. The parts of QSIG that
have direct analogs in SIP are mapped to the appropriate SIP element,
and the parts that do not are transferred as MIME body parts using
conventional encapsulations.
Working Group Summary
The document is a product of the SIPPING working group and was
developed over the course of about four years. There were some
concerns as to whether the SIPPING working group had adequate
expertise in QSIG, so informal external review was used to
establish a general agreement as to the adequacy of the work.
The work itself was not controversial within the working group,
which reported a high level of consensus on the output document.
Protocol Quality
This document was reviewed under the PROTO process by Dean Willis,
co-chair of the SIP and SIPPING working groups. The methodology used
in this specification is consistent with that used in other SIP-PSTN
interworking specification such as RFC 3398 and RFC 3578.
The Responsible AD was Allison Mankin.
IANA Note
This document has no IANA Considerations section because it raises
no IANA considerations. It may be appropriate to add an IANA
Considerations section with this disclaimer.
Notes to the RFC Editor
Abstract
OLD
ECMA Standards
NEW
Ecma Standards
[Rationale: Ecma now uses the word "Ecma", except in the names of its
Standards where it continues to use the old name "ECMA" (e.g., "ECMA-155").
Make only the changes specified in these Notes, please.]
---
Section 1 Introduction, paragraph 2:
OLD:
ECMA Standards
NEW:
Ecma Standards
---
Section 5, Background and architecture, paragraphs 9 and 10
(two occurrences):
OLD:
media information
NEW:
media streams
---
Section 5, Background and architecture, paragraph 11:
OLD:
transferring media information
NEW:
transferring media streams
OLD:
packetization of media information
NEW:
packetization of media streams
OLD:
de-packetization of media information
NEW:
de-packetization of media streams
-----
Section 6, Overview, paragraph 2:
OLD:
an initial response message completes negotiation of the bearer channel
NEW:
an initial response message (e.g., CALL PROCEEDING) completes
negotiation of the bearer channel
----
Section 9.1, Mapping from QSIG to SIP, paragraph 2:
OLD:
whether the gateway trusts the next hop SIP node
NEW:
whether the gateway is in the same trust domain (as defined
in [14]) as the next hop SIP node
----
Section 9.2.2, Generating the QSIG Calling party number
information element", paragraph 5:
OLD:
and the gateway supports this header, the gateway SHALL
New:
and the gateway supports this header, or if the value in the
>From header indicates anonymous, the gateway SHALL
----
Section 11.1, General
OLD:
Normal considerations apply for UA use of SIP security measures,
including digest authentication, TLS and SMIME.
NEW:
Normal considerations apply for UA use of SIP security measures,
including digest authentication, TLS and S/MIME as described in [10].
Please substitute "S/MIME" for "SMIME" throughout.
----
Section 12, Acknowledgements, paragraph 2:
OLD:
members of ECMA
NEW:
members of Ecma
OLD:
this draft
NEW:
this document
----
Section 14, Normative References, reference [1]:
OLD:
published by ECMA
NEW:
published by Ecma
Section 14, Normative References, reference [2]:
OLD:
published by ECMA
NEW:
published by Ecma
In Section 14, Normative References, reference [3]
OLD:
published by ECMA
NEW:
published by Ecma
- 30 -
_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce