SIPKnowledge (SIP Knowledge) - FAQ - IP basics questions and answers

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!

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).

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)

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.

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."

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?

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.

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)

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.

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!

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).

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.

This is not really a new dialog, as the definition of dialog per RFC 3261 section 5 is as follows: "A dialog is a peer-to-peer SIP relationship between two user agents that persists for some time". I.e. the dialog is between the endpoints, rather then between endpoint and a proxy. Note that in question 9 we had a new dialog when the proxy retries B2, because one of the endpoint has changed (B2 instead of B1).

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!

--- Triggered by the SIP RFC 3261 Clarifier/Navigator tool ---

That's exactly the purpose of both the Call-ID and the From tag to tell two call instances from one another on the calling device. Pls go back to any of our Invite related call flows and browse both the Call-ID and From Tag elaborations by clicking on the linked text. Re-invites from the called endpoint will use the info in the original Contact header as the target, and will swap the values of the from tag and to tag! Go back please to the direct Invite example and see how that happens when B Byes A. (Btw, we were missing the To Tag in the Re-invite (A to B) we added it; This however not the case you were looking for)

Who decides the policy (serial search depending upon the q values or parallel search) for various entries returned by the location service?

It is totally at the discrete of the implementation and the service represented by it!

Why does the dialogues not get established by the CALL-ID, TO-tag and FROM-tag in OPTIONS method? As per RFC dialogue is only established by INVITE method.

The reason is that OPTIONS was meant to be used as a standalone out-of-dialog query-response method. As Opposed to INVITE, which is expected to open a dialog, which is to remain open as long as RTP is flowing.

This action is again at the discrete of the registrar application. Keeping the empty entry might save a new creation of the entry when/if there is a new registration of that user. This comes however at the expense of efficient use of memory resources.

If a User agent is configured with an outbound proxy, is it required to add the Route header with the value equal to the its hostname or IP address when sending a request?

Yes. Based on section 12.2.1.1 the endpoint must place the SIP URI, which contains the IP addr or FQDN of the outbound proxy in a Route header. This may look like a useless info for the outbound proxy. However it was mandated to comply with the proxy rules of 16.4. It is true that based on the way 16.4 is written ("If the first value in the Route header field indicates this proxy, the proxy MUST remove that value from the request.") the outbound proxy is not expected to get over excited if Route header is not present.

page 39 - 8.1.1.2 - "As an example, a user in an airport might log in and send requests through an outbound proxy in the airport. ....." In the
example I think it is assumed that the user is using a public PC. If it were using his own device, that device outbound proxy on that device would be configured as a proxy in his home network. Please comment.

Good point. However even when you use your own soft/hard SIP phone it may decide to override the configured outbound proxy if it gets an IP/FQDN of a local outbound proxy via DHCP (RFC 3361).

8.1.1.3 - Is it not possible for a user to configure his From header field to a fake value?

Good point. From spoofing is possible in SIP just like it is possible (and often used) with email. There are special RFCs (e.g. 3323, 3325), which discuss this issue in a great detail and attempt to provide solution via authentication and trust domains.

According 3261 16.3 Max-Forwards check takes first first. In our minds this is a double-verification mechanism for loop situations. Even that in theory one can claim that reaching max-forwards situation still doesn't necessarily mean loop.. Practically in our minds this is loop, and btw we believe the value 70 is way too high.

Yes. There was a big argument over it in IETF. In RFC 2543 this was still limited to the same dialog. Only in 3261 this got enhanced beyond the current dialog. People realized that this was more realistic even if not bullet proof.

Page 43 - 8.1.1.8 follow up - In your answer you said that RFC 3261 enables caching the contact info (also) for future dialogs - How do current implementation go about that? Also, how long is the conatct cached for?

In most of the existing SIP networks this caching does not really come into play, as they are not peer to peer, but there is usually a network in between the
endpoints. It is basically a contradiction to the registrar idea. Endpoints might be in IP private domains having time-limited reachable addresses. On top of it IP
addresses nowadays have typically dynamic nature; thus this sip capability does not seem very practical.

Not really. The standard wants the UA to use outbound proxy if one is configured. But this is provided there is no Route header present. So basically the standard tries to distinguish a first request in a dialog from the subsequent ones. For the first one the outbound proxy shall be used as you do not expect to have Route hdr present, while for subsequent requests you may have Route present due to Record-Routing performed by some of the proxies. You can regard this is priority mechanism. I.e. Route is prioritized over outbound proxy.

