SIPKnowledge (SIP Knowledge) - FAQ - questions and answers - Relations between IP, Basic Telephony, 3GPP/3GPP2,PTT, PoC, IMS and SIP

Use case: Incoming calls filtering by 3rd party. User A and B are both IMS users, served by the same provider. User A wishes to control who calls user B. So user A sets up an access control list that is stored in an SIP application server. The list basically contains the list of allowed callers of user B. During an incoming call to user B, the SIP application server checks if the identity of the caller matches any of those in the list. If it matches, it continue as a normal call. If not, a “Query” is sent to User A asking for assistance in completing the call. The Query contains the call details of the session (identity of caller, callee, etc). User A checks the “Query”, and responds to this either by accepting the call himself (optional), or by allowing or denying the call. This decision is sent in a “response”. Problem: Simplest sip message to use for “Query” and “response”. Currently, I think using INVITE with call info payload, (redirected from User B to User A) for Query and 302 Redirect with response payload seems to be the good choice. Other choices like SIP MESSAGE are limited in their payloads (only plain or presence related). But I know that 3gpp hasn’t used much of 302 redirect explicitly. I would be grateful if you have any comments.

10a. Follow up -

Thanks for your explanation. I hesitate with 302 redirect because currently 302 redirect is sent back all the way to the caller (as in 23.218), which is a terrible waste of signaling. I was wondering if the S-CSCF or even the AS (am not sure filter criteria can be set for 302) on the terminating side could create another INVITE locally rather than the caller re-sending another INVITE as would normally be done. In fact, this is not only a waste of signaling but also a reason for confusion since the caller would receive a redirect with a contact info which has the same address that he initially intended to call.

10b. second Follow up -

Yes. But doesn’t 24.229 explicitly states “With the exception of 305 (Use Proxy) responses, the S-CSCF shall not recurse on 3xx responses.“ How do we work around this explicit statement?

11. When the doc mentioned that P-CSCF compresses\decompresses is it talking about P-CSCF to/from the UE or P-CSCF to/from the I-CSCF?

12. Is it true that the Registration not always has to go through the I-CSCF, if the UE is in his home Network the P-CSCF can go directly to the S-CSCF? Saying that, can I confirm that the P-CSCF is not always is in local/Visited network, right?

13. The local operator can charge base on the media stream because the P-CSCF understand the the SDP, and not because he talks with the GGSN, right?

14. Also as the P-CSCF understand the SDP, He can assign different QOS policies according the different streams in the same SDP, right? Off course the P-CSCF will order the GGSN to use different PDP Contexts ,right?

15. The GGSN has a Ip address on the Ip world, Also the GGSN send to the UE the IP address of the P-CSCF in order to let the UE know where locate the P-CSCF, and As all the traffic generated by the UE pass through the GGSN . It means, the UE send the traffic to the P-CSCF but the GGSN only transport this traffic, I dont think it is ok saying the GGSN route the SIP traffic, it only transport it, after the GGSN should be a router that route this traffic to the P-CSCF.
Can you clarify this?

16. Every IMS subscriber as the documentation says has a SIP URI identification that on the MMS it is related with a public number for the purpose of allowing PSTN customers call IMS subscribers, right? saying that a PSTN user have never be able to call a SIP URI Right?

17. The IMSI identification of the UE is what the SGSN check with the HLR in order to be sure that this mobile is authorized. After that the PDP Context is created, the UE (IMS Phone) must start registering to the S-CSCF using AKA authentification, this authentification is in both ways, the S-CSCF check the UE and the UE check the IMS server. That is correct ?
I don’t understand what could be wrong with a IMS server for saying that could be Malicious. Example?
IMS only carries signaling, however in many docs I read the RTP goes via IMS, and this is not correct right? The QOS and Billing goes another way, (SDP read it by the P-CSCF ,right?)

18. How QOS is handled when we have a Call to the PSTN, RTP from the GGSN is marked as the P-CSCF ask, but Who ask for the MGW to mark those packet, or as they always are RTP for Voice always are marked?

18a. The same for the MGCF (H.248)?

