WO2025145403A1

WO2025145403A1 - Enhancements to session initiation protocol communication

Info

Publication number: WO2025145403A1
Application number: PCT/CN2024/070689
Authority: WO
Inventors: Li Jun CUI
Original assignee: Nokia Solutions and Networks Investment China Co Ltd; Nokia Solutions and Networks Oy
Current assignee: Nokia Solutions and Networks Investment China Co Ltd; Nokia Solutions and Networks Oy
Priority date: 2024-01-04
Filing date: 2024-01-04
Publication date: 2025-07-10
Anticipated expiration: 2026-07-04

Abstract

Example embodiments of the present disclosure relate to enhancements to Session Initiation Protocol (SIP) communication. A method comprises receiving, at a user agent client and from an upstream network element, a session initiation protocol, SIP, INVITE request; retrieving a request uniform request identifier, URI, of the SIP INVITE request; appending a first indication of the request URI to the SIP INVITE request; and transmitting, to a user agent server, the SIP INVITE request appended with the first indication.

Description

ENHANCEMENTS TO SESSION INITIATION PROTOCOL COMMUNICATION

FIELDS

Various example embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to an apparatus, method and computer readable storage medium for enhancements to Session Initiation Protocol (SIP) communication.

BACKGROUND

In an internet protocol (IP) multimedia subsystem (IMS) core network, Session Initiation Protocol (SIP) is used to establish, modify, and terminate multimedia sessions. SIP is independent of whatever transport protocols are used to send SIP request and response. Under certain circumstances, data in the SIP layer and the transport layer may have different lifecycle. It is troublesome if data lifecycle in the SIP layer is shorter than the one in the transport layer.

SUMMARY

In a first aspect of the present disclosure, there is provided an apparatus. The apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: receiving, from an upstream network element, a session initiation protocol, SIP, INVITE request; retrieving a request uniform request identifier, URI, of the SIP INVITE request; appending a first indication of the request URI to the SIP INVITE request; and transmitting, to a user agent server, the SIP INVITE request appended with the first indication.

In a second aspect of the present disclosure, there is provided a method. The method comprises receiving, at a user agent server and from an upstream network element, a session initiation protocol, SIP, INVITE request; retrieving a request uniform request identifier, URI, of the SIP INVITE request; appending a first indication of the request URI to the SIP INVITE request; and transmitting, to a user agent server, the SIP INVITE request appended with the first indication.

In a third aspect of the present disclosure, there is provided an apparatus. The apparatus comprises means for receiving, at a user agent server and from an upstream network element, a session initiation protocol, SIP, INVITE request; means for retrieving a request uniform request identifier, URI, of the SIP INVITE request; means for appending a first indication of the request URI to the SIP INVITE request; and means for transmitting, to a user agent server, the SIP INVITE request appended with the first indication.

In a fourth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the second aspect.

In a fifth aspect of the present disclosure, there is provided a computer program. The computer program comprises instructions which, when executed by an apparatus, cause the apparatus to perform at least the method according to the second aspect.

It is to be understood that the Summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

Some example embodiments will now be described with reference to the accompanying drawings, where:

FIG. 1A illustrates an example case where an INVITE transaction terminated at a P-CSCF after a CANCEL request received from an upstream network element (NE) and callee user equipment (UE) gets a ghost call due to unstable network conditions;

FIG. 1B illustrates an example case where an INVITE transaction terminated at a P-CSCF after SIP Timer B expires and a callee UE gets a ghost call due to unstable network conditions;

FIG. 1C illustrates an example case where an INVITE transaction terminated at a P-CSCF after a CANCEL request received from an upstream NE and a callee UE gets a stuck call due to unstable network conditions;

FIG. 1D illustrates an example case where an INVITE transaction terminated at a P-CSCF after SIP Timer B expires and a callee UE gets a stuck call due to unstable network conditions;

FIG. 2 illustrates an example communication environment in which example embodiments of the present disclosure can be implemented;

FIG. 3 illustrates a signaling diagram for an example communication process 300 between an upstream NE, a UAC and a UAS according to some example embodiments of the present disclosure;

FIG. 4A illustrates an example process for SIP communication according to some example embodiments of the present disclosure;

FIG. 4B illustrates a further example process for SIP communication according to some example embodiments of the present disclosure;

FIG. 5 illustrates a flowchart of a method implemented according to some example embodiments of the present disclosure;

FIG. 6 illustrates a simplified block diagram of a device that is suitable for implementing example embodiments of the present disclosure; and

FIG. 7 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.

Throughout the drawings, the same or similar reference numerals represent the same or similar element.

DETAILED DESCRIPTION

Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. Embodiments described herein can be implemented in various manners other than the ones described below.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

References in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It shall be understood that although the terms “first, ” “second, ” ..., etc. in front of noun (s) and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another and they do not limit the order of the noun (s) . For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the listed terms.

As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

As used herein, unless stated explicitly, performing a step “in response to A” does not indicate that the step is performed immediately after “A” occurs and one or more intervening steps may be included.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and/or “including” , when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof.

As used in this application, the term “circuitry” may refer to one or more or all of the following:

