Iñaki Baz Castillo wrote:
> This is something I abosulutelly don't like in SIP: SIP is an application
> layer protocol but it seems it mistrusts the network transport layer by
> including all the info about the transport layer in the application level
> headers.
I have had the same thought many times.
Personally, my suspicion is that these features are a mixture of (1)
hacks to support legacy situations, such as rport, and (2) attempts to
plug leaky abstractions in a way that provides purely formal
satisfaction for developers and architects. Some of these are
misguided, others are perhaps necessary to preserve elegance in certain
implementations. I think most of the things that we look at with
wide-eyed bewilderment in terms of mistrusting the network layer
probably belong to category #2.
For instance, if you are implementing a UAS in C and you have both UDP
and TCP listening sockets, you probably don't maintain internal
identifiers within the data structures encapsulating your socket
descriptors that describe them as being UDP or TCP. That's the whole
point, really; you as a developer, operating in the space that mediates
between the SIP application layer and the network transport layer, don't
really care. To you, a TCP socket is simply:
fd = socket(PF_INET, SOCK_STREAM, IPPROTO_IP);
And a UDP socket is:
fd = socket(PF_INET, SOCK_DGRAM, IPPROTO_IP);
You really don't care to enclose these sockets in data structures that
have some field indicating whether it's TCP or UDP, nor to put some sort
of "recv_transport" indicator in your unserialised received SIP message
structures.
Or, perhaps if you are using some high-level SIP stack in Java or C++ or
what have you that provides some sort of abstraction to you around these
transport phenomena that does not expose the actual concepts of TCP or
UDP to you on that particular level of technical granularity, there may
be some desire to "properly" determine what the transport is, instead of
relying on the stack framework to tell you whether it is a "streaming"
or "unconnected" transport and whether that necessarily, irrevocably
means TCP or UDP.
I would wholeheartedly agree that the abstractions are leaky anyway -
after all, you routinely end up dealing with network/transport-layer
reachability information in SIP processing regardless, and also with the
concepts of "ports," in ways that SIP-level attributes do not
comprehensively cover. Aside from that, I believe SIP is something to
be treated and implemented in a fairly low-level way anyhow.
But, I think that's why those things are probably in the standard.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
