FORM 2
THE PATENTS ACT, 1970
(39 OF 1970)
AND
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“SYSTEM AND METHOD FOR SAVING NETWORK UPLINK
RESOURCES”
We, Reliance Jio Infocomm Limited, an Indian National of, 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad-380006, Gujarat, India.
The following specification particularly describes the invention and the manner in which it is to be performed.

TECHNICAL FIELD
The present invention generally relates to the field of wireless communication systems, and more particularly, to a system and method for saving network uplink resources.
BACKGROUND OF THE DISCLOSURE
The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.
Today a widely deployed wireless network, in order to provide various communication services such as voice, video, data, advertisement, content, messaging, broadcasts, etc. usually comprises multiple access networks and support communications for multiple users by sharing the available network resources.
One example of such a network is the Evolved Universal Terrestrial Radio Access (E-UTRA) which is a radio access network standard meant to be a replacement of the Universal Mobile Telecommunications System (UMTS) and High-Speed Downlink Packet Access/High-Speed Uplink Packet Access (HSDPA/HSUPA) technologies specified in 3GPP releases 5 and beyond. Unlike HSPA, Long Term Evolution’s (LTE's) E-UTRA is an entirely new air interface system, unrelated to and incompatible with W-CDMA. It provides higher data rates, lower latency and is optimized for packet data. The earlier UMTS Terrestrial Radio Access Network (UTRAN) is the radio access network (RAN), defined as a part of the Universal Mobile Telecommunications System (UMTS), a third-generation (3G) mobile phone technology supported by the 3rd Generation Partnership Project (3GPP). The UMTS, which is the successor to Global System for Mobile Communications (GSM) technologies, currently supports various air interface standards, such as

Wideband-Code Division Multiple Access (W-CDMA), Time Division-Code Division Multiple Access (TD-CDMA), and Time Division-Synchronous Code Division Multiple Access (TD-SCDMA). The UMTS also supports enhanced 3G data communications protocols, such as High-Speed Packet Access (HSPA), which provides higher data transfer speeds and capacity to associated UMTS networks. Furthermore, as the demand for mobile data and voice access continues to increase, research and development also continue to advance the technologies not only to meet the growing demand for access, but to advance and enhance the user experience with user device. Some of the technologies that have evolved starting GSM/EDGE, UMTS/HSPA, CDMA2000/EV-DO and TD-SCDMA radio interfaces with the 3GPP Release 8, e-UTRA are designed to provide a single evolution path for providing increased data speeds, and spectral efficiency, and for allowing the provision of more functionality.
Further, the voice over LTE or VoLTE is a GSMA profile of standards definition, for the delivery of services, currently provided via circuit switch networks for mainly voice and short message service (SMS) and over the packet-switched network of LTE, leveraging the core network IP Multimedia Subsystem (IMS). When the mobile networks deploy LTE radio access technology in conformity with the VoLTE profile, the service operator provides assurance of interworking between their LTE network and the devices that connect to it and as well as of providing the expected user experience of voice, multi-media telephony service and SMS. Also, in combination with Policy Control, the IP Multimedia Subsystem (IMS) provides the required QoS appropriate for voice service using LTE radio access technology, thereby providing the user experience of voice calls to the subscribers.
Moreover, VoLTE is designed to fully integrate with the existing user experience that is currently implemented with circuit-switched voice UEs, and therefore whether the call is a circuit-switched call or a VoLTE, the call is transparent to the end UE (including when moving in and out of LTE coverage) and is dependent

only on radio access technology to which the user is attached. Also, at the same time, using new, wideband codecs can provide higher voice quality and enhance the user experience at the UEs having such capabilities.
Furthermore, in order to establish a call over these networks using a Mobile Originated (MO) User Equipment (UE)/source UE, a number of protocols such as signaling protocols, media protocols etc., are required to establish and connect such calls. Further, Session Description Protocol (SDP) defines the kind of packets (such as RTP, DTMF etc.) that are to be transmitted during the establishment of said call.
Also, the current RTP packet flow for Caller Ring Back Tone (CRBT) indicates that when a Mobile Originated (MO) UE, calls, Mobile Terminated (MT) UE/destination UE, the destination UE starts ringing. Before MT party answers the call, ring-back tone (RBT) is played at MO UE. Timeout for RBT when MT doesn’t answer the call is network configurable say, 40 seconds.
Further, during a call initiation, the MO UE sends INVITE Request appended with the supported RTP/media codec in SDP (Session description protocol) with attribute ‘a’ = sendrecv towards MT UE via LTE & IMS network. Thereafter, the MT UE receives the INVITE Request and in response sends a Session Progress along with MT UE’s appended supported RTP/media codec in SDP of the Session Progress with attribute ‘a’ = sendrecv.
Thereafter, based on a provision acknowledgement (PRACK), MO UE starts sending RTP packets towards MT UE as a dedicated bearer is established. Next, the current RTP packet flow for Caller Ring Back Tone (CRBT) indicates that the MT UE sends a Ringing response to MO UE, and once telecom application server (TAS) receives the ringing response from MT UE, it (TAS) sends INVITE towards Media server (MRF) for CRBT negotiation. This INVITE will contain MO UE Session Description Protocol (SDP). Further, the MRF reply with an OK response for the INVITE received from TAS. In this OK response, the MRF adds its SDP – RTP Codec and attribute ‘a’ = Sendrecv. The TAS sends an acknowledgement for OK

response received from the MRF. Thereafter, TAS sends UPDATE Request toward MO UE with SDP of the MRF. In response to UPDATE MO, UE sends an OK response with its SDP – RTP Codec and attribute ‘a’ = sendrecv. After this negotiation, RTP tunnel is established between MO UE and the MRF which allows RTP flow between the MO UE and the MRF.
Media and Payload attributes
“sendonly”: The entity sending this attribute notifies the other end entity that it will be operational with only in ‘Sending’ mode and will not receive any media. “recvonly”: The entity sending this attribute notifies the other end entity that it will be operational with only in ‘Receiving’ mode and will not send any media. “sendrecv”: The entity sending this attribute notifies the other end entity that it will be operational with both ‘Sending’ and ‘Receiving’ mode simultaneously. “inactive”: The entity sending this attribute notifies the other end entity that it will be operational but will not ‘Send’ or ‘Receive’ any media.
Dual-tone multi-frequency (DTMF) signaling:
Dual-tone multi-frequency signaling (DTMF) is a telecommunication signaling system using the voice-frequency band over telephone lines between telephone equipment and other communications devices and switching centers. On the sending side, there could be possibilities: either the sending side is an end system that originates the signals itself, or it is a gateway with the task of propagating incoming telephone signals into the Internet.
Existing Problem
It is observed that before the call is answered by the receiving party, there are unwanted flow of RTP packets from call initiating device which further leads to consumption of resources. Further, the MO UE sends RTP packets during a ringing state as the MO UE receives UPDATE request with media session attribute ‘a’ = “sendrecv” for all codecs in SDP for ring-back tone, from the telecom application server (TAS). Furthermore, it is not required for MO UE to send RTP packets which unnecessarily consumes uplink resources during a

ringing state and therefore the unwanted flow of RTP packets from call initiating device (i.e. MO UE) leads to unnecessary consumption of the uplink resources.
Current Prior Arts:
Some of the known prior art solutions provide resource-saving techniques but
these solutions are not optimized and have limitations that make them unfit in
certain deployment scenarios as explained below.
One of the existing art describes a network resource environment that can be
used to dynamically control or manage the resource for a session that is
experiencing a resource shortage (detected either by the network or
communicated to the network) where session signaling is used to modify the
session resource according to network or base station.
Also, one other prior known solution describes method for the efficient
mechanism of circuit-switched fallback (CSFB) signaling and resource usage for a
system supporting Circuit Switched (CS) and Packet Switched (PS) sessions with
the help of wireless transmitting/receiving unit (WTRU).
Further, one more known prior art solution describes method to monitor VoLTE
call for any interruption in the packet flow that exceeds a threshold duration to
determine abnormal termination of the VoLTE call and information regarding the
abnormal VoLTE call termination to be propagated to the network (where an
abnormal VoLTE call termination event may be logged). And this abnormal VOLTE
call termination event may be utilized for analyzing and managing the
performance of communications over a Voice over Long-Term Evolution (VoLTE)
network.
Furthermore, from the above arts, it is clear that there are no solutions available
to prevent unwanted flow of RTP packets from the UE call initiating device
before the call is answered by the receiving party leading to consumption of
resources that disallow increased throughput performance and substantial
decline in average throughput experienced.
Therefore, in view of these and other existing limitations, there is an imperative

need to provide a solution to overcome the limitations of prior existing solutions and to provide methods and systems for saving network uplink resources by preventing the unwanted flow of RTP packets from the UE call initiating device.
SUMMARY OF THE DISCLOSURE
This section is provided to introduce certain objects and aspects of the present invention in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.
In order to overcome at least some of the drawbacks mentioned in the previous section and those otherwise known to persons skilled in the art, an object of the present disclosure is to provide a method and system for saving network uplink resources. Also, an object of the present invention is to prevent unwanted flow of RTP packets from the UE call initiating device (source UE) before the call is answered by the receiving party leading to consumption of resources. One other object of the present invention is to save a considerable amount of uplink resources which can be used for accommodating more users, say for emergency calls or NB-IoT deployment or any other use case based on service operator’s needs. Also, an object of the present invention is to provide improved throughput for network subscriptions in multi-SIM, multi-active wireless devices by preventing uplink scheduling. Another object of the present invention is to provide an automatic mechanism that aims at minimizing radio resource wastage occurring due to CBRT uplink request as well as improving performance. Also, one other object of the present invention is to prevent lower layer retransmissions from happening and to conserve radio resources that are wasted in carrying these retransmissions. Also, an object of the present invention is to provide increased throughput performance and to prevent substantial decline in average throughput. One other object of the present invention is to benefit end-users by neutralizing the adverse effect of the unwanted flow of RTP packets from the UE call initiating device, thereby rendering better user experience. Also,

an object of the present invention is to provide a device ecosystem that provides a seamless enhancement of session in multi-SIM, multi-active wireless devices. Yet another object of the present invention is to prevent unwanted flow of RTP packets from the source UE before the call is answered by the receiving party, independent of whether the source UE is 4G/3G/EV-Do/eHRPD capable technology.
In order to achieve the aforementioned objectives, the present invention provides a method and system for saving uplink network resources. A first aspect of the present invention relates to a method for saving uplink network resources. The method comprising transmitting, from a transceiver unit to a destination user equipment (UE), at least one INVITE request comprising one or more supported media and codecs parameters of a source user equipment (UE) in session description protocol (SDP), in an event at least one call is initiated from a source user equipment (UE) to the destination UE. Thereafter, the method encompasses receiving, at the transceiver unit from the destination UE, at least one ringing response based on the at least one initiated call. The method further comprises segregating, via a segregation module, the session description protocol (SDP) based on at least one payload type, in an event at least one P¬Early media parameter is not inactive. Thereafter, the method comprises modifying, via the segregation module, at least one payload attribute based on the segregation of the session description protocol (SDP) and the at least one payload type. The method further encompasses transmitting, from the transceiver unit to the source UE, at least one UPDATE request comprising the modified at least one payload attribute and at least one payload. Further, the method encompasses receiving, at the transceiver unit from the source UE, at least one UPDATE acknowledgement based on the at least one UPDATE request. Another aspect of the present invention relates to a system for saving uplink network resources. The system comprises a transceiver unit configured to transmit to a destination user equipment (UE), at least one INVITE request

comprising one or more supported media and codecs parameters of a source user equipment (UE) in session description protocol (SDP), in an event at least one call is initiated from a source user equipment (UE) to the destination UE. The transceiver unit is further configured to receive from the destination UE, at least one ringing response based on the at least one initiated call. The system further comprises a segregation module (SM), configured to segregate, the session description protocol (SDP) based on at least one payload type, in an event at least one P-Early media parameter is not inactive. The segregation module is further configured to modify, at least one payload attribute based on the segregation of the session description protocol (SDP) and the at least one payload type. Also, the transceiver unit is further configured to transmit, to the source UE, at least one UPDATE request comprising the modified at least one payload attribute and at least one payload. Thereafter, the transceiver unit is configured to receive, from the source UE, at least one UPDATE acknowledgement based on the at least one UPDATE request.
BRIEF DESCRIPTION OF DRAWINGS
The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components or circuitry commonly used to implement such components. Figure 1 illustrates an exemplary block diagram indicating a source user equipment (UE) connected to a destination user equipment (UE) in an event at least one call is initiated from the source UE to the destination UE, in accordance

with exemplary embodiments of the present invention.
Figure 2 illustrates an exemplary block diagram of the system for saving uplink
network resources, in accordance with exemplary embodiments of the present
invention.
Figure 3 illustrates an exemplary block diagram indicating an RTP packet Flow in
an event at least one call is initiated from the source UE to the destination UE in
an LTE network, in accordance with exemplary embodiments of the present
invention.
Figure 4 illustrates an exemplary method flow diagram, depicting a method for
saving uplink network resources, in accordance with exemplary embodiments of
the present invention.
Figure 5 illustrates an exemplary flow diagram, depicting an instance
implementation of the process of saving uplink network resources, in accordance
with exemplary embodiments of the present invention.
Figure 6 illustrates an exemplary sequence diagram, depicting an instance
implementation of the process of saving uplink network resources, in accordance
with exemplary embodiments of the present invention.
Figure 7 illustrates an exemplary block diagram of a user equipment comprising a
SIM (subscriber identity module) card, in accordance with exemplary
embodiments of the present invention.
The foregoing shall be more apparent from the following more detailed
description of the disclosure.
DESCRIPTION OF THE INVENTION
In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature

may not address all of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein.
The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth.
Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a sequence diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function. Furthermore, embodiments may be implemented by hardware, software,

firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks (e.g., a computer-program product) may be stored in a machine-readable medium. A processor(s) may perform the necessary tasks.
The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive—in a manner similar to the term “comprising” as an open transition word—without precluding any additional or other elements.
Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. 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” and/or “comprising,” when used in this

specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.
As utilized herein, terms “component,” “system,” “platform,” “node,” “layer,” “selector,” “interface,” and the like are intended to refer to a computer-related entity, hardware, software (e.g., in execution), and/or firmware. For example, a component can be a process running on a processor, a processor, an object, an executable, a program, a storage device, and/or a computer. By way of illustration, an application running on a server and the server can be a component. One or more components can reside within a process and a component can be localized on one computer and/or distributed between two or more computers.
Further, these components can execute from various computer-readable media having various data structures stored thereon. The components may communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal). As another example, a component can be an apparatus with specific functionality provided by mechanical parts operated by electric or electronic circuitry which is operated by a software application or a firmware application executed by a processor, wherein the processor can be internal or external to the apparatus and executes at least a part of the software or firmware application. As yet another example, a component can be any apparatus that provides specific functionality through electronic components without mechanical parts, the electronic components can include a processor therein to execute software or firmware that confers at least in part the functionality of the electronic

