Comp 346/488: Intro to Telecommunications

Tuesdays 4:15-6:45, Lewis Towers 412

Class 8, Mar 14

Reading (7th -- 9th editions)

Chapter 10: 10.1 - 10.5

Topics:
    band width and Fourier analysis
    packet size
    virtual-circuit routing examples
    conference calls
    SS7 v SIP

Conference-call demo

Note that we need a model for how to do this. The easiest is the "dial-in" model, where participants dial in to a specific conference number (asterisk extension) to join the conference call. An alternative is the "dial-out" model, in which the conference organizer dials out to the various participants.

To build a dial-in conference in asterisk, we'll use the MeetMe application. We'll first add an entry in meetme.conf, declaring that extension 4000 is a conference extension:
    conf => 4000
The full syntax is conf => confnumber[,pin[,adminpin]]

Then, within the extensions.conf (dialplan) file, we need to define 4000 as the conference extension. The part here that makes it a conference is the MeetMe call; the first three lines just play some information about the conference size to the caller.

exten => 4000,1,Playback(conf-thereare)
 same => n,MeetMeCount(4000)
 same => n,Playback(conf-peopleinconf)
 same => n,MeetMe(4000,i,4321)
The "i" option means that participants are announced on entry and exit. The "4321" is the conference passcode, or PIN.

To reach the conference, I also added
exten => 17734094359,1,Goto(default,4000,1)

For conferences of a few participants, MeetMe works quite well. For very large conferences, however, some sort of participant control on speakers is often necessary, to resolve multiple parties speaking at once.


Packet size figure: 10.14 (7th), 10.11(8th, 9th)
Uniformity of delay (ie jitter) is a separate issue, but is often worse with datagram switching
large versus small packets

Note that with virtual-circuit routing, the header size might be very much reduced. ATM headers are 5 bytes; IP headers are 20 bytes. Size is reduced because:

Virtual Circuits

Each switch has a table of the form ⟨vciin, portin, vciout, portout⟩
vci+port are treated as a contiguous string of bits, small enough to use as an array index, which is very fast!
Entries are typically duplicated, so given the (vci+port)in  we can look up (vci+port)out, and given (vci+port)out we can find (vci+port)in.
This allows bidirectionality.

Example: given the tables, identify the connections. See the midterm guide, #6.

Virtual-circuit packet-switched routing

We don't usually use the word "virtual" for TDM, though TDM circuits are in a sense virtual. But "virtual circuit switching" means using packets to simulate circuits.

Note that there is a big difference between circuit-switched T-carrier/SONET and any form of packet-based switching: packets are subject to fill time. That is, a 1000KB packet takes 125 ms to fill, at 64 Kbps, and the voice "turnaround time" is twice that. 250 ms is annoyingly large. When we looked at the SIP phone, we saw RTP packets with 160 B of data, corresponding to a fill time of 20 ms. ATM (Asynchronous Transfer Mode) uses 48-byte packets, with a fill time of 6 ms.

When you lease a data connection from your telco, you might lease a virtual circuit, which might be ATM or might be Frame Relay (older and with larger packets). With either strategy, your IP packets would ride on top of the virtual-circuit carrier packets. Alternatively, you might lease a bit stream, eg a DS-1 or DS-3 line or a SONET virtual tributary.


Some nomenclature

LATA: Local Access and Transport Areas. The US is divided into LATAs. These were originally defined in the AT&T divestiture judgment of 1984, separating AT&T from the seven "baby bells" (Regional Bell operating companies, or RBOCs). LATA boundaries are now determined by the FCC. Since then, new US LATAs have been created, and Canada has adopted the LATA structure.

Map: http://upload.wikimedia.org/wikipedia/commons/1/1f/LATAs.png

US LATA map

IntraLATA calls are calls that start and end within the same LATA; traditionally, these were the cheapest (though they may still be toll). Now, it is common for intraLATA (within one LATA) calls to be billed at a higher rate than interLATA calls. This has to do with competition.

Ideally, one tries not to have LATA boundaries bisect heavily populated areas.

There is some confusion about calls in the following categories:
The latter category, especially, confuses the heck out of people.

LEC: A LATA is a tariff region; the actual carrier (which may not be related to the original RBOCs) is your Local Exchange Carrier, or LEC. Verizon, for example, is still a LEC in some markets. Frontier Communications is another (currently buying many Verizon subscribers, such as me).
force
IEC: Non-RBOC LECs are sometimes called Independent Exchange Carriers, or IECs. (This is not to be confused with ILECs, or Incumbent LECs, the phone company with the "natural monopoly" in a given region; competitive LECs or CLECs are the johnny-come-lately alternative providers.)

