Towards an Innovation Oriented IP Multimedia Subsystem

IEEE Communications Magazine • March 2007130 0163-6804/07/$20.00 © 2007 IEEE

INTRODUCTION

The Session Initiation Protocol (SIP) [1] is atext-based rendezvous protocol that providesuser mobility and session establishment. SIP usermobility is based on registrations. Users registertheir current locations with the network, whichuses this registration information to route incom-ing session requests to those users.

SIP session establishment is based on theoffer/answer model [2], which is a two-way ses-sion description exchange between two SIP useragents. User agents involved in an offer/answerexchange obtain all the information required toestablish a session between them.

The IP multimedia subsystem (IMS) is systemarchitecture whose main signaling protocol isSIP. The goal of IMS is to provide service pro-viders with a platform that facilitates the provi-sion and management of a wide range ofservices. The success of service providers usingIMS and consequently, the success of IMS as awhole, depends on how appealing those IMSservices are to users.

To make IMS services more appealing thanservices developed for other platforms, IMSenables service developers to integrate their ser-vices horizontally. Horizontal service integration

is believed to produce faster service develop-ment times than the traditional vertical serviceintegration, where a stand-alone module pro-vides all of the functionality required by a partic-ular service. A horizontally integrated serviceconsists of a set of functions that work togetherto provide the functionality expected from thatparticular service. Given that many of thesefunctions (e.g., user authentication) are commonacross different services, the same function canbe reused by several services.

IMS provides these common functions andmakes them available to any service built on topof it. This way, service developers are notrequired to re-implement these functions foreach new service. Instead, they can simply focuson implementing the service logic specific toeach particular service and rely on the commonfunctionality provided by IMS. Common func-tions provided by IMS that are available to ser-vices built on top of it include capabilitynegotiation, authentication, service invocation,addressing, routing, group management, pres-ence, provisioning, session establishment, andcharging.

However, to be successful, IMS must gobeyond simply providing a fast service develop-ment environment. IMS also must foster the cre-ation of innovative services. This article describesan alternative approach to IMS policy controlthat aims to foster innovation. Innovation is,arguably, the key to creating successful servicesthat appeal to users. The approach removes therequirement to inspect the SDP (SessionDescription Protocol [3]) in the network nodes,which can be costly. In this way, new SDP exten-sions can be used to provide extended function-ality and innovative services without incurringhigh network upgrade costs and delays.

The remainder of this article is organized asfollows. We describe IMS session establishment,policy control implementation in IMS, and issuesrelated to the IMS approach to policy control.We propose an alternative approach to policycontrol, referred to as session policies, whichresolves those issues. We describe our experi-ences implementing session policies in an IMSenvironment. We outline our future work in thisarea.

ABSTRACT

This article proposes an approach to IMSpolicy control based on session policies thatachieve transparent end-to-end session establish-ments between IMS terminals. The article iden-tifies drawbacks in the current IMS policycontrol methodology, discusses how these draw-backs may negatively influence the potential ofIMS to provide innovative services, and describeshow the new approach overcomes these draw-backs. Our proposal offers modularity and scala-bility properties that enable operators toestablish policies and modify existing ones with-out major changes in the IMS core. Thus, poli-cies can be applied transparently to SIP dialogsbetween terminals and modified on the fly with-out tearing down ongoing dialogs. The articlealso discusses a test bed implementation thatworked as a proof-of-concept.

IP MULTIMEDIA SYSTEMS (IMS) INFRASTRUCTUREAND SERVICES

Gonzalo Camarillo, Tero Kauppinen, Martti Kuparinen, and Ignacio Más Ivars, Ericsson Research.

Towards an Innovation Oriented IP Multimedia Subsystem

IVARS LAYOUT 2/20/07 3:29 PM Page 130

IEEE Communications Magazine • March 2007 131

IMS SESSION ESTABLISHMENT

As stated previously, IMS session establishmentis based on SIP. SIP provides session establish-ment through a two-way session descriptionexchange called the offer/answer model [2]. Auser agent generates a session description (theoffer) that contains the information required toestablish the session (e.g., IP addresses to trans-fer the media) and sends it to the remote useragent.