components.
In addition, the disclosed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. The term “article of manufacture” as used herein is intended to encompass a computer program accessible from any computer-readable device, computer-readable carrier, or computer-readable media. For example, computer-readable media can include, but are not limited to, magnetic storage devices, e.g., hard disk; floppy disk; magnetic strip(s); optical disk (e.g., compact disk (CD), digital video disc (DVD), Blu-ray Disc™ (BD); smart card(s), flash memory device(s) (e.g., card, stick, key drive).
Moreover, terms like “source and/or destination user equipment (UE)”, “mobile station”, “smart computing device”, “user device”, “user equipment”, “mobile subscriber station,” “access terminal,” “terminal,” “handset,” and similar terminology refers to any electrical, electronic, electro-mechanical or an equipment or a combination of one or more of the above devices. Smart computing devices may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, pager, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device as may be obvious to a person skilled in the art. In general, a smart computing device is a digital, user-configured, computer networked device that can be operated autonomously. A smart computing device is one of the appropriate systems for storing data and other private/sensitive information. The smart computing device operates at all the seven levels of ISO reference model, but the primary function is related to the application layer along with the network, session and presentation layer. The smart computing device may also have additional features of a touch screen, apps ecosystem, physical and biometric security, etc. Further, the foregoing

terms are utilized interchangeably in the subject specification and related drawings.
Furthermore, the terms “user,” “subscriber,” “customer,” “consumer,” “agent,”, “owner,” and the like are employed interchangeably throughout the subject specification and related drawings, unless context warrants particular distinction(s) among the terms. It should be appreciated that such terms can refer to human entities, or automated components supported through artificial intelligence, e.g., a capacity to make inference based on complex mathematical formulations, that can provide simulated vision, sound recognition, decision making, etc. In addition, the terms “wireless network” and “network” are used interchangeable in the subject application, unless context warrants particular distinction(s) among the terms.
As used herein, a “processor” or “processing unit” includes one or more processors, wherein processor refers to any logic circuitry for processing instructions. A processor may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, a low-end microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input/output processing, and/or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor or processing unit is a hardware processor.
As used herein, a “transceiver unit” may comprise one or more transmitter units and one or more receiver units, configured to transmit and receive respectively, at least one of one or more signals, data and commands to one or more units/modules/equipment, in order to implement the features of the present disclosure. The transceiver unit may be any such transmitting and receiving unit known to the person skilled in the art, required to implement the features of the

present invention.
As used herein, a “segregation module (SM)” may be an intelligent unit/module having an analyzing, a transmitting, a receiving, a computing, an identifying and a segregating capability, and/or the segregation module (SM) may be any other such similar module configured to implement the features of the present disclosure and is obvious to a person skilled in the art.
Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings so that those skilled in the art can easily carry out the present disclosure.
The present invention provides a solution to save uplink network resources by preventing transmission of Real-time Transport Protocol (RTP) packets from a source UE to a destination UE, thereby saving PRB (physical resource block) resources during a ringing state, in an event at least one call is initiated from the source UE to the destination UE. Furthermore, the present invention encompasses a segregation module (SM) configured to save uplink network resources. The segregation module segregates at least one session description protocol (SDP) on the basis of one or more payload types, such as DTMF, Telephony and other media payload types. Furthermore, the segregation module segregates the DTMF payload from the other media payloads so as to modify at least one payload attribute as ‘sendonly’ for the Media payloads and also to modify the at least one payload attribute to ‘sendrecv’ for DTMF Payload. Furthermore, the segregation module of the present invention helps in signaling the ‘sendonly’ attribute for the non-DTMF/media/voice payloads, whilst the state between ringing and until the call is connected/terminated, the source UE stops sending non-DTMF media packets to a network.
Also, the present invention keeps the DTMF Payload attribute as ‘sendrecv’ considering various use-cases during a RINGING State, for instance, an input relating to a DTMF Payload from a source UE may be needed during a ringing state, therefore the present invention encompasses keeping the DTMF Payload

attribute as ‘sendrecv’. Therefore, the present invention prevents unwanted transmission RTP packets from the source UE to the destination UE, during the ringing state, by modifying the at least one payload attribute as ‘sendonly’ for the Media payloads and also by modifying the at least one payload attribute to ‘sendrecv’ for DTMF Payload.
The present invention is further explained in detail below with reference now to the diagrams.
Referring to FIG. 1, an exemplary block diagram [100] indicating a source user equipment (UE) connected to a destination user equipment (UE) in an event at least one call is initiated from the source UE to the destination UE, in accordance with exemplary embodiments of the present invention is shown.
The block diagram [100] as provided in Figure 1 indicates, that the source UE [102] is connected to the destination UE [108] via a telecom application server (TAS) [104] and a media server [106], in an event at least one call is initiated from the source user equipment (UE) [102] to the destination UE [108].
Further, the user equipment (UE) refers to a mobility wireless cellular connectivity device that allows end-users to use services on 2G, 3G, 4G and/or the like mobile broadband Internet connections. The UE may have an advanced mobile operating system which further combines features of a personal computer operating system with other features useful for mobile or handheld use. The user equipment/smartphones can access the Internet, and usually have a touchscreen user interface, also the user equipment can run third-party applications including the capability of hosting online applications, music players etc. Furthermore, the smartphone devices may also be camera smartphone devices, capable of possessing high-speed mobile broadband 4G LTE internet with video calling functionality, hotspot functionality, motion sensors, mobile-payment mechanisms, enhanced security features with alarm and alert in emergencies and other similar functionalities. Also, mobility devices may include smartphones, wearable devices, smart-watches, smart bands, wearable

augmented devices, etc. Further for the sake of specificity, the mobility device in the present disclosure refers to both feature phone and smartphones, but it does not limit the scope of the present disclosure and may extend to any mobility device in implementing the technical solutions. The above smart devices including the smartphone as well as the feature phone including IoT devices enable the communication on the devices.
Further, the source UE [102] is call initiating device or a mobile originator user equipment (MO UE) configured to initiate the at least one call to the destination UE [108]. Also, the destination UE is a mobile terminating user equipment (MT UE) configured to receive the at least one call from the source UE.
Furthermore, the source UE [102] in order to establish the at least one call with the destination UE [108] transmits at least one INVITE request comprising one or more supported media and codecs parameters of the source user equipment (UE) in session description protocol (SDP) to the TAS [104]. Further, the TAS [104] transmits the received INVITE request to the destination UE [108].
Further, the TAS [104] receives from the destination UE [108], at least one session progress response comprising one or more supported media and codecs parameters of the destination UE [108] in SDP, in response to the at least one INVITE request transmitted to the destination UE [108]. The TAS [104] thereafter transmits the received at least one session progress to the source UE [102]. Thereafter, at least one provision acknowledge (PRACK) is response is received at the source UE [102] from the destination UE [108] via the TAS [104], in response to at least one provision acknowledge request transmitted from the source UE [102] to the destination UE [108]. Further, once the at least one provision acknowledge is completed, at least one dedicated bearer (QCI1) for a voice call is established and the source UE [102] starts sending RTP packets towards the destination UE [108].
Further, the destination UE [108] transmits to the TAS [104], at least one ringing response based on the transmission of the RTP packets towards the destination

UE [108]. Thereafter, TAS transmits the received at least one ringing response to
the source UE [102].
Therefore, when the at least one call is initiated from the source UE [102] to the
destination UE [108], the destination UE [108] starts ringing on the basis of the
above-explained process. Also, before the destination UE [108] answers the call,
a ring back tone (RBT) is played at source UE [102]. In an instance, a timeout for
RBT when the destination UE [108] doesn’t answer the call is network
configurable say, 40 seconds.
Furthermore, the TAS [104] as disclosed in the Figure 1 comprises at least one
system [200] and also the TAS [104] is connected to a media server (MRF) [106].
The media server [106] is configured to receive at least one INVITE request from
the TAS [104], wherein the INVITE request comprises source UE [102] SDP.
Thereafter, the media server [106] is configured to transmit to the TAS [104] a
response to the received INVITE request along with destination UE’s SDP.
Also, the system [200] is configured to save uplink network resources by
implementing the features of the present invention.
Referring to FIG. 2, an exemplary block diagram of the system [200] for saving
uplink network resources, in accordance with exemplary embodiments of the
present invention is shown.
The system [200] comprises, at least one segregation module (SM) [202] and at
least one transceiver unit [204]. In an instance, the system [200] may be a part of
a telecom application server (TAS) [104]. Also, all of the components/ units of the
system [200] are assumed to be connected to each other unless otherwise
indicated below. Also, in Fig. 2 only a few units are shown, however, the system
[200] may comprise multiple such units or the system [200] may comprise any
such numbers of said units, obvious to a person skilled in the art or as required
to implement the features of the present disclosure.
The system [200], is configured to save uplink network resources, with the help
of the interconnection between the components/ units of the system [200].

The at least one transceiver unit [204] is configured to transmit to a destination user equipment (UE) [108], at least one INVITE request comprising one or more supported media and codecs parameters of a source user equipment (UE) [102] in session description protocol (SDP), in an event at least one call is initiated from the source user equipment (UE) [102] to the destination UE [108]. Thereafter, the transceiver unit [204] is further configured to receive, from the destination UE [108], at least one session progress response comprising one or more supported media and codecs parameters of the destination UE [108] in SDP. The transceiver unit [204] is further configured to transmit the received at least one session progress to the source UE [102]. For instance, the destination UE [108] in response to the received INVITE request may transmit 183-Session Progress with its supported media and codecs parameters in SDP towards the source UE [102]. Therefore said 183-Session Progress is first received at the transceiver unit [204] from the destination UE [108] and the transceiver unit [204] further transmits said 183-Session Progress to the source UE [102].
Thereafter, the transmitter unit [204] is further configured to transmit to the destination UE [108], at least one provision acknowledgement (PRACK) request, wherein said at least one provision acknowledgement (PRACK) request is received at the transmitter unit [204] from the source UE [102] in response to the at least one session progress. Further considering above instance, the source UE [102] is thereafter configured to identify a “require: 100rel” header in the received 183 response. Further if the at least one “require: 100rel” header is identified in the received 183 response, the source UE [102] transmits the at least one PRACK request to the transceiver unit [204]. The transceiver unit [204] is further configured to transmit the received at least one PRACK request to the destination UE [108].
Further, the transmitter unit [204] is further configured to receive, from the destination UE [108], at least one PRACK response based on the at least one PRACK request. Also, the transmitter unit [204] is further configured to transmit

the received at least one PRACK response to the source UE [102]. Further considering above instance, the at least one PRACK response received at the transmitter unit [204] from the destination UE [108] may comprise at least one 200 OK response/indication.
Further, once the at least one provision acknowledge is completed, at least one dedicated bearer (QCI1) for a voice call is established and the source UE [102] starts sending RTP packets towards the destination UE [108].
Thereafter, the transceiver unit [204] is configured to receive from the destination UE [108], at least one ringing response based on the at least one initiated call. Also, the transceiver unit [204] is further configured to receive from the destination UE [108], at least one ringing response based on at least one provision acknowledgement (PRACK). Further, the transceiver unit [204] transmits the received at least one ringing response to the source UE [102]. Also, considering above instance, the at least one ringing response may comprise at least one 180-Ringing response.
Further, the at least one segregation module [202] is connected to the at least one transceiver unit [204]. The segregation module [202] is configured to segregate, the session description protocol (SDP) based on at least one payload type in an event at least one P-Early media parameter is not inactive. Furthermore, in an event if the at least one P-Early media parameter is inactive, the transceiver unit [204] is configured to transmit to the source UE [102], the at least one ringing response, as no media is transmitted during the P-Early media in said event. Therefore, in such events where the at least one P-Early media parameter is inactive no segregation and modification of the session description protocol (SDP) is required.
Further, in the event where the at least one P-Early media parameter is not inactive, in order to segregate, the session description protocol (SDP), the segregation module [202] is further configured to receive from a media server [106], the session description protocol (SDP) comprising an attribute ‘sendrecv’.

Also, the segregation module [202] is configured to receive from the media server [106], the session description protocol (SDP) based on an INVITE request received at the media server [106] from the segregation module [202], wherein the INVITE request comprises an SDP of source UE [102] for CRBT negotiation. Further, considering the above instance, the segregation module [202] is further configured to receive from a media server [106], 200 OK (SDP of Media Server; Media attribute set to a=sendrecv). In an event the segregation module [202], on the basis of the at least one payload type, segregates the session description protocol (SDP) in at least one of a DTMF payload type and a non-DTMF payload type.
Further, the segregation module [202] is configured to modify, at least one payload attribute based on the segregation of the session description protocol (SDP) and the at least one payload type. Also, the segregation module [202] is further configured to identify the at least one payload type to modify the at least one payload attribute. Further, the segregation module [202] is further configured to modify the at least one payload attribute to ‘sendrecv’ in an event the identified at least one payload type is DTMF payload. Also, the segregation module [202] is further configured to modify the at least one payload attribute to ‘sendonly’ in an event the identified at least one payload is non-DTMF payload. Also, the non-DTMF payload is a voice payload.
Thereafter, the transceiver unit [204] is further configured to transmit, to the source UE [102], at least one UPDATE request comprising the modified at least one payload attribute and at least one payload. Also, the segregation module [202] is thereafter configured to terminate the segregation of the session description protocol (SDP) based on the transmission of at least one UPDATE request from the transceiver unit [204] to the source UE [102].
Further, the transceiver unit [204] is configured to receive, from the source UE [102], at least one UPDATE acknowledgement/response based on the at least one UPDATE request. Further considering the above instance the UPDATE

acknowledgment/response may comprise 200 OK (SDP – source UE) (a= recvonly for Voice Payload, a= sendrecv for DTMF Payload).
Also, the transceiver unit [204] is configured to receive from the media server [106], the session description protocol (SDP) based on an INVITE request received at the media server [106] from the transceiver unit [204], wherein the INVITE request comprises modified SDP of source UE [102] after CRBT negotiation. Further considering the above instance, INVITE (a= recvonly for Voice Payload, a= sendrecv for DTMF Payload) is transmitted from the transceiver unit [204] to the media server [106], based on the reception of at least one UPDATE acknowledgment/response from the source UE [102] to transceiver unit [204].
Further, the transceiver unit [204] at TAS [104] is further configured to receive from the media server [106], at least one INVITE acknowledgment/response based on the at least one INVITE request. Further considering the above instance the INVITE acknowledgment/response may comprise 200 OK (SDP of UE-MO) (a= recvonly for Voice Payload, a= sendrecv for DTMF Payload).
Also, the transceiver unit [204] at TAS [104] is configured to send at the media server [106], at least one Acknowledgment based on the at least one INVITE acknowledgment/response received at the transceiver unit [204]. Further considering the above instance, the Acknowledgement may comprise ACK. Therefore, segregation and modification of the SDP as provided above, allows the source UE [102] to only receive RTP packets for CRBT from Media Server, with media session for DTMF still in trans-receive mode.
Further some exemplary samples of the proposed solution are as below:
SDP Change Proposed:
1. SDP change in UPDATE request (from Media Server) for
CRBT: m= audio 41344 RTP/AVP 104

b=bandwidth AS RR RS
a=rtpmap: 104 AMR-WB/16000
a= fmtp:104 octet-algn=1; mode-set=0,1,2,3…….
a=sendonly
a=ptime:20
a=rtcp-xr
m= audio portno RTP/AVP 105
B= Bandwidth …
a=rtpmap : 105 telephone-event/16000
a=fmtp:105 0-15,32,36
a=sendrecv.
a=maxptime:80
2. SDP change in 200 OK (from UE) for UPDATE request for
CRBT: m= audio 50020 RTP/AVP 104
B=bandwidth AS RR RS
a=rtpmap : 104 AMR-WB/16000/1
a= fmtp:104 octet-algn=1;mode-set=0,1,2,3……..
a=recvonly.
a=ptime:20
a=maxptime:240
m= audio portno RTP/AVP 105
B= Bandwidth …
a=rtpmap : 105 telephone-event/16000
a=fmtp:105 0-15
a=sendrecv.
a=maxptime:240

a=ptime:20 Referring to Fig. 3, an exemplary block diagram [300] indicating an RTP packet Flow in an event at least one call is initiated from the source UE to the destination UE in an LTE network, in accordance with exemplary embodiments of the present invention is shown.
The exemplary block diagram [300] as indicated in the Figure 3 indicates that a source UE i.e. MO UE [102] is connected with a destination UE i.e. MT UE [108] via an IMS network [302], in an event a call is initiated from the MO UE [102] to MT UE [108] in an LTE environment. The MO UE [102] and the MT UE [108] are connected to the LTE network via LTE-Uu interface. Also, the MO UE [102] and the MT UE [108] are connected to a PCSCF [304] of the IMS network [302] over a Gm interface.
Further, the IMS network [302] comprises two PCSCF [304] connected to a SCSCF [306] over an Mw interface. The SCSCF [306] in the IMS network [302] is further connected to a telecom application server (TAS) [104] via an ISC interface. Thereafter, the TAS [104] is connected to a media server (MRF) [106] over a Mr interface.
Also, the TAS [104] further comprises at least one system [200], the same is not shown in the Figure 3 for the purpose of clarity. Further said system [200] is configured to save uplink network resources in the LTE environment. Also, the system [200] further comprises at least one segregation module [202] and at least one transceiver unit [204].
Further as provided above in the description of Figure 1 and Figure 2, when a call is initiated via the source UE [102] to the destination UE [108], a ringing response from the destination UE [108] to the source UE [102] is received via TAS [104]. Therefore, as per the Figure 3, when a 180-Ringing response reaches at the transceiver unit [204] of the system [200] of the TAS [104], the segregation module [202] of the system [200], identifies whether the ‘P-Early media’ parameter is ‘inactive’ or not.

Further, if in an event the P-Early media parameter is inactive, then the
transceiver unit [204] is configured to send the ‘180 RINGING’ to MO UE [102] as
no media will be transmitted during the P-Early media in such event.
Also, if in an event the P-Early media parameter is not inactive, then the
transceiver unit [204] is configured to transmit the ‘180 RINGING’ to MO UE
[102] and a media negotiation is started between the TAS [104] and the Media
Server [106]. Further in such event, the SM [202] is configured to identify the at
least one payload type to modify the at least one payload attribute, for instance,
the SM [202] identifies whether the payload type is ‘DTMF’ or not.
Further, if the identified payload type is DTMF payload then the SM [202] is
configured to modify the payload attribute to ‘sendrecv’. Also, if the identified
payload type is non-DTMF payload then the SM [202] is configured to modify the
payload attribute to ‘sendonly’.
Further, the transceiver unit [204] is configured to transmit the modified payload
and attributes by an UPDATE request towards MO UE [102]. For instance, the
UPDATE request comprises: SDP of Media Server: For DTMF, Media attribute set
to a=sendrecv. For non-DTMF, Media attribute set to a=sendonly.
Further, the segregation module [202] is further configured to terminate the
segregation of the session description protocol (SDP) based on the transmission
of the UPDATE request from the transceiver unit [204] to the MO UE [102].
Therefore, the implementation of the system [200] of the present invention at
the TAS [104], allows the source UE [102] to only receive RTP packets for CRBT
from Media Server, with media session for DTMF still in trans-receive mode,
thereby preventing the transmission of RTP packets to devices and saving PRB
resources.
Referring to Fig. 4, an exemplary method flow diagram, depicting a method for
saving uplink network resources, in accordance with exemplary embodiments of
the present invention is shown. As shown in Fig. 4, the method begins at step
[402].

At step [404], the method comprises transmitting from a transceiver unit [204] to a destination user equipment (UE) [108], at least one INVITE request comprising one or more supported media and codecs parameters of a source user equipment (UE) [102] in session description protocol (SDP), in an event at least one call is initiated from the source user equipment (UE) [102] to the destination UE [108].
Next, the transmitting, from a transceiver unit [204] to a destination user equipment (UE) [108], at least one INVITE request further comprises receiving, at the transceiver unit [204] from the destination UE [108], at least one session progress response comprising one or more supported media and codecs parameters of the destination UE [108] in SDP. The method thereafter encompasses transmitting from the transceiver unit [204] to the source user equipment (UE) [102], the received at least one session progress. In an instance, the session progress may be a 183-Session Progress.
Also, the transmitting, from a transceiver unit [204] to a destination user equipment (UE) [108], at least one INVITE request further comprises transmitting, from the transceiver unit [204] to the destination UE [108], at least one provision acknowledgement (PRACK) request, wherein said at least one provision acknowledgement (PRACK) request is received at the transmitter unit [204] from the source UE [102] in response to the at least one session progress. In an instance, if at least one “require: 100rel” header is identified in a received 183 response, the method in such instance encompasses transmitting via the transceiver unit [204], the received at least one PRACK request to the destination UE [108].
Further, the transmitting, from a transceiver unit [204] to a destination user equipment (UE) [108], at least one INVITE request also comprises receiving, at the transceiver unit [204] from the destination UE [108], at least one PRACK response based on the at least one PRACK request. Further, the method also comprises transmitting via the transmitter unit [204] the received at least one

PRACK response to the source UE [102]. Further considering above instance, the at least one PRACK response received at the transmitter unit [204] from the destination UE [108] may comprise at least one 200 OK response/indication. Further, once the at least one provision acknowledge is completed, at least one dedicated bearer (QCI1) for a voice call is established and the source UE [102] starts sending RTP packets towards the destination UE [108].
Thereafter, at step [406], the method comprises receiving, at the transceiver unit [204] from the destination UE [108], at least one ringing response based on the at least one initiated call. Also, receiving, at the transceiver unit [204] from the destination UE [108], at least one ringing response is further based on at least one provision acknowledgement (PRACK). Further, the method encompasses transmitting via the transceiver unit [204], the received at least one ringing response to the source UE [102]. Also, in an instance, the at least one ringing response may comprise at least one 180-Ringing response.
Thereafter, at step [408], the method comprises segregating, via a segregation module [202], the session description protocol (SDP) based on at least one payload type in an event at least one P-Early media parameter is not inactive. Also, the method further comprises transmitting from the transceiver unit [204] to the source UE [102], the at least one ringing response, in an event the at least one P-Early media parameter is inactive, as no media is transmitted during the P-Early media in said event. Therefore, in such events where the at least one P-Early media parameter is inactive no segregation and modification of the session description protocol (SDP) is required.
Further, in the event where the at least one P-Early media parameter is not inactive, in order to segregate, the session description protocol (SDP), the method encompasses receiving at the segregation module [202] from a media server [106], the session description protocol (SDP) comprising an attribute ‘sendrecv’. Also, the receiving at the segregation module [202] from the media server [106], the session description protocol (SDP) is based on an INVITE request

received at the media server [106] from the segregation module [202], wherein the INVITE request comprises an SDP of source UE [102] for CRBT negotiation. Further, in an instance, the method may comprise receiving at the segregation module [202] from a media server [106], a 200 OK (SDP of Media Server; Media attribute set to a=sendrecv). Further, in an event, the method further comprises segregating via the segregation module [202], the session description protocol (SDP) into at least one of a DTMF payload type and a non-DTMF payload type, wherein said segregation is based on the at least one payload type.
Thereafter, at step [410], the method comprises modifying, via the segregation module [202], at least one payload attribute based on the segregation of the session description protocol (SDP) and the at least one payload type. Also, the method further comprises modifying, via the segregation module [202], at least one payload attribute based on identifying via the segregation module [202] the at least one payload type.
Next, the method further comprises modifying via the segregation module [202] the at least one payload attribute to ‘sendrecv’ in an event the identified at least one payload type is DTMF payload. Also, the method further comprises modifying via the segregation module [202] the at least one payload attribute to ‘sendonly’ in an event the identified at least one payload is non-DTMF payload. Further, the non-DTMF payload is a voice payload.
Thereafter, at step [412], the method comprises transmitting, from the transceiver unit [204] to the source UE [102], at least one UPDATE request comprising the modified at least one payload attribute and at least one payload. Also, the transmitting from the transceiver unit [204] to the source UE [102], at least one UPDATE request further comprises terminating segregation of the session description protocol (SDP) via the segregation module [202].
Thereafter, at step [414], the method comprises receiving, at the transceiver unit [204] from the source UE [102], at least one UPDATE acknowledgement based on the at least one UPDATE request. For instance the UPDATE acknowledgment may

comprise 200 OK (SDP – source UE) (a= recvonly for Voice Payload) a= sendrecv for DTMF Payload).
Also, the method further comprises receiving at the transceiver unit [204] from the media server [106], the session description protocol (SDP) based on an INVITE request received at the media server [106] from the transceiver unit [204], wherein the INVITE request comprises modified SDP of source UE [102] after CRBT negotiation. Further considering an instance, INVITE (a= recvonly for Voice Payload, a= sendrecv for DTMF Payload) may be transmitted from the transceiver unit [204] to the media server [106], based on the reception of at least one UPDATE acknowledgment/response from the source UE [102] to transceiver unit [204].
Next, the method encompasses receiving at the transceiver unit [204] at TAS
[104] from the media server [106], at least one INVITE
acknowledgment/response based on the at least one INVITE request. Further considering an instance the INVITE acknowledgment/response may comprise 200 OK (SDP of source UE) (a= recvonly for Voice Payload, a= sendrecv for DTMF Payload).
Also, the method thereafter comprises transmitting from the transceiver unit [204] to the media server [106], at least one Acknowledgment based on the at least one INVITE acknowledgment/response received at the transceiver unit [204]. Further considering an instance, the Acknowledgement may comprise ACK.
Therefore, segregation and modification of the SDP via implementing the features of the method [400], allows the source UE [102] to only receive RTP packets for CRBT from Media Server, with media session for DTMF still in trans-receive mode, thereby saving the uplink network resources during call initiating. After, saving uplink network resources, the method further terminates at step [416]. Referring to Fig. 5, an exemplary flow diagram, depicting an instance

