[SR-Users] [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11

[Iñaki Baz Castillo]

2011/5/26 Daniel-Constantin Mierla <miconda at 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.

-- 
Iñaki Baz Castillo
<ibc at aliax.net>