Hi, I wonder how extended is the support of multipart body in the current SIP devices. I realize of more and more RFC's *requiring* multipart body to work. For example:
RFC 5365 -- Multiple-Recipient MESSAGE Requests in SIP (A user sends a special MESSAGE to a server which distributes it along all the desired destinations). This RFC makes use of a MESSAGE requests with two bodies: 1) The text message itself. 2) An XML list containing the destinations of the request. When the UAC generates such MESSAGE it must include: Required: recipient-list-message I'm sure that if one of these exotic MESSAGE arrives to most of the current softphones it will be rejected (because the UA doesn't support that extension), this is, it will not work. Why so complex RFC's? why not just adding the multi-destination info into request headers so devices no implementing multi-part can receive the MESSAGE ignoring the multi-destination headers? As a personal suggestion, this could be the MESSAGE alice sends to a server which will distribute it: ------------------ MESSAGE sip:[email protected] SIP/2.0 From: <sip:[email protected]>;tag=xxx To: <sip:[email protected]> Multi-To: <sip:[email protected]> Multi-To: <sip:[email protected]> Multi-To: <sip:[email protected]>;anonymize=true Multi-CC: <sip:[email protected]> Multi-BCC: <sip:[email protected]> Content-type: text/plain Hello all, let's play football -------------------- When the im-server receives this MESSAGE it would send the same MESSAGE to all the destinations (hidding some destinations). The MESSAGE to bob would be: ------------------ MESSAGE sip:[email protected] SIP/2.0 From: <sip:[email protected]>;tag=xxx To: <sip:[email protected]> Multi-To: <sip:[email protected]> Multi-To: <[email protected]>;count=1 Multi-CC: <sip:[email protected]> Content-type: text/plain Hello all, let's play football -------------------- In this way, if bob UA doesn't understand "Multi-XX" headers (this is, it doesn't support the RFC) it will receive the MESSAGE as normal. It must no reject it because no "Require: exotic-extension" exists. Please. compare how simple is my suggestion against the official specification in RFC 5365: http://tools.ietf.org/html/rfc5365#section-9 I have a clear opinion about it: such specifications (like RFC 5365) will *NEVER* work, and will never be widely implemented. Perhaps it could be implemented into a closed SIP environment (for example a SIP provider offering his own customized softphone) but no more, and I expect the future of SIP is based in interoperability. I'm becoming very skeptic and pessimistic when reading such specifications. Not sure if they are really done to be implemented. If a XMPP developer asks me "does SIP support multiple-recipient MESSAGE?" I can't answer "yes" even if this RFC 5365 does exist (writen != implemented). Just my pessimistic opinion. Regards. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