8.2.2 - I am not able to understand how the merged requests are detected. Can you please explain it to me in a little easier way.

Think about a CANCEL sent 3 seconds after an INVITE was sent. The UAC wants the UAS to realize that the INVITE is not valid any more. This is a good situation of two requests belong to the same transaction. Now if there was one INVITE after another without any final response in between this would be some kind of a loop, as the same request should NOT be sent twice within the same transaction. The rest (see 17.2.3) are just the rules how to compare the first request to the second in order to realize what case out of the two above is at hand.

8.2.3 - "If there are any bodies whose type (indicated by the Content-Type), language (indicated by the Content-Language) or encoding (indicated by the Content-Encoding) are not understood, and that body part is not optional (as indicated by the Content-Disposition header field), the UAS MUST reject the request with a 415 (Unsupported Media Type) response." If the body part is optional, how should it be treated? Should it be ignored?

In general Yes. But this is indeed at the discretion of the implementation. If for example the body contains picture of the caller and the UAS insists of using this is as a security mechanism for the callee to identify the caller (before accepting the call), and say something went wrong with its format (or perhaps some unknown file format is used) then even if the UAC did not mark the payload as mandatory, still the UAS may choose to reject.

8.2.6.2 - "If a request contained a To tag in the request, the To header field in the response MUST equal that of the request. " In what circumstances?

This tag match happens when the UAS returned already 180 or 200. Now if a subsequent request contains the tag it means the request was sent to the particular UAS instance, which created that tag. Think about forking case!

This is correct. Call-id is the key identifier of a media session. This is true not only when the session is active, but also off line. For example it is used as one of
the key identifiers of billing records, call logs etc Thus to avoid "record collisions" its uniqueness over both time and space is important.

Are there any other methods specified in the standard-tracks, which can initiate a dialogue?

Yes, the SUBSCRIBE method. See RFC 3265.

Page 82 - "If the remote sequence number is empty, it MUST be set to the value of the sequence number in the CSeq header field value in the request..." - In what conditions will the remote sequence number be empty? remote sequence number would have been set to the integer in CSeq header field in the previous request.

The RFC just attempts to cover all possible cases. In the normal realistic case the remote sequence number would have been set to the integer in CSeq header field in the previous request + 1. Empty CSeq shouldn't really happen and shows some state error on the sending side. SIP tries to demonstrate recoverability here, but again we do not see such a case/condition as a common one.

There is no contradiction, as page 87 does not say BYE needs to be sent by the caller only for confirmed dialogs. It only addresses the special condition in which a 2XX was sent but is not acceptable (for example the callee can not support the video stream of an offer), and instructs the UAC to first ACK the 2XX, in order to avoid re-transmission of the 2XX and bring the dialog to a "healthy" state on the UAS side; then terminate it. Note that this condition entirely falls under the umbrella of confirmed dialogs. This has nothing to do with early dialog cases, which are not discussed in that section of page 87.

Does BYE not require an SDP body which would close the session?

No. Why would you want to send SDP in a BYE...? If you did what would the UAS do with that...?

The proxy will select 40X responses based on its app logic. A simple logic for example would be aggregating the 401 and 407 responses, which were received from forked destinations within a certain time limit. As you can see the RFC leaves this pretty open.
Yes - 401 response can accommodate Proxy-Authenticate header field of 407 and vice-versa. See Table 2 in section 20 of the RFC, which details the requests and responses within which any SIP header may be used (hint: Lookup the WWW-Authenticate and Proxy-Authenticate headers...).

No contradiction. Think about who is going to use the RR (Record Route). In page 104 (Request processing) the RR will be used by the callee to set its route set! In page 113 it will be used by the caller to set its route set. Note that these two route sets would include the same elements, but in the reverse direction.
When you come from the reverse direction the transport you use may differ as the next downstream and upstream elements are differ. As a simple exercise take a look at the example in 16.12.1. The path from caller to callee is U1-P1-P2-U2, but from callee to caller it is U2-P2-P1-U1. Now let's say that secure transport (TLS) needs to be used only on the leg between U2 and P2. In the request processing (page 104) P2 would set RR to SIPS, as it knows it is to be used/consumed by U2 for subsequent requests on that dialog. However on the response direction (page 113) P2 would set RR to SI, as it knows it is to be used by U1 for subsequent requests on that dialog. Recall that in U1 to U2 direction P2 is to be approached (i.e. receives the request directly) from P1, while in the direction of U2 to U1 P2 is to receive requests directly from U2. Think about it!