18b. I can configure on one IMS phone some application for allowing me to make video calls directly to Yahoos but as they are handled as internet packet they don’t have the QOS needed, it does not have sense blocked by the IMS provider right?

19. How is activated an AS service? Dialing the SIP URI of the service? Off course the call does not go directly to the AS, the only one who can interact in SIP with the AS is the S-CSCF, right?

20. (follow up of question 18) About QOS again, if you say that the UE is who mark the packets, the policy that the GGSN apply, in what way It works?
E.g. If the UE mark a HTTP packet (trying to cheat IMS mechanism) and the GGSN/P-CSCF knows that these packets should not be mark. GGSN have a PDP Context saying that this packet should not have good QOS. What happened in this scenario?
SIP packet are marked by UE also when it tries to Register or make a call?

21. Hi, I just took the SIPKnowledge SIP/IMS training, and I like to make sure I understand well the advantage from the user perspective of using IMS over using just plain VoIP. It seems to me from what I have read that IMS is an attempt from the Telco companies to gain control on the Internet area. Is that so?

22. Hi, I just read the 3GPktDomain Basics of the 3GIMS illustrated section and I have a question: The current Telco companies can offer VoIP service to the user. Does it mean that they use the packet switched domain in the 3G diagram for voice encapsulation? If that is the case, how do they offer QoS when the voice goes out of their managed network? Is the VoIP offering from the Telco companies any different from the pure VoIP providers?

--- Answers ---

1. Is the IMS initial registration time (Expires header) always set to 600000 sec (TS 24.229 section 5.1.1.2 step f)? Or can this value be different?

This is just the default value. It can be set differently.

1a. Does this mean if there is no re-registration, the session will expire when the timer is reached, right?

Right.

1b. When that happens, does the UE re-register again?

Well behaved UE should (re-register again), otherwise its registry entry will get cleaned in the registrar related db (P-CSCF, S-CSCF and HSS).

1c. Can this timer be changed after the initial registration is performed?

Yes. It can be done every time the S-CSCF returns 200 OK for a re-reg request. It can also be done by notification for reg event with the appropriate param (e.g. shortened) per RFC 3680.

1d. Can the value be lowered than what the UE requested?

Yes.

2. In some 24.229 procedures, I found the following text "...determine the duration of the registration by checking the value of the Expires

header in the received REGISTER request. The S-CSCF may reduce the duration of the registration due to local policy."

2a. What triggers the network to adjust Expires Time less than the requested value (600000 sec)?

The desire to keep the size of the reg db smallest and realistic as possible. if the reg interval is very long there might be long time pass before the registrar (S-CSCF) will realize that the UE already shut down and thus its entry should have been cleaned up long time ago.

2b. What triggers the network to initiate re-authentication?

Quote from RFC 3680: "It is anticipated that many SIP devices will be wireless devices that will be always-on, and therefore, continually registered to the network. Unfortunately, history has shown that these devices can be compromised. To deal with this, an administrator will want to terminate or shorten a

registration, and ask the device to re-register so it can be re-authenticated."

2c. Is there a default value for the re-authentication expires header or it is operator set value?

We don't know of existence of expires for authentication. We know of existence of expires for registration, which indirectly can enforce re-authentication.

The authentication piggy backs on the reg.

2d. Is there trigger event re-registration, other than reaching expiration timer set in the original Register Contact expires header?

Yes, Explicit notification for one of the reg related events laid out in RFC 3680.

3. What is the purpose of minimum registration timer at the S-CSCF? I can't find the value in the 3GPP TS 24.229?

We don't know of an official minimum value. The default is 600,000 sec. The purpose of lower bound is to avoid network implosion and save

device power/battery.

4. On the subscription to the user's registration-state even package, the expires header may be set to a value higher than the Expires header.

What does a value higher than mean? For example, if the Expires header was set to 600000 sec, what is a value higher mean (600001 sec)?

It is not clear when you say 'expires' what you exactly mean.... It sounds like you are trying to compare/relate the expire header of the REGISTER request with the one of the Reg-Subscription-notification. Jonathan R. in his RFC 3680 discusses shortly this relation in section 4.4, and decides that the reg-sub-not needs to be just a couple of seconds longer than the REGISTER refresh interval. It makes sense to us either. He is talking about default of 3761 seconds, but this is just because he compares it to the RFC 3261 default of 3600 sec. So We'd say the IMS/3GPP default should be just a bit over 600,000 sec, and 3GPP TS 24.229 eludes to that.

