Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4497

Interworking between the Session Initiation Protocol (SIP) and QSIG

Pages: 65
Best Current Practice: 117
Updated by:  8996
Part 2 of 4 – Pages 12 to 32
First   Prev   Next

Top   ToC   RFC4497 - Page 12   prevText

8. Message Mapping Requirements

8.1. Message Validation and Handling of Protocol Errors

The gateway SHALL validate received QSIG messages in accordance with the requirements of [2] and SHALL act in accordance with [2] on detection of a QSIG protocol error. The requirements of this section for acting on a received QSIG message apply only to a received QSIG message that has been successfully validated and that satisfies one of the following conditions: -the QSIG message is a SETUP message and indicates a destination in the IP network and a bearer capability for which the gateway is able to provide interworking; or -the QSIG message is a message other than SETUP and contains a call reference that identifies an existing call for which the gateway is providing interworking between QSIG and SIP. The processing of any valid QSIG message that does not satisfy any of these conditions is outside the scope of this specification. Also, the processing of any QSIG message relating to call-independent signalling connections or connectionless transport, as specified in [3], is outside the scope of this specification. If segmented QSIG messages are received, the gateway SHALL await receipt of all segments of a message and SHALL validate and act on the complete reassembled message. The gateway SHALL validate received SIP messages (requests and responses) in accordance with the requirements of [10] and SHALL act in accordance with [10] on detection of a SIP protocol error.
Top   ToC   RFC4497 - Page 13
   Requirements of this section for acting on a received SIP message
   apply only to a received message that has been successfully validated
   and that satisfies one of the following conditions:

   - the SIP message is an INVITE request that contains no tag parameter
     in the To header field, does not match an ongoing transaction
     (i.e., is not a merged request; see Section 8.2.2.2 of [10]), and
     indicates a destination in the PISN for which the gateway is able
     to provide interworking; or

   - the SIP message is a request that relates to an existing dialog
     representing a call for which the gateway is providing interworking
     between QSIG and SIP; or

   - the SIP message is a CANCEL request that relates to a received
     INVITE request for which the gateway is providing interworking with
     QSIG but for which the only response sent is informational (1xx),
     no dialog having been confirmed; or

   - the SIP message is a response to a request sent by the gateway in
     accordance with this section.

   The processing of any valid SIP message that does not satisfy any of
   these conditions is outside the scope of this specification.

   NOTE: These rules mean that an error detected in a received message
   will not be propagated to the other side of the gateway.  However,
   there can be an indirect impact on the other side of the gateway,
   e.g., the initiation of call clearing procedures.

   The gateway SHALL run QSIG protocol timers as specified in [2] and
   SHALL act in accordance with [2] if a QSIG protocol timer expires.
   Any other action on expiry of a QSIG protocol timer is outside the
   scope of this specification, except that if it results in the
   clearing of the QSIG call, the gateway SHALL also clear the SIP call
   in accordance with Section 8.4.5.

   The gateway SHALL run SIP protocol timers as specified in [10] and
   SHALL act in accordance with [10] if a SIP protocol timer expires.
   Any other action on expiry of a SIP protocol timer is outside the
   scope of this specification, except that if it results in the
   clearing of the SIP call, the gateway SHALL also clear the QSIG call
   in accordance with Section 8.4.5.
Top   ToC   RFC4497 - Page 14

8.2. Call Establishment from QSIG to SIP

8.2.1. Call Establishment from QSIG to SIP Using En Bloc Procedures

The following procedures apply when the gateway receives a QSIG SETUP message containing a Sending Complete information element or the gateway receives a QSIG SETUP message and is able to determine that the number in the Called party number information element is complete. NOTE: In the absence of a Sending Complete information element, the means by which the gateway determines the number to be complete is an implementation matter. It can involve knowledge of the numbering plan and/or use of inter-digit timer expiry.
8.2.1.1. Receipt of QSIG SETUP Message
On receipt of a QSIG SETUP message containing a number that the gateway determines to be complete in the Called party number information element, or containing a Sending complete information element and a number that could potentially be complete, the gateway SHALL map the QSIG SETUP message to a SIP INVITE request. The gateway SHALL also send a QSIG CALL PROCEEDING message. The gateway SHALL generate the SIP Request-URI, To, and From fields in the SIP INVITE request in accordance with Section 9. The gateway SHALL include in the INVITE request a Supported header containing option tag 100rel, to indicate support for [11]. The gateway SHALL include SDP offer information in the SIP INVITE request as described in Section 10. It SHOULD also connect the incoming media stream to the user information channel of the inter- PINX link, to allow the caller to hear in-band tones or announcements and prevent speech clipping on answer. Because of forking, the gateway may receive more than one media stream, in which case it SHOULD select one (e.g., the first received). If the gateway is able to correlate an unselected media stream with a particular early dialog established using a reliable provisional response, it MAY use the UPDATE method [19] to stop that stream and then use the UPDATE method to start that stream again if a 2xx response is received on that dialog. On receipt of a QSIG SETUP message containing a Sending complete information element and a number that the gateway determines to be incomplete in the Called party number information element, the gateway SHALL initiate QSIG call clearing procedures using cause value 28, "invalid number format (address incomplete)".
Top   ToC   RFC4497 - Page 15
   If information in the QSIG SETUP message is unsuitable for generating
   any of the mandatory fields in a SIP INVITE request (e.g., if a
   Request-URI cannot be derived from the QSIG Called party number
   information element) or for generating SDP information, the gateway
   SHALL NOT issue a SIP INVITE request and SHALL initiate QSIG call
   clearing procedures in accordance with [2].

