26 May
2011
26 May
'11
1:19 p.m.
2011/5/26 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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(a)aliax.net>