On receiving the offer, the remote user agentgenerates its own session description, which isreferred to as the answer. Both the offer and theanswer are written in a session description for-mat that must be understood by both useragents. The default session description format isSDP. After the offer/answer exchange com-pletes, the user agents can start exchangingmedia between them. At that point, the sessionis considered to be established.

Offer/answer exchanges can be mapped to aSIP three-way handshake (INVITE — 200 OK— ACK) in two ways. The INVITE carries theoffer, and the 200 (OK) carries the answer, orthe 200 (OK) carries the offer, and the ACKcarries the answer. IMS supports both mappingsto establish sessions.

Figure 1 shows a basic session establishmentin IMS. Note that this session establishmentdoes not use the optional preconditions exten-sion [4] that is typically applied to basic sessionestablishments. Its use is not relevant for thisdiscussion and would add extra complexity to themessage flow.

The flow in Fig. 1 shows two roaming ter-minals establishing a session between them.Both P-CSCFs (proxy-call/state control func-tions) are located in the visited domains. S-CSCFs are always located in the home domainof the users they serve. The network elementsin Fig. 1 that relate to the offer/answer modelare the P-CSCF (proxy-CSCF) and the S-CSCF (serving-CSCF). Both have access to allthe offers and answers exchanged by the ter-minals.

POLICY CONTROL IN IMS

IMS provides policy control. IMS domains canspecify the types of media streams that areaccepted (e.g., voice streams) and the types thatare not (e.g., video streams). It also is possible tospecify the sessions that are accepted based oncharacteristics of their media streams, such asthe codecs used or the bandwidth requested forthem.

IMS policy control and IMS charging controlwere implemented using separate architecturesin 3GPP R5 (Release 5) and 3GPP R6. Howev-er, 3GPP R7 merged those architectures togeth-er. The policy and charging control (PCC)architecture defined in 3GGP R7 is the result ofmerging SBLP (service based local policy) andFBC (flow-based charging).

Figure 2 shows the 3GPP R7 policy and

n Figure 1. IMS session establishment.

IMSterminal P-CSCF

Originatingvisited

network

(1) INVITE

(15) ACK

(14) 200OK

S-CSCF

(2) INVITE

(16) ACK

(13) 200OK

I-CSCF

(3) INVITE

(12) 200OK

HSS

(4)Diameter

(5)Diameter

S-CSCF P-CSCF

(7) INVITE

(18) ACK

(10) 200OK

IMSterminal

(8) INVITE

(19) ACK

(9) 200 OK

(17) ACK

Originatinghome

network

Terminatingvisited

networkTerminating home network

(6) INVITE

(11) 200 OK

n Figure 2. IMS policy and charging control architecture.

RxG

x

AF

PCRF Sp

Gy

GzSubscription

profilerepository

Accessgateway

Onlinechargingsystem

Offlinechargingsystem


IEEE Communications Magazine • March 2007132

charging control architecture. Only the AF(application function), the PCRF (policy andcharging rules function), and the access gatewayare relevant to this discussion. The role of theAF can be performed by the P-CSCF or by anapplication server.

The PCRF receives information about theoffer/answer exchanges between the terminalsfrom the AF over the Rx interface. If the char-acteristics of the session being established areacceptable to the PCRF (based on the domainpolicy), the PCRF authorizes the session on theaccess gateway using the Gx interface. If thecharacteristics of the session are not acceptableto the PCRF, it instructs the AF to terminatethe session using the Rx interface. Of course, inthis case the PCRF does not authorize the ses-sion on the access gateway.

SIP AND POLICY CONTROLWhen the PCRF informs the AF that the sessionbeing established is not acceptable, the AF mustinform the terminal trying to establish the ses-sion. The AF uses its SIP interface to do that.The way an AF informs a terminal that its ses-sion request is not acceptable depends on themapping used between the offer/answer modeland the SIP three-way handshake. For example,assume that the originating P-CSCF in Fig. 1must inform the originating IMS terminal thatits session request is not acceptable (the termi-nating P-CSCF would use identical mechanisms).

If the INVITE request (1) carried an offer,the P-CSCF would respond with a 488 (notacceptable here) response. This response wouldcontain a session description of a session thatwould be acceptable. Such a session descriptioncould be used by the terminal to generate a newoffer in a new INVITE request that would beacceptable for the network.