8.2.1.2. Receipt of SIP 100 (Trying) Response to an INVITE Request
A SIP 100 response SHALL NOT trigger any QSIG messages. It only serves the purpose of suppressing INVITE request retransmissions.
8.2.1.3. Receipt of SIP 18x provisional response to an INVITE request
The gateway SHALL map a received SIP 18x response to an INVITE request to a QSIG PROGRESS or ALERTING message based on the following conditions. - If a SIP 180 response is received and no QSIG ALERTING message has been sent, the gateway SHALL generate a QSIG ALERTING message. The gateway MAY supply ring-back tone on the user information channel of the inter-PINX link, in which case the gateway SHALL include progress description number 8 in the QSIG ALERTING message. Otherwise the gateway SHALL NOT include progress description number 8 in the QSIG ALERTING message unless the gateway is aware that in-band information (e.g., ring-back tone) is being transmitted. - If a SIP 181/182/183 response is received, no QSIG ALERTING message has been sent, and no message containing progress description number 1 has been sent, the gateway SHALL generate a QSIG PROGRESS message containing progress description number 1. NOTE: This will ensure that QSIG timer T310 is stopped if running at the Originating PINX. In all other scenarios, the gateway SHALL NOT map the SIP 18x response to a QSIG message. If the SIP 18x response contains a Require header with option tag 100rel, the gateway SHALL send back a SIP PRACK request in accordance with [11].
8.2.1.4. Receipt of SIP 2xx Response to an INVITE Request
If the gateway receives a SIP 2xx response as the first SIP 2xx response to a SIP INVITE request, the gateway SHALL map the SIP 2xx response to a QSIG CONNECT message. The gateway SHALL also send a SIP ACK request to acknowledge the 2xx response. The gateway SHALL
Top   ToC   RFC4497 - Page 16
   NOT include any SDP information in the SIP ACK request.  If the
   gateway receives further 2xx responses, it SHALL respond to each in
   accordance with [10], SHOULD issue a BYE request for each, and SHALL
   NOT generate any further QSIG messages.

   Media streams will normally have been established in the IP network
   in each direction.  If so, the gateway SHALL connect the media
   streams to the corresponding user-information channel on the inter-
   PINX link if it has not already done so and stop any local ring-back
   tone.

   If the SIP 2xx response is received in response to the SIP PRACK
   request, the gateway SHALL NOT map this message to any QSIG message.

   NOTE: A SIP 2xx response to the INVITE request can be received later
   on a different dialog as a result of a forking proxy.

8.2.1.5. Receipt of SIP 3xx Response to an INVITE Request
On receipt of a SIP 3xx response to an INVITE request, the gateway SHALL act in accordance with [10]. NOTE: This will normally result in sending a new SIP INVITE request. Unless the gateway supports the QSIG Call Diversion Supplementary Service, no QSIG message SHALL be sent. The definition of Call Diversion Supplementary Service for QSIG to SIP interworking is beyond the scope of this specification.

8.2.2. Call Establishment from QSIG to SIP Using Overlap Procedures

SIP uses en bloc signalling, and it is strongly RECOMMENDED to avoid using overlap signalling in a SIP network. A SIP/QSIG gateway dealing with overlap signalling SHOULD perform a conversion from overlap to en bloc signalling method using one or more of the following mechanisms: - timers; - numbering plan information; - the presence of a Sending complete information element in a received QSIG INFORMATION message. If the gateway performs a conversion from overlap to en bloc signalling in the SIP network, then the procedures defined in Section 8.2.2.1 SHALL apply.
Top   ToC   RFC4497 - Page 17
   However, for some applications it might be impossible to avoid using
   overlap signalling in the SIP network.  In this case, the procedures
   defined in Section 8.2.2.2 SHALL apply.