5. What does Protected REGISTER mean?

It means the REGISTER was carried over IP-SEC secure virtual connection, and thus confidentiality, integrity and authenticity of the REGISTER-associated messages are guaranteed. Note however that this has nothing to do with the authenticity of the USER using the SIP/IMS device. Hence the SIP/IMS level of authentication.

6. How is expired IETF draft treated in the implementation? For example 3GPP TS 24.229 reference [82] draft-camarillo-sipping-user-database

expired on May 27, 2006. I don't see new version or RFC publish. What do you do in this case?

Excellent point! This is indeed an endless problem, and things like these happen all the time. Industry pioneers sometimes rush to comply themselves to those drafts in order to be the first ones to market, who can claim compliance and then oops... the I-D has no RFC continuation, or even worse, the RFC took a slight different direction or different way to implement the idea. This may lead of course to incompatibility between IMS elements, which may adhere to different versions of drafts or RFCs. For example, there may be two IMS elements, which implement the SIP/IMS privacy extension. However, one implements the remote-party-id draft, while the other one implements the newer privacy RFC 3325 (PAI header).

7. How is P-User-Database header value set? I understand the HSS address is obtained via SLF query, but haven't learned how the

P-User Database is set without the SLF query? Unless it is stored in the SIM or UE?

Our friend Gonzalo Camarillo Ericsson explains this nicely in his relatively new RFC (4457). The purpose of this hdr is for the I_CSCF to direct the S-CSCF to the right HSS in both the registration and termination-of-unregistered-user scenarios. i.e. make sure the S-CSCF goes to the right HSS out of several. So the only element which needs to be concerned with getting the address of the HSS in the first place is the I-CSCF. It can do that via SLF or via config or via any other way. The user and his/her device have nothing to do with that.

8. You mentioned in your training that access type is used for timer adjustment, what are the timers?

P-Access-Network-Info may be used by the IMS server/registrar (S-CSCF) as one of the inputs it takes into consideration when it decides what value to set for the registration-refresh-interval timer (and same for the reg-event-subscription-notification). For example if this hdr tells the S-CSCF the endpoint is registering from UMTS env, it can conclude this is an IMS app running on a UMTS cell phone, and thus reg timer should not be too short in order to save battery life and protect the limited BW of this access. If it is for example a wire-line IP environment the timer may be shorter.

9. How are multiple public user identities get correlated? I have general understanding of forking, but not sure how it is implement. I guess

what I am trying to find out is the common key amongst the identities the user use - IP address?

Lets take a look at the famous TS 23.228 figure 4.6 (text continues below)

Figure 4.6 – The relation of a shared Public User Identity (Public-ID-2) and Private User Identities

First, a key rule to understand/remember is that private id is globally unique across an IMS network. At any given time there will be one (and only one) particular subscriber who is assigned this private id. The private id will be associated with one particular equipment (UE/Cell phone) of that user (If the UE has an ISIM the private id is one of the key identifiers defined in that ISIM). Hence private id and UE have a relationship (cardinality) of one to one (We can simply summarize the above by saying that the Private id is the IMS equivalent of the good old GSM/GPRS IMSI (International Mobile Subscriber Identity)).

Now say we both are IMS users of the same operator, 'foo.net'. You have private id, jo_priv-id and two public IDs. First: sip:jo@ims.foo.net, second: sip:ims_support@ims.foo.net. I have also private id, phil_priv-id and two public IDs. First: sip:phil@ims.foo.net, second: sip:ims_support@ims.foo.net. So we both share the second public ID, because we both can be called upon to provide IMS online support.

Say we both register to the network. Let's assume there is only single S-CSCF in the network. so for sure we are both going to be registered in the same S-CSCF. Now say there is an incoming call destined to the SIP URI sip:ims_support@ims.foo.net. The S-CSCF would notice it has two different contacts (IP addresses) for this URI, so based on operator policy and/or service defined for this URI, it may decide to fork to both of our active devices, or perhaps try you first, and then try me second if there is no answer from you.