If the offer in the INVITE request (1) wasacceptable, but the answer in the 200 (OK)response (13) was not, the P-CSCF would waitfor the three-way handshake to finish. Immedi-ately after that, it would generate two BYErequests, one to the originating terminal and oneto the terminating terminal. In this case, theBYE request would not carry an indication ofthe type of session that would be acceptable tothe network. Therefore, it would be difficult forthe terminal to generate a new acceptable offer.

Additionally, the user behavior would be farfrom ideal. The session would be established andterminated immediately.

If the INVITE request (1) did not carry anoffer, the 200 (OK) response would. If the offerin the 200 (OK) response or the answer in theACK request (15) were not acceptable, the P-CSCF would behave as in the previous example.It would generate two BYE requests to termi-nate the session, with the same associated issuesas before.

In addition to the behaviors just described,many actual deployments (generally using fixedaccess), have their P-CSCFs perform SDP rewrit-ing. If a session description is not acceptable, theP-CSCF rewrites it before routing the messageforward so that the resulting session descriptionis acceptable. The P-CSCF can remove mediastreams, codecs, and so on.

SDP rewriting is also performed by P-CSCFshandling cellular terminals. The P-CSCF usesthe single reservation flow (SRF) SDP extensionto instruct the terminal about the PDP (packetdata protocol) context to use for the mediastream.

The characteristics of a session also can beunacceptable to one or both (originating andterminating) home domains. In this case, the S-CSCF performs the same actions as the P-CSCFsin the previous examples. The S-CSCF woulduse 488 (not acceptable here) responses or BYErequests to enforce its policy.

ISSUES WITH THE CURRENT APPROACH TOPOLICY CONTROL

There are issues with informing terminals aboutpolicy decisions in the ways described previously.As stated earlier, a terminal is not alwaysinformed why its session was rejected. The userof the terminal may not understand what to doto establish a new session that will be accepted.A user may also receive a successful-session-establishment indication and a session-terminat-ed indication, one immediately after the other.

A user cannot protect the integrity of orencrypt the session descriptions because the net-work may be required to modify them. Encrypt-ed sessions are rejected by the network andintegrity protection is broken by network nodesthat are not actual attackers. Additionally, a net-work cannot change the policies that apply to anongoing session. For example, if a networkdecides that using video is no longer acceptable,it cannot inform the terminals about this fact. Itsonly option is to terminate a whole session bysending BYE requests to both terminals, andusers will not know why the session terminated.

Although the previous issues that relate touser experience are important, this article focus-es on issues affecting application and servicedevelopers. These issues affect whether IMS ser-vices can be innovative. Service developers cur-rently are forced to use SDP as the only sessiondescription format. This is because network ele-ments such as P-CSCFs and S-CSCFs requireaccess to offers and answers.

New services cannot use SDP extensions thatare not understood by the network because ses-sions using unknown extensions most likely willbe rejected. Even if a user’s home domainaccepts sessions with unknown SDP extensions,other domains may not. This limits the users auser can communicate with to those in his or herdomain.

Additionally, SDP rewriting can have unex-pected interactions with extensions that areunknown to the entity performing the rewriting.SDP rewriting also makes it difficult for develop-ers to debug their implementations because thenetwork may modify their protocol messageswithout their knowledge.

This implies that service developers are limit-ed to establishing sessions that can be describedwith SDP and the SDP extensions that are sup-ported by the network. If the implementation ofan innovative service requires the use of a newSDP extension or the use of a different sessiondescription format, the whole network would

A user cannot

protect the integrity

of or encrypt the

session descriptions

because the network

may be required to

modify them.

Encrypted sessions

are rejected by the

network and

integrity protection is

broken by network

nodes that are not

actual attackers.



require upgrading before this service could beprovided. This would dramatically slow the intro-duction of such service and increase considerablythe price to introduce it.

SESSION POLICIESOne of the design principles of SIP was to enablethe creation of end-to-end services withoutrequiring the upgrading of the network elementsbetween endpoints. As discussed earlier, the cur-rent approach to IMS policy control breaks thisprinciple.

