26 May
2011
26 May
'11
6:40 p.m.
Inaki,
you are simply on the wrong path in this discussion, you kind of
misunderstand me.
First, I didn't know that SIP _MUST_ be over UDP only.
Try to re-think a bit the whole thing. You come to me with some examples
that are out of the purpose -- you try to demonstrate me that how SIP is
used now to do a voice call does not work for instant messaging session.
You are right, it doesn't, because that is for voice. But you can
negotiate a session that means exchange of MESSAGE requests (or if you
like better a new request type IM) within a dialog. That is session
negotiation and that is the purpose of SIP. Btw, you can force TCP if
you answer 200ok with a TCP address, moreover, TCP is mandatory in SIP
2.0 - bad implementations does not mean bad protocol.
Further, you try to tell me that MESSAGE has no notion of session,
trying to suggest that a new protocol (like MSRP) is a better approach
than defining the session for it (similar concept like for audio call
dialog, preserve call id, follow record routing). MSRP packets have
headers like SIP, just a bit fewer -- it is really bad design thinking
of they could have reused sip to specify IM sessions and file transfer.
Overall, maybe we have different understanding of simplicity.
Cheers,
Daniel
On 5/26/11 2:39 PM, Iñaki Baz Castillo wrote:
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.
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
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.