Note that another notion of local calls may be defined by your LEC to be calls of very short distance (commonly ~8 miles), and not subject to per-minute billing at all.

Exchange: the office serving phone numbers with a common area code and first three digits of the 7-digit number (eg the 508 exchange in Rogers Park). Due to Local Number Portability, some numbers in an exchange might not share the exchange prefix.

IXC: Inter-eXchange Carrier: a long-distance provider. Carries calls not only between exchanges but between LATAs. Once upon a time, Sprint and MCI were the best-known IXC alternatives to ATT in the US. Your LEC is required to let you choose your IXC.

IXCs (and maybe LECs too) have Carrier Identification Codes. You can ask for a certain IXC to carry your call by dialing 10-10 followed by the Carrier Identification Code, eg 10-10-288 for ATT. (Strictly speaking, 101 is the prefix and the 4-digit CIC is 0288; some IXCs have a CIC with non-zero first digit.)

In the US, phone numbers are 10 digits (soon we will need 11 digits, but there are no concrete plans yet for coping with the change). Many LECs enforce "1+" dialing, where you have to dial a 1 before any long-distance calls (where long-distance here means any measured call). The 1 here is the international-calling prefix for North America, but its primary role is to remind subscribers that the call is a toll call, billed by the minute.

Sometimes the leading 1 is an indication that the number following will have 10 digits. However, some LECs don't even require that. Distinguishing 7 digits from 10 digits is done with timing, anyway; if you don't dial the last three digits soon enough, your 10-digit number might be treated by your LEC as a 7-digit number.

Brief look at Signaling System 7

Here are some features for the call-setup / call-teardown parts. SS7 can do other things as well.

SS7 introduced common-channel signaling (also called out-of-band signaling), which means a set of separate communications channels reserved for signaling (all signaling shares a common channel; signals and voice do not). The older strategy sent the signaling data down the voice channels, before the voice path was set up. (In the US, this would have been the CCITT R1 protocol, the one vulnerable to the 2600 Hz attack.)

Mostly SS7 is used only to communicate bewteen central offices, not to "customer premises".

The portion of SS7 that includes call setup and teardown is ISUP: ISDN User Part.

A small amount of SS7 signaling is not associated with a particular call. Examples include:

SS7 signaling can be associated or quasi-associated. Associated signaling means that the signaling traverses roughly the same path as the call. That is, the signaling might traverse the same sequence of switches that the call will later traverse. Quasi-associated signaling means that signaling passes through signal transfer points When quasi-associated signaling is used, each switch along the call route must still be notified of what two channels should be tied together. (STPs) that may not be on the eventual voice path. In fact an entirely separate control network (or "control plane") might be set up for the signaling communication.

Quasi-associated signaling is the dominant mode in North America, except within relatively small SS7 domains (eg within Local Exchange Carriers, or LECs).


SS7 defines three types of nodes, or service points (SPs):
SCP nodes host a variety of databases:
Internetworking layer:
Routes are configured ahead of time, and consist of bundles (or linksets) of DS0 channels ("links") set aside for this purpose. So-called High-Speed Links are also used, eg DS1 links. Recall that a DS1 channel is essentially just a bundle of 24 DS0 channels. There are several types of links: A, B, C, D, E, and F:
Access links connect "leaf-node" SSP/SCP nodes to the STP backbone. In North America, most SSPs connect to STPs, not to other SSPs.

Normally, A-links (and most other links) are allocated in pairs for an anticipated data volume that would not fill one link, so that if one of the two links fails then the other can take 100% of the combined load.

STPs are usually also paired for redundancy; each SSP/SCP leaf node is joined to a mated STP pair by a pair of A-links. The two STPs forming a mated pair are joined by Cross links. Bridge links connect mated STP pairs to other mated pairs, forming much of the STP backbone. Diagonal links do the same, but are links between STPs of different SS7 networks (eg between an IXC and a LEC).

E links connect leaf-node SSP/SCP nodes to the STP backbone, but are provided as alternative paths; they are connections from an SSP/SCP to a "non-home" mated STP pair.

Finally, F links join SSPs (switches) directly. Associated signaling traffic, traveling from switch to switch, will usually take F links between adjacent switches. In such traffic, the destination address (or point code) will match the address of the receiving SSP; in quasi-associated signaling, the destination address will not match the receiving STP and the receiving STP will be responsible for forwarding the message to the next STP in the route.

From http://www.ss7-training.net/sigtran-training/ch04lev1sec3.html:


SS7 diagram showing link types

Between two given SPs (quite possibly nonadjacent) a number of predetermined routes may be defined; the collection of these is known as a routeset.

Destination addresses are 32-bit numbers, called point codes. Routing is not static, to be able to handle failed links.

