This is the third (but not last) post in a series that tries to describe the service-related and IMS-specific mechanisms used to route SIP requests in an IMS network.
After a first post that set the scene, and positioned IMS service routing into a bigger end-to-end context (big picture), after a second post that described the concept of IMS service profile, this post will describe how the IMS core network entity called S-CSCF makes use of the service profile to route SIP requests to application servers over the ISC reference point in the phases 2 and 5 of the big picture.
However, it takes two to tango. While this post concentrates on ISC from an S-CSCF perspective, the next one will address it from the point of view of an IMS application server.
Where to Look in 3GPP Specifications
The ISC procedures at the S-CSCF are not described in a dedicated document or in a dedicated chapter of a 3GPP specification. They are embedded in the detailed description of the S-CSCF procedures in TS 24.229.
Though it definitely makes sense to read other parts of the specification in order to fully understand the procedures, the following sections are the most important:
- Section 5.4.3.2 describes the procedures at the S-CSCF when it receives a request initiated by the user it serves. This corresponds to the phase 2 in the big picture diagram.
- Section 5.4.3.3 describes the procedures at the S-CSCF when it receives a request that is terminated at the user it serves. This corresponds to phase 5.
- Subsections in 5.4.1 address IMS registration procedures, which imply a specific ISC behavior.
As always, I recommend to read the specifications, while on my side I will try to provide a different description of the procedures, that can help the reader to more easily decrypt the occasionally obscure wording and the untold stories from the specifications.
Overview of the Procedure
When it receives an initial or standalone SIP request that is originated by or terminated to a "user" (IMPU, PSI) it serves, the S-CSCF processes the initial filter criterias in the service profile associated to the IMPU or PSI, according to their priority. If the trigger point in a filter criteria is true, the S-CSCF forwards the SIP request to the corresponding application server.
If the application server sends a related SIP request back to the S-CSCF, it proceeds with the next iFC, and so on until a terminating condition is met.
This may lead to the so-called chaining of several application servers in the signalling path that originated from a SIP endpoint (client or application server) and will terminate at another one (client or application server). This chaining may take place on both sides of the end-to-end signalling path (i.e. phases 2 and 5).
This may lead to the so-called chaining of several application servers in the signalling path that originated from a SIP endpoint (client or application server) and will terminate at another one (client or application server). This chaining may take place on both sides of the end-to-end signalling path (i.e. phases 2 and 5).
When a terminating condition is met and there is still a SIP request to be processed, the S-CSCF then proceeds with normal SIP routing procedures in the IMS (phase 3 or 6).
iFCs Are Only Applied on Standalone or Initial Requests
A SIP standalone request is an isolated transaction requiring a single final reponse. An example of standalone request is MESSAGE.
A SIP initial request starts a dialogue, which will include a set of related transactions. a SIP session started with an INVITE is an example of SIP dialogue, but there are others, like dialogues initiated by SUBSCRIBE or REFER.
The S-CSCF applies service profile based routing only on standalone or initial requests. If an AS is contacted and decides to act as a SIP proxy or Back-to-Back User Agent (B2BUA), for an initial request starting a dialogue, it determines if it wants to remain in the signalling path for the subsequent requests of the same dialogue. This decision is recorded in a specific header called Record-Route.
The S-CSCF then processes the subsequent requests in the same dialogue according to normal SIP routing procedures. These subsequent requests may either be routed to the AS or not, depending on its initial decision.
The Original Dialogue Identifier
The original dialogue identifier is described in section 5.4.3.4 of TS 24.229.
You can read the technical details by yourself, but this token inserted by the S-CSCF in the SIP request before it is forwarded to an AS is a kind of secret word, that the S-CSCF will recover from the SIP request (or a derived one) when it comes back.
This secret word, both created and consumed by the S-CSCF serves two purposes.
This secret word, both created and consumed by the S-CSCF serves two purposes.
This is first a convenient way for the S-CSCF to discriminate between the SIP requests it receives from the core network and those that are coming back from the application layer. When the SIP request includes an original dialogue identifier, it can be associated to an ongoing ISC procedure (i.e. ongoing processing of iFCs).
However, the original dialogue identifier was introduced for another reason.
When an application server receives a request originated from A and addressed to B, as it is shown in the big picture, it may decide to insert itself in the signalling path between the two endpoints. One way to do it is to just proxy the initial request back to the S-CSCF. However, a proxy behavior is very constraining, and does not permit the AS to have much control on the future SIP dialogue. For instance, the AS cannot change the SIP request as it wants, or temper with its body (e.g. change a codec in the SDP). Moreover, in the case of a SIP session, if the AS acts as a SIP proxy, it cannot decide during the session to e.g. play an announcement or transfer the session to another user.
In order to do this, the AS has to act as a Routeing Back-to-Back User Agent (B2BUA), which makes it act as an endpoint towards A and as another endpoint towards B. In the process, it may decide to make itself visible (i.e. place a PSI in the SIP requests towards A and B) or transparent (i.e. A and B cannot see there is a B2BUA, i.e. a service, inserted between them).
The problem is that when it acts as a routeing B2BUA, the AS creates a brand new SIP dialogue on the B-side and the S-CSCF has no standard SIP way to relate this new dialogue to the one on the A-side. The original dialogue identifier serves this purpose.
The procedure at the AS when it acts as a routeing B2BUA mandates it to copy the header in which the original dialogue identifier was placed (the Route header) in the request starting a new dialogue downstream (the second half of the B2BUA).
The procedure at the AS when it acts as a routeing B2BUA mandates it to copy the header in which the original dialogue identifier was placed (the Route header) in the request starting a new dialogue downstream (the second half of the B2BUA).
When it matches the original dialogue identifier from an incoming request with one it inserted in an outgoing request to the AS, the S-CSCF knows that the two requests relate to the same logical dialogue. This is important for charging, but also for being able to proceed with the evaluation of iFCs and associated service routing until the end.
iFC Processing Termination Condition
When does the S-CSCF stop processing iFCs?
There can be three conditions for the S-CSCF to stop its processing of iFCs:
1) An application server has decided to serve as an endpoint for the SIP request (not a routeing B2BUA, a real endpoint). The AS provides the responses to the request and does not proxy it further. Routing of the SIP request in the IMS stops there (phase 2 or 5).
2) This is a terminating case (phase 5) and an application server has modified the request-uri (i.e. intended destination) of the SIP request. The S-CSCF then processes the request according to this new request-uri, without any attempt to apply other iFCs that related to the previous request-uri.
3) All the iFCs in the service profile have been processed, and there is still a SIP request to be routed further (phase 3 or 6).
Requests Initiated by an Application Server
An AS can decide at any time to initiate a new SIP request towards the IMS core network. This SIP request may be generated totally out of the blue, or be the side effect of an interaction with a user or a 3rd party through e.g. a web page or web services. It may also be the side effect of an incoming SIP request. For instance, when receiving an INVITE from A to B, the AS may decide to send an instant message to A, B, or C.
In some cases the request is initiated on behalf of a user. In that case, the AS inserts the IMPU of the user (e.g. A) as the initiator of the request. As it acts on behalf of a user, its request must be processed as if it was really originated by the user. It must therefore be routed to an S-CSCF serving the user so that it applies originating procedures (phase 2), which include the processing of the service profile associated to the IMPU.
Similarly, if the AS uses a PSI as the originator identity for the SIP request, it may need to route it to an S-CSCF, so that originating procedures apply as well, this time for the PSI.
Similarly, if the AS uses a PSI as the originator identity for the SIP request, it may need to route it to an S-CSCF, so that originating procedures apply as well, this time for the PSI.
An S-CSCF uses different ports to process incoming and terminating SIP requests. However, in the standards, an AS has no means to know which port an S-CSCF uses for originating requests, it only knows the port for terminating requests. This is the reason why the specifications mandate that when an AS issues a SIP request on behalf of an IMPU (PSI) towards an S-CSCF serving this IMPU (PSI), it includes a specific parameter called "orig", which permits the S-CSCF to detect that the request that is coming on the terminating port should actually be processed as if it was coming on the originating one (see section 5.4.3.1 in TS 24.229).
Support of IMS Registration Notification
For an application server, knowing when an IMPU registers and de-registers from the IMS core network might be an essential information. For instance, a message store might want to be notified when a user registers, and is therefore able to receive a message that is anxiously waiting for her.
However, SIP REGISTER is the only SIP request that cannot be forwarded by the S-CSCF for the simple reason that the S-CSCF, acting as a SIP registrar, is itself the endpoint for it.
Consequently, in order to notify application servers about registration events as requested in the service profile (i.e. registration, re-registration, de-registration) , the S-CSCF issues a 3rd party REGISTER towards them. This is, the S-CSCF registers the IMPU of the user in the application server on behalf of the user.
The information in this 3rd party register is more limited than the in the original REGISTER issued by the IMS client towards the S-CSCF. For instance, 3rd party registration does not permit the application server to discover the capabilities of the IMS client (which can be very important for some services), and it only provides information about a single IMPU being registered, while the user might register several IMPUs at once.
For accessing more information about the registration, the application server can subscribe to the registration event package (using SIP SUBSCRIBE). It will receive the registration information in the body of the NOTIFY(s) issued by the S-CSCF. The registration event package is also an alternative to 3rd party registration for the AS to be notified of de-registration and re-registration events.
For accessing more information about the registration, the application server can subscribe to the registration event package (using SIP SUBSCRIBE). It will receive the registration information in the body of the NOTIFY(s) issued by the S-CSCF. The registration event package is also an alternative to 3rd party registration for the AS to be notified of de-registration and re-registration events.
Note that, if 3rd party registration (a standard IETF mechanism) is specific to the ISC reference point in the IMS architecture, the usage of the registration event package is not: the I-CSCF and standard IMS clients are supposed to subscribe to this event package in order to be notified about de-registration when it has been decided by the IMS core network (e.g. the operator has decided to de-register the IMPU).
Details of SIP on ISC
SIP messages over ISC include IMS-specific headers, some of which I already listed in a previous post.
However, it is important to note that none of these headers is specific to ISC. These are IMS SIP headers that are also used on other reference points.
Therefore, there is no such a thing as a specific SIP that would be used only on the ISC reference point. What makes ISC special from a core network perspective is essentially the usage of a service profile by the S-CSCF for deciding on how to route an incoming SIP request to possibly multiple IMS application servers.
Christophe
Stumble It!
55 comments:
Dear christophe,
Do you see a value in inserting an Application Server in P2P sessions capable of defining more precisely end-point capabilities and able to make recommendations and push software updates maybe using presence mechanisms? e.g. "Please user A switch to your HD TV if you wish to view this content" (the session woudl then continue there) OR silent upgrade of terminal capabilities on-the-fly in order to participate in a multimedia session requiring a media player that the device is lacking?
Thanks for the great posts!
XaaaV
Definitely, and you are pointing at a fundamental issue.
In my very early post on multimedia communication (April), I wrote that operators face three important challenges in this area:
1) Enabling multimedia communication, which is a natural SIP P2P feature. I made a post about it.
2) Adding value to multimedia communication
3) Using multimedia communication to deliver their own content services
Your point relates to #2 and I intend to write about it in the future.
In the meantime, you can read my other April post on IMS Service Logic Distribution.
Christophe
Hi, Christophe!
You said: "If the application server sends a related SIP request back to the S-CSCF, it proceeds with the next iFC, and so on until a terminating condition is met".
If the AS has modified the original request in such kind, that one of the iFC with higher priority becomes applicable, does it means that this one will be missed because of S-CSCF is proceeding the next iFC with lower priorities?
I would say yes. If the AS acts as a SIP proxy server or routeing B2BUA (see September 8th post on ISC from IMS AS perspective for details), then the only change that could have an impact on the evaluation of iFCs by the S-CSCF is a change of the request-uri.
However, if you know that a specific change could occur because of AS X, and that this change may lead to the need to invoke Y, you can add an iFC for this.
In the case where AS X could be invoked first, but then a subsequent AS Y could change the signalling and make necessary to invoke AS X again, then you could have an iFC involving AS X again like this:
iFC #n: AS X
iFC #n+m: AS Y
iFC #n+m+o: AS X
So you could say that a way to handle your issue with an iFC of higher priority that becomes applicable again is to duplicate it as an iFC of lower priority. However, this implies that the service logic on AS X and/or AS Y takes care of the potential loops that this approach might lead to.
Christophe
I find your blog very useful and informative. I am new to IMS..just one month old! I will have my own set of doubts, which i will share with you here.\
Thanks
You wrote: "An S-CSCF uses different ports to process incoming and terminating SIP requests."
Have the specifications now started to dictate this? Last time I read them, there was nothing about this in there.
Sure, there ARE CSCF implementations which function this way, but this is NOT how they MUST function to be within spec.
Hi Jorge,
You are right.
The routing of SIP requests to the S-CSCF is based on the delivery of the right URI to other IMS entities. In order to permit the S-CSCF to distinguish between originating and terminating requests (for which different behaviors apply) there must be a difference between the one used for originating requests and the one used for terminating ones.
A difference of port number is one possibility among others, which is used by some suppliers.
I do not think that there is a need to standardize further than that, as this matter has no interoperability impact.
Christophe
Hi Christophe,
I wanted to know that what settings/configurations are required for a third party registration to take place ? do we need to create some special type of User profile ??
Please let me know
Abhi
Hi Abhi,
You have what you need in the iFC data model.
You need to define a service point trigger which specifies that the SIP method is REGISTER.
Then, there is an attribute associated to the service point trigger, which is only relevant when the method is REGISTER, and which is called RegistrationType.
This is a list of integers which can take the value 0 (initial registration), 1 (re-registration) or 2 (de-registration).
Christophe
hi
i am working on isc interface .in this i created IFC for third party register request and its working good and geting 200 OK reply from application server ...
but getting 403 Forbidden error from scscf while sending SUBSCRIBE request for "REG" event package...
gor this any changes are required in scscf configuration file ....
thank you for the posts
Some implementations are late with the registration event package.
Besides its usage on the ISC interface, this event package is required in the core network and used by the P-CSCF and the User Equipment in order to be notified about network based user de-registration.
Network based de-registration is typically performed by an operator, for instance when an abuse of the IMS subscription has been detected. It requires support of a whole chain of mechanisms, which includes but is not limited to the support of the registration event package.
Some suppliers are therefore likely to link the support of the registration event package to this more global set of mechanisms, which may explain why it is not supported yet in some implementations.
Christophe
Dear Christophe,
First of all, a very educative blog.
I have a silly question. If I remeber correctly, in AIN (old era!) there is a possibility that an SSP can send notifications to SCP where the SSP does not await any response from the SCP and can continue with the call/session.
In terms of IMS is there any mechanism that an S-CSCF can send notification to an AS which is just a pure notification and the S-CSCF does not wait for any response back from the AS to proceed with the session? If this type of notification mechanism is not already part of the specification, how one could achieve that?
I understand that in the iFC we can specify the Default Handling to SESSION_CONTINUED. However, this is meant to be used to determine whether the dialog should be released if the "Application Server could not be reached or not" (29.228, B.2.2).
The question is not exactly related to "reachability" of the AS, but implementation of notification of SIP events to an AS (which may use it for some bookkeeping service or whatever).
Also, another related question is: which parameter in a S-CSCF decides that how long it should wait for an AS to respond before it continues with the session (in case Default Handling is set to SESSION_CONTINUED)?
Thnaks again for the great posts.
Best Regards,
Ari
Thanks for your good introduction. I got a lot of help from it. Now i have a question:
As you said, there is 2 ports at S-CSCF, one for originating request, another for terminating.
If a request from terminal UA, the request will be route to S-CSCF as originating request via P-CSCF, and then route to AS as an originating request.
How can we send a request from another AS(requester AS) and make it looks like originating request from target AS? If we use "orig" tag, the request will be regarded as originating request by S-CSCF, but S-CSCF SHOULD remove this tag according to 24.229. Once this request was routed to target AS, which type does this request look like from target AS view? originating or terminating?
I have a question about the following statement:
2) This is a terminating case (phase 5) and an application server has modified the request-uri (i.e. intended destination) of the SIP request. The S-CSCF then processes the request according to this new request-uri, without any attempt to apply other iFCs that related to the previous request-uri.
If the new request URI belongs to a served user will the SCSCF apply the iFCs related to that user i.e. the new Request-URI.
The specifications don't seem to specify this. I've tested with the Ericsson SDS and found that it does not. WDYT?
Do You interesting how to [b]Buy Viagra per pill[/b]? You can find below...
[size=10]>>>[url=http://listita.info/go.php?sid=1][b]Buy Viagra per pill[/b][/url]<<<[/size]
[URL=http://imgwebsearch.com/30269/link/viagra%2C%20tramadol%2C%20zithromax%2C%20carisoprodol%2C%20buy%20cialis/1_valentine3.html][IMG]http://imgwebsearch.com/30269/img0/viagra%2C%20tramadol%2C%20zithromax%2C%20carisoprodol%2C%20buy%20cialis/1_valentine3.png[/IMG][/URL]
[URL=http://imgwebsearch.com/30269/link/buy%20viagra/3_headsex1.html][IMG]http://imgwebsearch.com/30269/img0/buy%20viagra/3_headsex1.png[/IMG][/URL]
[b]Bonus Policy[/b]
Order 3 or more products and get free Regular Airmail shipping!
Free Regular Airmail shipping for orders starting with $200.00!
Free insurance (guaranteed reshipment if delivery failed) for orders starting with $300.00!
[b]Description[/b]
Generic Viagra (sildenafil citrate; brand names include: Aphrodil / Edegra / Erasmo / Penegra / Revatio / Supra / Zwagra) is an effective treatment for erectile dysfunction regardless of the cause or duration of the problem or the age of the patient.
Sildenafil Citrate is the active ingredient used to treat erectile dysfunction (impotence) in men. It can help men who have erectile dysfunction get and sustain an erection when they are sexually excited.
Generic Viagra is manufactured in accordance with World Health Organization standards and guidelines (WHO-GMP). Also you can find on our sites.
Generic [url=http://viagra.deutafilm.ru]buy generic viagra online in canada[/url] is made with thorough reverse engineering for the sildenafil citrate molecule - a totally different process of making sildenafil and its reaction. That is why it takes effect in 15 minutes compared to other drugs which take 30-40 minutes to take effect.
[b]viagra and lisinopril
Viagra Non Responder
buy viagra over the counter us
Viagra Duration Of Effect
Viagra Muscle
Viagra Falls Palm Desert
Viagra Merchandise
[/b]
Even in the most sexually liberated and self-satisfied of nations, many people still yearn to burn more, to feel ready for bedding no matter what the clock says and to desire their partner of 23 years as much as they did when their love was brand new.
The market is saturated with books on how to revive a flagging libido or spice up monotonous sex, and sex therapists say “lack of desire” is one of the most common complaints they hear from patients, particularly women.
hello, I love the information in this blog about "IMS Service Routing: ISC for S-CSCF", I wonder if there are updates to this post, thanks!
Hi all,
I am doing some experiments on registering the client and inviting the alice using openimscore.
I am done with registration and when i come to inviting the client i was successful till first 200 ok but after that bob is sending ack then scscf is back the errror message as:
Status: 403 Forbidden - Dialog not found on S-CSCF or Terminating user not suitable for unregistered services....
i am not familiar with openims and this is a part of my studies so i need help from you guys please help me.....
free poker money play no deposit poker and bonus poker or bonus bez depozytu
--------------------------
Visit my web: Poker bonus sans depot & Poker Bonus 50 & Poker ohne einzahlung & Bonus senza deposito
Well written "IMS Service Routing: ISC for S-CSCF" article, well researched and useful for me in the future.I am so happy you took the time and effort to make awesome The IMS Lantern blog here. See you around
--------------------------
My site: 50 Poker Money Bonuses.
I am really enjoying reading your well written "IMS Service Routing: ISC for S-CSCF" article. I think you spend numerous effort and time updating your The IMS Lantern blog. I have bookmarked it and I am taking a look ahead to reading new articles. Please keep up the good articles!
--------------------------
Website to visit: Free Poker
Could you all please clarify one doubt. My query is suppose an IMS terminal registered to a domain, say example.com and when the user dials a number who is located in another domain, say xyz.com, then that INVITE request uri and To: header contains, for example xxx.example.com (home domain). In this case, how S-CSCF route the INVITE request to xyz.com domain?.
Could you all please clarify one doubt. My query is suppose an IMS terminal registered to a domain, say example.com and when the user dials a number who is located in another domain, say xyz.com, then that INVITE request uri and To: header contains, for example xxx.example.com (home domain). In this case, how S-CSCF route the INVITE request to xyz.com domain?.
online xanax no prescription generic xanax l441 - xanax online fake
buy viagra online without rx order viagra overnight delivery - order viagra from boots
viagra cost generic viagra echeck - buy 100mg viagra online
order soma buy soma online mastercard - buy soma online florida
generic soma stores have soma bras - makes generic soma
cheap soma methocarbamol generic soma - soma 250 high
soma sale soma drug of abuse - soma half life
buy tramadol online tramadol hcl side effects - tramadol is generic for
order cialis online no prescription where to order cialis in usa - can you order cialis online for usa
buy tramadol online tramadol quinine - tramadol 50 mg abuse
generic xanax xanax urine detection time - percocet xanax high
generic xanax xanax 2mg half life - xanax for getting high
buy carisoprodol carisoprodol 350 mg for pain - carisoprodol class of drug
where can i buy xanax online which has less side effects xanax or klonopin - can xanax overdose kill
discount xanax buy xanax online cheap no prescription - mouth swab drug test xanax
Simply want to say уοur artіclе is as surprіѕing.
The cleaгnesѕ for your publіѕh іs just excellent and i can
suppose you are a profеssiοnal
on this subject. Well with your permiѕsion let me to grаsp your feed tο stay up to date with forthcοmіng роѕt.
Тhanκs one million and please κеер
up thе еnjoyable woгk.
My page - www.lgtensunits.com
buy tramadol buy tramadol online usa - tramadol withdrawal what to do
All of the richest payday impart services we reviewed are nice, dependable institutions that forward a legalize backing to those who ask for a infrequent extraneous dollars to away to a woman's heels it be means of a sketch patch. In this locating, you'll call up up articles with payday loans communication and moolah tips, as fount as full reviews and a side in the vicinity side resemblance to servants you pinch an cultured firmness on which advantage is uprightness factual side forward of your short-term facility needs. We establish that the out of sight options payment payday loans online.
Payment those that requisite difficulty cash between paydays, concession the differences in payday advance lenders can determine how conclusively and speedily you fare the money you need. It used to be that you had to be done with to a physical laying and wait pro an affirmation on your payday allow, after submitting copies of check stubs and bank statements. For the nonce, there is a inconsistency in payday accommodation lenders because there are some that offer rapid and convenient online options. When you run after use of online options, it is reachable to hire trice approvals and have the filthy lucre you fundamental in a quandary of a only one hours, or less.
Best Online Payday Loans and Cash Advance:
payday advance loan
[url=http://paydayloanmoneyfast.com/loan/kansas-payday-loans-db]Kansas payday loans[/url]
http://paydayloanmoneyfast.com/loan/low-fee-payday-loan-97 - Low fee payday loan
buy cialis with paypal buy cialis brand online - cialis customer reviews
Informatіve article, еxаctly whаt I needed.
Нaѵe а looκ at my wеbsite - Irving taxi
klonopin klonopin online prescription - 2mg klonopin sublingual
buy klonopin online klonopin withdrawal numbness - trazodone klonopin overdose
http://buytramadolonlinecool.com/#63102 can i get high on 50 mg tramadol - tramadol buy usa
learn how to buy tramdadol tramadol 717 - tramadol dosage sizes
tramadol 50mg tramadol overdose in cats - tramadol 100mg sr
buy tramadol tramadol dosage australia - buy tramadol with visa
klonopin buy 2mg klonopin half life - erowid experience vault klonopin
buy ativan ativan weight gain - bad ativan you
carisoprodol 350 mg cheap carisoprodol online - carisoprodol cost
Your currеnt ρost offers еѕtablished useful to
me реrsonally. It’s verу useful and you're clearly extremely knowledgeable in this region. You have popped my face to be able to various opinion of this kind of topic together with intriguing, notable and sound articles.
My web site Xanax
This is also a very good post which I really enjoyed reading. It is not everyday that I have the possibility to see something
kids games
friv
unblocked games
juegos de un show mas
Post a Comment