One document matched: draft-elwell-sipping-qsig-tunnel-01.txt
Differences from draft-elwell-sipping-qsig-tunnel-00.txt
Internet Engineering Task Force J. Elwell
Internet Draft Siemens
J. McMillen
Avaya Inc.
JF. Rey/O. Rousseau
draft-elwell-sipping-qsig-tunnel-01.txt Alcatel
Expires: April 2004 October 2003
Tunnelling of QSIG over SIP
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC 2026 except that the right to produce derivative
works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies tunnelling of "QSIG" over the Session
Initiation Protocol (SIP). This enables calls between "islands" of
circuit switched networks that use QSIG signalling to be
interconnected by an IP network that uses SIP signalling without loss
of QSIG functionality.
This document is a product of the authors' activities in ECMA
(www.ecma.ch) on interoperability of QSIG with IP networks.
1 Introduction....................................................2
2 Terminology.....................................................3
3 Definitions.....................................................3
3.1 External definitions..........................................3
3.2 Other definitions.............................................3
3.2.1 Corporate telecommunication Network (CN)....................3
3.2.2 Egress gateway..............................................4
Elwell et alia Expires - April 2004 [Page 1]
Tunnelling of QSIG over SIP October 2003
3.2.3 Gateway.....................................................4
3.2.4 Ingress gateway.............................................4
3.2.5 IP network..................................................4
3.2.6 Media stream................................................4
3.2.7 Private Integrated Services Network (PISN)..................4
3.2.8 Private Integrated services Network eXchange (PINX).........4
4 Acronyms........................................................5
5 Background and architecture.....................................5
6 Procedures......................................................7
6.1 General.......................................................7
6.2 Encapsulation of QSIG messages in SIP messages................8
6.3 QSIG SETUP message handling at an ingress gateway.............8
6.3.1 Sending a SIP INVITE request................................8
6.3.2 Receipt of responses to the INVITE request..................9
6.4 QSIG SETUP message handling at an egress gateway..............9
6.4.1 Receiving a SIP INVITE request..............................9
6.5 Subsequent QSIG messages.....................................10
6.6 Terminating the SIP dialog...................................10
7 Example message sequences......................................11
7.1 Call establishment...........................................11
7.2 Call clearing................................................12
8 Security considerations........................................12
9 IANA considerations............................................12
10 Author's Addresses............................................12
11 Normative References..........................................13
Annex A - Change log.............................................14
1 Introduction
This document specifies tunnelling of "QSIG" over the Session
Initiation Protocol (SIP) within a corporate telecommunication
network (CN).
"QSIG" is a signalling protocol that operates between Private
Integrated Services eXchanges (PINX) within a Private Integrated
Services Network (PISN). A PISN provides circuit-switched basic
services and supplementary services to its users. QSIG is specified
in ECMA Standards, in particular [2] (call control in support of
basic services), [3] (generic functional protocol for the support of
supplementary services) and a number of Standards specifying
individual supplementary services.
NOTE. The name QSIG was derived from the fact that it is used for
signalling at the Q reference point. The Q reference point is a point
of demarcation between two PINXs.
SIP is an application layer protocol for establishing, terminating
and modifying multimedia sessions. It is typically carried over IP
Elwell et alia Expires - April 2004 [Page 2]
Tunnelling of QSIG over SIP October 2003
[6], [7]. Telephone calls are considered as a type of multimedia
session where just audio is exchanged. SIP is defined in [1].
Often a CN comprises both PISNs employing QSIG and IP networks
employing SIP. A call can originate at a user connected to a PISN and
terminate at a user connected to an IP network or vice versa. In
either case, a gateway provides interworking between QSIG and SIP at
the boundary between the PISN and the IP network. Basic call
interworking at a gateway is specified in [5]. Another case is where
a call originates at a user connected to a PISN, traverses an IP
network using SIP, and terminates at a user connected to another (or
another part of the same) PISN. This document addresses this last
case in a way that preserves all QSIG capabilities across the IP
network. It achieves this by tunnelling QSIG messages within SIP
requests and responses in the context of a SIP dialog.
The tunnelling of QSIG through a public IP network employing SIP is
outside the scope of this specification. However, the functionality
specified in this specification is in principle applicable to such a
scenario when deployed in conjunction with other relevant
functionality (e.g., address translation, security functions, etc.).
This specification is applicable to any interworking unit that can
act as a gateway between a PISN employing QSIG and a corporate IP
network employing SIP, with QSIG tunnelled within SIP requests and
responses.
2 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and
indicate requirement levels for compliant SIP implementations.
3 Definitions
For the purposes of this specification, the following definitions
apply.
3.1 External definitions
The definitions in [2] and [1] apply as appropriate.
3.2 Other definitions
3.2.1 Corporate telecommunication Network (CN)
Elwell et alia Expires - April 2004 [Page 3]
Tunnelling of QSIG over SIP October 2003
Sets of privately-owned or carrier-provided equipment that are
located at geographically dispersed locations and are interconnected
to provide telecommunication services to a defined group of users.
NOTE. A CN can comprise a PISN, a private IP network (intranet) or a
combination of the two.
3.2.2 Egress gateway
A gateway handling a QSIG call established in the direction IP
network to PISN.
3.2.3 Gateway
An entity that behaves as a QSIG Transit PINX with QSIG carried over
a circuit-switch link within a PISN on one side and QSIG tunnelled
over SIP within an IP network on the other side.
3.2.4 Ingress gateway
A gateway handling a QSIG call established in the direction PISN to
IP network.
3.2.5 IP network
A network, unless otherwise stated a corporate network, offering
connectionless packet-mode services based on the Internet Protocol
(IP) as the network layer protocol.
3.2.6 Media stream
Audio or other user information transmitted in UDP packets, typically
containing RTP, in a single direction between the gateway and a peer
entity participating in a session established using SIP.
NOTE. Normally a SIP session establishes a pair of media streams, one
in each direction.
3.2.7 Private Integrated Services Network (PISN)
A CN or part of a CN that employs circuit-switched technology and
QSIG signalling.
3.2.8 Private Integrated services Network eXchange (PINX)
A PISN nodal entity comprising switching and call handling functions
and supporting QSIG signalling in accordance with [2].
Elwell et alia Expires - April 2004 [Page 4]
Tunnelling of QSIG over SIP October 2003
4 Acronyms
IP Internet Protocol
PINX Private Integrated services Network eXchange
PISN Private Integrated Services Network
RTP Real-time Transport Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
TCP Transmission Control Protocol
UA User Agent
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
5 Background and architecture
This document concerns the case of a call that originates at a user
connected to a PISN employing QSIG, traverses an IP network employing
SIP, and terminates at a user connected to another (or another part
of the same) PISN. This can be achieved by employing a gateway at
each boundary between a PISN employing QSIG and an IP network
employing SIP, as shown in Figure 1.
PISN IP network (SIP) PISN
(QSIG) <-----------------------> (QSIG)
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|PINX | |Gate-| |SIP | |SIP | |Gate-| |PINX |
| |---|way |---|proxy|---|proxy|---|way |---| |
| | | | | | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 1 – Call from QSIG via SIP to QSIG
EDITOR'S NOTE. Further consideration needs to be given to tunnelling
call-unrelated signalling information (both connection-oriented and
connectionless).
Each gateway can provide interworking as specified in [5]. This
provides a basic call capability. However, [5] only specifies
interworking for QSIG basic call, as specified in [2]. Many of the
other capabilities of QSIG (support for supplementary services and
additional network features) as specified in other standards and in
vendor-specific specifications are not covered. Some of these
additional capabilities of QSIG are suitable for interworking with
SIP and might be the subject of future informational RFCs or other
specifications. Other capabilities of QSIG are unsuitable for
interworking with SIP because corresponding capabilities do not exist
in SIP or are achieved in ways that are incompatible with QSIG.
Therefore interworking at a gateway between QSIG and SIP will be
Elwell et alia Expires - April 2004 [Page 5]
Tunnelling of QSIG over SIP October 2003
limited to those QSIG capabilities that have sufficiently compatible
equivalents in SIP. Each capability requires special implementation
in the gateway, and therefore a typical gateway might provide
interworking for only a subset of capabilities for which interworking
is feasible.
The result of this is that there will be a loss of capability on a
call from QSIG to SIP or vice versa. For a call similar to that shown
in figure 1 there will likewise be a loss of capability. This can be
compounded if the two gateways are of different types, since only
those capabilities common to both gateways will survive end-to-end.
The solution is to tunnel QSIG messages through the IP network within
SIP messages so that no end-to-end QSIG capabilities are lost. One of
the two gateways originates a SIP dialog to the other gateway. SIP
messages within the dialog are used to tunnel QSIG messages. Through
the use of SDP, the dialog also establishes a session in which media
streams carry user information (e.g., speech) between the two QSIG
gateways. The two gateways act as QSIG Transit PINXs, which relay
QSIG messages with little or no modification.
In a conventional PISN employing QSIG, two PINXs are connected by
means of an inter-PINX link, which comprises a signalling channel
(carrying QSIG messages) and one or more user information channels
carrying speech, modem information or data. With the tunnelling
solution, the IP network provides the inter-PINX link between the two
gateways acting as Transit PINXs. The tunnel provided by SIP for QSIG
messages acts as the signalling channel and the media streams act as
the user information channels.
This document restricts itself to the case where a single dialog
between two gateways is used for a single QSIG call. This means that
the dialog is established when the QSIG call is established and
cleared down when the QSIG call is cleared down. An enhanced scenario
in which a single SIP dialog is maintained long term and used to
tunnel a multiplicity of QSIG calls, with the possibility of multiple
QSIG calls being in progress at any one time, is outside the scope of
this document.
When a gateway (the ingress gateway) receives a QSIG call
establishment request (QSIG SETUP message) from the PISN, it needs to
generate a SIP INVITE request using a Request-URI that will route the
request to an appropriate egress gateway. The Request-URI must be
derived in some way from the required destination of the QSIG call
(as indicated in the Called party number information element of the
QSIG SETUP message). The Request-URI can explicitly identify the
egress gateway or it can simply identify the required destination.
The first case is likely to require some sort of look-up capability
in the gateway, the configuration of which is outside the scope of
Elwell et alia Expires - April 2004 [Page 6]
Tunnelling of QSIG over SIP October 2003
this document. For the latter case algorithmic mapping of the called
party number to a Request-URI might be sufficient, but this delegates
the task of selecting an appropriate egress gateway to SIP proxies.
An ingress gateway may determine from the required destination of a
call that the destination is not reachable via QSIG tunnelling. In
this case the QSIG gateway can either route the call onwards within
the PISN or can route the call into the IP network using interworking
as specified in [5]. How an ingress gateway determines that the
destination is not reachable via QSIG tunnelling is outside the scope
of this document.
If an ingress gateway maps the QSIG called party number to a Request
URI that does not explicitly identify a particular egress gateway,
routing of the INVITE request is left to SIP proxies. A proxy might
route the request to a UAS that is not an egress gateway to QSIG, in
which case QSIG tunnelling will not be possible. Allowing the call to
proceed in this situation is likely to be undesirable, since the
ingress gateway expects to carry out QSIG tunnelling whereas
interworking with SIP, as specified in [5], would be more
appropriate. To cater for this situation, a mechanism is defined that
causes the an INVITE request containing tunnelled QSIG to be rejected
by an egress gateway that does not support this capability.
NOTE. Allowing the INVITE request to be routed by proxies either to
an egress gateway to QSIG or to some other UAS without the ability
for the ingress gateway to choose in advance is undesirable. It
implies that the ingress gateway maps the QSIG SETUP message to a SIP
INVITE request in accordance with both this document and [5]
simultaneously. Although this may seem feasible superficially,
architecturally it is dangerous because with QSIG tunnelling the
ingress gateway should act as a QSIG Transit PINX whereas with
interworking in accordance with [5] it should act as a QSIG Outgoing
Gateway PINX. The ingress gateway will not know for certain which
behaviour to adopt until a 200 OK arrives, and therefore in the
meantime it will not know how to handle information relating to
certain QSIG capabilities (supplementary services and additional
network features) in the QSIG SETUP message. It is not clear whether
this can be handled safely for all possible QSIG capabilities
(including vendor-specific capabilities). For this reason, this
specification and [5] require the ingress gateway to make a decision
between tunnelling and interworking respectively.
6 Procedures
6.1 General
A gateway SHALL behave as a QSIG Transit PINX as specified in [2] and
modified as specified below.
Elwell et alia Expires - April 2004 [Page 7]
Tunnelling of QSIG over SIP October 2003
6.2 Encapsulation of QSIG messages in SIP messages
When encapsulating a QSIG message inside a SIP message, a gateway
SHALL include the QSIG message in a MIME body of the SIP request or
response in accordance with [8] using media type application/QSIG.
QSIG segmentation SHALL NOT apply. The body shall also contain a
Content-Disposition header indicating "signal" and
"handling=required".
If any other MIME body is to be included (e.g., SDP), the gateway
shall use multi-part MIME.
EDITOR'S NOTE. In the multipart case, the SIP Content-Type header
should indicate "multipart/mixed". In other cases, what should the
SIP Content-Type and Content-Disposition headers be set to?
6.3 QSIG SETUP message handling at an ingress gateway
6.3.1 Sending a SIP INVITE request
The ingress gateway, on receipt of a QSIG SETUP message eligible for
tunnelling over SIP to an egress gateway, SHALL build a SIP INVITE
request message containing a Request-URI suitable for routing towards
a suitable egress.
NOTE. The Request-URI should be derived in some way from the Called
party number information in the QSIG SETUP message. The Request-URI
can explicitly identify a particular egress gateway. Alternatively it
can identify the final destination in a way that leaves selection of
a suitable egress gateway to SIP proxies.
The From header should contain a URI identifying either the ingress
gateway or the calling party (derived from the QSIG Calling party
number information element).
The ingress gateway SHALL encapsulate the QSIG SETUP message in the
SIP INVITE request.
EDITOR'S NOTE. Should we relax this to allow the QSIG SETUP message
to be sent later after receipt of 200 OK? This might be more in line
with the proposed multiple calls / 1 dialog scenario. On the other
hand, without a body containing encapsulated QSIG, there will be
nothing to instruct the egress gateway to reject if it does not
support encapsulated QSIG.
The encapsulated QSIG SETUP message MAY differ from the received
SETUP message in accordance with acceptable modification at a QSIG
Transit PINX. For example, the Channel identification information
Elwell et alia Expires - April 2004 [Page 8]
Tunnelling of QSIG over SIP October 2003
element MAY change. Because in the encapsulated QSIG SETUP message
the contents of the Channel identification information element have
no significance, the channel number field SHOULD contain value 1 and
the preferred/exclusive field SHOULD contain value 1 (exclusive).
The INVITE request SHALL contain an SDP offer proposing a pair of
media streams, one in each direction, that the gateway can map to the
user information channel indicated in the Channel identification
information element in the received QSIG message. The media streams
SHALL be suitable for use in accordance with the Bearer capability
information element in the received QSIG SETUP message.
After sending the SIP INVITE request, the ingress gateway SHALL NOT
encapsulate any further message from QSIG until a SIP 200 OK response
has been received.
6.3.2 Receipt of responses to the INVITE request
The action specified below is in addition to normal UA handling of a
SIP response.
On receipt of a SIP 4xx, 5xx or 6xx final response, the ingress
gateway SHALL either take alternative action to route the call
(outside the scope of this document) or clear the call using an
appropriate cause value in the QSIG Cause information element of the
QSIG call clearing message concerned (DISCONNECT, RELEASE or RELEASE
COMPLETE). If the SIP response contains an encapsulated QSIG RELEASE
COMPLETE message, the ingress gateway MAY use the cause value in that
message to determine the cause value when clearing the call.
EDITOR'S NOTE. Cause mapping may need to be specified.
NOTE. A SIP 415 Unsupported Media Type final response can be expected
if the UAS does not support encapsulated QSIG.
On receipt of a SIP 200 OK response, the ingress gateway SHALL carry
out normal SIP processing, including transmission of an ACK request,
and SHALL act upon any encapsulated QSIG message. The ingress gateway
SHALL also connect the QSIG user information channel to the media
streams indicated in the SDP answer.
EDITOR'S NOTE. Is the Supported header necessary?
6.4 QSIG SETUP message handling at an egress gateway
6.4.1 Receiving a SIP INVITE request
On receipt of a SIP INVITE request containing a QSIG message in the
body of the request, the egress gateway shall behave as follows.
Elwell et alia Expires - April 2004 [Page 9]
Tunnelling of QSIG over SIP October 2003
If the QSIG message is a SETUP message acceptable for routing onwards
into the PISN, the egress gateway SHALL select a user information
channel on the PISN side and shall forward the QSIG SETUP message.
The forwarded QSIG SETUP message MAY differ from the received SETUP
message in accordance with acceptable modification at a QSIG Transit
PINX. In particular, the Channel identification information element
SHALL reflect the selected user information channel. The egress
gateway SHALL also send a SIP 200 response containing an SDP answer
confirming a pair of media streams (one in each direction) that the
gateway can map to the selected user information channel used in
accordance with the Bearer capability information element in the
forwarded QSIG SETUP message. The egress gateway SHALL also connect
the QSIG user information channel to the media streams indicated in
the SDP answer.
The egress gateway MAY include in the SIP 200 response an
encapsulated QSIG SETUP ACKNOWLEDGE message or CALL PROCEEDING
message. Otherwise the gateway SHALL transmit this first responding
QSIG message later in a SIP INFO message in accordance with 6.5.
If the egress gateway contains an INVITE request containing a QSIG
message that is not a SETUP message suitable for routing onwards, the
egress gateway SHALL send back a ???? response containing a
responding QSIG message in accordance with ECMA-143, e.g, a RELEASE
COMPLETE message containing an appropriate value in the QSIG Cause
information element.
EDITOR’S NOTE. Appropriate SIP response code to be identified.
NOTE. If the SIP UAS does not support encapsulated QSIG and therefore
is not capable of being an egress gateway, RFC3261 requires it to
reject the INVITE request using response code 415 Unsupported Media
Type.
6.5 Subsequent QSIG messages
After receipt transmitting a 200 OK response (egress gateway) or
transmitting an ACK following receipt of a 200 OK response (ingress
gateway), a gateway SHALL encapsulate any further QSIG messages for
transmission to the peer gateway in the body of a SIP INFO request
[9] and SHALL be able to receive further QSIG messages from the peer
gateway encapsulated in the body of SIP INFO request. The exception
is a QSIG RELEASE COMPLETE message, which MAY be encapsulated in a
SIP BYE request in accordance with 6.6.
6.6 Terminating the SIP dialog
Elwell et alia Expires - April 2004 [Page 10]
Tunnelling of QSIG over SIP October 2003
When a gateway determines that a QSIG call has terminated, it SHALL
terminate the SIP session by transmitting a BYE request. If a gateway
transmits the final QSIG message of the call (RELEASE COMPLETE), the
gateway MAY encapsulate that QSIG message in the BYE request.
Otherwise the gateway SHALL transmit the BYE request after the final
QSIG message has been sent or received and SHALL NOT encapsulate a
QSIG message in the BYE request.
7 Example message sequences
7.1 Call establishment
IP network
+-----------+ (SIP with +-----------+
PISN |Ingress | tunnelled |Egress | PISN
(QSIG) |gateway | QSIG) |gateway | (QSIG)
+-----------+ +-----------+
QSIG SETUP || SIP INVITE request ||
----------------->|| QSIG SETUP ||
|| ||
QSIG CALL ||----------------------->|| QSIG SETUP
PROCEEDING || ||----------------->
<-----------------|| SIP 200 OK ||
|| QSIG CALL PROCEEDING || QSIG CALL
||<-----------------------|| PROCEEDING
|| ||<-----------------
|| SIP ACK ||
||----------------------->||
|| || QSIG ALERTING
|| SIP INFO ||<-----------------
|| QSIG ALERTING ||
||<-----------------------||
QSIG ALERTING || ||
<-----------------|| SIP 200 OK ||
||----------------------->||
|| || QSIG CONNECT
|| SIP INFO ||<-----------------
|| QSIG CONNECT ||
||<-----------------------|| QSIG CONNECT ACK
QSIG CONNECT || ||----------------->
<-----------------|| SIP 200 OK ||
||----------------------->||
|| ||
|| SIP INFO ||
|| QSIG CONNECT ACK ||
||----------------------->||
QSIG CONNECT ACK || ||
----------------->|| SIP 200 OK ||
||<-----------------------||
Elwell et alia Expires - April 2004 [Page 11]
Tunnelling of QSIG over SIP October 2003
|| ||
Figure 2 – Call establishment QSIG-SIP-QSIG
7.2 Call clearing
IP network
+-----------+ (SIP with +-----------+
PISN |Ingress | tunnelled |Egress | PISN
(QSIG) |gateway | QSIG) |gateway | (QSIG)
+-----------+ +-----------+
QSIG DISCONNECT || SIP INFO ||
----------------->|| QSIG DISCONNECT ||
||----------------------->|| QSIG DISCONNECT
QSIG RELEASE || ||----------------->
<-----------------|| SIP 200 OK ||
||<-----------------------||
QSIG RELEASE || ||
COMPLETE || SIP INFO ||
----------------->|| QSIG RELEASE ||
||<-----------------------|| QSIG RELEASE
|| ||<-----------------
|| ||
|| || QSIG RELEASE
|| || COMPLETE
|| SIP 200 OK ||----------------->
||----------------------->||
|| ||
|| SIP BYE ||
|| QSIG RELEASE COMPLETE ||
||----------------------->||
|| ||
|| SIP 200 OK ||
||<-----------------------||
|| ||
Figure 3 – Call clearing QSIG-SIP-QSIG
8 Security considerations
EDITOR'S NOTE. To be added
9 IANA considerations
None
10 Author's Addresses
John Elwell
Elwell et alia Expires - April 2004 [Page 12]
Tunnelling of QSIG over SIP October 2003
Siemens Communications
Technology Drive
Beeston
Nottingham, UK, NG9 1LA
email: john.elwell@siemens.com
Joanne McMillen
Avaya Inc.
1300 W. 120th Ave.
Westminster, CO 80234-2726
email: joanne@avaya.com
Olivier Rousseau
Alcatel Business Systems
32,Avenue Kleber
92700 Colombes
France
email: olivier.rousseau@col.bsf.alcatel.fr
Jean-Francois Rey
Alcatel Business Systems
8,Rue de Kervezennec, BP 82 802
29228 Brest Cedex 2
France
email: jean-francois.rey@bst.bsf.alcatel.fr
11 Normative References
[1] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation
protocol", RFC 3261.
[2] International Standard ISO/IEC 11572 "Private Integrated Services
Network - Circuit-mode Bearer Services - Inter-Exchange Signalling
Procedures and Protocol" (also published by ECMA as Standard
ECMA-143)
[3] International Standard ISO/IEC 11582 "Private Integrated Services
Network - Generic Functional Protocol for the Support of
Supplementary Services - Inter-Exchange Signalling Procedures and
Protocol" (also published by ECMA as Standard ECMA-165)
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] F. Derks, J. Elwell, P. Mourot, O. Rousseau, "Interworking
between SIP and QSIG", draft-ietf-sipping-qsig2sip-03
[6] J. Postel, "Internet Protocol", RFC 791.
Elwell et alia Expires - April 2004 [Page 13]
Tunnelling of QSIG over SIP October 2003
[7] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)",
RFC 2460.
[8] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG
objects", RFC 3204, December 2001.
[9] Donovan, S., "The SIP INFO Method", RFC2976, October 2000.
Annex A (temporary) - Change log
Elwell et alia Expires - April 2004 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 00:11:49 |