Content-Type check for incoming SIP MESSAGE

[jmillan]

Enhance the content type check for incoming SIP MESSAGES. Nowadays only an exact "text/plain" value is allowed, but not media type parameters.

Also, respond a (415 Unsupported Media Type) if received content is not "text/plain"

[saghul]

We should deliver all messages to the app. Then the user decides. Now, as for replying 415, we have 2 choices (from the top of my head):

• Don't reply in the library, let the user to it (accept() and reject(code) methods)
• Have a way to configure which are the acceptable types in the UA

I like the first approach because it's more flexible and allows for extra checks like the wrapped content type in case CPIM is used.

[ibc]

It's like we receive an INVITE and "deliver it to the application on top of OverSIP", leaving the user to deal with WebRTC stuff, IMHO it makes no sense.

JsSIP is a SIP stack and thus must provide a usable API for common tasks as receiving a text message, without forcing the end user (web developer) to deal with Content-Type value.

BTW:

• If the user defines a function (or functions) for event newMessage (in UA) then execute it and don't reply automatically 200.
• If not, the JsSIP must reply "something" (maybe 404 since the user does not want to receive MESSAGE requests).

[ibc]

BTW this requires a new API for incomming MESSAGES. But a easy API which means don't pass (always) the full body to the high user (imagine passing the "iscomposing" XML body... no please). Anyhow let's discuss such a new API in a new issue (not for 0.2 branch).

[saghul]

Please define "text message". It could de anything. text/plain, text/html, text/base64 (not sure if it exists bu anyway). And the best one: message/cpim, which contains a wrapped content type.

JsSIP is a SIP stack, not an IM client.

Yes, we need to pass the iscomposing body to the user. BUT, we can build another API on top of this, which just deals with IM, so it's hidden and only available to those who really want to.

[ibc]

If defining what a "text message" is is so hard then we have chosen the wrong protocol ;)

Not 100% sure, but IMHO it would make sense some API that calls a function by passing the "body" of the message and some other parameter "type" which could be "text", "html" or "other".

In the case of "iscomposing" we need a separate callback (IMHO).

Is it ok to discuss this subject in a separate issue?

[jmillan]

In fact it is not an issue but a design task.

[saghul]

Sure, let's discuss it as a design issue. Since it will probably require API changes, I'd go for applying the suggested fix on 0.2 branch and update the docs saying that only text/plain is supported right now.

[jmillan]

Issue defined in the initial note has been solved 4e70a25