Session policies provide a means for domainsto communicate their policy to terminals and forterminals to provide domains with informationabout the sessions that they establish. There aretwo types of session policies: session-indepen-dent policies and session-specific policies. Ses-sion-independent policies are general policiesthat apply to all the sessions a terminal mayattempt to establish. For example, a terminalmay not be allowed to use video streams in itssessions. Session-specific policies only apply to aparticular session. For example, a terminal maybe required to group two of the session mediastreams (e.g., audio and video) into a single PDPcontext and transfer a third media stream over adifferent PDP context (e.g., instant messaging).

A domain typically requires informationabout the session being established by a terminalto provide it with session-specific policies forthat session. The terminal informs the domainabout the session and obtains the domain poli-cies for that session. For example, a domain canuse the information received from a terminalabout the IP addresses it will use to open thegates of the access gateway or a pinhole in afirewall.

Some policies can be implemented as session-independent or as session-specific policies. Forexample, a domain may choose to provide termi-nals with a list of all the audio codecs the termi-nals are allowed to use as a session-independentpolicy. On the other hand, a domain couldchoose to be informed about the codecs a termi-nal intends to use in a session and inform theterminal which of the codecs are acceptable.

Some domains prefer to implement this typeof policy as session-specific policies to avoid dis-closing the entire domain policy to the terminal.These domains want to prevent competitor oper-ators from copying their policies, which someproviders believe to be a source of competitiveadvantage.

THE POLICY SERVERSession policies define a logical entity referredto as a policy server. Terminals subscribe to thepolicy server using a SUBSCRIBE request andobtain information about the domain session-independent policies in NOTIFY requests.

Session-independent policies are a form ofconfiguration information. Therefore, the eventpackage used to transfer session-independentpolicies is the event package for the user agentprofile delivery specified in [5].

Terminals also use SUBSCRIBE requests toobtain sessions-specific policies. When a termi-nal intends to establish a session, it sends a

SUBSCRIBE request to its policy server. Thisrequest uses the event package for session-spe-cific policies defined in [6]. The terminal includesan XML document describing the session it isabout to establish in the body of its SUBSCRIBErequest.

The policy server receives the SUBSCRIBErequest and based on the XML documentreceived and the user’s profile, returns its poli-cies in a NOTIFY request. If the terminal mustchange the characteristics of the session at somepoint, it sends a new SUBSCRIBE within thesame SUBSCRIBE-initiated dialog to the policyserver. If the policy server must send additionalpolicies to the terminal at some point, it issues anew NOTIFY request.

Figure 3 shows an example of a message flowincluding session-specific policies. The useragent sends the policy server a SUBSCRIBErequest (1). The request contains an XML bodydescribing the session the user agent intends toestablish. The policy server returns a NOTIFYrequest (3) that contains an XML body describ-ing the policies applicable to the session.

The user agent generates an INVITE request(5) with an offer that complies with the policiesreceived from the policy server. After the useragent receives an 200 (OK) response (8) with ananswer, it sends a new SUBSCRIBE request(11) with a new XML body to the policy server.The new XML body informs the policy serverabout the session parameters contained in theanswer (e.g., agreed codecs, IP addresses, mediastreams accepted and rejected, and so on.).

n Figure 3. Session-specific policies message flow.

Useragent

(1) SUBSCRIBE

Policyserver

Proxyserver

(4) 200 OK

(11) SUBSCRIBE

(14) 200 OK

(13) NOTIFY

(12) 200 OK

(3) NOTIFY

(2) 200 OK

(8) 200 OK

(5) INVITE

(9) ACK(10) ACK

(6) INVITE

(7) 200 OK



SESSION ESTABLISHMENT DELAY

As discussed earlier, session-independent poli-cies are a form of configuration data. Therefore,they are obtained at configuration time beforeany session can be established. Consequently,they do not add any session establishment delay.

If session-specific policies are implemented asdescribed in Fig. 3, they increase slightly the ses-sion establishment delay in some cases. As shownin Fig. 3, a round-trip time between the useragent and the policy server is required beforethe initial INVITE request can be sent.