(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and

(b) combinations of hardware circuits and software, such as (as applicable) :

(i) a combination of analog and/or digital hardware circuit (s) with software/firmware and

(ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

(c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

As used herein, the term “network device” refers to a device in a communication network via which a terminal device receives services therefrom. The network device may comprise an access network device and a core network device.

The term “terminal device” refers to any end device that receives services via a network device in a communication network. By way of example rather than limitation, a terminal device may also be referred to as user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device and applications (e.g., remote surgery) , an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. The terminal device may also correspond to a Mobile Termination (MT) part of an IAB node (e.g., a relay node) . In the following description, the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.

As described above, in an IMS core network, data in the SIP layer and the transport layer may have different lifecycle. It is troublesome if data lifecycle in the SIP layer is shorter than the one in the transport layer. Taking example of the SIP INVITE call, if an INVITE transaction terminates earlier at the SIP layer but the corresponding SIP request is still being transmitted in the transport layer, then after the SIP response is received from a user agent server (UAS) , there is no matching dialog found at a user agent client (UAC) . In this case, the SIP response is discarded, which can cause a ghost call or stuck call at the SIP UAS.

There are various conditions that can result in the troublesome situations including unstable network conditions, SIP UAC service restarts, and so on. If it is a wireless access network between SIP UAC and UAS, especially for a call service with Voice over Wi-Fi (VoWi-Fi) , it is possible that a call is released in the SIP layer at a UAC, while the relevant data is still being retransmitted in a transport layer for unstable network conditions. If network conditions restore stable before retransmission aborts in the transport layer, the retransmitted call can be delivered to a UAS, which can cause a ghost call or stuck call at the SIP UAS.

One of the issues was ever observed in a customer site as below. When user equipment (UE) is experiencing poor VoWi-Fi signals and Transport Layer Security (TLS) (over Transmission Control Protocol (TCP) ) is used in a transport layer, the SIP INVITE call from a terminating Proxy Call Session Control Function (Proxy-CSCF or P-CSCF) (or a UAC) to the UE (or UAS) cannot be delivered successfully and it is kept being retransmitted in the TCP transport layer. For retransmission times on a TCP connection with an established state, it is controlled by parameter of “/proc/sys/net/ipv4/tcp_retries2” on a Linux server. The default value of “/proc/sys/net/ipv4/tcp_retries2” is 15, which corresponds to a duration of approximately between 13 to 30 minutes. While the SIP Timer B, e.g., INVITE transaction timeout timer, is 64*T1, where T1 is 500ms by default regarding “Table 4: Summary of timers” in Request For Comments (RFC) 3261, and it is usually customized within about 1s or 2s in a customer site for exchanging SIP messages between IMS core networks and wireless networks, that is, Gm interface.

With the above situation, the INVITE transaction terminates in the SIP session layer after 64s or 128s, while corresponding data is still being retransmitted in the transport layer from a server hosting the P-CSCF. When a callee UE recovers to a good signal condition before the retransmission aborts in the TCP layer, the retransmitted data is delivered to the callee UE. The callee UE responds with the SIP response (e.g., the 180 Ringing) , then a 18x message (e.g., a 183 session progress message) . It depends on whether reliability of a provisional response is required or not, and a provisional response acknowledgement (PRACK) will be awaited at the UAS if it is, otherwise, the callee answers the call with 200 OK.

As the SIP INVITE transaction already terminates at the P-CSCF, there is no voice received after the call is answered, which makes the callee experience a ghost call. Furthermore, if the callee UE is waiting for PRACK, it will be stuck at a “waiting” state until timeouts waiting for PRACK, which is 64*T1 regarding RFC 3262. If T1 is configured as 2s, within 128s, no other new calls can be accepted at the callee UE, which makes the callee experience a stealthy call Denial-of-service (DoS) attack. FIGS. 1A to 1D illustrate the above scenarios where the UAC is a P-CSCF in the IMS core network and the UAS is a callee UE with VoWi-Fi and gets a ghost or stuck call.

For the issues caused by unstable network conditions, the SO_KEEPALIVE socket option can be used to detect TCP connection status, which allows a TCP socket to periodically send a packet to the other end of the connection to check if it is still reachable. However, it is usually disabled at a SIP server in an IMS core network with the following considerations.

It is hard to tune a proper value of interval (tcp_keepalive_intvl) , count for keep-alive probes (tcp_keepalive_probes) , and when to begin sending out keep-alive probes (tcp_keepalive_time) in the IMS core network, especially at the Gm interface due to the complexity of a wireless network and a variant of a UE. Therefore, it is hard to detect the short-time instability of wireless signals timely.

Enabling the SO_KEEPALIVE socket option also introduces some overhead due to the periodic transmission of keep-alive packets. Considering one P-CSCF can home hundreds and thousands of UEs, it would cause obvious overhead in network bandwidth consumption and resource usage by doing so.

TCP socket option TCP_USER_TIMEOUT can be used to specify the maximum amount of time in milliseconds that transmitted data may remain unacknowledged, or buffered data may remain un-transmitted before a TCP connection is closed. While the calculating of a timeout value is following an exponential backoff mechanism, which causes the actual duration to detect TCP unavailability is longer than the configured value of TCP_USER_TIMEOUT. Even a same value is used to configure TCP_USER_TIMEOUT and SIP Timer B, there still exists a time window, in which a UAS recovers to a good signal condition and a callee can get a ghost or stuck call at a UAS.

Furthermore, if no response has been received when SIP Timer B timeouts at a UAC, the UAC releases the SIP INVITE transaction/dialog with sending 408 Request Timeout to the upstream NE. However, the UAC does not send CANCEL to the UAS on non-pending client transaction because the INVITE transaction without any provisional response received is not treated as pending client transaction.

One approach is, in conjunction with configuring the same value to TCP_USER_TIMEOUT and SIP timer B, to retrieve information about this socket maintained in Linux kernel (TCP_INFO) when SIP Timer B expires, to determine whether the TCP connection is to be closed at the time INVITE transaction is being terminated. If the TCP connection is to be closed along with INVITE transaction termination, and after it is closed, the queued (INVITE) packets cannot be transmitted to the UAS by the transport layer. With this improvement, it addresses the issue of a ghost or stuck call at the callee.

One of the drawbacks of the above approach is that it closes the TCP connection to prevent the queued data from being delivered to the UAS. The UAC can initiate a new TCP connection when it sends a SIP request to the UAS. However, at least an interval of 1.5 *RTT is added to the call setup duration.

Another drawback is that for a call service via VoWi-Fi, where a UE is software application (App) running on VoWi-Fi, and TLS is usually used between the App and the P-CSCF. In practice, software App initiates a TLS connection and registers itself over TLS to an IMS network, and the P-CSCF reuses the same TLS connection when it sends a terminating INVITE request to the App. The P-CSCF shall not close the TLS connection proactively. Otherwise, requests terminated to the callee UE cannot be delivered to the UE until the software application registers to establish a TLS connection again, and the UE is unaware of missing incoming calls.

Example embodiments of the present disclosure propose a solution for enhancements to SIP communication. In this solution, before an apparatus (e.g., a UAC) sends a SIP INVITE request to a UAS, the apparatus retrieves the request uniform request identifier (request URI) of the SIP INVITE request before the request is sent out, and appends an indication of the request URI into the SIP INVITE request.

The request URI of the SIP INVITE request may be used to build the request URI of a SIP CANCEL request later. Upon receiving a late SIP response from the UAS, where no matching transaction is found, a UAC may build a SIP CANCEL request instead of discarding the late response. Information necessary to build the SIP CANCLE request may be retrieved from 1xx response. After the SIP CANCEL request is built and sent to the UAS, the UAS may stop processing the SIP INVITE request. If the UAS is a callee UE, the callee UE may be prevented from a ghost or stuck call, and the call resources at the callee UE may be released quickly.

The solution may solve the issues of ghost or stuck calls at the SIP UAS due to earlier release of the data in the SIP layer than the data in the transport layer at the UAC side regardless of the transport connection that is used between UAC and UAS, and conditions to cause the data lifecycle mismatch between the two layers.

FIG. 2 illustrates an example communication environment 200 in which example embodiments of the present disclosure can be implemented. In the communication environment 200, a UAC (also called a SIP UAC) 210 communicates with a UAS (also called a SIP UAS) 220 in a SIP call procedure. The communication environment 200 further involves an upstream NE 230 which is in an upstream location of the UAC 210. The UAC 210, the UAS 220 and the upstream NE 230 may operate as any devices in a SIP call procedure.

In some other embodiments, the UAC 210 may operate as a network device, and the UAS 220 may operate as a terminal device. For example, in a case of a SIP INVITE call from a terminating P-CSCF to a UE, the P-CSCF may act as the UAC 210, and the UE may be act as the UAS 220, and an upstream NE of the P-CSCF may act as the upstream NE 230.

In some example embodiments, the apparatus UAC may be a part of B2BUA (Back-to-Back User Agent) , which comprises functions of UAC and UAS. Its UAS part handles SIP requests from the upstream NE and sends responses to the upstream NE, and its UAC part generates and sends SIP requests to downstream NE and handles SIP responses from downstream NE.

The communications in the communication environment 200 may be implemented according to the SIP protocol. It is to be understood that the number of apparatuses is shown in FIG. 2 only for the purpose of illustration without suggesting any limitation. The communication environment 200 may include any suitable number of apparatuses configured to implement example embodiments of the present disclosure.

In the communication environment 200, during a SIP INVITE call from the UAC 210 to the UAS 220, the UAC 210 may encode a request URI of the SIP INVITE request before the request is sent out, and appends the encoded value to the SIP INVITE request, which can be used to build the request URI for a SIP CANCEL request later.

Some example implementations of the present disclosure will be described in detail below with reference to FIGS. 3 to 4B.

FIG. 3 shows a signaling diagram for an example communication process 300 between the upstream NE 230, the UAC 210, and the UAS 220 according to some example embodiments of the present disclosure.

As shown in FIG. 3, the UAC 210 receives (305) , from the upstream NE 230, a SIP INVITE request. The UAC 210 retrieves (310) a request URI of the SIP INVITE request. The UAC 210 appends (315) a first indication of the request URI to the SIP INVITE request. The UAC 210 transmits (320) , to the UAS 220, the SIP INVITE request appended with the first indication.

In some example embodiments, the SIP INVITE request may contain a Route header. It has been specified (e.g., in RFC 3261) that if the request being cancelled contains a Route header field, the SIP CANCEL request also needs to include that Route header field’s values. In some example embodiments, if a Route header is included in the SIP INVITE request, the UAC 210 may further append a second indication of the Route header value to the SIP INVITE request. In this case, the SIP INVITE request is appended with the first indication and the second indication.

In some example embodiments, the UAC 210 may encode the request URI of the SIP INVITE request into a first indication, and/or may encode the Route header value of the SIP INVITE request into a second indication. The encoded data may be appended in a very flexible way. For example, the encoded data can be appended into any header of the SIP INVITE request that is piggybacked in the SIP response intactly from the UAS 220. In some example embodiments, the first indication and/or the second indication may be appended (315) to one of the following: a top Via header of the SIP INVITE request, a From header (e.g., from-tag of From) of the SIP INVITE request, or a call identity (ID) header (e.g., Call-ID ) of the SIP INVITE request. In the following, some example embodiments will be described using the top Via header as an example while the example embodiments herein can be applied in general for any header. In some example embodiments, the first indication and the second indication may be appended the same or different headers of the SIP INVITE request.

In some example embodiments, the UAC 210 may determine whether at least one appending condition required for the first indication and/or the second indication (if present) is satisfied. If the UAC 210 determines that the at least one appending condition is satisfied, the UAC 210 may determine that the first indication and/or the second indication is to be appended to the SIP INVITE request. Then, the UAC 210 may retrieve (310) and append (315) the first indication and/or the second indication to the SIP INVITE request. In some example embodiments, the at least one appending condition may be defined based on network condition information related to the UAS 220.

For example, before the SIP INVITE request is sent to the UAS 220, the UAC 210 decides whether to check certain conditions or not, or unconditionally to encode the request URI of the SIP INVITE request and the Router header (if present) . Then, the UAC 210 may add the encoded data, e.g., as a special token value appended to a header in SIP INVITE request and send the information along with the SIP INVITE request to the UAS 220.

Taking the example of the issue observed in a customer site where the UAC 210 operates as a P-CSCF and the UAS 220 operates as a callee UE, the UAC 210 may decide to check conditions in the following situation. Before an incoming call is sent to the UAS 220, the UAC 210 may check whether the UAS 220 is using a TLS connection to communicate with the UAC 210 or not, and whether an access network of the UAS 220 is via VoWi-Fi or not. Such information may be saved after the UAS 220 registers to an IMS network successfully. For example, an IP address and port, a TLS Session ID, an IP Multimedia Private Identity (IMPI) and an IM Public Identity (IMPU) of the UAS 220 are associated, e.g., as specified in the third generation partnership project (3GPP) standards such as 3GPP TS 33.203, after the UAS 220 registers to the IMS network successfully. The access network information can be retrieved from a saved value of P-Access-Network-Info header in a UE registration request.

In some examples, regarding RFC 7315, P-Access-Network-Info header may be defined as below:

In some example embodiments, if the access-type and access-class indicates a wireless network, including wireless local networking (WLAN) and 3GPP related wireless networking, the appending condition required for the first indication is met and the first indication can be appended in the SIP INVITE request.

If the conditions are met, or it is unconditional, the UAC 210 may encode the request URI and the Route header value (if present) of the SIP INVITE request, add the encoded data as special token values appended to the top Via header in the SIP INVITE request, and send the information along with the SIP INVITE request to the UAS 220. If the access-type or access-class indicates that the UAS 220 is accessing an IMS network via the wireless network, then the UAC 210 can encode the necessary information (e.g., the first indication and/or the second) into the SIP INVITE request, which is needed to construct the SIP CANCEL request. For example, for case of IEEE-802 related access-types or access-class=3GPP-WLAN standards are related to wireless local area networking (WLAN) is considered to appending the first indication and/or the second indication proposed in the example embodiments of the present disclosure. For the access-type or access-class of 3GPP, 3GPP2 or DVB-RCS2 (Digital Video Broadcasting -Return Channel via Satellite) related access-type or access-class, if the wireless signal is weak, then it is also suggested to append the first indication and/or the second indication in the SIP INVITE request in order to construct the SIP CANCEL request later.

As mentioned above, if the request being cancelled contains a Route header field, the SIP CANCEL request needs include that Route header field's values. However, there may be no SIP proxy sitting between a P-CSCF and a UE, which means when a terminating P-CSCF sends the SIP INVITE request to a callee UE, no Route header will be inserted in the SIP INVITE request.

In some example embodiments, if the Route header field is present in the INIVTE request from the UAC 210 to the UAS 220, the following mechanisms can be used to construct the Route header in the SIP CANCEL request. In an example, the same logic may be used to construct Route in the SIP INVITE request if the Route header value is a pre-configured and static data. In another example, as discussed above, a second indication, e.g., a token named "orh" (original Route header) may be inserted into a header (the top Via header) of the SIP INVITE request to represent the Route header value in the SIP INVITE request.

For example, in the latter case, a SIP INVITE request before encoding the necessary information looks as below, where a Session Description Protocol (SDP) part is omitted for simplicity.

Supposing that the encoded data of the request URI "sip: 1234@196.168.90.203: 5061; transport=tls SIP/2.0" is “QbkRBthOEgsTXlRfUUZYXFNCXF5BQUVK” , the UAC 210 adds a special token "oru" (as an example of the first indication of the request URI) in the SIP INVITE request, which means that the original request URI has the encoded value added to the top Via header. Further supposing that the encoded data of the Route header value “<sip: p1. example. com; lr>” is XYZ, the UAC 210 adds token “orh” (as an example of the second indication of the Route header value) , with the encoded value to the top Via header.

After encoding the request URI and the Route header value, the top Via header of the SIP INVITE request is as below:

In some example embodiments, if no SIP response is received from the UAS 220 upon expiry of a retransmission timer for the SIP INVITE request, the UAC 210 may retransmit, to the UAS 220, the SIP INVITE request appended with the first indication and the second indication (if present) .

In some example embodiments, the UAC 210 may receive (325) a SIP response from the UAS 220. If the UAC 210 detects no matching SIP transaction for the SIP response, the UAC 210 may determine (330) whether the first indication of the request URI is present in the SIP response. If the UAC 210 determines (330) that the first indication of the request URI is present in the SIP response, the UAC 210 may determine (335) the request URI from the first indication is present in the SIP response. Then, the UAC 210 may transmit (340) , to the UAS 220, a SIP CANCEL request appended with the request URI.

For example, Internet Engineering Task Force (IETF) RFC or 3GPP TS may define new generic parameters of Via header. The UAS 220 may add it to the top Via header in the received request from the UAC 210. When the late response is sent back to the UAC 210, such additional parameters are sent back to the UAC 210 as well. In order to distinguish the Via parameters inserted by the UAC 210 in the SIP INVITE request from the additional ones inserted by the UAS 220. The UAC 210 can use a bit map value inserted in the top Via header in the SIP INVITE request, which is sent back to the UAC 210 in a SIP response. With this, when the UAC 210 constructs the SIP CANCEL request, the UAC 210 may only use the parameters inserted for the SIP INVITE request to construct the top Via header of the SIP CANCEL request.

By way of example, in the situation that the SIP INVITE transaction terminates earlier, upon receiving a late SIP response (e.g., a 1XX response such as the 180 Ringing response) from the UAS 220, the UAC 210 tries to find the matching SIP INVITE transaction for the 180 Ringing response. If the SIP INVITE transaction is found at the UAC 210 for the SIP response, which means the SIP INVITE transaction has not terminated at the UAC 210. The UAC 210 shall not construct and send the SIP CANCEL request, and the existing normal procedures to handle the SIP response can be executed.

Conventionally, the 180 Ringing response might be discarded at the UAC 210 if no matching SIP transaction is found. According to the example embodiments of the present disclosure, the UAC 210 may check whether the token “oru” (corresponding to the first indication of the request URI) is present in the SIP response or not if no matching SIP transaction is found. If the token “oru” is present in the SIP response, the UAC 210 may generate a CANCEL request, for example, with the following operations. The request URI may be decoded from the token “oru” in the top Via header of the SIP response. In some example embodiments, if the token “orh” (corresponding to the second indication of the Route header value) is present in the SIP response, the UAC 210 may decode the Route header value from the token “orh” in the top Via header of the SIP response. The request URI and the Route header value are used to generate the SIP CANCEL request. Further, the Call-ID, To, the numeric part of CSeq, and From header fields of the SIP CANCEL request may be simply copied from the SIP response.

In some example embodiments, the UAC 210 may not need to check whether the token “orh” (corresponding to the second indication of the Route header value) is present in the SIP response or not, because the Route header field is optional in the SIP INVITE request, and thus the token “orh” is optional.

For the example of the SIP INVITE request as described above, a CANCEL request may appear as below:

The Via headers in the SIP INVITE request may be preserved in a SIP response from the UAS 220. However, the UAS 220 may add any parameter (s) in a Via header in a response to the UAC 210, which may be treated as "generic-param" . Upon receiving the response with additional parameters, the UAC 210 may fail to figure out which optional parameters were added by the UAC 210 from those added by the UAS 220, which looks not strictly follow RFC 3261 which requires at that “a CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled. ”

Actually, since the branch parameter of the top Via header in the SIP CANCEL request is identical with the one presented in the SIP INVITE request, upon receiving the SIP CANCEL request, the branch parameter is used to match the SIP INVITE transaction at the UAS 220, as specified in RFC 3261 which requires that the INVITE transaction to be terminated can be identified. Therefore, in practice, it will not cause any issues if the top Via header in the SIP CANCEL request with additional parameters sent to UAS.

In some example embodiments where it requires to follow the relevant statement in RFC 3261 strictly, a token may be added to the top Via header of the SIP INVITE request, which can be named "ovpl" to present the "optional via parameters list" inserted in the SIP INVITE request by the UAC 210. If the top Via header in the SIP response contains additional parameters added by the UAS 220, which are not in "ovpl" , these parameters are not used to construct the top Via header in the SIP CANCEL request. Therefore, the top Via header in the SIP CANCEL request can still be equivalent to the top Via header in the SIP INVITE request.

One of the example implementations is besides the "oru" parameter, the UAC 210 can define the bit map as below:

Before the UAC 210 sends the SIP INVITE request to the UAS 220, the UAC 210 may check the Via parameters in the top Via header, and record the Via parameters added by the UAC 210 in a token "ovpl" . For example, if "ttl" and "branch" are inserted in the top Via header by the UAC 210, then:

ovpl = VIA_OVPL_TTL | VIA_OVTL_BRANCH, which is 9 (1 | 8) , and “ovpl=9” is inserted in the top Via header in the SIP INVITE request as below:

Via: SIP/2.0/TLS 196.168.90.62: 5060; branch=z9hG4bK; oru=QbkRBthOEgsTXlRfUUZYXFNCXF5BQUVK; ovpl=9; orh=XYZ

If only "branch" is inserted in top Via by the UAC 210, then:

ovpl = VIA_OVTL_BRANCH (8) , and "ovpl=8" is inserted in Top Via in INVITE request as below:

Via: SIP/2.0/TLS 196.168.90.62: 5060; branch=z9hG4bK; oru=QbkRBthOEgsTXlRfUUZYXFNCXF5BQUVK; ovpl=8; orh=XYZ

It would be appreciated that adding the token of “ovpl” is optional in the present disclosure as it is explained in above, where the branch parameter is used to identify the pending SIP INVITE transaction at the UAS, and the branch parameter is identical between the SIP INVITE request and CANCEL request.

In some example embodiments, the first indication can be encrypted or encoded from the request URI, and/or the second indication can be encrypted or encoded from the Route header value. A simple two way encoding like the base64 encoding mechanism may be used. In some example embodiments, to further improve security, the first indication may be encrypted, and only the UAC 210 has the key. In this case, an attacker cannot forge an indication. In some example embodiments, the encryption may be created on the request URI plus a sequence, e.g. a wall clock. In this case, the attacker cannot eavesdrop one indication and keep sending it to the UAC 210. If the UAC 210 finds the sequence is old after decryption, the UAC 210 may just discard it and raise a security alert.

In some example embodiments, in addition to adding the first indication and/or the second indication (e.g., the tokens “oru” and “orh” ) into the SIP INVITE request sent to the UAS 220, the first indication and/or the second indication may be appended in the SIP CANCEL request sent from the UAC 210 to the UAS 220 in order to follow the requirements of the single Via header field value of the SIP CANCEL request matching the top Via value in the request being cancelled.

In some example embodiments, after the UAC 210 transmit (340) , to the UAS 220, a SIP CANCEL request appended with the request URI, the UAC 210 may receive (345) , from the UAS 220, a response to the SIP CANCEL request. The response may be appended with the first indication and/or the second indication. The response may be, for example, a 200 OK message. If the UAC 210 determines that the first indication is present in the response, the UAC 210 may discard (350) the response. The UAS 220 may copy the top Via header of the SIP CANCEL request sent from the UAC 210 and include the top Via header (appended with the first indication) into the response.

In some example embodiments, the UAC 210 may further receive (355) , from the UAS 220, a Request Terminated response (e.g., the 487 (Request Terminated) response) for the SIP INVITE request. The 487 (Request Terminated) response may be appended with the first indication. If the UAC 210 determines that the first indication is present in the 487 (Request Terminated) response, the UAC 210 may discard (360) the 487 (Request Terminated) response without further processing it. The UAC 210 may then transmit (365) the ACK request to the UAS 220.

Upon receiving the 487 (Request Terminated) response, the UAC 210 needs to construct an ACK request (acknowledgement request) . The rule and data to construct the ACK request is similar to construct the SIP CANCEL request as discussed above.

First, the UAC 210 tries to find the matching SIP INVITE transaction for the 487 (Request Terminated) response. If the SIP INVITE transaction is found at the UAC 210 for the 487 (Request Terminated) response, which means the SIP INVITE transaction has not terminated at UAC. The UAC 210 shall not construct the ACK request as proposed in the present disclosure, and the existing procedures to construct the ACK request shall be executed.

Conventionally, the 487 (Request Terminated) response is discarded at UAC if no matching SIP INVITE transaction is found. According to the example embodiments of the present disclosure, the UAC 210 further checks whether the token “oru” is presented or not if no matching SIP INVITE transaction is found.

If the token “oru” is present in the Request Terminated response, the UAC 210 may generate an ACK request, for example, with the following operations. The request URI may be decoded from the token “oru” in the top Via header of the 487 (Request Terminated) response. In some example embodiments, if the token “orh” (corresponding to the second indication of the Route header value) is present in the 487 (Request Terminated) response, the UAC 210 may decode the Route header value from the token “orh” in the top Via header of the 487 (Request Terminated) response . The request URI and the Route header value are used to generate the ACK request to be sent back to the UAS 220. Further, the Call-ID, To, the numeric part of CSeq, and From header fields of the ACK request may be simply copied from the 487 (Request Terminated) response .

Again, in some example embodiments, the UAC 210 may not need to check whether the token “orh” is present or not, because Route header field is optional in the SIP INVITE request, and the token “orh” is optional. However, the request URI in the SIP INVITE request is mandatory, and thus the token “oru” is mandatory if it is added to the top Via header.

In some example embodiments, the ACK request may also be appended with the first indication and/or the second indication present in the Request Terminated response. For example, the first indication and/or the second indication present may be included in the top Via header of the ACK request.

Some example processes of appending the encoded data into top Via header in a SIP request will be described below with reference FIGS. 4A and 4B.

FIG. 4A shows an example process 400 with an example of unstable network conditions which caused a SIP request gone in the SIP layer after the SIP CANCEL request is received from the upstream NE 230 according to some example embodiments of the present disclosure.

As shown in FIG. 4A, in the process 400, after the UAC 210 receives (402) a SIP INVITE request from the upstream NE 230, the UAC 210 may transmit (404) to the UAS 220 a SIP INVITE request with a top via header appended with a first indication of the request URI and a second indication of the Route header value of the SIP INVITE request (e.g., Via: SIP/2.0/TLS 196.168.90.62: 5060; branch=z9hG4bK; oru=QbkRBthOEgsTXlRfUUZYXFNCXF5BQUVK; ovpl=8; orh=XYZ) . However, the transmission of the SIP INVITE request to the UAS 220 is failed. The UAC 210 may retransmit (405) the SIP INVITE request to the UAS 220.

The UAC 210 may receive (406) a CANCEL request from the upstream NE 230. A SIP transaction or dialog may be released (408) after the SIP CANCEL request is received (406) from the upstream NE 230, but no CANCEL request is sent to the UAS 220 (as a callee) because the INVITE transaction between the UAC 210 and the UAS 220 is not treated as a pending transaction.

As a response to the SIP CANCEL request from the upstream NE 230, the UAC 210 may transmit (409) a response, e.g., a 200 OK message, and then transmit (410) a 487 (Request Terminated) response to the upstream NE 230. The upstream NE 230 may transmit (411) a further acknowledgement, e.g., an ACK request to the UAC 210.

Then, the UAC 210 may keep retransmitting (412, 414) to the UAS 220 the SIP INVITE request with the top Via header of “Via: SIP/2.0/TLS 196.168.90.62: 5060; branch=z9hG4bK; oru=QbkRBthOEgsTXlRfUUZYXFNCXF5BQUVK; ovpl=8; orh=XYZ” . In the case that the transmission (414) is successful, the UAC 210 may receive (416) from the UAS 220 a SIP response with the same top Via header of “Via: SIP/2.0/TLS 196.168.90.62: 5060; branch=z9hG4bK; oru=QbkRBthOEgsTXlRfUUZYXFNCXF5BQUVK; ovpl=8; orh=XYZ” . This SIP response may be a 18x response.

If no matching dialog or SIP transaction is found and the special token (e.g., the token “oru” ) is present in the SIP response, then the UAC 210 may transmit (418) to the UAS 220 a CANCEL request with the request URI and the Route header value (if present in the SIP INVITE request) decoded from the SIP response. In some examples, the SIP CANCEL request may also be constructed with the top Via header of “Via: SIP/2.0/TLS 196.168.90.62: 5060; branch=z9hG4bK; oru=QbkRBthOEgsTXlRfUUZYXFNCXF5BQUVK; ovpl=8; orh=XYZ” .

The UAC 210 may receive (420) , from the UAS 220, a 200 OK message to the SIP CANCEL request with the top Via header of “Via: SIP/2.0/TLS 196.168.90.62: 5060; branch=z9hG4bK; oru=QbkRBthOEgsTXlRfUUZYXFNCXF5BQUVK; ovpl=8; orh=XYZ” . The UAC 210 may receive (422) , from the UAS 220, a 487 (Request Terminated) response with the top Via header of “Via: SIP/2.0/TLS 196.168.90.62: 5060; branch=z9hG4bK; oru=QbkRBthOEgsTXlRfUUZYXFNCXF5BQUVK; ovpl=8; orh=XYZ” . As the special token is present, the UAC 210 may discard the 200 OK and the 487 (Request Terminated) responses without further processing. Further, the UAC 210 may generate an ACK request in a similar way as the generation of the SIP CANCEL request, based on the special token “oru” and the token “orh” (if present) . The UAC 210 may transmit (424) to the UAS 220 the ACK message with the top Via header of “Via: SIP/2.0/TLS 196.168.90.62: 5060; branch=z9hG4bK; oru= QbkRBthOEgsTXlRfUUZYXFNCXF5BQUVK; ovpl=8; orh=XYZ” .

FIG. 4B shows an example process 401 with an example of unstable network conditions which caused a SIP request gone in the SIP layer after SIP Timer B expires at the UAC 210 according to some example embodiments of the present disclosure.

The operations or actions of the UAC 210 the process 401 as shown in FIG. 4B are similar to those in the process 414 as shown in FIG. 4A. The difference between the process 401 and the process 400 is that in the process 401, the transaction or dialog is released (430) due to expiration of SIP Timer B, instead of the reception (406) of the SIP CANCEL request from the upstream NE 230 in FIG. 4A. As a response to the expiration of SIP Timer B, the UAC 210 may transmit (432) a Request Terminated response, e.g., a 408 Request Terminated message, to the upstream NE 230. The upstream NE 230 transmits (434) an ACK request to the UAC 210.

According to some example embodiments of the present disclosure, efficiency in resources usage in a SIP UAC may be improved. For example, the minimum and necessary data may be encoded into a SIP request (such as Via header) , which can be piggybacked to a UAC in a SIP response, instead of saving and holding the entire SIP request for quite long time to save UAC memory at the UAC. With this, the memory usage efficiency may be improved at the UAC, especially for large SIP requests.

Moreover, efficiency in processing subsequent responses after sending CANCEL may be improved. For example, in building the SIP CANCEL request, the special token "oru" and “orh” (if it is present) in the SIP response and their values may be also copied to the top Via header of the SIP CANCEL request. The purpose is, upon receiving 200 OK to the SIP CANCEL request, the UAC doesn't need to process the 200 OK message to the SIP CANCEL request if the special token "oru" is present, and just discards it without further processing, because the presence of the token means transaction/dialog matching has already been done and no matching one is found. Also, upon receiving 487 Request Terminated to the SIP INVITE request, same treatment is applied. With this, efficiency may be improved in the response processing, and processing cycles may be saved.

Further, flexibility in appending the data may be provided. Although in some example embodiments, the data may be appended to Via header, it is flexible for implementation to choose any other header that can be piggybacked in a SIP response intactly from the UAS, such as Via, from-tag of From, Call-ID, etc.

As an example, if it is decided to append the encoded data into from-tag, the SIP INVITE request may appear as below:

From: <sip: abcd@example. com>; tag=6510f182-652365e033f5d4e5-000004-oru-QbkRBthOEgsTXlRfUUZYXFNCXF5BQUVK-orh-XYZ

If the encoded data is appended into Call-ID, the SIP INVITE request may appear as below:

Call-ID: a84b4c76e66710-oru-QbkRBthOEgsTXlRfUUZYXFNCXF5BQUVK-orh-XYZ

In addition, complexity in software implementation may be reduced. For example, encoding data into a SIP request and decoding data from a SIP response are implemented at same SIP NE (e.g., a UAC) . No matter how late the response is, the UAC can build CANCEL based on response only.

With example embodiments of the present disclosure, a UAC may simply release the data object in the SIP layer based on the requirement in SIP layer without considering implementation in other layers. Managing connection status and data is usually complicated because implementation from multiple layers can trigger connection closure. According to example embodiments of the present disclosure, a connection between a UAC and a UAS will not be closed.

FIG. 5 shows a flowchart of an example method 500 in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 500 will be described from the perspective of the UAC 210 in FIG. 2.

At block 510, the UAC 210 receives, from an upstream network element, a session initiation protocol, SIP, INVITE request.

At block 520, the UAC 210 retrieves a request uniform request identifier, URI, of the SIP INVITE request.

At block 530, the UAC 210 appends a first indication of the request URI to the SIP INVITE request; and

At block 540, the UAC 210 transmits, to a user agent server, the SIP INVITE request appended with the first indication.

In some example embodiments, the method 500 further comprises: in accordance with a determination that a Route header value is comprised in the SIP INVITE request, appending a second indication of the Route header value to the SIP INVITE request. In some example embodiments, transmitting the SIP INVITE request comprises: transmitting, to the user agent server, the SIP INVITE request appended with the first indication and the second indication.

In some example embodiments, the method 500 further comprises: receiving a SIP response from the user agent server; in accordance with a detection of no matching SIP transaction for the SIP response, determining whether the first indication is present in the SIP response; and in accordance with a determination that the first indication is present in the SIP response, determining the request URI from the first indication present in the SIP response, generating a SIP CANCEL request based on the request URI, and transmitting the SIP CANCEL request to the user agent server.

In some example embodiments, the method 500 further comprises: in accordance with a determination that the second indication is present in the SIP response, determining the Route header value from the second indication present in the SIP response, and generating the SIP CANCEL request further based on the Route header value.

In some example embodiments, the SIP CANCEL request is appended with the first indication and/or the second indication present in the SIP response.

In some example embodiments, the method 500 further comprises: determining whether at least one appending condition required for the first indication and/or the second indication is satisfied; and in accordance with a determination that the at least one appending condition is satisfied, determining that the first indication and/or the second indication is to be appended to the SIP INVITE request.

In some example embodiments, at least one appending condition is defined based on network condition information related to the user agent server.

In some example embodiments, the method 500 further comprises: encoding the request URI of the SIP INVITE request into the first indication; or encoding the Route header value comprised in the SIP INVITE request into the second indication.

In some example embodiments, at least one of the first indication or the second indication is comprised in one of the following: a top Via header of the SIP INVITE request, a From header of the SIP INVITE request, or a call identity (ID) header of the SIP INVITE request.

In some example embodiments, the method 500 further comprises: receiving, from the user agent server, a response to the SIP CANCEL request, the response being appended with the first indication and/or the second indication; and in accordance with a determination that the first indication is present in the response, discarding the response to the SIP CANCEL request.

In some example embodiments, the method 500 further comprises: receiving, from the user agent server, a Request Terminated response for the SIP INVITE request; in accordance with a detection of no matching SIP transaction for the Request Terminated response, determining whether the first indication is present in the Request Terminated response; in accordance with a determination that the first indication is present in the Request Terminated response, determining the request URI from the first indication present in the Request Terminated response, generating an acknowledgement, ACK request based on the request URI, and transmitting the ACK response to the user agent server.

In some example embodiments, generating the ACK request comprises: in accordance with a determination that the second indication is present in the Request Terminated response, determining the Route header value from the second indication present in the Request Terminated response, and generating the ACK request further based on the Route header value.

In some example embodiments, the ACK request is appended with the first indication and/or the second indication present in the Request Terminated response.

In some example embodiments, the apparatus comprises a user agent client.

In some example embodiments, the user agent client comprises a proxy-call session control function.

In some example embodiments, an apparatus capable of performing any of the method 500 (for example, the UAC 210 in FIG. 2) may comprise means for performing the respective operations of the method 500. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The apparatus may be implemented as or included in the UAC 210 in FIG. 2.

In some example embodiments, the apparatus comprises means for receiving, from an upstream network element, a session initiation protocol, SIP, INVITE request; means for retrieving a request uniform request identifier, URI, of the SIP INVITE request; means for appending a first indication of the request URI to the SIP INVITE request; and means for transmitting, to a user agent server, the SIP INVITE request appended with the first indication.

In some example embodiments, the apparatus further comprises: means for, in accordance with a determination that a Route header value is comprised in the SIP INVITE request, appending a second indication of the Route header value to the SIP INVITE request. The means for transmitting the SIP INVITE request comprises: means for transmitting, to the user agent server, the SIP INVITE request appended with the first indication and the second indication.

In some example embodiments, the apparatus further comprises: means for receiving a SIP response from the user agent server; in accordance with a detection of no matching SIP transaction for the SIP response, determining whether the first indication is present in the SIP response; and in accordance with a determination that the first indication is present in the SIP response, means for determining the request URI from the first indication present in the SIP response, means for generating a SIP CANCEL request based on the request URI, and means for transmitting the SIP CANCEL request to the user agent server.

In some example embodiments, the apparatus further comprises: in accordance with a determination that the second indication is present in the SIP response, means for determining the Route header value from the second indication present in the SIP response, and means for generating the SIP CANCEL request further based on the Route header value.

In some example embodiments, the apparatus further comprises: means for determining whether at least one appending condition required for the first indication and/or the second indication is satisfied; and in accordance with a determination that the at least one appending condition is satisfied, determining that the first indication and/or the second indication is to be appended to the SIP INVITE request.

In some example embodiments, the at least one appending condition is defined based on network condition information related to the user agent server.

In some example embodiments, the apparatus further comprises: means for encoding the request URI of the SIP INVITE request into the first indication; or means for encoding the Route header value comprised in the SIP INVITE request into the second indication.

In some example embodiments, the apparatus further comprises: means for receiving, from the user agent server, a response to the SIP CANCEL request, the response being appended with the first indication and/or the second indication; and in accordance with a determination that the first indication is present in the response, discarding the response to the SIP CANCEL request.

In some example embodiments, the apparatus further comprises: means for receiving, from the user agent server, a Request Terminated response for the SIP INVITE request; in accordance with a detection of no matching SIP transaction for the Request Terminated response, determining whether the first indication is present in the Request Terminated response; in accordance with a determination that the first indication is present in the Request Terminated response, means for determining the request URI from the first indication present in the Request Terminated response, means for generating a ACK request based on the request URI, and means for transmitting the ACK request to the user agent server.

In some example embodiments, the apparatus further comprises: means for, in accordance with a determination that the second indication is present in the Request Terminated response, determining the Route header value from the second indication present in the Request Terminated response, and means for generating the ACK request further based on the Route header value.

In some example embodiments, the apparatus comprises a user agent client.

In some example embodiments, the apparatus further comprises means for performing other operations in some example embodiments of the method 500 or the UAC 210. In some example embodiments, the means comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the performance of the apparatus.

FIG. 6 is a simplified block diagram of a device 600 that is suitable for implementing example embodiments of the present disclosure. The device 600 may be provided to implement a communication device, for example, the UAC 210 or the UAS 220 as shown in FIG. 2. As shown, the device 600 includes one or more processors 610, one or more memories 620 coupled to the processor 610, and one or more communication modules 640 coupled to the processor 610.

The communication module 640 is for bidirectional communications. The communication module 640 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interfaces may represent any interface that is necessary for communication with other network elements. In some example embodiments, the communication module 640 may include at least one antenna.

The processor 610 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 600 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

The memory 620 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 624, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , an optical disk, a laser disk, and other magnetic storage and/or optical storage. Examples of the volatile memories include, but are not limited to, a random access memory (RAM) 622 and other volatile memories that will not last in the power-down duration.

A computer program 630 includes computer executable instructions that are executed by the associated processor 610. The instructions of the program 630 may include instructions for performing operations/acts of some example embodiments of the present disclosure. The program 630 may be stored in the memory, e.g., the ROM 624. The processor 610 may perform any suitable actions and processing by loading the program 630 into the RAM 622.

The example embodiments of the present disclosure may be implemented by means of the program 630 so that the device 600 may perform any process of the disclosure as discussed with reference to FIGS 3 to 5. The example embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

In some example embodiments, the program 630 may be tangibly contained in a computer readable medium which may be included in the device 600 (such as in the memory 620) or other storage devices that are accessible by the device 600. The device 600 may load the program 630 from the computer readable medium to the RAM 622 for execution. In some example embodiments, the computer readable medium may include any types of non-transitory storage medium, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like. The term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) .

FIG. 7 shows an example of the computer readable medium 700 which may be in form of CD, DVD or other optical storage disk. The computer readable medium 700 has the program 630 stored thereon.

Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, and other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. Although various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

Some example embodiments of the present disclosure also provide at least one computer program product tangibly stored on a computer readable medium, such as a non-transitory computer readable medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target physical or virtual processor, to carry out any of the methods as described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. The program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of the present disclosure, the computer program code or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.

The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Further, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, although several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Unless explicitly stated, certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, unless explicitly stated, various features that are described in the context of a single embodiment may also be implemented in a plurality of embodiments separately or in any suitable sub-combination.

Although the present disclosure has been described in languages specific to structural features and/or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

An apparatus comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform:

receiving, from an upstream network element, a session initiation protocol, SIP, INVITE request;

retrieving a request uniform request identifier, URI, of the SIP INVITE request;

appending a first indication of the request URI to the SIP INVITE request; and

transmitting, to a user agent server, the SIP INVITE request appended with the first indication.
The apparatus of claim 1, wherein the apparatus is further caused to perform:

in accordance with a determination that a Route header value is comprised in the SIP INVITE request, appending a second indication of the Route header value to the SIP INVITE request; and

wherein the apparatus is caused to perform transmitting the SIP INVITE request by:

transmitting, to the user agent server, the SIP INVITE request appended with the first indication and the second indication.
The apparatus of claim 1 or 2, wherein the apparatus is further caused to perform:

receiving a SIP response from the user agent server;

in accordance with a detection of no matching SIP transaction for the SIP response, determining whether the first indication is present in the SIP response; and

in accordance with a determination that the first indication is present in the SIP response,

determining the request URI from the first indication present in the SIP response,

generating a SIP CANCEL request based on the request URI, and

transmitting the SIP CANCEL request to the user agent server.
The apparatus of claim 3, wherein the apparatus is caused to generate the SIP CANCEL request by:

in accordance with a determination that the second indication is present in the SIP response,

determining the Route header value from the second indication present in the SIP response, and

generating the SIP CANCEL request further based on the Route header value.
The apparatus of claim 3 or 4, wherein the SIP CANCEL request is appended with the first indication and/or the second indication present in the SIP response.
The apparatus of any of claims 2 to 5, wherein the apparatus is further caused to perform:

determining whether at least one appending condition required for the first indication and/or the second indication is satisfied; and

in accordance with a determination that the at least one appending condition is satisfied, determining that the first indication and/or the second indication is to be appended to the SIP INVITE request.
The apparatus of claim 6, wherein the at least one appending condition is defined based on network condition information related to the user agent server.
The apparatus of any of claims 2 to 7, wherein the apparatus is further caused to perform at least one of the following:

encoding the request URI of the SIP INVITE request into the first indication; or

encoding the Route header value comprised in the SIP INVITE request into the second indication.
The apparatus of any of claims 2 to 8, wherein at least one of the first indication or the second indication is comprised in one of the following:

a top Via header of the SIP INVITE request,

a From header of the SIP INVITE request, or

a call identity (ID) header of the SIP INVITE request.
The apparatus of any of claims 3 to 9, wherein the apparatus is further caused to perform:

receiving, from the user agent server, a response to the SIP CANCEL request, the response being appended with the first indication and/or the second indication; and

in accordance with a determination that the first indication is present in the response, discarding the response.
The apparatus of any of claims 3 to 10, wherein the apparatus is further caused to perform:

receiving, from the user agent server, a Request Terminated response for the SIP INVITE request;

in accordance with a detection of no matching SIP transaction for the Request Terminated response, determining whether the first indication is present in the Request Terminated response;

in accordance with a determination that the first indication is present in the Request Terminated response,

determining the request URI from the first indication present in the Request Terminated response,

generating an acknowledgement, ACK, request based on the request URI, and

transmitting the ACK request to the user agent server.
The apparatus of claim 11, wherein the apparatus is caused to generate the ACK request by:

in accordance with a determination that the second indication is present in the Request Terminated response,

determining the Route header value from the second indication present in the Request Terminated response, and

generating the ACK request further based on the Route header value.
The apparatus of claim 11 or 12, wherein the ACK request is appended with the first indication and/or the second indication present in the Request Terminated response.
The apparatus of any of claims 1 to 13, wherein the apparatus comprises a user agent client.
The apparatus of claim 14, wherein the user agent client comprises a proxy-call session control function.
A method comprising:

receiving, from an upstream network element, a session initiation protocol, SIP, INVITE request;

retrieving a request uniform request identifier, URI, of the SIP INVITE request;

appending a first indication of the request URI to the SIP INVITE request; and

transmitting, to a user agent server, the SIP INVITE request appended with the first indication.
An apparatus comprising:

means for receiving, from an upstream network element, a session initiation protocol, SIP, INVITE request;

means for retrieving a request uniform request identifier, URI, of the SIP INVITE request;

means for appending a first indication of the request URI to the SIP INVITE request; and

means for transmitting, to a user agent server, the SIP INVITE request appended with the first indication.
A computer readable medium comprising instructions stored thereon for causing an apparatus at least to perform the method of claim 16.
A computer program comprising instructions which, when executed by an apparatus, cause the apparatus to perform the method of claim 16.