So far so good… Like promised, let’s start our journey about IP networking in the telecom context from the ceiling and going down. So let’s understand what the heck is an “application”.
Technically we call an application any program that runs under control – and taking advantage of the services of – the operating system. That’s a fairly reasonable definition for our purposes, since all networking architectures are devised to allow communication between applications, not people. Each application has it’s own way of human-machine interaction handling (if it exists at all). We’re not concerned with this here. All we want to explain is how applications can reliably exchange data among them.
And here we arrive at the first paradigm-breaking aspect of the change from the circuit-switching-based plain old telephony service (POTS) and the IP-packet-switching-based next-generation network (NGN).
POTS networks are organized in such a way that you’ve got dumb (and reasonably cheap) user terminals connected through a smart (and very, very expensive) network. Everytime the user wants to use network services – and for a very long time there’d be only one: telephony – he/she has to ask the network for it. By means of sound-based network-to-user signaling and key-pressing user-to-network signaling (see DTMF) and ITU-T recommendation Q.23 and Q.24 the user says “I want to talk with this user”, and the network makes the arrangements to provide the end-to end circuit which the communicating parties will use.
DTMF:
Q23:
https://www.itu.int/rec/T-REC-Q.23/en
Q24:
https://www.itu.int/rec/T-REC-Q.24/en
IP-based networks, of which the Internet is the major example, were built assuming the user terminals are smart (and not overwhelmingly expensive) and the network doesn’t have to have more smartness than necessary to perform a single function: take the data packets from one side to the other with reasonable reliability. All the aspects of communication that telephony engineers are used to name as “call-control” are negotiated directly between user applications. This is the function of the so-called application-layer protocols.
So we have, so to speak, two different philosophies to handle the “call control” (which is another way to say “session control”): the network-in-the-middle approach, and the end-to-end principle
End-to-end principle:
The schematic call-flow diagrams below give an example of the differences between them.
Generally speaking there are two ways of application interaction, both widely used: peer-to-peer and client-server. On peer-to-peer sessions the communicating parties have the same status, and any of them can request or offer services to the other. Client-server sessions, on the other hand, have a clear role distinction between the parties: one requests services (the client) and the other fulfill the services requests (the server).
Most of Internet applications use the client-server model, and that goes quite well with the end-to-end principle. Otherwise NGN telecommunication services go both ways. There’s services that are a clear fit to the client-server model, like video or audio streaming, and there’s services that use peer-to-peer, like voice and video telephony (by the way, videoconferencing can go both ways).
This and a few other issues (security, mostly) forced NGN call-control architecture to use client-server interactions for signaling, and peer-to-peer or client-server for data exchange, according to service characteristics. The diagram below is an example of this.
The packet routers between the elements are not shown. And this picture is a gross oversimplification of NGN architecture. I will not go into details about this, but if you want to get a more rigorous approach to this subject I recommend you strt reading ITU-T recommendations Y.2001 – General overview of NGN and Y.2011 – General principles and general reference model for Next Generation Networks.
Roughly speaking, the AAA (authentication, authorization and accounting) server role goes to the IP Multimedia Subsystem (IMS), which was initially standardized by 3GPP/ETSI (see ETSI TS 123 228 V9.4.0 – IP Multimedia Subsystem), and later adopted by ITU (recommendation Y.2021 – IMS for Next Generation Networks). Actually it does much more than simply AAA functions. It’s the entry door to all NGN signaling which are based on Session Initiation Protocol – SIP, and Session Description Protocol – SDP (see ETSI TS 124 229 V9.10.2 – IP multimedia call control protocol based on SIP and SDP; IETF RFC 3261 – SIP: Session Initiation Protocol; and IETF RFC 4566 – SDP: Session Description Protocol).
On the next part of this article series we’ll take a closer and more formal look at IMS, SIP and SDP.
Hope it’ll be soon. Auf wiedersehen .