27 May
2011
27 May
'11
11:41 a.m.
2011/5/27 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
I wonder if you really read to understand or just spot
'single concepts' to
make them out of the context in order to reply something. That is endless
and topic breaker.
Hi Daniel, that is not my aim. Let me summarize (correct me if I
minunderstood something):
1) You argued that SIP protocol (I mean just signalling) is a very
good approach as it makes easy dealing with NAT/firewalls. Of course I
agree.
2) So based on 1) (and other reasons) you suggest IM and file transfer
traveling into SIP message bodies within a SIP dialog
(INVITE/200/ACK/MESSAGE/200/MESSAGE/200/BYE/200). It could make sense,
ok.
3) I exposed that IMHO it's not good that a proxy (SIP signalling)
should deal with 1MB size SIP messages (i.e. sending a big AVI file).
I don't mean the proxy is not capable of that. But IMHO its better not
to saturate the signalling path by transferring big files over it.
4) So you argue that proxies could avoid loose-routing, just take part
in the dialog establishement and then let endpoints to talk SIP
end-to-end (as RFC 3261 allows, of course). This would solve point 3).
I just said that point 4) breaks point 1). And I consider point 1) as
important as point 3), but both are mutually exclusive.
I just meant that. I'm not spotting single concepts to make a quick
reply (it's not my aim), I'm trying to see the whole picture here.
You think too much of sip at it was specified for
voice calls ("an use
case"), you cannot escape that thus you cannot see how flexible it is and
what one can do with it.
I dream every day with SIP for any purpose but just voice. I'm bored
with SIP + just RTP :)
Perhaps same did those coming up with a new very
large set of new protocols that try to exceed PSTN list of
terms/abbreviations. RFC3261 is mainly exemplified with how to use SIP for
voice calls, but not restricted to - forget the examples in the rfc, look at
protocol architecture. But, indeed, on the other hand, it is also more cool
to say 'I am author of a protocol" than of a "specifications for an use
case".
Of course I agree on that. But I think MSRP fits well here (SIP is
used for routing and session establishement and MSRP for application
data communication). And MSRP satisfies point 3) above, which is
important IMHO.
I understand you opinion pointing out that MSRP is too much a very new
protocol on top of SIP, which indeed could be indesirable. I'd also
would like an intermediate approach in which MSRP is used just for
data transmission (chunks over TCP/TLS) and SIP is still used within
the session, not just for sending a BYE at the end).
Cheers.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>