10. Use case: Incoming calls filtering by 3rd party. (Long question - please see the details above in the questions section).

Since A's choices are: 1. accept the call himself 2. Redirect/Refer to B 3. Reject then INVITE with the call info as payload seems a good clean solution. A has enough info if he wants to take the call himself. And he can redirect (302) to B (which serves as an indication that the call is okay to be answered by his child) or reject by 403. 3GPP does not have any direct problem wrt to redirections (e.g. see 3GPP TS 23.218 Annex B1). Only thing is you need to be careful and check whether the redirection may cause you to skip App Servers in a chain of AS..! With good design however of Filter criteria you should be fine.

Also it should be noted that you need to have some special logic in endpoint A (or either in the last hop B2BUA/AS) to understand that the call is not originally intended to him (A), but is intended to his child (B) (and so he would know to apply the special behavior). This may be done by looking at the call info in the payload (Request-URI/TO etc) or/and perhaps by flagging with some header (e.g Subject). When you have made a progress you can send us if you wish a detailed example and we will do our best to verify.

10a. (Follow up - please see the details above in the questions section).

Yep. Good point! Some of our customers ran into this issue in their core IMS network, and we made sure they understand they need to recurse on 3XX either in the AS or in the IMS server (S-CSCF + internal AS). and let's not forget that 3XX may be returned for all sort of reasons, so your network better be able to handle it anyways..:-)

10b. (Second Follow up - please see the details above in the questions section).

Painful indeed. However, S-CSCF is just a standard function. And you can claim that your IMS server incorporates more logic than just that (For example, you can say it incorporates also an AS function, which works in a proxy mode). Recall that 3261 does not have that limitation (3261 16.5). It is indeed always a delicate balance to keep the standard compliance people happy, but at the same time resolve practical issues...

11. When the doc mentioned that P-CSCF compresses\decompresses is it talking about P-CSCF to/from the UE or P-CSCF to/from the I-CSCF?

Compression\de-compression refers to the interface between the P-CSCF and the UE. The idea behind it is that in 3GPP or 3GPP2 (or/and other air interface) the messages between the UE and the P-CSCF travels partially over the air with limited bandwidth, and thus compression is crucial.

Excellent question/comment. Surprisingly however the answer is Nop! In registration (whether it is first time Reg or Re-Reg) the P-CSCF always has to go via the I-CSCF. No matter whether he is roaming or at home.(No short-cuts are allowed per 3GPP). One may be surprised, since in call origination scenario P-CSCF goes directly to the S-CSCF (unless it is a network hiding case). This is show/explained both in our IMS Illustrated course in the long call flow examples (Operation module) and in 3GPP TS 24.228 (also you can see 3GPP TS 29.228). The reason for the need in Re-reg to go via the I-CSCF is for the most part because 3GPP decided that way :-)
But now beyond that, when P-CSCF has to go thru I-CSCF in reg or re-reg it enables the network operator (thru the HSS) to authorize the user and validate the current legality of his subscription and/or roaming agreement (as part of the user status query request submitted to the HSS by the I-CSCF). Also it opens up opportunity to S-CSCF re-selection (by the HSS/I) and/or load balancing!

To your other question. Right, P-CSCF can be either in visited or home network. It only depends where the user is currently roaming (or "homing"). recall that in reality it would be in many cases the same IMS server (platform) fulfilling the role of all - P-CSCF, I-CSCF and S-CSCF).

13. The local operator can charge base on the media stream because the P-CSCF understand the the SDP, and not because he talks with the GGSN, right?

That's exactly true (and same goes for the S-CSCF).

Right. Both of your statements are correct.

Correct. ALL traffic from UE to the IP network goes via the GGSN. That means both media (e.g. RTP) and signaling (e.g. SIP). Same for HTTP packets etc. The GGSN is agnostic of that. It treats any traffic based on the particular PDP context associated with the flow. It doesn't care (or know) whether the traffic is SIP signaling or RTP media.