Note that sessions that are not initially accept-able to the network do not suffer any additionaldelay because of session policies. This is because,even when session policies are not implemented,there is an INVITE/488 (not acceptable)exchange prior to the actual session establish-ment. This exchange takes the same time as theinitial SUBSCRIBE/NOTIFY exchange used bysession policies.

Fortunately, it is possible to optimize the flowin Fig. 3 to eliminate the extra delay introducedto sessions that are directly acceptable to thenetwork. Such optimization requires coordina-tion between the policy server and the proxyserver in the figure. The user agent sends theSUBSCRIBE request (1) and the INVITErequest (5) in parallel. If the session is accept-able to the policy server, it informs the proxyserver, which routes the INVITE request for-ward. If, on the other hand, the session is notacceptable, the policy server instructs the proxyserver to return a 488 (not acceptable here)response. The user agent receives session-specif-ic policies in a NOTIFY request from the policyserver as usual.

Things are different on the terminating side.Session-specific policies introduce a round-triptime to the establishment of sessions that aredirectly acceptable to the network. This round-trip time between the user agent and the policyserver is required between the reception of theINVITE request and the generation of the 200(OK) response by the user agent. The user agentsends a SUBSCRIBE request and receives aNOTIFY request with policies during this round-trip time.

The same one round-trip delay is introducedto sessions that are not directly acceptable to thenetwork. However, when session policies are notused, those sessions are terminated by the net-work. Session policies allow those sessions to beestablished.

The delay introduced to some sessions is the

price to pay for having both policy control andend-to-end negotiations. However, when itcomes to the future of IMS as a successful ser-vice enabling platform, it seems much moreimportant to introduce new services quickly andinexpensively than to provide very low establish-ment delays in every situation.

Note that a domain that implemented all itspolicies based on session-independent policiesstill must use session-specific policies to beinformed of the characteristics of a given ses-sion. For example, information such as the IPaddresses used in a session might be required toopen the gates of the access gateway.

SESSION POLICIES IN IMSThe addition of session policies to IMS requiresa logical function in the IMS architecture: thepolicy server. The policy server has a SIP-basedinterface to the terminals and a Diameter-basedinterface to the PCRF.

The functionality of the interface between thepolicy server and the PCRF is similar to the cur-rent Rx interface between an AF and the PCRF(Fig. 2). The PCRF makes policy decisions basedon the information provided by the policy server,and the policy server informs the terminalsabout those decisions.

IMS sessions between roaming users involvefour different domains, as shown in Fig. 1. Theoriginating domains (home and visited) providesession policies to the originating terminal. Theterminating domains provide session policies tothe terminating terminal. Therefore, a terminalmust consult its visited and home policy serversbefore attempting to establish a new session.However, even though the terminal consults twopolicy servers, both consultations can be per-formed in parallel to avoid additional delays.Interestingly, if both the visited network and thehome network find a particular session unac-ceptable, the session-policies-based approachachieves a lower session establishment time thanthe currently specified approach to IMS policycontrol.

When the current approach is used, the P-CSCF rejects the initial INVITE request fromthe terminal. The terminal modifies its sessiondescription according to the 488 (not acceptable)response received, and issues a new INVITErequest. This INVITE request is then rejected bythe S-CSCF with a new 488 (not acceptable)response.

If session policies were used instead, the ter-minal obtains (in parallel) the policies from bothdomains before generating its initial INVITErequest. This way, it saves one round-trip time.

Alternatively, session policies from bothdomains can be consolidated into a single policy.The terminal consults only the visited policyserver, which applies its policies and consults thehome policy server. The home policy serverapplies further policies, if required, and informsthe visited policy server, which sends the termi-nal the consolidated policies for the session.

IMPLEMENTATION EXPERIENCEThis section describes our proof-of-conceptimplementation of session policies in an IMS

n Figure 4. Implementation architecture.

MIP homeagent

ABC profileserver

P-CSCFpolicy server

WLAN

LAN



network. One of the goals of this implementa-tion is to enable the network to modify its poli-cies in the middle of an ongoing session. Whenthe policies change, the network informs the ter-minal, and the terminal adapts to the new poli-cies, typically by sending a re-INVITE request.

Note that, currently, the IMS architecturedoes not provide a means for the network toinform terminals about policy changes that applyto ongoing sessions, as discussed earlier.