implementation of the process of saving uplink network resources, in accordance with exemplary embodiments of the present invention is shown. As shown in Fig. 5, the method begins at step [502].
At step [504], the method of the exemplary process encompasses initiating a MO call from a MO UE [102], by sending an INVITE request with its supported media and codecs parameters in SDP towards the other end MT UE [108].
After sending INVITE request, at step [506], MO UE [102] receives a response 183-Session Progress with its supported media and codecs parameters in SDP from MT UE [108].
Next, at step [508], a PRACK (Provision Acknowledgement) is completed between the MO UE [102] and the MT UE [108], based on the 183-Session Progress. Now, at step [510], the method encompasses receiving at a TAS [104] a 180-Ringing response from the MT UE [108].
Next, at step [512], the method encompasses initiating at the TAS [104], the segregation module [202] of the system [200], in an event the 180-Ringing response received at the TAS [104].
Next at step [514], the method encompasses, identifying if the ‘P-Early media’ parameter is ‘inactive’ or not. Further, if the ‘P-Early media’ parameter is ‘inactive’ the method leads to step [516] otherwise the method leads to step [520].
Next, at step [516], the method comprises transmitting from the TAS [104] to the MO UE [102], the 180 ringing response.
Also, the method thereafter at step [518] encompasses stopping/terminating the segregation module [202]. Further, the method leads to step [538] from the step [518].
Next, at step [520], the method encompasses transmitting the 180 ringing response to the MO UE [102] along with performing via the TAS [104] a media negotiation with a media server [106]. Next, at step [522] the method encompasses, receiving at the TAS [104],

