[sip-comm-dev] [PATCH] fix for handling charset in SIP MESSAGE messages


#1

Hi all,

I am currently using/testing the SIP SIMPLE capabilities of
SipCommunicator and the interaction with other SIP IM clients. I came
across a couple of problems that SC has when dealing with other SIP
clients. The following is a description of one of these problems on
which I have investigated and a suggestion for solving this issue.

SC currently isn't able to display incoming instant messages (SIP
MESSAGE method) coming from other clients - at least not from the ones I
tested, i.e. Ekiga, Pidgin, X-Lite, and WengoPhone. This is due to 1) a
wrong usage of a header field in the SIP messages and 2) a bug in the
code. In detail:

The MESSAGE requests sent by SC include a Content-Encoding header with
UTF-8 as value. However, the Content-Encoding header is not supposed to
contain the charset for text content, but rather information about
(possible) compression of the body content (see RFC 3261, section
7.4.1). If a charset other than the default (which is UTF-8) has to be
provided, this should instead be included as part of the Content-Type
header, such as
  Content-Type: text/plain;charset=ISO-8859-1
Moreover, the Content-Encoding header MUST be omitted according to RFC
3261 if no additional encoding such as compression is applied to the
message body.

Currently, outgoing messages from SC can be understood by other clients,
for these clients most likely ignore the Content-Encoding header and
assume the default charset UTF-8 anyway. Incoming messages from other
clients (the ones I tried) on the other hand are not processed properly
in SC, because a NullPointerException is thrown if no Content-Encoding
header is present in the MESSAGE requests.

To fix this problem, the SIP IM processing of SC should be adapted such
that:
1) the usage of the Content-Encoding header to define/look for the
charset in outoing/incoming MESSAGE requests is removed and
2) the Content-Type header is used for this instead (for outgoing text
messages only if the charset is not the default UTF-8)

Attached you find a patch for
net.java.sip.communicator.impl.protocol.sip.OperationSetBasicInstantMess
agingSipImpl.java
which should realize these changes (created with Tortoise SVN).

Note that when this patch is applied, SC clients without the patch will
no longer be able to receive messages from patched versions of SC, since
the Content-Encoding header field will be missing, causing the NPE as
described above.

So much for now, more to come :wink:
Cheers,
Ralph Weires

sip-MESSAGE-charset-handling.patch (3.53 KB)

···

###########################################
CONFIDENTIALITY: This e-mail and any attachments are confidential and may also be privileged.
If you are not the designated recipient, please notify the sender immediately by reply e-mail and destroy all copies (digital and paper).
Any unauthorized disclosure, distribution, copying, storage or use of the information contained in this e-mail or any attachments is strictly prohibited and may be unlawful.


#2

Hi Ralph,

Thank you for your great catch/fix ! There was effectively an ugly bug here, your patch perfectly corrected it.

I commited and ack-ed your contribution,

Thanks again,
Ben

ralph.weires@hitec.lu a �crit :

···

Hi all,

I am currently using/testing the SIP SIMPLE capabilities of
SipCommunicator and the interaction with other SIP IM clients. I came
across a couple of problems that SC has when dealing with other SIP
clients. The following is a description of one of these problems on
which I have investigated and a suggestion for solving this issue.
SC currently isn't able to display incoming instant messages (SIP
MESSAGE method) coming from other clients - at least not from the ones I
tested, i.e. Ekiga, Pidgin, X-Lite, and WengoPhone. This is due to 1) a
wrong usage of a header field in the SIP messages and 2) a bug in the
code. In detail:

The MESSAGE requests sent by SC include a Content-Encoding header with
UTF-8 as value. However, the Content-Encoding header is not supposed to
contain the charset for text content, but rather information about
(possible) compression of the body content (see RFC 3261, section
7.4.1). If a charset other than the default (which is UTF-8) has to be
provided, this should instead be included as part of the Content-Type
header, such as
  Content-Type: text/plain;charset=ISO-8859-1
Moreover, the Content-Encoding header MUST be omitted according to RFC
3261 if no additional encoding such as compression is applied to the
message body.

Currently, outgoing messages from SC can be understood by other clients,
for these clients most likely ignore the Content-Encoding header and
assume the default charset UTF-8 anyway. Incoming messages from other
clients (the ones I tried) on the other hand are not processed properly
in SC, because a NullPointerException is thrown if no Content-Encoding
header is present in the MESSAGE requests.

To fix this problem, the SIP IM processing of SC should be adapted such
that:
1) the usage of the Content-Encoding header to define/look for the
charset in outoing/incoming MESSAGE requests is removed and
2) the Content-Type header is used for this instead (for outgoing text
messages only if the charset is not the default UTF-8)

Attached you find a patch for
net.java.sip.communicator.impl.protocol.sip.OperationSetBasicInstantMess
agingSipImpl.java which should realize these changes (created with Tortoise SVN).

Note that when this patch is applied, SC clients without the patch will
no longer be able to receive messages from patched versions of SC, since
the Content-Encoding header field will be missing, causing the NPE as
described above.

So much for now, more to come :wink:
Cheers,
Ralph Weires

###########################################
CONFIDENTIALITY: This e-mail and any attachments are confidential and may also be privileged.
If you are not the designated recipient, please notify the sender immediately by reply e-mail and destroy all copies (digital and paper).
Any unauthorized disclosure, distribution, copying, storage or use of the information contained in this e-mail or any attachments is strictly prohibited and may be unlawful.
------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net