Signaling is sent as packets, with a special (non-IP, non-OSI) format. The physical, LAN and Internetwork layers are known as MTP1, MTP2 and MTP3, respectively, or collectively as MTP. Header addresses are provided at the MTP3 level.


SS7 is used between phone switches, both within a company (to do the above setup) and also between companies. In the latter setting, some of its capabilities include
LECs use SS7 to get their T-carrier/SONET lines to work with others.


SIP/SDP & H.323

These are all forms of session-setup protocols; the actual data transfer would then be handled via RTP or the equivalent (below). SIP & SDP are IETF protocols; H.323 is standardized by the International Telecommunications Union. Within the TCP/IP world, this means that there tends to be a bias in favor of SIP. H.323 may provide more complete switching options, but nobody really cares; SIP provides everything you need to place calls and is more widely supported.

SIP

One of the deepest differences between SIP and SS7 is that SS7 is centralized and SIP is entirely between the endpoints. In SIP, there are no reserved channels because there are no channels to reserve: SIP messages and the voice data packets travel on the global internet.

Another is that we now have to negotiate the encoding used, eg µlaw (also known as G.711). SIP doesn't actually do this itself; it leaves that up to SDP. Strictly speaking, SS7 has to negotiate the encoding too, but the only choices are usually µlaw or Alaw.

Another difference is that while SIP very happily serves to connect voice-call endpoints (ie phone numbers), its endpoint-naming schema is in fact much more general. SIP can also be used for multi-endpoint teleconferencing. It can also be used for game setup, or for instant messaging.

SIP's message format is somewhat similar to HTTP. It is often used in conjunction with the Session Description Protocol (SDP); the SDP data defines the format of the proposed call and is typically encapsulated in the SIP packet. SDP allows specification of IP addresses, names, and specific formats for the data streams. SIP can interact with Signaling System 7, though the two are structurally rather different.

SIP can be used to get two Asterisk servers to communicate, though it is more common to use IAX for that.

Goals for SIP include:
Often the initial connection to a user is made to a sip proxy; the asterisk server acts as a proxy for the cisco phones. If your phones are behind a NAT firewall, you will need a proxy outside. Proxies forward SIP packets, perhaps after editing them; proxies may negotiate (or allow the endpoints to negotiate) a more direct route for the actual call path. Proxies typically know the locations of the various local telephones; there is a SIP registration mechanism for a phone to announce itself to, say, its Asterisk server. A proxy may also fork a call to multiple devices (eg to my desk phone and my cell phone); forking may either be parallel (ring both simultaneously) or sequential (ring one for 15 seconds, then the other).

In asterisk, sequential ringing is done by one Dial() call followed by another; the first Dial() call must have a timeout. Parallel ringing is handled by including both channels in a single Dial() call.

SIP endpoints are User Agents, or UAs. Other entities are

Connections start with a sip URI (uniform resource identifier -- not locator!), eg
The part of a SIP URI to the right of the "@" represents a host to be contacted, that is, the "remote proxy" (it might not be the final remote proxy, however). The part to the left of the "@" is to be interpreted by the remote proxy. In some cases it represents a telephone number; in other cases, it represents some identifier that the remote proxy knows how to find and page.

The most common SIP messages are
SIP packet bodies contain ASCII text spelling out all the fields. This allows flexible addition of new fields; for example, SIP INVITEs from flowroute for inbound calls often contain the P-Asserted-Identity field (from SS7/ISUP).

Someone calling me would start with an INVITE message, sent by their proxy (the User Agent Client, or UAC) to mine. My proxy may not be the final stage, however. As the INVITE message is passed along, each proxy returns the message 100 Trying. Eventually the INVITE reaches the end of the path (or fails), and the phone rings. It also sends back 180 Ringing, and sometimes also 183 Session in Progress. When the phone is answered, it sends back 200 OK along the proxy chain. Sometimes there are SIP proxies ("stateless" proxies) that lie between proxyA and proxyB on the path, but which "edit themselves out" of the final signaling path.

One of the purposes of the proxies is to allow connection to sip:pld@cs.luc.edu through any of several phones, thus supporting forwarding: my office phone first, but my cell phone if I have pressed a button on my office phone to forward calls.

The actual data (the RTP packets) do not traverse the proxy path; they take the most direct route they can. Note, however, that endpoints behind NAT firewalls will need some kind of proxy.

SIP connection setup with proxies