negotiated media payloads from the media server [106].
Next, at step [524] the method encompasses, modifying via the segregation
module, payload attributes based payload types. Also, the method further
encompasses identifying via the segregation module [202] the payload types.
Next at step [526], the method determines whether the identified payload type
is ‘DTMF’ or not. Further, if the payload type is ‘DTMF’ the method leads to step
[528] otherwise the method leads to step [530].
Next, at step [528], the method comprises adding attributes as ‘Sendrecv’ for the
DTMF payloads.
Also, at step [530], the method comprises adding attributes as ‘Sendonly’ for the
non-DTMF/voice payloads.
Next, at step [532] the method encompasses, modifying payload and updating
attributes based on the step [528] and step [530].
Next, at step [534], the method encompasses, sending the modified payload and
attributes via an UPDATE request from the transceiver unit [204] to MO UE [102].
Also at step [534] the method further encompasses stopping the segregation
module, based on the transmission of the UPDATE response.
Thereafter, at step [536], the method encompasses receiving at the TAS [104], an
UPDATE-200 OK response from the MO UE [102].
Therefore, the implementation of above-described steps of the present
invention, allows the source UE [102] to only receive RTP packets for CRBT from
Media Server [106], with media session for DTMF still in trans-receive mode,
thereby saving the uplink network resources during call initiating.
Further, after saving uplink network resources, the process terminates at step
[538].
Referring to Fig. 6, an exemplary sequence diagram, depicting an instance
implementation of the process of saving uplink network resources, in accordance
with exemplary embodiments of the present invention is shown.
As provided above in the description, when a call is initiated via the source UE

