The IETF working group on Internet Emergency Preparedness (ieprep) [12]
is working on various Internet standards for emergency preparedness.
NOTEInternet Emergency Peparedness is complex topic given several facts of
Internet traffic, such as:
■■ Wide disparity in bandwidth between the Internet core and access
links to the Internet.
■■ Reports indicate the majority of the Internet traffic in 2004–2005 was
due to peer-to-peer (P2P) applications of proprietary nature, some of
them purposefully designed not to be easily blocked.
■■ Multimedia traffic such as streaming video (IP TV) is expected to
produce a further surge in Internet traffic as well as in private domains.
■■ Voice traffic is only a negligible fraction of Internet traffic and as a
consequence, applying preemption measures only for voice make
sense only in single administrative domains where traffic from all
applications can be strictly controlled.
■■ Last, but not least, should voice communications deteriorate due to
traffic peaks in an emergency, users can fall back on IM and still get
through for vital communications.
For the reasons outlined here, preemption mechanisms for SIP make sense
where SIP is controlling all or most of the IP traffic:
■■ For gateways to the PSTN
■■ On access links in single domains where the traffic can be controlled,
especially on satellite links to remote or isolated locations on the globe
Emergency Call Preemption Using SIP
In a mixed PSTN-Internet environment, either the circuits on the PSTN or the
VoIP-PSTN gateways may be the most constrained resources. Also, ETS is
already implemented on the PSTN side, as mentioned. A scenario for this
mixed environment is shown in Figure 16.3, where User 1 on the PSTN (left
side) needs to send a preemption message to User 2 on the Internet (right side).
User 2 may have to drop any other sessions in progress not shown here and
take the call. The preemption message on the PSTN side will also free TDM cir-
cuits using the ITU-T specification Q.850, and will also free a gateway port in
case this is necessary.
The rich capabilities of SIP can support informing the preempted user of the
reason, thus avoiding confusion and further unwanted callback attempts. This
is illustrated in Figure 16.4.
282 Chapter 16