26 May
2011
26 May
'11
3:08 p.m.
Hello,
On 5/26/11 12:19 PM, Iñaki Baz Castillo wrote:
2011/5/26 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
for veterans here, we know
it was a proposal (maybe is a rfc now) where
INVITE was used to establish the IM session and them MESSAGE requests to
carry the IMs. At least M$ Windows Messenger implemented it in some
versions.
I think that is far more better approach, as it solves firewall issues
with yet another port and relaying. Just straightforward and simply
works, no new nodes in the core network to care about HA, scalability &
stuff.
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?).
Desktop sharing works now with RTP (jitsi has
it) -- you can think of
image/video transmission. For file transfer I expressed my opinion as a
potential easy mechanism: invite-200ok-ack then what-so-ever SIPr equest
carrying the chunks, synchronized by cseq, then bye.
Since you named some protocols, does XMPP use out of band channels for IM?
A SIP network got too heavy, too many entities in the core network, the
sip router, the rtp relay, the IM relay a.s.o... while it is not really
needed more than 2.
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.
It fits with the concept of making
SIP network heavy and hard to manage,
it simply adds complexity for no real benefit. SIP has the capability to
carry payloads -- like IM is. If you don't want pager mode for IM, start
a session with INVITE, then send MESSAGEs and you are set.
I do know about MSRP implementations and they work very well. The
protocol itself (which I'm implementing right now
Here is a problem: you are implementing it -- that means time and money,
for the SIP in-band the implementation requirements does not exist in
the core network and the endpoints have all the components already in
place, so it will be quite trivial (e.g.,session management with invite,
sending sip requests).
) 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).
Another point of failure is not
good at all, is very bad.
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.
So you look to define a new protocol instead of setting a constraint for
a specific case?
Have in mind that what I said is not specified, but it is (IMO) a much
simpler approach for everyone. So don't argue against me with what is
potentially valid in SIP right now. I know them, they can just be more
specific for particular case.
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.
That's because it does not worth the time. The model is not really
bringing benefits, is just another fantasy.
Honestly I could think of just few restrictions/amendments/additions to
the base SIP RFC3261 and the next 10 following it to have very good and
simple model for im, presence, file transfer, desktop sharing a.s.o.
Think about 100 000 000 customers where you need 10 000 media relays, i
should add 10 000 IM relays? Good for vendors, they sell, bad for
operations and quality of service. Really, that's it, period.
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.
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda