Patent Application
20110213873
The present invention relates to session management in communication systems in general, and specifically to policing of session setup signaling in such systems.
In relation to exchange of streaming multimedia content in a session between two or more parties in a communication system, the so called Session Description Protocol (SDP) [4] is a protocol that describes the media (for instance audio, video) in such a session. It is intended for describing multimedia communication sessions for the purpose of session announcement, session invitation and other forms of multimedia session initiation. SDP does not provide the content of the media form itself but simply provides a negotiation between two end points to allow them to agree on a media type and format. Examples of what is described are the codecs that are to be used and the bitrates and possibly also if the media is going in both directions (bidirectional) or just in one direction (unidirectional). The SDP is commonly included in the body of a SIP INVITE. SIP (Session Initiation Protocol) [5] is the stack protocols that makes sure that for instance ring back and busy tones in a telecommunication system are generated and that it is possible to e.g. redirect a call.
The SDP was initially intended to describe only unidirectional flows; however, it has been extended to handle bidirectional flows as well. Offer/answer is a typical mechanism used within SDP, the main idea is that a user agent (UA) that initiates a call offers an SDP (carried in a SIP-INVITE message) with a set of different media options and recommended codecs for each media. The UA that receives the SDP offer returns the preferred codec configuration in another SIP message in the reverse direction. Once this offer/answer exchange is done, the session starts and media will flow between the two participants (agents) in the session.
An SDP or SDP message typically consists of two parts.
The use of SDP is not without problems. Typical problems with conventional SDP's as they will be referred to in this text is that it is not possible to describe a session that offers different transport formats or codecs with different bitrates without the need of repeating almost similar media descriptions. The result being a bulky session description that easily becomes ambiguous.
The so-called and recently developed SDP Capability Negotiation framework (SDPCapNeg [1]) is a framework for SDP offer/answer in the IETF MMUSIC WG. The role of SDPCapNeg is to solve most of the issues with SDP and still be able to be backwards compatible with conventional SDP.
The core SDPCapNeg framework makes it possible to propose e.g. different transport formats for a given media without the need to specify several media descriptions with almost the same contents (a described before a severe limitation with conventional SDP).
The SDPCapNeg framework supports addition of extensions; these extensions are identified by so-called option tags in the SDP. One extension is media capabilities (SDPMedCapNeg) [2] identified by the option tag “med-v0” that makes it possible to propose e.g. different codec options with different bitrate requirements, something that is not possible with conventional SDP.
The SDPCapNeg framework introduces a number of capability attributes (attribute names tcap and acap) and the possibility to specify a number of potential configurations (attribute name pcfg) that references the capability attributes. The SDPMedCapNeg adds more capability attributes and also the concept of latent configurations that makes it possible to do capabilities exchange for media and do the actual session setup at a later stage.
The potential with SDPCapNeg may introduce a few problems in an IMS environment. One serious issue is that, as the framework supports extensions, there is a risk that extensions that are unsupported in the network gets introduced in the session setup negotiation by user agents. The problem is elevated by the fact that the SDPCapNeg framework can hide these extensions from an intermediary node that does not understand the extensions.
There is therefore a need for means by which to ensure that the use of unsupported extensions does not result in ambiguous or incomprehensible SDP messages.
An aspect of the present invention is to provide methods and arrangements to provide improved management of extensions in SDP or similar messages in telecommunication systems.
A basic aspect of the present invention discloses an improved method in a control node managing media sessions between nodes in a telecommunication network. Initially, exchanging S10 a media session description message between two nodes and determining S20 if the message comprises at least one option tag. The option tag indicates potential configurations for the media session. Subsequently, comparing S30 the option tag to a set of network supported option tags indicating supported configurations for the network. Finally, modifying S40 the media session initiation message based on the comparison.
Advantages of the present invention include
The invention, together with further objects and advantages thereof, may best be understood by making reference to the following description taken together with the accompanying drawings, in which:
To further improve the understanding of the framework in which the present invention has evolved, some of the specific problems with prior art will be discussed below. In addition, a few key concepts and parts of a system in which the present invention can be beneficial will be described.
The previously mentioned SDP is a format for describing streaming media initialization parameters in an ASCII string (or similar). It can be used with a number of transport protocols, such as SIP, HTTP and others. However, for the present invention it will be described in the context of SIP. It is intended for describing multimedia communication sessions for the purpose of session announcement, session invitation and other forms of multimedia session initiation. SDP does not provide the content of the media form itself but simply provides a negotiation between two end points to allow them to agree on a media type and format. This allows SDP to support upcoming media type and formats, enabling systems based on this technology to be forward compatible. There are in essence five terms closely related to and viewed as key aspects of the SDP stack, namely:
A session is described by a series of attributes/value pairs, one per line. The attribute names are single characters, followed by = and a value. Optional values are specified with =*. Values are either an ASCII string or a sequence of specific types separated by spaces. Note that attribute names are only unique within the associated syntactic construct, i.e. within the Session, Time, or Media only.
A session border controller (SBC) is a session aware device used in some VoIP networks to exert control over the signaling and usually also the media streams involved in setting up, conducting and tearing down calls. SBCs are inserted into the signaling and/or media paths between calling and called parties or agents in a VoIP call, predominantly those using SIP, H.323, and MGCP call signaling protocols. Typically, the SBC modifies the stream of call control data involved in each call, perhaps limiting the kind of calls that can be conducted, changing the codec choices, and so on.
A few of the problem cases with the previously described SDPCapNeg protocols are
A known solution to this problem is that an IP Mobility Subsystem Call Session Control Function (IMS CSCF) or Session Border Gateway (SBG) can inspect and rewrite SDP's in the sense that unknown attributes or extensions are removed from the SDP. This may cause a number of problems however.
If one for instance consider the offer SDP below using the Media Capabilities [2] and the SDP for CS [3] extensions.
A CSCF supports the media capabilities (indicated by the option tag “med-v0”) but it does not support the SDP for CS extension (indicated by the option tag “ccap-v0”) and the associated ccap attributes. The lines with the “a=ccap” attributes are therefore erased from the SDP.
Problem is however that on the “a=pcfg” line several capability attributes are referenced to form a potential configuration and as the referenced ccap attributes are removed the potential configuration becomes ambiguous.
This behavior can lead to severe problems, as several of the referenced attributes may be interconnected. For instance, a bandwidth attribute may only be relevant for a specific transport format and removal of one or many referenced attributes may cause potential configurations that are difficult or impossible to interpret by the recipient of the SDP.
Another example is the use of the “+” option on the “a=pcfg” line
As with the previous example the “ccap-v0” option is not supported and the corresponding “a=ccap” attributes are removed as they are unknown. In this case the line “a=pcfg:1 +med-v0 +ccap-v0 m=1 c=2” becomes ambiguous.
The ambiguous potential configurations may, if not taken care of, cause unknown interoperability issues that may be problematic to resolve.
The basic concept of embodiment of the present invention is to implement an SDPCapNeg policy function in the CSCF's or SBG's (or similar intermediary device) that inspects the SDP and either rejects or modifies the SDP based on a list of supported extensions to the SDPCapNeg framework. The invention is not limited to IMS entities such as SBG or CSCF as it can be utilized e.g. by SBC's outside the IMS framework.
In
With reference to
Consider the situation depicted in
The step of modifying the media session description message is typically performed both for the session description part of the message and the media description part of the message.
According to a further embodiment of the invention the inspection and policing is performed in three steps:
With reference to
In particular, extensions to the SDPCapNeg framework are required to specify the use of the extensions indicated by option tags using either the “a=creq” attribute or the “+” parameter on the “a=pcfg” line in the SDP. Moreover, support for SDPCapNeg extensions can be indicated by means of the “a=csup” option.
A policy function according to the embodiments of the present invention in e.g. the IMS SBG and/or CSCF should then inspect the SDP for such extensions and do the necessary policing on these.
SDPCapNeg [1] specifies how recipients of SDP should handle extensions that it does not understand.
The role of the policy function in a node (e.g. an SBG or a CSCF) in this invention is to remove parts of the SDP corresponding to extensions to SDPCapNeg that are not supported by the network.
The method can be best described in relation to the following exemplary embodiments:
Extensions Indicated by the a=creq Attribute
If the a=creq attribute is given on media level and this extensions is not supported by the network, the policy function will remove SDPCapNeg framework completely for the given media. In other words, all potential configurations are removed.
The “med-v0” extension (media capabilities) is not supported; the consequence of this is that the entire SDPCapNeg framework is removed for the media. The SDP is then modified to become
In other words the potential configurations are removed. Optionally the “a=creq” line can be removed as well.
If the unsupported option tag is specified on the “a=creq” line on session level then the potential and/or latent configurations would be removed from the entire SDP.
Extensions Indicated by the “+” Parameter on the “a=pcfg/” Lines
If the required extensions are indicated as option tags on the “a=pcfg” line(s), the role of the policy function is to remove the “a=pcfg” lines corresponding to SDPCapNeg extensions that are not supported.
As with the previous example “med-v0” is not supported by the network, this means that the line “a=pcfg:1 +med-v0 . . . ” is removed from the SDP. The resulting SDP will then look like
In order to exploit the embodiments of the present invention to its fullest degree and at the same time be backwards compatible against older IMS releases it is beneficial to create SDP's in a layered fashion in the sense that a few basic potential configurations, which do not require extensions to SDPCapNeg, are given.
According to a further embodiment, a SIP INVITE from UA A to UA B contains the SDP below
A policy function in the home CSCF does not support the extension ccap-v0, therefore the corresponding “a=pcfg” line will be erased from the SDP with the resulting SDP below.
It is fully possible that the network where UA B is located does not support med-v0. Thus the corresponding “a=pcfg” line will be erased as well with the resulting SDP.
In other words, only the basic SDPCapNeg framework is supported in this case.
Later on as hardware and software in the IMS networks are updated, fewer potential configurations will potentially be removed from the SDP's. This will give the end user a more rich experience when allowed by the network and at the same time guarantee a predictable experience when one or many extensions are not allowed by the networks and therefore removed by the policing function described in this invention.
To illustrate the embodiments of the present invention, the interested reader is advised to look at an algorithm pseudo code in Appendix. The code gives a brief overview how the policy function might be implemented. It is syntactically similar to the flowchart of
A list of supported extensions to SDPCapNeg (a white list) needs to be maintained by the policy function in order to enable the comparison of the determined option tags and the supported option tags, the role of the policy function is then to see if the option tags determine in the SDP's are supported. As an example, this white list could look like Table 1 below.
Variants to the list may exist for instance due to local policy rules. For example, an operator may not wish the “foo-bar” extension to be used in his/her IMS network even though the equipment may support it, the removal policy may also be subject to billing issues.
Besides the above described modifying option there is a possibility to completely reject SDP's. In the reason string it is then beneficial to include which extensions that are not supported, and to reject any SDP that contains option tags indicative of unsupported extensions. This is implemented on session level, media level or both.
With reference to
Specifically, the comparing unit 30 is further adapted to maintain and update a list of supported option tags in the system.
Some of the advantages of the invention include:
The proposed invention is recommended to be included in applicable parts in IMS networks to ensure secure use of SDPCapNeg and its extensions.
It needs to be stressed that the previously described SDP Capabilities Negotiation Framework and its extensions are currently a work in progress that means that names of attributes and option tags may change. The major design principle is however very unlikely to change.
It will be understood by those skilled in the art that various modifications and changes may be made to the present invention without departure from the scope thereof, which is defined by the appended claims.
The pseudo code below gives a brief overview how the policy function might work in a real implementation. This pseudo code is syntactically similar to the flowchart in
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/SE2009/050009 | 1/9/2009 | WO | 00 | 4/21/2011 |
| Number | Date | Country | |
|---|---|---|---|
| 61108383 | Oct 2008 | US |
