2011/5/27 Daniel-Constantin Mierla miconda@gmail.com:
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.
Perhaps I didn't explain well. I mean that, in the case of audio/video, the proxy does not add constrain to the media negotiation, neither it imposes limitations in the data size (as the data is carried over a different transport, in this case RTP).
But what you are suggesting is that other kind of media (as IM or file transfer) could share signalling stream. In the example of file transfer carried within chunks in MESSAGE body, you said that the proxy could mandate a minimum/maximun data size. So in this case the proxy takes active part in such media transmission.
Below I reply yo your suggestion of non using record-routing.
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.
So you propose pure SIP transport for carrying data arguing that is makes NAT/firewall scenarios easy, and now you suggest not using record-routing which is, in fact, the reason SIP (signalling) can work even if both endpoints are behind NAT. IMHO we all know that record-routing is a MUST in any real scenario.
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?
NAT. And STUN/ICE doesn't help here as TCP/TLS is supossed to be used to carry big data in SIP message bodies.
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.
Right, I agree. But I still think that media (I don't mean audio/video now) should take a different path than the signalling. Name me radical :)
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 can agree that there is too much stuff in MSRP protocol, but IMHO people defining it has learnt the leasson of RFC 3261 (too much flexibility). MSRP is much more specific, it mandates TLS (yes or yes) and covers NAT scenarios from the beggining. Of course, non implementing MSRP is still easier than implementing it :)
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.
I like discussions as they are the best way to learn from other people :)
Obviously we don't agree but I will have in mind your opinion.
Cheers.