A network can change the policies applicableto a given ongoing session based on a set ofevents. We chose to implement a multi-accessenvironment where our terminals could movebetween different accesses. The accesses had dif-ferent characteristics and thus, different policiesassociated to them. For example, video streamswere not allowed on certain accesses. Therefore,when a terminal moved to a new access with dif-ferent policies, it was informed by the networkabout those new policies.

Figure 4 shows the architecture of our imple-mentation. It represents the network of an oper-ator that provides IP connectivity over twodifferent access technologies and IMS connectiv-ity. The two access technologies chosen for ourimplementation were an 802.11-based WLANand an Ethernet-based LAN. The mobilitybetween both accesses was handled using MobileIP (MIP).

We based our implementation on the 3GPPR5 IMS architecture, where the P-CSCF and thePDF (policy decision function) were co-located(the 3GPP R7 PCRF is an evolution of thePDF). Consequently, we co-located the P-CSCFand the policy server in a single node.

Access management was based on the ABC(always best connected) architecture proposed in[7]. Our terminals could detect when one oftheir link layers came up (e.g., the terminalgained WLAN coverage). At that point, theyinformed the ABC profile server about all oftheir available accesses and the accesses used atthat point.

When a terminal chose to use a new access, itinformed the ABC profile server, which in turn,informed the policy server. As a result, the poli-cy server sent new policies to the terminal.

In our test bed, the terminals consisted ofLinux-based laptops with software-based IMSclients on them. We were required to modify thesoftware-based IMS clients to implement sessionpolicies and the ABC framework.

The policies used in our experiments consist-ed of allowing audio and video streams over oneaccess but only audio streams over the other.When a terminal changed access, it received newpolicies. Based on the new policies received, theterminal sent a re-INVITE, adding or removingthe video stream.

As expected (we did not implement the opti-mization described earlier), we observed highersession establishment delays for session requeststhat were acceptable to the network. The extradelay was caused by the initialSUBSCRIBE/NOTIFY exchange between theterminal and the policy server. In this case, theNOTIFY request simply informed the terminalto establish the session because it was accept-able.

Session requests that were not acceptable tothe network did not suffer any additional delaybecause of session policies, as discussed earlier.

Our implementation shows that currentlydefined IMS policy control functions can beimplemented based on session policies. Addi-tionally, functions that are not supported by thecurrent IMS policy control architecture, such aspolicy modifications for ongoing sessions, alsocan be implemented based on session policies.

FUTURE WORKOur future work includes standardizing the ele-ments of session policies in the IETF (InternetEngineering Task Force). A proposal for aframework for session policies can be found at[8]. A proposal for the event package to deliversession-specific policies discussed previously canbe found at [6]. A proposal for an XML formatto carry policy information can be found at [9].A set of policy-related functions that are cur-rently based on SDP rewriting and could benefitfrom session policies can be found at [10]. Ourfuture work also includes proposing the additionof policy control based on session policies intoIMS specifications.

CONCLUSIONSThis article describes how session policies couldbe used to implement policy control in IMS.Using session policies instead of the currentlyspecified techniques for policy control wouldmake IMS a better platform for service innova-tions.

Session policies remove the requirement toinspect and understand session descriptions inthe network. Therefore, the use of session poli-cies would enable service providers to offerinnovative services based on new SDP extensionsor other session description formats withoutrequiring them to upgrade their networks. Thisway, IMS services would reach their users fasterand at a lower price.

The price to pay to implement session poli-cies is a slightly higher session establishmentdelay for sessions that would have been accept-able to the network in the first place. Althoughproviding innovative services is a key to the suc-cess of IMS, optimizing session establishmenttimes to a minimum in every possible scenario isnot seen as essential by many users.

REFERENCES[1] J. Rosenberg et al., “SIP: Session Initiation Protocol,”

IETF RFC 3261, June 2002, at http://www.rfc-editor.org/rfc/rfc3261.txt

[2] J. Rosenberg and H. Schulzrinne, “An Offer/Answer Modelwith Session Description Protocol (SDP),” IETF RFC 3264,June 2002, http://www.rfc-editor.org/rfc/rfc3264.txt