16. Every IMS subscriber as the documentation says has a SIP URI identification that on the MMS it is related with a public number for the purpose of allowing PSTN customers call IMS subscribers, right? saying that a PSTN user have never be able to call a SIP URI Right?

Very true. That's why the SIP RFC (3261) uses TEL URLs as well. SIP URIs are to be used only within the IP domain (e.g. IMS cloud). PSTN user dials digits (E.164 world number), which based on 3GPP needs to be converted to SIP URI once enters the IMS cloud. The conversion from E.164# to SIP URI may take place based on DNS ENUM or other translation tables. At some cases this is really just a syntactical conversion, and the digits stay the same only they are encapsulated in SIP URI format rather than TEL URI (e.g. tel:+1-212-555-2222 may be converted to sip:+1-212-555-2222@home_opearator.net or in some cases it may be converted to sip:federico@home_opearator.net).

17. The IMSI identification of the UE is what the SGSN check with the HLR in order to be sure that this mobile is authorized. After that the PDP Context is created, the UE (IMS Phone) must start registering to the S-CSCF using AKA authentication, this authentication is in both ways, the S-CSCF check the UE and the UE check the IMS server. That is correct ?
I don’t understand what could be wrong with a IMS server for saying that could be Malicious. Example?
IMS only carries signaling, however in many docs I read the RTP goes via IMS, and this is not correct right? The QOS and Billing goes another way, (SDP read it by the P-CSCF ,right?)

Very true. In addition, the UE uses some of the info sent in the 401 response to generate security keys for the IPSec between itself and the P-CSCF. The 401 response is part of the digest AKA authentication procedure. For simplicity (and because this material is covered in a great detail in the SIP Illustrated course) we skipped this phase and had the S-CSCF return 200 OK right away. Now based on your good question/comment we will add some explanation there for sake of future students. Please see attached paper, which I wrote awhile ago, and which explains the AKA digest authentication procedure in detail (and compares it to MD5 digest used in "pure" SIP).

About your question what could be malicious with the server. Could be some hacker that snoops the REGISTER message, steals the credentials of the user, while returning 200 ok to the user to make him think that everything is alright. At the meantime this hacker register to the real IMS network pretending to be the user. Since he would register his own IP address he can steal calls of the user or even answer on the user's behalf...

QoS and billing goes via IMS like you said. RTP indeed normally would NOT go via IMS. However there could be special cases of Media server (MRFP) or Voice Mail server, which are part of the IMS cloud, and they use of course RTP between them and the UEs.

First, in some cases it is not the P-CSCF that asks the GGSN to mark, but rather it is the UE that marks the RTP packets, per the permission that the GGSN gets apriori from the P-CSCF/PDF (based on the operator policy).
Second, about the MGW, right. As a VoIP client it has the responsibility to mark the packets based on the operator policy and based on the specific service/app. Nothing is taken for granted, UE or/and MGW will mark RTP packets only if they are designed and configured to do so.

18a. The same for the MGCF (H.248)?

Yes. in reality MGCF and MGW come as two parts of the same platform (which could be of course a distributed one), which has a policy function that is in charge of many things, among them packets marking. E.g. see the Souns GSX, PSX, SGX etc.

18b. I can configure on one IMS phone some application for allowing me to make video calls directly to Yahoos but as they are handled as internet packet they don’t have the QOS needed, it does not have sense blocked by the IMS provider right?

Right. Their QoS might be so poor that they should have the incentive to use your IMS service. You can also have SBC (e.g. Acme packet), which can help you to discriminate QoS per source and destination...!

19. How is activated an AS service? Dialing the SIP URI of the service? Off course the call does not go directly to the AS, the only one who can interact in SIP with the AS is the S-CSCF, right?