i.e. MO UE [102] to the destination UE i.e. MT UE [108], a ringing response from
the destination UE [108] to the source UE [102] is received via TAS [104]. Also,
the steps relating to the ringing response are already described in the above
description and therefore the same is not repeated for figure 6.
Therefore, as per the Figure 6, when a 180-Ringing response transmitted from
the MT UE [108] to the MO UE [102], the steps of suggested scenario [602] are
implemented for saving uplink network resources.
At step [1], the exemplary process as disclosed in the Figure 6 encompasses
transmitting an INVITE request (SDP of UE (MO)) from the TAS [104] to Media
Server [106], for CRBT negotiation, in an instance the 180-Ringing response
received at the TAS [104].
Next at step [2], the method encompasses, transmitting from the media server
[106], a 200 OK (SDP of Media Server) response with attribute a = sendrecv to
the TAS [104].
Next, at step [3], the TAS [104] sends an acknowledgement (ACK) to the Media
Server [106].
Next at step [4], the method encompasses, sending from the TAS [104] to UE
(MO) [102], an UPDATE request (SDP of Media Server) along with modified
Media attribute a=’sendonly’ for voice payload and a=’sendrecv‘, for DTMF
payload.
Next at step [5], the method encompasses, sending from the MO UE [102], a 200
OK (SDP of UE-MO) response to the TAS [104], along with media attribute
a=’recvonly’ for voice payload and a=’sendrecv’ for DTMF payload.
Next at step [6], the method encompasses sending INVITE request (SDP of UE
(MO)), from the TAS [104] to Media Server [106] along with media attribute
a=’recvonly’ for voice payload and a=’sendrecv’ for DTMF payload.
Next at step [7], the method encompasses sending a 200 OK (SDP of UE-MO)
response from the media server [106] to the TAS [104], along with media
attribute a=’recvonly’ for voice payload and a=’sendrecv’ for DTMF payload.