8.2.2.1. En Bloc Signalling in SIP Network
8.2.2.1.1. Receipt of QSIG SETUP Message
On receipt of a QSIG SETUP message containing no Sending complete information element and a number in the Called party number information element that the gateway cannot determine to be complete, the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message, start QSIG timer T302, and await further number digits.
8.2.2.1.2. Receipt of QSIG INFORMATION Message
On receipt of each QSIG INFORMATION message containing no Sending complete information element and containing a number that the gateway cannot determine to be complete, QSIG timer T302 SHALL be restarted. When QSIG timer T302 expires or a QSIG INFORMATION message containing a Sending complete information element is received, the gateway SHALL send a SIP INVITE request as described in Section 8.2.1.1. The Request-URI and To fields (see Section 9) SHALL be generated from the concatenation of information in the Called party number information element in the received QSIG SETUP and INFORMATION messages. The gateway SHALL also send a QSIG CALL PROCEEDING message.
8.2.2.1.3. Receipt of SIP Responses to INVITE Requests
SIP responses to INVITE requests SHALL be mapped as described in 8.2.1.
8.2.2.2. Overlap Signalling in SIP Network
The procedures below for using overlap signalling in the SIP network are in accordance with the principles described in [18] for using overlap sending when interworking with ISDN User Part (ISUP). In [18], there is discussion of some potential problems arising from the use of overlap sending in the SIP network. These potential problems are applicable also in the context of QSIG-SIP interworking and can be avoided if overlap sending in the QSIG network is terminated at the gateway, in accordance with Section 8.2.2.1. The procedures below should be used only where it is not feasible to use the procedures of Section 8.2.2.1.
Top   ToC   RFC4497 - Page 18
8.2.2.2.1. Receipt of QSIG SETUP Message
On receipt of a QSIG SETUP message containing no Sending complete information element and a number in the Called party number information element that the gateway cannot determine to be complete, the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message and start QSIG timer T302. If the QSIG SETUP message contains the minimum number of digits required to route the call in the IP network, the gateway SHALL send a SIP INVITE request as specified in Section 8.2.1.1. Otherwise, the gateway SHALL wait for more digits to arrive in QSIG INFORMATION messages.
8.2.2.2.2. Receipt of QSIG INFORMATION Message
On receipt of a QSIG INFORMATION message, the gateway SHALL handle the QSIG timer T302 in accordance with [2]. NOTE: [2] requires the QSIG timer to be stopped if the INFORMATION message contains a Sending complete information element or to be restarted otherwise. Further behaviour of the gateway SHALL depend on whether or not it has already sent a SIP INVITE request. If the gateway has not sent a SIP INVITE request and it now has the minimum number of digits required to route the call, it SHALL send a SIP INVITE request as specified in Section 8.2.2.1.2. If the gateway still does not have the minimum number of digits required, it SHALL wait for more QSIG INFORMATION messages to arrive. If the gateway has already sent one or more SIP INVITE requests, whether or not final responses to those requests have been received, it SHALL send a new SIP INVITE request in accordance with Section 3.2 of [18]. The updated Request-URI and To fields (see Section 9) SHALL be generated from the concatenation of information in the Called party number information element in the received QSIG SETUP and INFORMATION messages. NOTE: [18] requires the new request to have the same Call-ID and the same From header (including tag) as in the previous INVITE request. [18] recommends that the CSeq header should contain a value higher than that in the previous INVITE request.
8.2.2.2.3. Receipt of SIP 100 (Trying) Response to an INVITE Request
The requirements of Section 8.2.1.2 SHALL apply.
Top   ToC   RFC4497 - Page 19
8.2.2.2.4. Receipt of SIP 18x Provisional Response to an INVITE Request
The requirements of Section 8.2.1.3 SHALL apply.
8.2.2.2.5. Receipt of SIP 2xx Response to an INVITE Request
The requirements of Section 8.2.1.4 SHALL apply. In addition, the gateway SHALL send a SIP CANCEL request in accordance with Section 3.4 of [18] to cancel any SIP INVITE transactions for which no final response has been received.
8.2.2.2.6. Receipt of SIP 3xx Response to an INVITE Request
The requirements of Section 8.2.1.5 SHALL apply.
8.2.2.2.7. Receipt of a SIP 4xx, 5xx, or 6xx Final Response to an INVITE Request
On receipt of a SIP 4xx, 5xx, or 6xx final response to an INVITE request, the gateway SHALL send back a SIP ACK request. Unless the gateway is able to retry the INVITE request to avoid the problem (e.g., by supplying authentication in the case of a 401 or 407 response), the gateway SHALL also send a QSIG DISCONNECT message (8.4.4) if no further QSIG INFORMATION messages are expected and final responses have been received to all transmitted SIP INVITE requests. NOTE: Further QSIG INFORMATION messages will not be expected after QSIG timer T302 has expired or after a Sending complete information element has been received. In all other cases, the receipt of a SIP 4xx, 5xx, or 6xx final response to an INVITE request SHALL NOT trigger the sending of any QSIG message. NOTE: If further QSIG INFORMATION messages arrive, these will result in further SIP INVITE requests being sent, one of which might result in successful call establishment. For example, initial INVITE requests might produce 484 (Address Incomplete) or 404 (Not Found) responses because the Request-URIs derived from incomplete numbers cannot be routed, yet a subsequent INVITE request with a routable Request-URI might produce a 2xx final response or a more meaningful 4xx, 5xx, or 6xx final response.
Top   ToC   RFC4497 - Page 20
8.2.2.2.8. Receipt of Multiple SIP Responses to an INVITE Request
Section 3.3 of [18] applies.
8.2.2.2.9. Cancelling Pending SIP INVITE Transactions
As stated in Section 3.4 of [18], when a gateway sends a new SIP INVITE request containing new digits, it SHOULD NOT send a SIP CANCEL request to cancel a previous SIP INVITE transaction that has not had a final response. This SIP CANCEL request could arrive at an egress gateway before the new SIP INVITE request and trigger premature call clearing. NOTE: Previous SIP INVITE transactions can be expected to result in SIP 4xx class responses, which terminate the transaction. In Section 8.2.2.2.5, there is provision for cancelling any transactions still in progress after a SIP 2xx response has been received.
8.2.2.2.10. QSIG Timer T302 Expiry
If QSIG timer T302 expires and the gateway has received 4xx, 5xx, or 6xx responses to all transmitted SIP INVITE requests, the gateway SHALL send a QSIG DISCONNECT message. If T302 expires and the gateway has not received 4xx, 5xx, or 6xx responses to all transmitted SIP INVITE requests, the gateway SHALL ignore any further QSIG INFORMATION messages but SHALL NOT send a QSIG DISCONNECT message at this stage. NOTE: A QSIG DISCONNECT request will be sent when all outstanding SIP INVITE requests have received 4xx, 5xx, or 6xx responses.