Right. But no, not dialing SIP URI. Please see in IMS Illustrated the explanation about the IFC. This is the Filter criteria, which is provisioned in the HSS for each user (as well as system based). Then in Reg time, it is downloaded to the S-CSCF. In call processing time the S-CSCF will try to match the SIP request against the IFC (Filter Criteria) and may route to AS respectively. (for example, you can provision IFC (rule) for a pre paid users, which says that every origination of these users needs to be routed first to the Pre paid As platform.

20. (follow up of q18) About QOS again, if you say that the UE is who mark the packets, the policy that the GGSN apply, in what way It works?
E.g. If the UE mark a HTTP packet (trying to cheat IMS mechanism) and the GGSN/P-CSCF knows that these packets should not be mark. GGSN have a PDP Context saying that this packet should not have good QOS. What happened in this scenario?
SIP packet are marked by UE also when it tries to Register or make a call?

Dear amigo. Your questions/comments are just becoming better by the day... Long answer follows! It is true that one of the key attributes of the PDP context is the QoS. However as 3GPP TS 23.207 annex A (figure A.1) shows, the scope of the PDP context is limited to the UMTS/GPRS access network, i.e. everything, which is between the UE and the GGSN (but not beyond the GGSN towards the core IP network). Now as the different scenarios in 23.207 Annex A show, the UE can either trust the GGSN to do the marking for it when the IP packet leaves GPRS towards core (i.e. uplink direction) or it can decide not to take a chance and mark it itself just in case.. 23.207 also shows you alternative QoS control via diffserv (i.e. reserve resources apriori rather than mark on the fly). We (SIPKnowledge) were involved in some IMS deployments, which were wireline/WiFi/WiMax based, and thus are used to have the pessimic approach that the endpoint needs to try take care of itself... In these networks we had in addition the SBC, which was in charge as well of packet marking (No GGSN of course there) on the direction from the core towards the endpoint.

If UE is malicious or tricky and it tries to give a high-priority marking to background or interactive class of packets, e.g. HTTP packets, the PDP context can override that indeed, first for the part of the path under its control (i.e. between UE to the GGSN) then the GGSN (if it is smart enough) can consider the PDP context also for the core outbound portion and overrides the DSCP bits set by the malicious UE downgrading it to best effort QoS.

So all in all, you always need to check these delicate points against the vendors/equipment in your particular deployment. E.g. Is it Cisco GGSN or Nokia? What model? What do they support etc.

About your last question (SIP packet are marked by UE also when it tries to Register or make a call?) Based on 23.107 signaling falls under interactive QoS class while RTP either conversation or streaming class, thus (as 24.228 5.3 shows (as well as 23.060 and 23.107/23.207)) UE need to always set PDP context (also for signaling, since SIP signaling goes over the GPRS data pipe), but the QoS value requested should be appropriate. So all in all the resource reservation procedure is described in context of call setup for sake of the RTP. i.e. UE (or GGSN or any other core edge router/gateway) needs to mark the bits (or perform RSVP reservation) during the call setup only (and not during registration).

Excellent question! First and for the most part, you are definitely right. Sometimes we the little users may feel like pieces in the big operators game of control... However, QoS, security and High Availability may be better provided and fine-tuned when controlled by the IMS operator rather than by the 3rd party Yahoo/AOL or the like. In many cases the calls will be local (from both signaling and media perspectives) and thus better controlled/served/optimized by the local operator rather than the Yahoo server(s) on the external/public Internet. In some cases the operators may use dedicated IP trunks for IMS, which further assists in achieving the desired effect indicated above.

Exactly dear. They use the packet switched domain in the 3G diagram for voice encapsulation. But not only... Also the IMS/SIP signaling uses the same packet switched domain! (since the SGSN and GGSN do not know or care about the payload of the IP packets travel over their heads). The packet switched domain can guarantee QoS inside the domain, and this is quite significant, since bottlenecks of IP traffic tend to occur at the periphery (think for example about the difference between 56K modem to Cable or DSL service (Core is the same core)). When the voice goes out of the operators managed network there is indeed no guarantee for QoS delivery (even if the packets are class-marked), but as said the problem is typically the periphery. Thus when the periphery-QoS is handles well by the Packet domain the overall-QoS is good. Regarding VoIP providers (e.g. Vonage, Comcast) versus Telco companies (e.g. VZW) I'd say there is much room for comparison as both have control over the critical portion of their networks (i.e. the periphery). Recall that practically nowadays the real diff between IMS and VoIP network or/and IMS and VoIP endpoints is more semantic. Quite few so called IMS systems are really just VoIP networks with some IMS extension support (e.g. P-headers, AKA authentication etc).