Next, at step [8], the TAS [104] sends an acknowledgement (ACK) to the Media Server [106].
Further, at step [9], the method encompasses playing CRBT at MO UE [102] based on a tone set by the MT UE [108]. At this step, the MO UE [102] receives RTP Packets for CRBT and the MO UE [102] does not send unnecessary RTP packets to the media server [106], due to changes made in media attributes from both ends.
Therefore, the implementation of the features of the present invention, allows the MO UE [102] to only receive RTP packets for CRBT from Media Server and hence saving uplink network resources.
Thereafter, once the uplink network resources are saved, the call establishing process will follow the standard procedures/steps till receiving or terminating of the call.
Referring to Fig 7, an exemplary block diagram of a user equipment comprising a SIM (subscriber identity module) card, in accordance with exemplary embodiments of the present invention is shown.
The user equipment [710] as indicated in the Figure 7 comprises the subscriber identity module (SIM) [720]. The SIM [720] is configured inside the user equipment [710] for providing various functionalities in accordance with the present disclosure. The user equipment [710] further may comprise a plurality of subsystems [702, 702A, 702B, 702C, 703, 704, 705 and 706], wherein said subsystems [702, 702A, 702B, 702C, 703, 704, 705 and 706] may include, but not limiting to, a modem subsystem [702] with a Baseband DSP processor [702C] and a plurality of radio interfaces [702A]. The user equipment [710] may further include a cellular radio [702B], a transmission/reception radio frequency (RF) connected to the antenna [707] for receiving and transmitting wireless services such as VoIP and Internet/Intranet services. Also, the user equipment [710] may comprise an application processor [704], a memory subsystem [705], a power