Your assumption is correct. ACK for final responses, which are not 2XX, is done by the INVITE transaction, as opposed to ACK for 2XX response, which is done by the UA core. Also please note that ACK for 3XX-6xx are hop by hop, while ACK for 2XX are end to end, i.e. must be generated by the calling endpoint (as opposed to client side of mid chain proxy). The idea behind it is the significance of ACKing the 2XX (e.g. billing can start, media resources need to be allocated etc) hence making sure the core logic of the calling endpoint is aware of the call acceptance, and has confirmed that to the callee endpoint.

Since Timer C is started by Transaction Users, is the timer C also used in UAs and reset at the receipt of provisional response?

Timer C is a special one. It is only used by client side of proxies. Its purpose is to serve as a 'master timer' for stateful proxy, which may have forked, hence helping it to make dynamic decisions on the potential set of transactions created by it. The key timers which are correlated between client and server side of INVITE transaction are B and H (giving up on the transaction respectively). There is NO equivalent for timer C on the server side.

Basically Chicken and egg situation. Back then it was decided that for clarity purpose it is better to leave it as is in 3261 (which preceded 3262) and "fix" it in
3262.

First, there is no guarantee that the guideline is going to be followed by any UAS in the market. Second, the provisional response might be 100 returned by the next hop (e.g. proxy). Recall that 100 responses are hop by hop ones.

Page 145 - "If there is a match, the response MUST be passed to that transaction. Otherwise, the response MUST be passed to the core (whether it be stateless proxy, stateful proxy, or UA) for further processing. Handling of these "stray" responses is dependent on the core (a proxy will forward them, while a UA will discard, for example)." Why would the client discard the response? In case of 200 response received for a forked request, the client would have to process it.

Good catch. Absolutely agree. UAC, which, can exchange media with multiple UAS in parallel, should pass the 2XX to the core. See our Forking Proxy example, in which Sherlock talks at the same time to both Ann and Watson. The RFC says "for example" though, so one may conclude that the authors were
referring to a simple UAC, which is either capable or configured to exchange media only with a single user at a given time.

Good catch. Absolutely agree. In the example in RFC 3665 the UAC assumed its ACK will not get rejected by the proxy, even it does not include the credentials. In reality this may work or this may not work. Depends on the proxy security policy. As a rule sometimes in the call flow examples Alan J. et al wanted to simplify some of the things, in order to focus on some other characteristics of the particular call flow.

Well, exact same answer as A6...:-) We will repeat it here for your convenience: The proxy will select 40X responses based on its app logic. A simple logic for
example would be aggregating the 401 and 407 responses, which were received from forked destinations within a certain time limit. As you can see the RFC leaves this pretty open.
Yes - 401 response can accommodate Proxy-Authenticate header field of 407 and vice-versa. See Table 2 in section 20 of the RFC, which details the requests and responses within which any SIP header may be used (hint: Lookup the WWW-Authenticate and Proxy-Authenticate headers...).
Pay extra attention to as whether the particular field is optional or mandatory! For example in 407 response to an INVITE request the Proxy-Authenticate header is mandatory (because 407 is supposed to be generated by proxies and not by endpoints), while WWW-Authenticate is optional. The inverse is true for 401. Think about it!

Page 80 - Third Paragraph - "As discussed in Section 12.2.2, a Contact header field in a target refresh request updates the remote target URI. This allows a UA to provide a new contact address, should its address change during the duration of the dialog." - Can you please elaborate?

Think about a simple case of endpoints A and B talking to each other. Now the IP address of one of them gets changed mid session because of expiration of DHCP lease. re-invite (or UPDATE) provides that endpoint to let the other endpoint about that change. The Contact header of the Re-invite will contain the new IP address for signaling, while the SDP can reflect the address change for the media (in the common case when the same address is used for both media and sig)

It is indeed a bit unfortunate the way 3261 17.1.1.2 is written. It seems that the diff between the calling and proceeding states should be just the elimination of the need to retransmit the INVITE (over unreliable transport)(since receiving 1xx indicates that the INVITE reached its destination (or at least the retransmission is taken care of by statefull proxy (which is why they do not allow stateless proxy to return 100))). The problem is that according the RFC the transaction-timer B (i.e. when you should give up on waiting for a final response) seems to be active only when you are in the initial state (Calling). We believe that developers of SIP stacks should continue to guard timer-B also when in the proceeding state (otherwise we end up with what you have described).