Q&A Triggered by the SIP Illustrated course and 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).