8.3. Call Establishment from SIP to QSIG

8.3.1. Receipt of SIP INVITE Request for a New Call

On receipt of a SIP INVITE request for a new call, if a suitable channel is available on the inter-PINX link, the gateway SHALL generate a QSIG SETUP message from the received SIP INVITE request. The gateway SHALL generate the Called party number and Calling party number information elements in accordance with Section 9 and SHALL generate the Bearer capability information element in accordance with Section 10. If the gateway can determine that the number placed in the Called party number information element is complete, the gateway MAY include the Sending complete information element. NOTE: The means by which the gateway determines the number to be complete is an implementation matter. It can involve knowledge of the numbering plan and/or use of the inter-digit timer.
Top   ToC   RFC4497 - Page 21
   The gateway SHOULD send a SIP 100 (Trying) response.

   If information in the SIP INVITE request is unsuitable for generating
   any of the mandatory information elements in a QSIG SETUP message
   (e.g., if a QSIG Called party number information element cannot be
   derived from SIP Request-URI field) or if no suitable channel is
   available on the inter-PINX link, the gateway SHALL NOT issue a QSIG
   SETUP message and SHALL send a SIP 4xx, 5xx, or 6xx response.  If no
   suitable channel is available, the gateway should use response code
   503 (Service Unavailable).

   If the SIP INVITE request does not contain SDP information and does
   not contain either a Required header or a Supported header with
   option tag 100rel, the gateway SHOULD still proceed as above,
   although an implementation can instead send a SIP 488 (Not Acceptable
   Here) response, in which case it SHALL NOT issue a QSIG SETUP
   message.

   NOTE: The absence of SDP offer information in the SIP INVITE request
   means that the gateway might need to send SDP offer information in a
   provisional response and receive SDP answer information in a SIP
   PRACK request (in accordance with [11]) in order to ensure that tones
   and announcements from the PISN are transmitted. SDP offer
   information cannot be sent in an unreliable provisional response
   because SDP answer information would need to be returned in a SIP
   PRACK request.  The recommendation above still to proceed with call
   establishment in this situation reflects the desire to maximise the
   chances of a successful call.  However, if important in-band
   information is likely to be denied in this situation, a gateway can
   choose not to proceed.

   NOTE: If SDP offer information is present in the INVITE request, the
   issuing of a QSIG SETUP message is not dependent on the presence of a
   Required header or a Supported header with option tag 100rel.

   On receipt of a SIP INVITE request relating to a call that has
   already been established from SIP to QSIG, the procedures of 8.3.9
   SHALL apply.

8.3.2. Receipt of QSIG CALL PROCEEDING Message

The receipt of a QSIG CALL PROCEEDING message SHALL NOT result in any SIP message being sent.
Top   ToC   RFC4497 - Page 22

8.3.3. Receipt of QSIG PROGRESS Message

