Interworking between the Session Initiation Protocol (SIP) and QSIG
RFC 4497

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    sipping mailing list <sipping@ietf.org>, 
    sipping chair <sipping-chairs@tools.ietf.org>
Subject: 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-05.txt> as a BCP

This document is the product of the Session Initiation Proposal 
Investigation Working Group. 

The IESG contact persons are Allison Mankin and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-05.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 -