subsystem [706] and an external I/O interfaces subsystem [703]. The present disclosure further encompasses that the subscriber identity module [720] may comprise a processor [720B], an I/O interface [720A], a RAM temporary storage [720C], an EEPROM / Non- volatile Memory (NVM) [720D] and a SIM file system [720E]. Further, the EEPROM / Non- Volatile Memory (NVM) [720D] may consist of an operating system code, a code of other SIM applications and the Auto IMSI Switch SIM application. The SIM file system [720E] and USIM application may contain elementary files and location parameters such as EFLOCI (Location Information), EFPSLOCI (PS Location Information), EFEPSLOCI (PS Location Information) and various other application-specific files used by various SIM applications running on the subscriber identity module [720] along with a plurality of context and configuration files of the Auto IMSI Switch SIM application.
As is evident from the above disclosure, the present disclosure saves uplink network resources in an event at least one call is initiated from a source user equipment (UE) to a destination UE. Furthermore, the present disclosure also provides preventing the unwanted flow of RTP packets from the UE call initiating device leading to consumption of resources, based on the modification of payload attributes of media payloads. The present disclosure thereby overcomes the limitations of the existing solutions.
While considerable emphasis has been placed herein on the disclosed embodiments, it will be appreciated that many embodiments can be made and that many changes can be made to the embodiments without departing from the principles of the present invention. These and other changes in the embodiments of the present invention will be apparent to those skilled in the art, whereby it is to be understood that the foregoing descriptive matter to be implemented is illustrative and non-limiting.

