[Q9] UAC has its INVITE transaction in the “Proceeding” state:

a) It should not retransmit the request even if T1 has expired. b) It should retransmit the request, only if T1 has expired. c) It should not retransmit the request only if it saw at least one 1xx response while in this state. d) None of the above is true.

[Q10] The TO header field in any SIP request:

a) Can be modified by proxies. b) Shall never be modified by proxies. c) Can be modified by proxies only if they are stateful. d) Can be modified by proxies only if they are super stateful (i.e. call stateful).

[Q11] A UAS has received a SIP request over UDP transport with a payload greater than zero, but with no length field:

a) It shall reject the request by returning a 400 (bad request) error code. b) It shall reject the request by returning a 413 (request entity too large) error code. c) It shall accept the request and shall assume the data to the end of the pkt to be a payload. d) None of the above is correct.

For questions Q12-Q14:

Let us define an external call as a SIP call between a SIP client, C1, and another SIP client, C2, such that there is at least one NAT between C1 and C2 (i.e. 1. C1 sits in a private IP domain and thus gets NATTed. 2. C1 and C2 are located in two different IP routable domains). Let us assume that the NAT/router or any other network element does NOT provide ALG/SBC functionality. In addition let's assume existence of a SIP registrar, R. R sits beyond the NAT. C1 registers with R every interval X. X is short enough so as to keep the NAT pinhole open. Let us also assume that the client is configured to send RTP comfort noise during silent periods (i.e. Silence Suppression is off). This starts from the moment the client knows the media address/characteristics of the other endpoint.

[Q12] A SIP client, which supports STUN, sits behind a Full cone NAT. It is provisioned with an IP address of a STUN server:

a) It can not make or receive external calls. b) It can not make outgoing external calls, but may still be able to receive incoming external calls though. c) It can not receive incoming external calls, but may still be able to make outgoing external calls though. d) It can both make and receive external calls.

[Q13] A SIP client, which supports STUN, sits behind a Restricted cone NAT. It is provisioned with a host name (FQDN) of a STUN server and IP address of a DNS server.:

a) In that case STUN/DNS servers are sadly both not accessible for that client, thus It can not make or receive external calls. b) It can not make outgoing external calls, but may still be able to receive incoming external calls though. c) It can not receive incoming external calls, but may still be able to make outgoing external calls though. d) It can both make and receive external calls.

[Q14] A SIP client, which supports STUN, sits behind a Symmetric NAT. It is provisioned with the IP address of a STUN server:

a) It can not make or receive external calls. b) It can not make outgoing external calls, but may still be able to receive incoming external calls though. c) It can not receive incoming external calls, but may still be able to make outgoing external calls though. d) It can both make and receive external calls.

Now, Let us assume that the NAT/router still does NOT provide ALG/SBC functionality, but there is an SBC element sitting beyond the NAT. The SIP client is provisioned with the IP address of the SBC, and is configured to use it as its SIP outbound proxy. Let us also still assume that the client is configured to send RTP comfort noise during silent periods (i.e. Silence Suppression is off):

[Q15] A SIP client, which does not support STUN, sits behind a Symmetric NAT:

a) It can not make or receive external calls. b) It can not make outgoing external calls, but may still be able to receive incoming external calls though. c) It can not receive incoming external calls, but may still be able to make outgoing external calls though. d) It can both make and receive external calls.

[Q16] During the SDP exchange phase a SIP client wishes to define the RTP packetization to be used:

a) It can do so via the ptime/maxptime directives, but only on a session level (i.e. same packetization for ALL streams). b) It can do so via the ptime/maxptime directives. It can be done independently for each stream (i.e. not all streams are bound to the same value). c) No, this can not be done, since a codec already well defines the packetization it uses. d) It can do so, except for the G.723/G.729, which do not have packetization flexibility, but always use ptime=20msec.

[Q17] Which of the following statements is the correct one?

a) T.38 is the real-time FAX over IP protocol. It may be used for carrying Voice as well. b) T.38 can be used between IP-FAX endpoint and a regular fax (via gateway). c) It is impossible to transmit FAX over IP using "normal" Voice codecs. d) None of the above is true.

[Q18] Which one (and only one) of the following is a correct statement?

a) SRTP is a security profile for RTP. Sadly it can not be used by SIP elements due to lack of support in SDP. b) SRTP can be used to add security for RTP, but not for RTCP packets. c) SRTP resides between the transport layer and the RTP one. d) Since SRTP is implemented as a "bump in the stack" it can not be used in conjunction with header compression. e) None of the above is correct.

[Q19] SIP client MAY be SIP-authenticated (i.e. by using the authentication mechanism described in RFC 3261) by a 3261-compliant-server (hence needs to be ready to provide credentials) during:

a) First time registration only. b) First time and any following registration. c) Any registration and any invitation, but not for non-register or non-dialog requests such as OPTIONS. d) Any SIP request in the outgoing direction, but not for incoming requests (if they called me they must know what they were doing...). e) Any SIP request in any direction (i.e. both outgoing and incoming).

Skipped...