2011/5/26 Daniel-Constantin Mierla miconda@gmail.com:
on the other hand, I think MSRP didn't bring much value, just another type of stream out of signaling channel. I am not that familiar with MSRP to know really if there are real benefits, but sending instant messaging over SIP was there from beginning and rather simple without other components that introduce new points of failure.
Daniel, I strongly don't agree here. If you state that SIP MESSAGE is a good way of instant messaging I must say that SIP MESSAGE is as limited as a mobile SMS and a complete hack if we try to use it as real IM. If I send a MESSAGE to bob, he will receive it in every device it holds (parallel forking), regardless which device he uses to reply my messages. There is no "session of messages" (as there is in MSRP, XMPP, MSN, Skype or whatever decent IM protocol).
Also, don't forget that MSRP also allows file transfer along with future extensions (desktop sharing?).
MSRP is the normal procedure for message sessions in SIP. SIP uses a media stream for audio and video, using a new media stream for IM (and file transfer) is the correct aproach (IMHO) and fits very well with SIP protocol concept and existing deployments.
I do know about MSRP implementations and they work very well. The protocol itself (which I'm implementing right now) is quite easy (just 3 RFC's), it assumes NAT exists so defines MSRP relays (RFC 4976). I'm also coding a MSRP relay server.
MSRP is the only good added value to SIP (IMHO). Even if it's designed by SIMPLE WG, I strongly would like to separate it from SIMPLE PRESENCE (a full pain). It's much simpler and it's well designed.
Reducing the number of optional headers will make the messages also quite small. As for path optimization, initial request creating the dialog could get only record-routes from the SIP hops that are intended to stay in the path (like the relay).
There is no SIP dialog for MESSAGE request, so record-route doesn't apply. If it was exist, there should be needed a way to finish the dialog (a BYE?, a MESSAGE with a custom header "Terminate-IM: yes"?). MESSAGE requests are like individual SMS's in mobile world.
For file transfer, clunking the content and sending over several requests (again with minimum number of headers) with proper cseq incrementation will be a straightforward implementation.
I don't agree. You are mixing signalling indicators (CSeq) que application data indicators (message offset). Any CSeq greater than a previous one is valid (even if it's 100 times greater). The UAS could never know wheter some other requests have been lost so it has no information enough to reconstruct the whole message.
Also, you would send the file to all the UAS's in which the destination user is registered.
In MSRP I send an INVITE with SDP containing MSRP to bob. He receives the INVITE in his computer and mobile. He decides to answer/accept it in his computer. Then I have a real IM session with him jsut between my device and his computer.
SIP can be used in very simple ways, without new types of protocols and communication channels...
You know I agree with this statement for other kind of communications, but not in case of IM. MSRP is the way to go, it's cool, it's already defined (you are propossing a new specification in your mail) and it works ok.
Best regards.
PS: It's sad that just a very few softphones/UA's implement MSRP, but that doesn't mean that using MESSAGE is the way to go.