N95 SIP registration failed

[FRLinux]

Hello,

I have been toying with the N95 for about a week and the nokia SIP client might be slightly not RFC compliant according to my findings. I am trying to register with a SIP provider here in Ireland and it always fails to register with a simple message going : Registration Failed.

The problem seems to be lying in the Contact header, it seems that the phone might be expecting it to be identical to what it sends which clearly isn't SIP standard.

So that brings me to the following questions :

- Is anyone aware of this issue ?
- Is there a firmware lined up ?

Cheers,
Steph

[franco_m]

Could you give us more details please?

1) Are you manually entering the settings and what are they.
2) Who is the provider and do you know what SIP server they're using.
3) What is the handset reporting when you attempt to register.
4) Have you made sure the access point you are using is configured and working properly (e.g. by web browsing).

[nly]

According to Nokia's interpretation of the RFC3261, the UAC performing the registration has to validate that the own contact is found in the 200 OK response - instead of listing only other SIP UAs using the same AOR.

Also the registration expires time - carried in the Contact URI parameter needs to be extracted and the detecting the own contact is needed for this. The expires time may be shortened by the registrar.

If the registrar overwrites the Contact URI with detected public address or even with its own address, the above operation fails.

Because this RFC violation has been detected to be relatively common, we added a fallback function which helps in many cases. Many SIP servers insert the detected public address in the Contact and S60 VoIP clients accept also that - if the same address and port can be seen in the Via header's received:rport parameters. So if the SIP proxy supports RFC3581, a modified contact is accepted.

Another way is to provision the S60 VoIP client to use STUN server (if the NAT type is is compatible with STUN). Then the UAC will populate the public address into the Contact - and that is hopefully not altered by the registrar.

[aaronc]

Hi,

I work for one provider that had a problem getting the Nokia devices registered initially. We use our own in-house registrar so were able to make some code changes to send back the Contact header unmodified once we worked out thats what the problem was. I can understand the reasoning for parsing the Contact header like that but it was strange that it seemed the same logic was applying to incoming calls. By rejecting them unless the invite URI matched what the initial Contact header meant incoming calls were impossible from a lot of commercial SIP servers. There are not too many SIP servers that send calls by putting the Contact URI in a Route header and leaving the request URI as the private address.

In regards to the Contact URI dilemna there are two commonly accepted methods I've seen to process the returned Contact AOR:

1. The AOR in the Contact header is essentially ignored if the AOR record is not recognised and the Expires header is used or failing that some default value. This is definitely preferrable to rejecting the register response outright since the Nokia SIP stack does not allow outgoing calls unless it is registered,

2. The ideal approach is to put a identifying tag into the Contact header along with the AOR. SIP registrar servers are unlikely to mess with the tag since it's meaningless to them and it therefore provides a clean simple way to identify the return AOR. The xten softphone works like this and uses ftag as the tag name.

Regards,

Aaron

[seanwg]

Because this RFC violation has been detected to be relatively common, we added a fallback function which helps in many cases. Many SIP servers insert the detected public address in the Contact and S60 VoIP clients accept also that - if the same address and port can be seen in the Via header's received:rport parameters. So if the SIP proxy supports RFC3581, a modified contact is accepted.

Another way is to provision the S60 VoIP client to use STUN server (if the NAT type is is compatible with STUN). Then the UAC will populate the public address into the Contact - and that is hopefully not altered by the registrar.

Right now the VoIP client on the E65 seems to always include a Via Header with the internal IP & port of the phone.

Is it possible to change the Via header to indicate use the detected STUN External IP & Port instead of the internal IP? This would FIX allot of problems with sip servers. Not sure where it fits in with the RFCs, but most of the softphones/hard phones use this for nat.. or at least have an option to enable this.


Sean

[aaronc]

Right now the VoIP client on the E65 seems to always include a Via Header with the internal IP & port of the phone.

Is it possible to change the Via header to indicate use the detected STUN External IP & Port instead of the internal IP? This would FIX allot of problems with sip servers. Not sure where it fits in with the RFCs, but most of the softphones/hard phones use this for nat.. or at least have an option to enable this.

Hi Sean,

It's quite common for devices to use their local IP address and port in the Via header and there is an extension to the SIP RFC to deal with this. When a SIP proxy receives a request it will set the "received" and "rport" parameters on the Via header if the socket the request was received on is different from the socket indicated.

I'd be surpised if the Via header being set by your E65 is causing your SIP server any problems and certainly I never noticed any issues in this regard when doing some work to get the E60 to work with a SIP server I use.

Instead of the Via header I suspect your problem will be with the Contact header. The SIP stack in the E61 I tested does require the Contact header to be sent back with the contact URI unmodified. As a lot of SIP registrars will substitute the socket the REGISTER request was received on with the value in the contact URI - in a similar manner to the Via header - the Nokia SIP phones will be unable to register.

Hth,

Aaron

[aaronc]

Because this RFC violation has been detected to be relatively common, we added a fallback function which helps in many cases. Many SIP servers insert the detected public address in the Contact and S60 VoIP clients accept also that - if the same address and port can be seen in the Via header's received:rport parameters. So if the SIP proxy supports RFC3581, a modified contact is accepted.hopefully not altered by the registrar.

Hi Nly,

I think your post should read:

"Because the violation of Nokia's interpretation of RFC 3261 has been detected to be relatively common...."

I've scoured the RFC a few times and cannot find anywhere it mandates that the Contact header URI must not be modified. The RFC does turn up directives in strange places though so if I'm wrong and you do know of such a section I'll happily eat some humble pie .

Regards,

Aaron

[bkkiran17]

Hi All,

I was trying to register to my IMS network through Nokia N95 using the UMTS access network and I find that the N95 is adding the Transport port type and Port number in the request URI of the SIP Register message.

Can anybody tell me if this is a bug within the N95 SIP client.

Thanks in advance,
Kiran.

[anklemet]

Hi bkkiran17.

Why do you assume there is a bug in N95 SIP client?
According to RFC 3261, the Request-URI can have explicit transport-parameter and explicit port.

You can change the port and transport as follows:
1) Go to Tools -> Settings -> Connection -> SIP settings.
2) Select the SIP profile that you are using
3) Go to Registrar server settings
4) Port can be set using field Port.
If set to 5060, there won't be an explicit port in the Request-URI.
5) Transport can be set using field Transport.
Auto: SIP client will use DNS to resolve the transport protocol
if the registrar address is a domain name (not an IP address)
UDP: Parameter transport=UDP will appear in Request-URI and
UDP is used for sending the REGISTER.
TCP: Parameter transport=TCP will appear in Request-URI and
TCP is used for sending the REGISTER.

Note that if you configure also Proxy server settings to the SIP profile,
the proxy will be the so called next-hop for REGISTER
and the REGISTER will be sent to the port and transport configured
in the Proxy server settings.

Also be prepared for SIP registration problems if you change these settings
without knowing their meaning and without knowing what your operator requires.