In the above picture (from http://en.wikipedia.org/wiki/File:SIP_signaling.png), the following has happened:
  1. user1 sent INVITE(1) to Proxy1
  2. Proxy1 sent INVITE(1) to the Redirect Server, which responds with MOVED TEMPORARILY
  3. Proxy1 then sent a new INVITE, INVITE(2), to the Stateless Proxy
  4. INVITE(2) is forwarded to Proxy2
  5. Proxy2 forwards it to user2
  6. User2 sends back 200 OK, which traverses Proxy 2, Stateless Proxy, and Proxy 1
  7. User1 then sends ACK(2), which bypasses the Stateless Proxy (no longer in the "path")
               proxy1------------proxy2
              /                        \
             /                          \
            /                            \
         user1------- media path -------user2

This arrangement is sometimes called the SIP trapezoid.

Note that, when flowroute.com (in California or Nevada) is proxy2, then user2 is likely to be a SIP-to-SS7 transfer point ideally in the LATA of the PSTN side of the call. That is, if I'm calling someone in Pennsylvania, proxy2 is in California but hopefully user2 is in Pennsylvania.

One important field in the SIP header is the Call-ID, which is a unique identifier for referring to this call in subsequent packets. In the To: field there is usually a "tag" field with another unique identifier. This tag can be chosen independently by each side, and may be chosen uniquely for each transaction (related set of packets). From RFC 3261:

Call-ID contains a globally unique identifier for this call, generated by the combination of a random string and the softphone's host name or IP address.  The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between Alice and Bob and is referred to as a dialog.


UDP v TCP

SIP can run on UDP or TCP. For most VoIP applications, UDP is the transport layer of choice. Just why this is so, however, is not as clear as it might be. The actual RTP data, of course, needs to use UDP so that a lost data packet can be ignored. TCP forces a wait until any lost packet is retransmitted. Would the delay for a lost INVITE packet be unacceptable? SIP over UDP has to have its own timeout mechanisms.

One advantage of having SIP use UDP, aside from the realtime aspect, is that the transition from including the proxies in the communication path to omitting them can be made seamlessly. At any point, either endpoint can start sending to another entity (eg the other proxy or the other endpoint).

Note that in the diagram above, the INVITE, 200 OK and ACK(2) packets form a three-way handshake.

When SIP is sent over UDP, the following simple timeout/retransmission mechanism is used [RFC 3261]

the client transaction retransmits requests at an interval that starts at T1 seconds and doubles after every retransmission.  T1 is an estimate of the round-trip time (RTT), and it defaults to 500 ms.

ACKS are, as with TCP, not themselves acknowledged.

Traversing NAT

This is actually somewhat easier for TCP, at least in terms of having a phone behind a NAT firewall register itself to an asterisk server. However, the problem then becomes what to do when the proxies drop out (in some cases, the proxies simply cannot drop out).

    proxy ------------------------ NAT firewall --------------------- phone

SIP usually uses port 5060. Generally, if there is only one device behind a NAT firewall trying to reach a proxy on the outside, and it uses source port 5060, then port 5060 will be passed through unchanged. That is, packets will arrive at the proxy from port 5060 of the NAT firewall; the source port number will not  be remapped. (However, if there are two hosts inside trying to reach the outside from port 5059, one would be remapped, possibly to 5060, leading to a need to remap the phone's use of port 5060). Alternatively, some NAT firewalls allow punching through certain "holes" for designated ⟨host,port⟩ combinations on the inside.

Finally, it is possible that the packets from the inside phone will be remapped. The packets will arrive at the outside proxy's port 5060, but appear to be coming from another port on the NAT firewall, perhaps 5067. In this case, as long as the proxy remembers this source port, it can always reply.

SIP registration packets are sent at periodic intervals; one consequence of this is that the firewall is kept "open". At any time, the proxy can reply to the phone by sending to the firewall with the port that the phone appears outside the firewall to be using as its source port.

When the SIP end users leave the proxies out of the path and begin direct communication, they get each other's IP address from the SIP packets so far. That IP address will be wrong if one endpoint is behind a NAT firewall. Furthermore, if the other phone tries to send to the phone shown above through the NAT firewall, the firewall will not be open for packets coming from other-phone's IP address. The bottom line is that if one phone/user is behind a NAT firewall, its proxy probably cannot drop out of the media path.

In asterisk, the media path is initially set up through the asterisk proxy. The asterisk proxy can then issue a SIP RE-INVITE request to modify this to allow direct communication between the endpoints. The "reinvite=no" option disables this, and thus is generally required when an endpoint is behind a NAT firewall.


H.323

This is rather like SIP, except everything has a different name. (To be fair, there are also additional features). Proxy servers are known as Gatekeepers or Peer Elements or Border Elements. H.323 has more features for admission control and authentication. Where SIP connections begin with an INVITE message, H.323 may (this is what the telecom world is like) begin with a Request for Permission To Call.

See http://en.wikipedia.org/wiki/H.323.

One advantage of SIP, as a protocol, is its greater flexibility. New data formats can be added to SDP very quickly; getting revisions to H.323 can take decades and usually takes years.