Undocumented Features of the Nokia SIP Stack
1. Incoming INVITE routing logic
Nokia Internet Telephony client is present in the S60 device and its SIP capabilities in the XML are the following:
<SIP_CLIENT ALLOW_STARTING="YES">
<SIP_HEADERS>
<ACCEPT value="application/sdp"/>
<ACCEPT value="\"/>
</SIP_HEADERS>
<SDP_LINES>
<LINE name="m" value="video 0 RTP/AVP 0"/>
<LINE name="m" value="application 0 tcp wb"/>
<LINE name="m" value="audio 0 RTP/AVP 0"/>
<LINE name="m" value="audio 0 RTP/SAVP 0"/>
</SDP_LINES>
</SIP_CLIENT>
If the incoming SIP request (for example INVITE) contains this information, Nokia Internet Telephony client always gets the SIP request. The reason is that ROM-based clients are preferred
when two or more clients match to the request. Other clients must use some distinctive values like the following:
1) Accept-Contact-header with some special feature tags like
Accept-Contact: *;+myfeaturetag
expressed in XML as
<ACCEPT_CONTACT value="*;+myfeaturetag"/>
2) Adding application spesific m-lines like
"m=application 12345 UDP myapplication"
expressed in XML as
<LINE name="m" value="application 0 UDP myapplication"/>
3) Application specific attributes for existing m-lines like
"m=audio 12345 RTP/AVP 0
a=myapplication"
expressed in XML as
<LINE name="m" value="audio 0 RTP/AVP 0">
<MEDIA_ATTRIBUTE value="myapplication"/>
</LINE>
4. Configuring SIP profile for IMS
This is applicable for the S60 3.1 and later platform releases.
Service profile: Nokia 3GPP
Default access point: <xxx>
Use compression: No
Security negotoation: Not active
Proxy address: <x.x.x.x>'
0.0.0.0 in the Proxy address field indicates that proxy will be resolved using dynamic methods. (DHCP or PCO element)
If the phone supports IMS AKA and contains USIM and ISIM applications REGISTER request with authentication header will be sent out from the terminal as per 3GPP TS 24.229. In case device contains only SIM application the registration will be performed as per TR 33.978 (early IMS) e.g. REGISTER request will not include Authorization header nor other security related headers.
5. SIP profile registration failure recovery
When the registration recovery is ongoing, the SIP profile shows "Not registered".
If also the registration recovery has failed, the SIP profile shows "Registration failed".
There are different recovery procedures for 'IETF' and 'Nokia 3GPP' modes.
IETF:
The terminal tries to recover from the following registration errors:
DNS failure, ICMP error, SIP transaction timeout, 503 SIP response.
Recovery procedures:
To recover from a registration failure, the terminal maintains a wait-time value for determining when it should try to register again. Wait-time value in seconds is calculated as follows:
wait-time = min( 1800, (30 * (2 ^ consecutive-failures)))
The delay time between two successive registration attempts is computed by selecting a uniform random time between 50 and 100 percent of the the wait time. If 10 successive attempts fail no further attempts are made.
Nokia 3GPP:
The terminal tries to recover from the following registration errors:
DNS failure, ICMP error, SIP transaction timeout and 408, 480, 500, 503 and 504 SIP responses.
Recovery procedures:
If the registration failure was caused by one of the SIP responses, terminal checks the presence of Retry-After-header and tries to register after the value indicated in the header. In all other cases the registration is tried again immediately. The registration recovery is tried only once.
See attachement for the routing of invite messages