A QSIG PROGRESS message can be received in the event of interworking on the remote side of the PISN or if the PISN is unable to complete the call and generates an in-band tone or announcement. In the latter case, a Cause information element is included in the QSIG PROGRESS message. The gateway SHALL map a received QSIG PROGRESS message to a SIP 183 (Session Progress) response to the INVITE request. If the SIP INVITE request contained either a Require header or a Supported header with option tag 100rel, the gateway SHALL include in the SIP 183 response a Require header with option tag 100rel. NOTE: In accordance with [11], inclusion of option tag 100rel in a provisional response instructs the UAC to acknowledge the provisional response by sending a PRACK request. [11] also specifies procedures for repeating a provisional response with option tag 100rel if no PRACK is received. If the QSIG PROGRESS message contained a Progress indicator information element with Progress description number 1 or 8, the gateway SHALL connect the media streams to the corresponding user information channel of the inter-PINX link if it has not already done so, provided that SDP answer information is included in the transmitted SIP response to the INVITE request or has already been sent or received. Inclusion of SDP offer or answer information in the 183 provisional response SHALL be in accordance with Section 8.3.5. If the QSIG PROGRESS message is received with a Cause information element, the gateway SHALL either wait until the tone/announcement is complete or has been applied for sufficient time before initiating call clearing, or wait for a SIP CANCEL request. If call clearing is initiated, the cause value in the QSIG PROGRESS message SHALL be used to derive the response to the SIP INVITE request in accordance with Table 1.

8.3.4. Receipt of QSIG ALERTING Message

The gateway SHALL map a QSIG ALERTING message to a SIP 180 (Ringing) response to the INVITE request. If the SIP INVITE request contained either a Require header or a Supported header with option tag 100rel, the gateway SHALL include in the SIP 180 response a Require header with option tag 100rel.
Top   ToC   RFC4497 - Page 23
   NOTE: In accordance with [11], inclusion of option tag 100rel in a
   provisional response instructs the UAC to acknowledge the provisional
   response by sending a PRACK request.  [11] also specifies procedures
   for repeating a provisional response with option tag 100rel if no
   PRACK is received.

   If the QSIG ALERTING message contained a Progress indicator
   information element with Progress description number 1 or 8, the
   gateway SHALL connect the media streams to the corresponding user
   information channel of the inter-PINX link if it has not already done
   so, provided that SDP answer information is included in the
   transmitted SIP response or has already been sent or received.
   Inclusion of SDP offer or answer information in the 180 provisional
   response SHALL be in accordance with Section 8.3.5.

8.3.5. Inclusion of SDP Information in a SIP 18x Provisional Response

When sending a SIP 18x provisional response to the INVITE request, if a QSIG message containing a Progress indicator information element with progress description number 1 or 8 has been received the gateway SHALL include SDP information. Otherwise, the gateway MAY include SDP information. If SDP information is included, it shall be in accordance with the following rules. If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if SDP offer and answer information has already been exchanged, no SDP information SHALL be included in the SIP 18x provisional response. If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if SDP offer information was received in the SIP INVITE request but no SDP answer information has been sent, SDP answer information SHALL be included in the SIP 18x provisional response. If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if no SDP offer information was received in the SIP INVITE request and no SDP offer information has already been sent, SDP offer information SHALL be included in the SIP 18x provisional response. NOTE: In this case, SDP answer information can be expected in the SIP PRACK. If the SIP INVITE request contained neither a Required nor a Supported header with option tag 100rel, SDP answer information SHALL be included in the SIP 18x provisional response.
Top   ToC   RFC4497 - Page 24
   NOTE: Because the provisional response is unreliable, SDP answer
   information needs to be repeated in each provisional response and in
   the final SIP 2xx response.

   NOTE: If the SIP INVITE request contained no SDP offer information
   and neither a Required nor a Supported header with option tag 100rel,
   it should have been rejected in accordance with Section 8.3.1.

8.3.6. Receipt of QSIG CONNECT Message

The gateway SHALL map a QSIG CONNECT message to a SIP 200 (OK) final response for the SIP INVITE request. The gateway SHALL also send a QSIG CONNECT ACKNOWLEDGE message. If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if SDP offer and answer information has already been exchanged, no SDP information SHALL be included in the SIP 200 response. If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if SDP offer information was received in the SIP INVITE request but no SDP answer information has been sent, SDP answer information SHALL be included in the SIP 200 response. If the SIP INVITE request contained a Required or Supported header with option tag 100rel, and if no SDP offer information was received in the SIP INVITE request and no SDP offer information has already been sent, SDP offer information SHALL be included in the SIP 200 response. NOTE: In this case, SDP answer information can be expected in the SIP ACK. If the SIP INVITE request contained neither a Required nor a Supported header with option tag 100rel, SDP answer information SHALL be included in the SIP 200 response. NOTE: Because the provisional response is unreliable, SDP answer information needs to be repeated in each provisional response and in the final 2xx response. NOTE: If the SIP INVITE request contained no SDP offer information and neither a Required nor a Supported header with option tag 100rel, it may have been rejected in accordance with Section 8.3.1.
Top   ToC   RFC4497 - Page 25
   The gateway SHALL connect the media streams to the corresponding user
   information channel of the inter-PINX link if it has not already done
   so, provided that SDP answer information is included in the
   transmitted SIP response or has already been sent or received.

