| Home | eBook | Buy | SIPKnowledge Hall Of Fame (Top 1%) | FAQ | About | Contact |
| iLearn | iCertify | iLAB | 3GPP IMS Specifications | SIP RFCs | IMS? | SIP? | DEMO |
| SIP Feature/Topic Of The Month | SIP Glossary | VoIP Glossary | (3GPP) IMS Glossary |
| Test Your SIP Knowledge | Test Your IMS Knowledge | Test Your VoIP Knowledge | SIP Books | "The" SIP RFC (3261) - Annotated |
|
SIP/IMS detailed Q&A - Triggered by our SIP/IMS training courses (or/and exams)
|
Note: Please scroll down (or click here) to see the SIP training related questions.
--- Questions triggered by our IMS training course --- |
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?
b. When that happen does the UE re-register again?
c. Can this timer be changed after the initial registration is performed?
d. Can the value be lowered than what the UE requested?
a. What triggers the network to adjust Expires Time less than the requested value (600000 sec)?
b. What triggers the network to initiate re-authentication?
c. Is there a default value for the re-authentication expires header or it is operator set value?
5. What does Protected REGISTER mean?
May 27, 2006. I don't see new version or RFC publish. What do you do in this case?
without the SLF query? Unless it is stored in the SIM or UE?
trying to find out is the common key amongst the identities the user use - IP address?
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?
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?
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?
--- IMS 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, neither was I able to find it in your SIP/IMS training?
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 SIP/IMS 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.
10a. (Follow up - please see the details above in the questions section).
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.
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?
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).
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?
Right. Both of your statements are correct.
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?
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.
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?
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).
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?
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.
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?
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).
23. In your SIP/IMS training PCC module you specify only 3GPP references. Why is that?
This is simply per our expectation that all major PCC specifications will converge around 3GPP in R9 time frame, which is just about to start (9/2008).
--- Questions triggered by our SIP training course --- |
1. (Part 1) Why is CSeq kept same for all the SIP registration requests? One of the slides says that the CSeq field is used by the registrar to search for the records when registration is updated. However, the records in the registrar can be searched using the To: header of the new Registration request.
(Part 2) Since Registrar uses the URI in the TO field to search for the entry in its database, why is it required to keep the Call-ID same in all the requests to the same registrar? How does it help Registrar and what are the consequences if the Call-ID is not kept the same?
2. SIP to SIP Direct Dialing - Slide 10 - In the Message 200 OK from, it is indicated that user B accepts the media format 0. Had it been capable of accepting both the media formats suggested by A (0 and 98), which media format be used in the session? (I think 0 because it is the preferred media format. Please confirm.) Which media format would be used if B preferred 98 to 0?
3. SIP to SIP Direct Dialing - Slide 14 - User A sends a re-invite to add the video session. So the SDP version is modified from 2890844526 to 2890844527. When the user B sends a 200 OK response to it in slide 16, the SDP session Id is also modified to 2890844527. Why is it so? (I guess it is a typo)
4. If the user B is capable of only receiving the video and not sending it, will it also modify the sendrecv attribute for the video media format in the 200 OK response to recvonly? If the attribute sendrecv is not present specifically (because the default attribute is sendrecv), will it also insert the attribute?
5. Invitation to Multicast conference - slide 6 - In the scenario described, only user A accepts the Invitation. If other users B and C also accepted the invitation, would they also be able to participate in the conference?
6. Call Hold - Slide 18 - In this scenario, the proxy P adds reconstructed header in the initial Invite request when it forwards it to user B and the 200 OK response for it when it forwards it to user A. When user B send a new Invite request to invoke call hold, it adds the route header field. When the proxy P forwards this request to User A, it again adds the record-route header field. Why does proxy P need to add the record route header field again (slide 18) when both the users are aware that the requests within the dialogue are to be routed through it using the Route header field?
7. Call Hold - slides 19, 20 - When the call hold is invoked by the user B it sends Invite request with attribute sendonly for the media. But in the 200 OK response for this Invite (in slides 19 and 20), attribute is changed to sendrecv. Why is it so?
8. Unattended call transfer - slide 18 - The user B sends Invite request to user C with Supported: Refer-To and Refered-By. However, User B intends that user C should understand the fields Refer-To and Referred-By because user B will use these fields in the messages it sends. So I think it should have used the header field Require instead to Supported. (In my understanding, Supported header field is used by UAC or UAS to enumerate the headers it supports and Require header field is used by a UAC to enumerate the header fields it expects the UAS to understand) Please clarify.
9. Call Forwarding on Busy - Slide 11 - The slide says that the new Invite is a new call leg for P. But in the message the Call Id and the From-tag remain the same. So it is not a new call leg (dialogue)?
10. Call Forwarding on Busy - Slide 21 - When Bye request is sent from Proxy P to user B it contains two Via headers. When user B sends a 200 OK response for it to the proxy P, the request contains only one Via header. I think it should contain the two via headers it received in the Bye Request. Please clarify.
11. Call Management - slide 8 - When the new Invite request is sent to the proxy P, I think it would be a new dialogue (because the request is formulated using the contact URI in the 3XX header field). However in the Invite request being sent, the Call-ID, and the To-tag are same as in the initial Invite. Please clarify.
13. In some of your call flow examples you had the UA indicate its host name (FQDN) in the Via field. Is that how it is supposed to be? Would the UA even know its host name?
14. In Call-forwarding
scenarios such your
Call Forwarding on Busy example
slide 11, the Proxy P sends an Invite to the
forwarded-to user Alice. In that case, the Request-URI addresses Alice,
right?
--- Answers to the SIP training related questions--- |
1. Why is CSeq kept same for all the SIP registration requests? One of the slides says that the CSeq field is used by the registrar to search for the records when registration is updated. However, the records in the registrar can be searched using the To: header of the new Registration request.
(Part 1) The registration flows show that cseq is NOT kept the same for the sequence of registrations by the same user. It is incremented by one each new registration. Indeed the SIP URI in the TO filed is used as a key for the bindings record of the user. Then Call-ID is used in conjunction with the Cseq value for correlation of particular registration update within a sequence. Please go back to any of the registration flows and read the elaborations of the Call-ID and CSeq fields (by following their hyper links).
(Part 2) Call-ID is the key
field, which uniquely identifies all registrations from the same client to the
same Registrar (at least within the same reboot cycle).
It works together with the CSeq field to help the Registrar process the
registration requests in the right order and make the appropriate updates to the
existing bindings. For instance, a client, A, sent a registration request with
call-ID=100 and CSeq=1, and then sent (right away) another contradicting
(overriding) registration request with call-ID=100 and CSeq=2. Say the Registrar
was busy processing requests from another client, B, and so when it is finally
available to process the requests from A, it notices both requests.
Based on the call-ID and the CSeq it would know it should process the one with
the CSeq=1 first and only then the one with CSeq=2. If the requests had
different call-IDs the Registrar wouldn't know which one to process first, since
the scope of CSeq is bound to a particular call-ID.
Another possible scenario could be as follows: The same client A has sent a
registration request with call-ID=100 and CSeq=3, and right away another
contradicting (overriding) registration request with call-ID=100 and CSeq=4.
Say the requests from the client have arrived at the Registrar out of order,
i.e. the one with the CSeq=4 has arrived first. The Registrar processes it. Then
when done (Registrars always process requests in atomic manner) it notices the
request with the CSeq=3 and the same call-ID.
Based on the call-ID and the CSeq number the Registrar would know it needs to
reject the request with the CSeq=3, since it has arrived out of order.
That definitely makes sense, since it reflects the client’s wish that always the
last request it sends (in a sequence of registration requests) would override
the ones that preceded it (no matter in what order they arrive at the
Registrar).
If there was no call-ID associated with the sequence of registration requests,
there would have been no means by which the Registrar could correlate the
requests and decide which one should override the others. Think about it!
2. SIP to SIP Direct Dialing - Slide 10 - In the Message 200 OK from, it is indicated that user B accepts the media format 0. Had it been capable of accepting both the media formats suggested by A (0 and 98), which media format be used in the session? (I think 0 because it is the preferred media format. Please confirm.) Which media format would be used if B preferred 98 to 0?
First we need to notice that the codec A uses to send media to B is independent of the codec used by B to send media to A. For example you can speak English to me and I can reply with Spanish. As long as you understand Spanish and I understand English (which is true only to a certain degree) we are fine. If B had indicated to A that it is capable of receiving both formats (codecs), It is a well behavior of A to try use the first one indicated by B, but it can still change this on the fly and B should be able to adopt. Note that RTP indicates the type of payload, so as to enable a receiving node decode the pay load on the fly and adjust to dynamic changes. (You can read more in RFC 3264).
3. SIP to SIP Direct Dialing - Slide 14 - User A sends a re-invite to add the video session. So the SDP version is modified from 2890844526 to2890844527. When the user B sends a 200 OK response to it in slide 16, the SDP session Id is also modified to 2890844527. Why is it so? (I guess it is a typo)
RFC 2327 (obsoleted by RFC 4566) says: "<sess-version> is a version number for this session description. Its usage is up to the creating tool, so long as <sess-version> is increased when a modification is made to the session data. Again, it is RECOMMENDED that an NTP format timestamp is used." Also please consult our elaboration on that field (as usual follow the link embedded in the call flow). So First you are right (but for a diff reason than the one you specified..). We do have a typo, and we have just corrected that. The value should be 2890844528 (and we have just corrected that. Thanks!) The idea is that each side is free to run its own sess-version regardless of what the other side chose. So B increments the <sess-version> in the 200 OK in slide 16 from what it was in the 200 OK in slide 10. In our example the sess-version of A and B are very close, not because B was forced to use A’s number, but simply because both used NTP to calculate the number. This is indeed diff than the correlation of values in the SIP header. For example in SIP both endpoints must use the same call-id, but in SDP each can use its own <sess-id> independently of the other.
4. If the user B is capable of only receiving the video and not sending it, will it also modify the sendrecv attribute for the video media format in the 200 OK response to recvonly? If the attribute sendrecv is not present specifically (because the default attribute is sendrecv), will it also insert the attribute?Yes and yes. See the standard excerpt below. RFC 3264 section 6.1 "If an offered media stream is listed as sendrecv (or if there is no direction attribute at the media or session level, in which case the stream is sendrecv by default), The corresponding stream in the answer MAY be marked as sendonly, recvonly, sendrecv, or inactive."
5. Invitation to Multicast conference - slide 6 - In the scenario described, only user A accepts the Invitation. If other users B and C alsoaccepted the invitation, would they also be able to participate in the conference?
Yes. In general every user who accepts a multicast invitation can participate in the session. In our particular scenario based on the SIP URI (in the Request-URI and TO fields) endpoints C and D decided to ignore the invitation, but if their logic had been to accept the call then nothing would have prevent them from responding with 200 Ok and participating in the session. To begin with they know the mcast address of the media. If they are (or become) members of this mcast group they will happily receive the RTP sent to that mcast group, and they can also send RTP to that address. (btw when you said A you really meant B right..?) Note the interesting point with D and E who learned about the session in whatever way (doesn’t have to be necessarily SIP) and thus can participate.
6. Call Hold - Slide 18 - In this scenario, the proxy P adds reconstructed header in the initial Invite request when it forwards it to user B and the 200 OK response for it when it forwards it to user A. When user B send a new Invite request to invoke call hold, it adds the route header field. When the proxy P forwards this request to User A, it again adds the record-route header field. Why does proxy P need to add the record route header field again (slide 18) when both the users are aware that the requests within the dialogue are to be routed through it using the Route header field?Such an excellent question. The proxy did not really have to do it. In our example it chose to do it in order not to count on the states being maintained at the end points. (For example endpoint may crash or just not well behave). This is an example for how SIP messages may contain state info, and by that making the protocol more robust (/recoverable). Note that the invitation examples in 3GPP 24.228 demonstrate the same idea. (e.g. TS 24.228 section 7.2.2.1)
7. Call Hold - slides 19, 20 - When the call hold is invoked by the user B it sends Invite request with attribute sendonly for the media. But in the 200 OK response for this Invite (in slides 19 and 20), attribute is changed to sendrecv. Why is it so?Again excellent question. Note our inline comment on that slide (19) next to the "a=sendrecv" field. We say there that the answerer does not have to change its original SDP and can still honor the oferrer’s request for not sending RTP. As slide 1 shows we wrote the example based on version 3 of the I-D service examples (Alan J. et al). This draft later on got updated per the new RFC 3264, which mandates the answerer to change the SDP to "a=recevonly". Very good catch. We still hesitant whether to modify this slide as if we did we would slightly deviate from our reference.
8. Unattended call transfer - slide 18 - The user B sends Invite request to user C with Supported: Refer-To and Refered-By. However, User B intends that user C should understand the fields Refer-To and Referred-By because user B will use these fields in the messages it sends. So I think it should have used the header field Require instead to Supported. (In my understanding, Supported header field is used by UAC or UAS to enumerate the headers it supports and Require header field is used by a UAC to enumerate the header fields it expects the UAS to understand) Please clarify.
First please note that Supported does not enumerate the headers, which the UA supports but it does enumerate the SIP extensions it supports. These extensions may come into play as headers, algorithms and entire RFCs, which include a whole bunch of messages, parameters etc. Second, for clarity perhaps we should have omitted that header in message 11 onward. We just dragged it from message #1. Its importance was in message #1 when B let A know it may refer him at a later time. Later when B uses this header again when it invites C, its use can only be to let C know it may refer B to D for example. No one of our students ever commented about this one, but if you think this may be confusing we may remove it (from messages #11 and above). Thanks!
9. Call Forwarding on Busy - Slide 11 - The slide says that the new Invite is a new call leg for P. But in the message the Call Id and the From-tag remain the same. So it is not a new call leg (dialogue)?
As the elaboration of the call-leg explains dialog is consisted of three elements: From tag, Call-id and To tag. So in slide 12 when the 180 comes back it has a new To tag hence the new dialog (call-leg).
10. Call Forwarding on Busy - Slide 21 - When Bye request is sent from Proxy P to user B it contains two Via headers. When user B sends a 200 OK response for it the proxy P, the request contains only one Via header. I think it should contain the two via headers it received in the Bye Request. Please clarify.Such a good catch! Thanks. Correction was made to the slide.
11. Call Management - slide 8 - When the new Invite request is sent to the proxy P, I think it would be a new dialogue (because the request is formulated using the contact URI in the 3XX header field). However in the Invite request being sent, the Call-ID, and the To-tag are same as in the initial Invite. Please clarify.12. SIP to PSTN ISUP dialing - My question is related to Cause Code Values that is used by TDM signaling ( ex ISUP, ANSI etc) and how SIP encodes it into its messages when it talks to these signaling schemes. For example, when SIP send 480 that can mean Cause code value 18,19,20 and 21 ( as per Q.1912.5). My question is where in the SIP message body I can see that Cause Code Value? The example I mentioned was related to ISUP, but I assume it will be valid for all TDM signaling scheme. Is there a document that can clearly spell that out?
First, RFC 3398 tables 7.2.4.1 shows a bit diff mapping. Pls check there. Still your question is valid for telling 19 from 20. Our idea. use 480 for both but use the respective text of 19,20 to explain the particular cause!
13. In some of your call flow examples you had the UA indicate its host name (FQDN) in the Via field. Is that how it is supposed to be? Would the UA even know its host name?
Good point! In most of the examples we had the UE indicate its IP address in the Via field (sent by parameter), as this is what we normally see in real life systems. However, for illustration purpose we did have some of the UAs indicate their host name there. Some UAs (e.g. PSTN Gateways) may indeed have an 'official' host name (FQDN) and may know it and use it.
14. In Call-forwarding scenarios such your Call Forwarding on Busy example slide 11, the Proxy P sends an Invite to the forwarded-to user Alice. In that case, the Request-URI addresses Alice, right?
Right on. When the intermediate node (stateful proxy) has more fine-tuned information about the exact destination (Alice's UA in this example) it has to reflect it in the Request-URI field.
© 2003-2010, SIPKnowledge.