27 May
2011
27 May
'11
2:50 a.m.
2011/5/27 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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.
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.
NAT. And STUN/ICE doesn't help here as TCP/TLS is supossed to be used
to carry big data in SIP message bodies.
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. 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? 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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>