The S60 Implementation uses SIP profiles to access different SIP networks and servers. This includes IMS and IETF SIP access. SIP profiles can have a different Internet Access Point (IAP), IP-address, and home-domain address. If a MIDlet is using the SIP profile, the IAP defined in the profile is used.
If a MIDlet is to use the profile as registration context in the request,
it can set the ‘From’ header to the request, which has to be equal with the
value of the ‘To’ header of the profile (Public username field
in the SIP Settings Tool).
A MIDlet does not have to set the ‘Contact’ header in this situation.
The S60 implementation generates the value of the ‘Contact’ header from the
value of ‘From’ header. A MIDlet does not have to pass the SipConnectionNotifier object
as an argument to the initRequest() operation.
The S60 implementation does not generate the ‘Contact’ header if a MIDlet sets it by itself to the request. “Default profile” is used as the registration context if a MIDlet does not set the ‘From’ header at all to the request.
“Default profile” is a single profile, that the user has chosen in the SIP Settings Tool to be used in these kinds of situations, where no other registration context is given by a MIDlet to the S60 implementation.
SIP Settings Tool can contain multiple profiles with same value of the ‘To’ header. This approach can be used if e.g. the user desires to use separate profiles for different access points. I.e. one profile uses WLAN and another profile uses GPRS access point. The S60 implementation uses the following logic (in the SipConnection.send() operation) to choose a profile in that situation:
The “default profile” is used if the MIDlet has not set the “From” header to the request.
S60 implementation asks the user to choose one profile (dialog contains names of profiles) in the situation where MIDlet has set the “From” header to the request and it matches multiple profiles.
Note: The dialog is also shown to the user even if one of the profiles is the default profile. S60 implementation throws an IOException if the user selects the cancel option of the dialog.
The Accept-Contact header in the example is needed for the receiving side.
This example code uses default profile as registration context. Appendix 1 includes an example code where a MIDlet’s own registration is used as registration context.
SipClientConnection scc = ( SipClientConnection ) Connector.open("sip:[email protected]:5070"); scc.initRequest("INVITE", null); scc.setHeader( "Accept-Contact", "*;type=\"application/test\"" ); scc.addHeader( "From", "sip:[email protected]"); scc.send();
The example code above generates following sip request:
INVITE sip:[email protected]:5070 SIP/2.0 Via: SIP/2.0/UDP 174.22.99.137:5060;branch=z9hG4bKf27db71i05hc6th3goiun2c From: sip:[email protected];tag=d1mtb76sqlhc65k4goim To: sip:[email protected] Contact: sip:[email protected] Accept-Contact: *;type="application/test" CSeq: 1535 INVITE Call-ID: 8XHlD8pToIcoVEoBrjuj11lChzdnEE Max-Forwards: 70