5 Amendments and Endorsements to Referenced Specifications
29.2313GPPApplication of SIP-I Protocols to Circuit Switched (CS) core network architectureRelease 17Stage 3TS
5.1 ITU-T Q.1912.5 (Interworking between Session Initiation Protocol (SIP) and Bearer Independent Call Control protocol or ISDN User Part)
Only Profile C shall apply.
5.2 IETF RFC 2046 (Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types)
The "multipart" MIME type with the sub-type of "mixed" shall be supported as per IETF RFC 2046 [5] to allow exchange of multiple bodies in a single SIP message (e.g. initial INVITE message with ISUP IAM encapsulation and SDP bodies) between (G)MSC-Servers. Nested MIME message is not supported in the SIP-I based Nc interface.
The following MIME types only shall be supported in the SIP-I based Nc interface:
– The "application" MIME type as per IETF RFC 2046 [5] with the sub-type of "ISUP" as per IETF RFC 3204 [8] to allow exchange of ISUP encapsulation in SIP messages between (G)MSC-Servers.
– The "application" MIME type as per IETF RFC 2046 [5] with the sub-type of "SDP" as per IETF RFC 4566 [17] to allow exchange of SDP in SIP messages between (G)MSC-Servers.
5.3 IETF RFC 4566 (SDP: Session Description Protocol)
The following SDP properties are described for SIP-I call control procedures; use of SDP within H.248 MGW control protocol interface is described in the relevant profile specification, e.g. 3GPP TS 29.232 [18].
Table 5.3.1: Support of SDP Fields
|
field |
Meaning |
Support |
Comments |
|
v |
Protocol Version |
Mandatory |
The value shall be "v=0" |
|
o |
Origin |
Mandatory |
|
|
s |
Session Name |
Mandatory |
|
|
c |
Connection Data |
Mandatory |
|
|
t |
Timing |
Mandatory |
The value shall be "t=0 0" |
|
a |
Attributes |
Conditional |
See table 5.3.2. |
|
m |
Media Descriptions |
Mandatory |
|
|
b=RS, b=RR |
RTCP bandwidth modifiers |
Conditional |
A (G)MSC wishing to deactivate RTCP or using RTCP only to negotiate the use of RTP bearer multiplexing and RTP header compression (see 3GPP TS 29.414 [20]) shall set the RTCP bandwidth modifiers to zero. If a (G)MSC receives SDP bandwidth modifiers for RTCP equal to zero, it should reply by setting its RTCP bandwidth using SDP bandwidth modifiers with values equal to zero. |
|
NOTE: Fields not listed in the table may be ignored by the (G)MSC Server on receipt of the SDP. |
|||
Table 5.3.2: Support of Attributes
|
attr |
Meaning |
Support |
Comments |
|
rtpmap |
RTP map |
Conditional |
Mandatory for dynamic payload type and optional for static payload type. |
|
recvonly |
Receive only |
Mandatory |
|
|
sendrecv |
Send and receive |
Mandatory |
|
|
sendonly |
Send only |
Mandatory |
|
|
inactive |
Inactive |
Mandatory |
|
|
fmtp |
format specific parameters |
Conditional |
It is dependent upon the payload type if format specific parameters are required or not. |
|
maxptime |
Maximum packet size in ms |
See 3GPP TS 26.102 [31] |
|
|
ptime |
Packetisation length |
See 3GPP TS 26.102 [31] |
|
|
NOTE: Attributes not listed in the table may be ignored by the (G)MSC Server on receipt of the SDP. |
|||
5.4 IETF RFC 3966 (The tel URI for Telephone Numbers)
The Tel-URI, in both global and local telephone formats, shall be supported as defined in IETF RFC 3966 [6].
The "isub" parameter defined within IETF RFC 3966 [6] may be used to include the ISDN sub-address as may be required within the MSISDN. See 3GPP TS 23.003 [33]. When the "isub" parameter is present, the "isub-encoding" parameter defined within IETF RFC 4715 [34] shall be used to define the ISDN subaddress encoding type. The procedures specified within ITU-T Q.1912.5 [4] Annex B.5 for profile C shall be applied for Sub-addressing.
5.5 IETF RFC 2976 (The SIP INFO method)
The SIP INFO method shall be supported as per IETF RFC 2976 [7] to allow exchange of ISUP signalling between (G)MSC-Servers. The contents of the message body shall not be encrypted. The SIP INFO method shall not be used to carry any other kind of information, e.g. DTMF digits.
5.6 IETF RFC 3204 (MIME media types for ISUP and QSIG Objects)
Only ISUP Media Type is supported in the SIP-I based Nc interface, see ITU-T Q.1912.5 [4] Clause 5.4.1.2.
The "version" parameter is used to signal the ISUP version, as per ITU-T Q.1912.5 [4], sub-clause 5.4.1.2.
5.7 IETF RFC 3261(SIP: Session Initiation Protocol)
SIP-I initial and any subsequent INVITEs shall always include SDP.
3GPP SIP-I entities shall apply loose routeing on SIP-I based Nc.
SIP forking is not supported in the SIP-I Nc interface.
Race conditions for call clearing should be solved as described in clause 3.1.2 of the IETF RFC 5407 [28].
Non-INVITE transaction shall be implemented as specified in subclause 5.22 of the present specification.
5.8 IETF RFC 3262 (Reliability of Provisional Responses in the Session Initiation Protocol)
IETF RFC 3262 [10] specifies an extension to SIP in order to provide reliable provisional response messages. As support for PRACK’s is required for a SIP-I based Nc interface to support preconditions, the support of 100rel is mandatory for the 3GPP SIP-I profile on the Nc interface.
Procedures in clauses 3 and 4 of IETF RFC 3262 [10] apply on the Nc interface according to the following rules:
– A (G)MSC Server originating a SIP INVITE shall advertise its preference of provisional reliable responses via a SUPPORTED header containing the tag "100Rel".
– A (G)MSC Server receiving a SIP INVITE will receive a SUPPORTED header containing the tag "100rel" and shall include a REQUIRE header with tag "100rel" and RSeq header field when sending a response in the range 101-199.
– A (G)MSC Server receiving a response in the range 101-199 with a REQUIRE header present with tag "100rel" shall generate a PRACK request for this provisional response.
Authentication procedures are not required to be supported for PRACK (and any other) messages.
5.9 IETF RFC 3264 (An Offer/Answer Model with the Session Description Protocol)
5.9.1 Multicast Streams
Procedures in Clauses 5.2 and 6.2 of IETF RFC 3264 do not need to be supported.
5.9.2 3GPP Node Generating the Offer
Procedures in Clause 5.1 of IETF RFC 3264 apply with the following modifications:
– An MSC-S initiating an offer with multiple speech codec payload types in one m-line shall apply the related procedures in Clause 9 of 3GPP TS 23.153 [2], in particular the following requirement from IETF RFC 3264 Clause 5.1 is overruled:
"Once the offerer has sent the offer, it MUST be prepared to receive media for any recvonly streams described by that offer. It MUST be prepared to send and receive media for any sendrecv streams in the offer, and send media for any sendonly streams in the offer (ofcourse, it cannot actually send until the peer provides an answerwith the needed address and port information)."
5.9.3 3GPP Node Generating the Answer
Procedures in Clause 6 of IETF RFC 3264 apply with the following modifications:
– If the 3GPP MSC-S terminating the codec negotiation supports multiple speech codec payload types it shall apply the related procedures in Clause 9 of 3GPP TS 23.153 [2]. It does not need to be prepared to receive media encoded by speech codec payload types within the answered Available Codec List (see Clause 6.1.1).
5.9.4 3GPP Node as Offerer Processing of the Answer
Procedures in Clause 7 of IETF RFC 3264 apply with the following modifications:
– If the offering MSC supports multiple speech codecs and the MSC-S receives an answer with multiple speech codec payload types in one m-line, it shall apply the related procedures in Clause 9 of 3GPP TS 23.153 [2]. It does not need to be prepared to receive media encoded by speech codec payload types within the Available Codec List (see Clause 6.1.1) received in the answer.
5.9.5 Modifying the session
Procedures in Clause 8 of IETF RFC 3264 apply with the same modifications as described in Clauses 5.9.2, 5.9.3, and 5.9.4.
5.9.6 Unspecified Connection Address
The use of an "unspecified connection address" may be used during initial call establishment, for deferred MGW selection where no user plane connection has been seized by the Offerer.
No further applications for the use of an "unspecified connection address" are defined in SIP-I on Nc.
The "unspecified connection address" shall not be sent within a re-INVITE message.
For IPv6 implementations the "unspecified connection address" shall be defined by a domain name within the ".invalid" DNS top-level domain.
For IPv4 implementations if the "unspecified connection address" shall be defined by the IPv4 unspecified address (c= IN IP4 0.0.0.0).
5.10 IETF RFC 3311 (The Session Initiation Protocol (SIP) UPDATE Method)
The SIP UPDATE method shall be supported to allow updating of session parameters (media streams, codecs) during early and confirmed dialog, and allow the support of preconditions.
The support of the UPDATE method shall be negotiated on SIP-I based Nc according to the following rules:
– A (G)MSC Server originating a SIP INVITE request shall advertise its support of the UPDATE method via the ALLOW header listing the UPDATE method.
– A (G)MSC Server receiving a SIP INVITE request shall include an ALLOW header listing the UPDATE method when sending a response in the range 101-199. The MSC-S is then allowed to generate the UPDATE method, for the purpose of session modification during early dialog. In addition the MSC-S shall include an ALLOW header listing the UPDATE method when sending a 2xx final response.
– A (G)MSC Server receiving a response to a SIP INVITE request with an ALLOW header present listing the UPDATE method is then allowed to generate the UPDATE method.
Authentication and Integrity protection procedures are not required to be supported for the UPDATE message.
5.11 IETF RFC 3312 (Integration of Resource Management and Session Initiation Protocol)
Precondition type QoS only shall be supported using the segmented status type (therefore end-to-end status type e.g. Clause 13.1 does not apply) and the strength-tag value "mandatory" for the local segment and the strength-tag value "optional" for the remote segment. Precondition tag may be included in either REQUIRE or SUPPORTED header; the use of the SUPPORTED header is a deviation from this RFC when the strength-tag contains a "mandatory" value.
5.12 IETF RFC 3323 (A Privacy Mechanism for the Session Initiation Protocol)
IETF RFC 3323 [14] provides privacy requirements and mechanisms for SIP.
The Privacy header shall be supported to signal privacy of the P-Asserted-Identity and allow or restrict the presentation of the network asserted identity, as specified in 3GPP TS 23.231 [1]. The following privacy values may be used: header, none, critical, id.
5.13 IETF RFC 3325 (Private Extensions to the Session Initiation Protocol (SIP) for Network Asserted Identity within Trusted Networks)
IETF RFC 3325 [15] provides for the existence and trust of an asserted identity within a trust domain. It shall be supported on the SIP-I based Nc interface with the following modifications:
– a (G)MSC Server shall consider that neighbouring (G)MSC Servers connected via a Nc interface are trusted;
– the P-Preferred-Identity header and related requirements shall not be used.
5.14 IETF RFC 3326 (The Reason Header Field for the Session Initiation Protocol)
The SIP Reason header provides a means of transporting SIP or ISUP/BICC cause value in the SIP message; this is especially useful in SIP message without encapsulated ISUP information.
The SIP Reason header shall be supported as specified by IETF RFC 3326 [16] and by ITU-T Q.1912.5 [4] (as endorsed by sub-clause 5.1 of the present specification), with the following modifications:
– a Reason header field containing a Q.850 cause value shall be added to the SIP CANCEL message sent by the (G)MSC Server if the value is known; if unknown, the Q.850 cause value 31 (normal unspecified) shall be sent.
– the header field shall not be protected by any integrity mechanism.
5.15 IETF RFC 4028 (Session Timers in the Session Initiation Protocol)
SIP session continuity may be supported through the use of SIP Session Timer as per IETF RFC 4028 [24] with the following amendments.
– Clause 4 indicates that the minimum value of the Session-Expires header field should not be less than 30 minutes. Since the vast majority of mobile calls are significantly less than 30 minutes, it may be desirable to use a minimum Session-Expires of less than 30 minutes within the 3GPP CS core network. The RFC states that the value SHOULD NOT be less then 30 minutes. That statement is modified to "…MAY choose values of less than 30 minutes but greater than the absolute minimum of 90 seconds."
– Clause 8 "Proxy Behavior" is not applicable to MSC Servers.
5.16 IETF RFC 4960 (Stream Control Transmission Protocol)
See sub-clause 5.18.
5.17 Void
5.18 IETF RFC 4168 (The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol)
SCTP shall be the transport protocol for a SIP-I based Nc interface as per IETF RFC 4168 [27].
Semi-permanent SCTP associations shall be established between peer 3GPP SIP-I entities, i.e. the SCTP associations shall remain up under normal circumstances.
Local multi-homing should be supported. Remote multi-homing shall be supported.
Multiple local SCTP endpoints may be supported. Multiple remote SCTP endpoints shall be supported. When multiple local or remote SCTP endpoints are configured, several simultaneous SCTP associations shall be supported between peer 3GPP SIP-I entities.
Published IP addresses and ports for SCTP associations are supported as specified below:
– The (G)MSC Server shall support SCTP association setup, where an SCTP association request is performed to a published IP address and port.
– The (G)MSC Server may initiate SCTP association requests from a local published IP address and port.
– The (G)MSC Server shall accept incoming SCTP association requests from remote published IP address and port.
– When two endpoints are configured for a specific SCTP association between two published IP addresses and ports, one endpoint shall be configured as "server" and the peer endpoint as the "client" with respect to SCTP association setup.
NOTE: Published IP addresses or ports can be configured via O&M or they can be obtained through a DNS enquiry.
Dynamically assigned ports for SCTP associations are supported as specified below:
– The (G)MSC Server may initiate a SCTP association from an ephemeral (non-published) port.
– The (G)MSC Server shall accept incoming SCTP association requests from remote ephemeral (non-published) ports.
5.19 IETF RFC 791 (Internet Protocol, Version 4)
IPv4 (IETF RFC 791 [29]) shall be supported on the Nc interface.
5.20 IETF RFC 2460 (Internet Protocol, Version 6)
IPv6 (IETF RFC 2460 [30]) may be supported on the Nc interface.
5.21 IETF RFC 4715 (The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI)
The "isub-encoding" parameter defined within IETF RFC 4715 [yy] shall be present and include the ISDN subaddress encoding type when the "isub" parameter of the Tel-URI is present as defined in Clause 5.4.
5.22 IETF RFC 4320 (Actions Addressing Identified Issues with the Session Initiation Protocol’s (SIP) Non-INVITE Transaction)
The actions specified in clause 4 of the IETF RFC 4320 [35] shall be supported with following modifications:
– Actions which are not applicable for SCTP transport are not required to be supported.
– Actions specified for proxy are not applicable to MSC-S.
5.23 IETF RFC 5079 (Rejecting Anonymous Requests in the Session Initiation Protocol (SIP))
The response code 433 (Anonymity Disallowed) defined by IETF RFC 5079 [36] shall be supported on SIP-I on Nc.