We claim:
1. A method for saving uplink network resources, the method comprising:
- transmitting, from a transceiver unit [204] to a destination user equipment (UE) [108], at least one INVITE request comprising one or more supported media and codecs parameters of a source user equipment (UE) [102] in session description protocol (SDP), in an event at least one call is initiated from the source user equipment (UE) [102] to the destination UE [108];
- receiving, at the transceiver unit [204] from the destination UE [108], at least one ringing response based on the at least one initiated call;
- segregating, via a segregation module [202], the session description protocol (SDP) based on at least one payload type, in an event at least one P-Early media parameter is not inactive;
- modifying, via the segregation module [202], at least one payload attribute based on the segregation of the session description protocol (SDP) and the at least one payload type;
- transmitting, from the transceiver unit [204] to the source UE [102], at least one UPDATE request comprising the modified at least one payload attribute and at least one payload; and
- receiving, at the transceiver unit [204] from the source UE [102], at least one UPDATE acknowledgment based on the at least one UPDATE request.
2. The method as claimed in claim 1, wherein the transmitting, from a
transceiver unit [204] to a destination user equipment (UE) [108], at least
one INVITE request further comprises:
- receiving, at the transceiver unit [204] from the destination UE [108],
at least one session progress response comprising one or more
supported media and codecs parameters of the destination UE [108]

in SDP;
- transmitting, from the transceiver unit [204] to the destination UE[108], at least one provision acknowledgement (PRACK) request; and
- receiving, at the transceiver unit [204] from the destination UE [108], at least one PRACK response based on the at least one PRACK request.
3. The method as claimed in claim 1, the method further comprises:
- receiving, at the transceiver unit [204] from the destination UE [108], at least one ringing response based on at least one provision acknowledgement (PRACK), and
- transmitting from the transceiver unit [204] to the source UE [102], the at least one ringing response, in an event the at least one P-Early media parameter is inactive.

4. The method as claimed in claim 1, wherein the segregating, via a segregation module [202], the session description protocol (SDP) is further based on receiving at the segregation module [202], the session description protocol (SDP) comprising an attribute ‘sendrecv’ from a media server.
5. The method as claimed in claim 1, the method further comprises:

- modifying, via the segregation module [202], at least one payload attribute based on identifying via the segregation module [202] the at least one payload type; and
- modifying via the segregation module [202], the at least one payload attribute to:
‘sendrecv’ in an event the identified at least one payload type is DTMF payload, and
‘sendonly’ in an event the identified at least one payload is non-
DTMF payload.

6. A system [200] for saving uplink network resources, the system
comprising:
- a transceiver unit [204], configured to:
transmit to a destination user equipment (UE) [108], at least one INVITE request comprising one or more supported media and codecs parameters of a source user equipment (UE) [102] in session description protocol (SDP), in an event at least one call is initiated from the source user equipment (UE) [102] to the destination UE [108], and
receive from the destination UE [108], at least one ringing response based on the at least one initiated call;
- a segregation module [202], configured to:
segregate, the session description protocol (SDP) based on at least
one payload type, in an event at least one P-Early media
parameter is not inactive, and
modify, at least one payload attribute based on the segregation of
the session description protocol (SDP) and the at least one
payload type; wherein:
the transceiver unit [204] is further configured to:
transmit, to the source UE [102], at least one UPDATE request comprising the modified at least one payload attribute and at least one payload, and
receive, from the source UE [102], at least one UPDATE acknowledgment based on the at least one UPDATE request.
7. The system as claimed in claim 6, wherein the transceiver unit [204] is
further configured to:
- receive, from the destination UE [108], at least one session progress
response comprising one or more supported media and codecs

parameters of the destination UE [108] in SDP;
- transmit, to the destination UE [108], at least one provision acknowledgement (PRACK) request; and
- receive, from the destination UE [108], at least one PRACK response based on the at least one PRACK request.
8. The system as claimed in claim 6, wherein the transceiver unit [204] is
further configured to:
- receive from the destination UE [108], at least one ringing response based on at least one provision acknowledgement (PRACK), and
- transmit to the source UE [102], the at least one ringing response, in an event the at least one P-Early media parameter is inactive.

9. The system as claimed in claim 6, wherein the segregation module [202] is further configured to receive from a media server [106], the session description protocol (SDP) comprising an attribute ‘sendrecv’.
10. The system as claimed in claim 6, wherein the segregation module [202] is further configured to:

- identify the at least one payload type to modify the at least one payload attribute; and
- modify the at least one payload attribute to:
‘sendrecv’ in an event the identified at least one payload type is DTMF payload, and ‘sendonly’ in an event the identified at least one payload is non-DTMF payload.