On 5/26/11 11:41 PM, Iñaki Baz Castillo wrote:
2011/5/26 Daniel-Constantin Mierlamiconda@gmail.com:
I would not like to send a ISO image using RTP ;)
That can be done with payload in sip messages. Again, you look only at a side of the coin, the one that is wrong, but gives you some reason to continue this debate -- I haven't said everything has to be RTP, so for example I mentioned TCP.
Just to confirm: when you say TCP, do you mean SIP over TCP/TLS and message data of file data within SIP messages body? Or do you mean something like "RTP over TCP" for binary data transmission? (I'm 90% sure you mean the first option, just want to confirm it).
SIP over TCP with payload.
I really wonder how good is for kamailio having to deal with message bodies of 1MB (being kamailio a SIP proxy, so theorically something ready for handling small messages).
This is your assumption. Besides that we talk about negotiation of a communication session, where parameter as agreed. The proxy can say in some cases when something is too big or too low (see registration time).
When an audio/video session is negotiated, the SIP proxy does not validate/constrain the "size" of the media.
Amazing, you found an example and it is again about voice/video! You believe that SIP is only for those kind of communications. Btw, maybe you know that rtp proxy can do re-sampling to avoid congestion.
By passing the media (as you suggest) through the signaling, such traffic is not end-to-end anymore and intermediary proxies with no very good bandwitch (or messages size constrains) would stand in the media traffic.
By initial design, sip is an end-to-end communication model. Forget about record routing and see how the requests are flowing within dialog.
Honestly I like the concept of "signalling through intermediaries and media sessions end-to-end".
What keeps me to have a session negotiation of MESSAGE requests to be sent from point A to point B?
Again, I think you haven't understood my point. MSRP defines a new protocol, that is barely different than SIP. From MSRP RFC, here is the very basic example:
MSRP a786hjs2 SEND To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp Message-ID: 87652491 Byte-Range: 1-25/25 Content-Type: text/plain
Hey Bob, are you there? -------a786hjs2$
MSRP a786hjs2 200 OK To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp From-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp -------a786hjs2$
What is the benefit over all, just a bit fewer headers, but more or less the same format as SIP messages. Maybe it saves a bit of bandwidth (hey there is SIP compession for that :-) ), but then new points of failure are added in the core network unnecessary. Such nodes need to keep states, if they crash communication drops (like with rtp relays). It is not the case with pure sip.
I just looked quickly to some of msrp rfcs, it is practically yet another sip-like protocol: they defiles paths set for the case of many msrp relays (would that be like record-routing mechanism -- don't take it literally and come back to me saying r-r has a different purpose for audio sessions), authentication with digest, a.s.o. Really funny!!
I am more sure now that is really poor solution, no benefits, no effective gain.
It is time to stop here with the discussion, you loop back with out of the context examples and I don't think you got my idea: session is negotiated with invite-200ok-ack. The content is carried via SIP (end-to-end or relayed through intermediate node when necessary) and session terminated with bye-200ok. Simple as that -- when relay is necessary, a sip proxy can do really good job in terms of performances, no need to reinvent the wheel and have different applications in the network.
Cheers, Daniel
[...]