[3] M. Handley, V. Jacobson, and C. Perkins, “SDP: SessionDescription Protocol,” IETF RFC 4566, July 2006,http://www.rfc-editor.org/rfc/rfc4566.txt

[4] G. Camarillo, W. Marshall, and J. Rosenberg, “Integra-tion of Resource Management and Session InitiationProtocol (SIP),” IETF RFC 3312, Oct. 2002, http://www.rfc-editor.org/rfc/rfc3312.txt

[5] D. Petrie, “A Framework for Session Initiation ProtocolUser Agent Profile Delivery,” IETF Internet draft, draft-ietf-sipping-config-framework-08, Mar. 2006, work inprogress, http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-08.txt

The use of session

policies would

enable service

providers to offer

innovative services

based on new SDP

extensions or other

session description

formats without

requiring them to

upgrade their

networks. Thus, IMS

services would reach

their users faster and

at a lower price.



[6] V. Hilt and G. Camarillo, “A Session Initiation Protocol(SIP) Event Package for Session-Specific Session Poli-cies,” IETF Internet draft, draft-ietf-sipping-policy-pack-age-02, Oct. 2006, work in progress, http://www.ietf.org/internet-drafts/draft-ietf-sipping-policy-package-02.txt

[7] E. Gustafsson and A. Jonsson, “Always Best Connect-ed,” IEEE Wireless Commun., vol. 10, no. 1, 2003.

[8] V. Hilt, G. Camarillo, and J. Rosenberg, “A Frameworkfor Session Initiation Protocol (SIP) Session Policies,”IETF Internet draft draft-ietf-sip-session-policy-frame-work-00, Oct. 2006, work in progress, http://www.ietf.org/internet-drafts/draft-ietf-sipping-session-policy-framework-00.txt

[9] V. Hilt, G. Camarillo, and J. Rosenberg, “A User AgentProfile Data Set for Media Policy,” IETF Internet draft,draft-ietf-sipping-media-policy-dataset-02, Oct. 2006,work in progress, http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-policy-dataset-02.txt

[10] J. Hautakorpi et al., “Requirements from SIP (SessionInitiation Protocol) Session Border Control Deploy-ments,” IETF Internet draft, draft-ietf-sipping-sbc-funcs-00, Nov. 2006, work in progress, http://www.ietf.org/internet-drafts/draft-ietf-sipping-sbc-funcs-00.txt

BIOGRAPHIESGONZALO CAMARILLO ([email protected])received his M.Sc. degrees in electrical engineering fromthe Royal Institute of Technology, Stockholm, Sweden, andfrom Universidad Politecnica de Madrid (Spain). He headsthe Advanced Signaling Research Laboratory at Ericsson inFinland. He has co-authored, among other standards, the

SIP specification (RFC 3261). He is the IETF liaison managerto 3GPP and currently co-chairs the SIPPING and HIP work-ing groups in the IETF. He is the author of the books SIPDemystified and The 3G IP Multimedia Subsystem (IMS).His research interests include signaling, multimedia applica-tions, transport protocols, and network security

TERO KAUPPINEN ([email protected]) received hisM.Sc. degree in computer science from the University ofHelsinki, Finland. He has a strong background in Linux,Internet protocols, and programming on both the kerneland user levels. He is currently working as a research scien-tist at Ericsson Research in Finland. His current focus is onIPv6 related research and prototyping.

MARTTI KUPARINEN ([email protected]) is cur-rently working as a research scientist at Ericsson Researchin Finland. He has a strong background in UNIX, Internetprotocols, and programming. He has been working withvarious IPv6 related issues since the late 1990s. His mainfocus is building various prototype systems.

IGNACIO MAS IVARS ([email protected])received his M.Sc. degrees in electrical engineering fromthe Royal Institute of Technology, Stockholm, Sweden, andUniversidad Politecnica de Madrid, Spain. He obtained hisTechnology Licentiate degree from the Royal Institute ofTechnology. He works in the Service Layer TechnologyDepartment of Ericsson Research, Stockholm. He hasauthored and co-authored several papers on admissioncontrol and quality of service on the Internet. His researchinterests include admission control, quality of service, mul-timedia transport, signaling, and network security.


Documents

Towards an Innovation Oriented IP Multimedia Subsystem