8.3.7. Receipt of SIP PRACK Request

The receipt of a SIP PRACK request acknowledging a reliable provisional response SHALL NOT result in any QSIG message being sent. The gateway SHALL send back a SIP 200 (OK) response to the SIP PRACK request. If the SIP PRACK contains SDP answer information and a QSIG message containing a Progress indicator information element with progress description number 1 or 8 has been received, the gateway SHALL connect the media streams to the corresponding user information channel of the inter-PINX link.

8.3.8. Receipt of SIP ACK Request

The receipt of a SIP ACK request SHALL NOT result in any QSIG message being sent. If the SIP ACK contains SDP answer information, the gateway SHALL connect the media streams to the corresponding user information channel of the inter-PINX link if it has not already done so.

8.3.9. Receipt of a SIP INVITE Request for a Call Already Being Established

A gateway can receive a call from SIP using overlap procedures. This should occur when the UAC for the INVITE request is a gateway from a network that employs overlap procedures (e.g., an ISUP gateway or another QSIG gateway) and the gateway has not absorbed overlap. For a call from SIP using overlap procedures, the gateway will receive multiple SIP INVITE requests that belong to the same call but have different Request-URI and To fields. Each SIP INVITE request belongs to a different dialog. A SIP INVITE request is considered to be for the purpose of overlap sending if, compared to a previously received SIP INVITE request, it has: - the same Call-ID header; - the same From header (including the tag); - no tag in the To header;
Top   ToC   RFC4497 - Page 26
      - an updated Request-URI from which can be derived a called party
        number with a superset of the digits derived from the previously
        received SIP INVITE request;

      and if

      - the gateway has not yet sent a final response other than 484 to
        the previously received SIP INVITE request.

   If a gateway receives a SIP INVITE request for the purpose of overlap
   sending, it SHALL generate a QSIG INFORMATION message using the call
   reference of the existing QSIG call instead of a new QSIG SETUP
   message and containing only the additional digits in the Called party
   number information element.  It SHALL also respond to the SIP INVITE
   request received previously with a SIP 484 Address Incomplete
   response.

   If a gateway receives a SIP INVITE request that meets all of the
   conditions for a SIP INVITE request for the purpose of overlap
   sending except the condition concerning the Request-URI, the gateway
   SHALL respond to the new request with a SIP 485 (Ambiguous) response.

8.4. Call Clearing and Call Failure

8.4.1. Receipt of a QSIG DISCONNECT, RELEASE, or RELEASE COMPLETE Message

On receipt of QSIG DISCONNECT, RELEASE, or RELEASE COMPLETE message as the first QSIG call clearing message, gateway behaviour SHALL depend on the state of call establishment. 1) If the gateway has sent a SIP 200 (OK) response to a SIP INVITE request and received a SIP ACK request, or if it has received a SIP 200 (OK) response to a SIP INVITE request and sent a SIP ACK request, the gateway SHALL send a SIP BYE request to clear the call. 2) If the gateway has sent a SIP 200 (OK) response to a SIP INVITE request (indicating that call establishment is complete) but has not received a SIP ACK request, the gateway SHALL wait until a SIP ACK is received and then send a SIP BYE request to clear the call. 3) If the gateway has sent a SIP INVITE request and received a SIP provisional response but not a SIP final response, the gateway SHALL send a SIP CANCEL request to clear the call.
Top   ToC   RFC4497 - Page 27
      NOTE 1: In accordance with [10], if after sending a SIP CANCEL
      request a SIP 2xx response is received to the SIP INVITE request,
      the gateway will need to send a SIP BYE request.

   4) If the gateway has sent a SIP INVITE request but received no SIP
      response, the gateway SHALL NOT send a SIP message.  If a SIP
      final or provisional response is subsequently received, the
      gateway SHALL then act in accordance with 1, 2, or 3 above,
      respectively.

   5) If the gateway has received a SIP INVITE request but not sent a
      SIP final response, the gateway SHALL send a SIP final response
      chosen according to the cause value in the received QSIG message
      as specified in Table 1.  SIP response 500 (Server internal error)
      SHALL be used as the default for cause values not shown in
      Table 1.

   NOTE 2: It is not necessarily appropriate to map some QSIG cause
   values to SIP messages because these cause values are meaningful only
   at the gateway.  A good example of this is cause value 44, "Requested
   circuit or channel not available", which signifies that the channel
   number in the transmitted QSIG SETUP message was not acceptable to
   the peer PINX.  The appropriate behavior in this case is for the
   gateway to send another SETUP message indicating a different channel
   number.  If this is not possible, the gateway should treat it either
   as a congestion situation (no channels available; see Section 8.3.1)
   or as a gateway failure situation (in which case the default SIP
   response code applies).

   In all cases, the gateway SHALL also disconnect media streams, if
   established, and allow QSIG and SIP signalling to complete in
   accordance with [2] and [10], respectively.
