26 May
2011
26 May
'11
2:39 p.m.
2011/5/26 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
UDP is good for audio/video transmission. I don't think any other kind
of information is reliably sent via UDP/RTP. But maybe I'm wrong. I
would like to know how a big file is transferred via RTP.
Already justified that it is not suitable (IMHO).
Of course. 99% of existing SIP implementations just speak SIP and have
done mostly nothing for IM. Does it mean that they deserve a good IM
system without implementing nothing?
The very same as a RtpProxy server.
You cannot expect that during a dialog any kind of in-dialog request
should not be sent. If the UA implements SessionTimers it must
periodically send re-INVITE or UPDATE. If you put on-hold the peer,
you send an INVITE, maybe an INFO for DTMF (even if it's not a
standard). You cannot add such a constrain in the CSeq value. CSeq
value belongs to SIP signalling layer, while a IM session (as a RTP
session) belongs to core/application layer.
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.
INVITE exists for negotiating a session. Which session is being negociated here?
Even within the ÏNVITE dialog, how do you correlate received MESSAGE's? i.e:
I send 4 MESSAGE's:
1) Hello
2) Daniel
3) How
4) are you?
Message 3 is lost in some UDP path, so you receive:
"Hello Daniel are you?"
and later (retransmissions):
"How"
If you want to solve it, you would add ugly contrains to SIP
signalling 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.
As explained before, using CSeq for that is wrong. If I send you 4
in-dialog request (having my initial INVITE CSeq 1) these requests can
have:
1) CSeq: 2
2) CSeq: 33
3) CSeq: 1000
4) CSeq: 999999
And they are valid. If you (UAS) receive the third in-dialog request
with CSeq 1000 you have no way to know if the network has lost any
previous message(s) (after second request with CSeq 33) or not. CSeq
cannot be used to sync application data on top of the signalling
within a dialog.
Since you named some protocols, does XMPP use out of
band channels for IM?
No, but XMPP has the concept of IM session. SIP MESSAGE has not.
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. 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.
So you look to define a new protocol instead of setting a constraint for a
specific case? 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). 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.
If you have 100 000 000 customers you could also need 10 000 RtpProxy
servers. Different kind of media sessions (RTP is UDP while MSRP is
TLS) so different kind of relay servers. I don't see the difference.
Cheers.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>