Top   ToC   RFC4497 - Page 28
   Table 1: Mapping of QSIG Cause Value to SIP 4xx-6xx responses to an
   INVITE request

   QSIG Cause value               SIP response
   ----------------------------------------------------------------
   1  Unallocated number          404 Not found
   2  No route to specified       404 Not found
      transit network
   3  No route to destination     404 Not found
   16 Normal call clearing        (NOTE 3)
   17 User busy                   486 Busy here
   18 No user responding          408 Request timeout
   19 No answer from the user     480 Temporarily unavailable
   20 Subscriber absent           480 Temporarily unavailable
   21 Call rejected               603 Decline, if location field
                                      in Cause information element
                                      indicates user.  Otherwise:
                                      403 Forbidden
   22 Number changed              301 Moved permanently, if
                                      information in diagnostic field
                                      of Cause information element is
                                      suitable for generating a SIP
                                      Contact header.  Otherwise:
                                      410 Gone
   23 Redirection to new          410 Gone
      destination
   27 Destination out of order    502 Bad gateway
   28 Address incomplete          484 Address incomplete
   29 Facility rejected           501 Not implemented
   31 Normal, unspecified         480 Temporarily unavailable
   34 No circuit/channel          503 Service unavailable
      available
   38 Network out of order        503 Service unavailable
   41 Temporary failure           503 Service unavailable
   42 Switching equipment         503 Service unavailable
      congestion
   47 Resource unavailable,       503 Service unavailable
      unspecified
   55 Incoming calls barred       403 Forbidden
      within CUG
   57 Bearer capability not       403 Forbidden
      authorized
   58 Bearer capability not       503 Service unavailable
      presently available
   65 Bearer capability not       488 Not acceptable here (NOTE 4)
      implemented
   69 Requested facility not      501 Not implemented
      implemented
Top   ToC   RFC4497 - Page 29
   70 Only restricted digital     488 Not acceptable here (NOTE 4)
      information available
   79 Service or option not       501 Not implemented
      implemented, unspecified
   87 User not member of CUG      403 Forbidden
   88 Incompatible destination    503 Service unavailable
   102 Recovery on timer expiry   504 Server time-out

   NOTE 3: A QSIG call clearing message containing cause value 16 will
   normally result in the sending of a SIP BYE or CANCEL request.
   However, if a SIP response is to be sent to the INVITE request, the
   default response code should be used.

   NOTE 4: The gateway may include a SIP Warning header if diagnostic
   information in the QSIG Cause information element allows a suitable
   warning code to be selected.

8.4.2. Receipt of a SIP BYE Request

On receipt of a SIP BYE request, the gateway SHALL send a QSIG DISCONNECT message with cause value 16 (normal call clearing). The gateway SHALL also disconnect media streams, if established, and allow QSIG and SIP signalling to complete in accordance with [2] and [10], respectively. NOTE: When responding to a SIP BYE request, in accordance with [10], the gateway is also required to respond to any other outstanding transactions, e.g., with a SIP 487 (Request Terminated) response. This applies in particular if the gateway has not yet returned a final response to the SIP INVITE request.

8.4.3. Receipt of a SIP CANCEL Request

On receipt of a SIP CANCEL request to clear a call for which the gateway has not sent a SIP final response to the received SIP INVITE request, the gateway SHALL send a QSIG DISCONNECT message with cause value 16 (normal call clearing). The gateway SHALL also disconnect media streams, if established, and allow QSIG and SIP signalling to complete in accordance with [2] and [10], respectively.

8.4.4. Receipt of a SIP 4xx-6xx Response to an INVITE Request

Except where otherwise specified in the context of overlap sending (8.2.2.2), on receipt of a SIP final response (4xx-6xx) to a SIP INVITE request, unless the gateway is able to retry the INVITE request to avoid the problem (e.g., by supplying authentication in the case of a 401 or 407 response), the gateway SHALL transmit a QSIG DISCONNECT message. The cause value in the QSIG DISCONNECT message
Top   ToC   RFC4497 - Page 30
   SHALL be derived from the SIP 4xx-6xx response according to Table 2.
   Cause value 31 (Normal, unspecified) SHALL be used as the default for
   SIP responses not shown in Table 2.  The gateway SHALL also
   disconnect media streams, if established, and allow QSIG and SIP
   signalling to complete in accordance with [2] and [10], respectively.

   When generating a QSIG Cause information element, the location field
   SHOULD contain the value "user", if generated as a result of a SIP
   response code 6xx, or the value "Private network serving the remote
   user" in other circumstances.

   Table 2: Mapping of SIP 4xx-6xx responses to an INVITE request to
   QSIG Cause values

   SIP response                        QSIG Cause value (NOTE 6)
   ------------------------------------------------------------------
   400 Bad request                     41  Temporary failure
   401 Unauthorized                    21  Call rejected (NOTE 5)
   402 Payment required                21  Call rejected
   403 Forbidden                       21  Call rejected
   404 Not found                       1   Unallocated number
   405 Method not allowed              63  Service or option
                                           unavailable, unspecified
   406 Not acceptable                  79  Service or option not
                                           implemented, unspecified
   407 Proxy Authentication required   21  Call rejected (NOTE 5)
   408 Request timeout                 102 Recovery on timer expiry
   410 Gone                            22  Number changed
   413 Request entity too large        127 Interworking, unspecified
                                           (NOTE 6)
   414 Request-URI too long            127 Interworking, unspecified
                                           (NOTE 6)
   415 Unsupported media type          79  Service or option not
                                           implemented, unspecified
                                           (NOTE 6)
   416 Unsupported URI scheme          127 Interworking, unspecified
                                           (NOTE 6)
   420 Bad extension                   127 Interworking, unspecified
                                           (NOTE 6)
   421 Extension required              127 Interworking, unspecified
                                           (NOTE 6)
   423 Interval too brief              127 Interworking, unspecified
                                           (NOTE 6)
   480 Temporarily unavailable         18  No user responding
   481 Call/transaction does not exist 41  Temporary failure
   482 Loop detected                   25  Exchange routing error
   483 Too many hops                   25  Exchange routing error
Top   ToC   RFC4497 - Page 31
   484 Address incomplete              28  Invalid number format
                                           (NOTE 6)
   485 Ambiguous                       1   Unallocated Number
   486 Busy here                       17  User busy
   487 Request terminated              (NOTE 7)
   488 Not Acceptable Here             65  Bearer capability not
                                           implemented or 31 Normal,
                                           unspecified (NOTE 8)
   500 Server internal error           41  Temporary failure
   501 Not implemented                 79  Service or option not
                                           implemented, unspecified
   502 Bad gateway                     38  Network out of order
   503 Service unavailable             41  Temporary failure
   504 Gateway time-out                102 Recovery on timer expiry
   505 Version not supported           127 Interworking, unspecified
                                           (NOTE 6)
   513 Message too large               127 Interworking, unspecified
                                           (NOTE 6)
   600 Busy everywhere                 17  User busy
   603 Decline                         21  Call rejected
   604 Does not exist anywhere         1   Unallocated number
   606 Not acceptable                  65  Bearer capability not
                                           implemented or
                                       31  Normal, unspecified (NOTE 8)

   NOTE 5: In some cases, it may be possible for the gateway to provide
   credentials to the SIP UAS that is rejecting an INVITE due to
   authorization failure.  If the gateway can authenticate itself, then
   obviously it should do so and proceed with the call.  Only if the
   gateway cannot authorize itself should the gateway clear the call in
   the QSIG network with this cause value.

   NOTE 6: For some response codes, the gateway may be able to retry the
   INVITE request in order to work around the problem.  In particular,
   this may be the case with response codes indicating a protocol error.
   The gateway SHOULD clear the call in the QSIG network with the
   indicated cause value only if retry is not possible or fails.

   NOTE 7: The circumstances in which SIP response code 487 can be
   expected to arise do not require it to be mapped to a QSIG cause
   code, since the QSIG call will normally already be cleared or in the
   process of clearing.  If QSIG call clearing does, however, need to be
   initiated, the default cause value should be used.

   NOTE 8: When the Warning header is present in a SIP 606 or 488
   message, the warning code should be examined to determine whether it
   is reasonable to generate cause value 65.  This cause value should be
   generated only if there is a chance that a new call attempt with
Top   ToC   RFC4497 - Page 32
   different content in the Bearer capability information element will
   avoid the problem.  In other circumstances, the default cause value
   should be used.

8.4.5 Gateway-Initiated Call Clearing

If the gateway initiates clearing of the QSIG call owing to QSIG timer expiry, QSIG protocol error, or use of the QSIG RESTART message in accordance with [2], the gateway SHALL also initiate clearing of the SIP call in accordance with Section 8.4.1. If this involves the sending of a final response to a SIP INVITE request, the gateway SHALL use response code 480 (Temporarily Unavailable) if optional QSIG timer T301 has expired or, otherwise, response code 408 (Request timeout) or 500 (Server internal error), as appropriate. If the gateway initiates clearing of the SIP call owing to SIP timer expiry or SIP protocol error in accordance with [10], the gateway SHALL also initiate clearing of the QSIG call in accordance with [2] using cause value 102 (Recovery on timer expiry) or 41 (Temporary failure), as appropriate.

8.5. Request to Change Media Characteristics

If after a call has been successfully established the gateway receives a SIP INVITE request to change the media characteristics of the call in a way that would be incompatible with the bearer capability in use within the PISN, the gateway SHALL send back a SIP 488 (Not Acceptable Here) response and SHALL NOT change the media characteristics of the existing call.


(page 32 continued on part 3)

Next Section