VoIP Terminology and Concepts.doc.doc


Published on

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

VoIP Terminology and Concepts.doc.doc

  1. 1. VoIP Terminology and Concepts Contents A P V • Anti-tromboning • Packet Loss • Vamming Concealment • Vishing B • PacketCable • VoIP VPN • Purple minutes • VoIP phone • Back-to-back user agent • VoIP spam R • Voice chat C • Voice over • Real-time Transport IP • Call origination Protocol • Chatter bug • Voice S peering D • STUN • Downstream QoS • Session Border Controller I • Session Initiation Protocol • IP Multimedia Subsystem • Signaling gateway • Internet telephony service • Soft phone provider T L • Traversal Using Relay • Lawful interception NAT M • Media Gateway Control Protocol Retrieved from "http://en.wikipedia.org/wiki/Category:VoIP_terminology_ %26_concepts" DHN 9-18-07 1
  2. 2. Anti-tromboning (Also referred to as Anti-Hairpinning or Media Release) is a feature employed in Voice over IP networks that optimizes the use of the access network. A Session Border Controller handling calls as they pass from the Access Network to the Core Network can examine the IP Address of both the caller and called parties and if they reside in the same part of the network the media path can be “released” allowing media to flow directly between the two parties without entering the access network. The benefits of this action are twofold: 1) the Caller is not paying for any bandwidth usage on the carrier network and 2) The carrier's network is less congested. DHN 9-18-07 2
  3. 3. The Back-to-Back User Agent (B2BUA) acts as a user agent to both ends of a Session Initiation Protocol (SIP) call. The B2BUA is responsible for handling all SIP signalling between both ends of the call, from call establishment to termination. Each call is tracked from beginning to end, allowing the operators of the B2BUA to offer value-added features to the call. To SIP clients, the B2BUA acts as a User Agent server on one side and as a User Agent client on the other (back-to-back) side. The basic implementation of a B2BUA is defined in RFC 3261. The B2BUA may provide the following functionalities: • call management (billing, automatic call disconnection, call transfer, etc.) • network interworking (perhaps with protocol adaptation) • hiding of network internals (private addresses, network topology, etc.) • codec translation between two call legs Because it maintains call state for all SIP calls it handles, failure of a B2BUA affects all these calls. Often, B2BUAs also terminate and bridge the media streams to have full control over the whole session. A Signaling gateway, part of a Session Border Controller, or Asterisk PBX are good examples of a B2BUA. DHN 9-18-07 3
  4. 4. Call Origination, also known as voice origination, refers to the collecting of the calls initiated by a calling party on a telephone exchange of PSTN, and handing off the calls to a VoIP endpoint or to another exchange or telephone company for completion to a called party. In the VoIP world, the opposite of call origination is call termination, where a call initiated as a VoIP call is terminated to the PSTN. The term is often used in referring to a VoIP trunking service. DHN 9-18-07 4
  5. 5. Chatter Bug is a service and hardware device used to route long distance voice calls over an IP network. • Device: Small hardware device that plugs in between the telephone and phone line. Detects and automatically routes long distance calls to the Chatter Bug VoIP service without the need of a separate or high speed internet provider. • Service: Routes calls using a VoIP network to terminate calls to normal telephones. DHN 9-18-07 5
  6. 6. Downstream QoS (see Qos) is a technology innovation that enhances VoIP calls by improving the clarity of incoming voice. When data floods the caller's downstream Internet-access line, Downstream QoS can throttle incoming data to ensure time-sensitive voice traffic gets through promptly to the listener. One notable version of the technology was pioneered by Patton Electronics Co. for their SmartNode brand of VoIP equipment. Other versions can be found in VoIP equipment from Cisco Systems and application software from Packeteer. Standard Upstream QoS. Upstream QoS improves voice quality for the remote side of a VoIP call by transmitting upstream voice traffic at a higher priority than data. Applying upstream QoS at both ends of the call improves voice quality for both users. Yet upstream QoS still leaves the caller vulnerable to downstream data surges. During large file downloads voice quality may degrade. Some Internet providers may offer services similar to Downstream QoS as a higher- priced, premium service. VoIP systems that combine upstream and downstream QoS mechanisms, reduce the user's dependence on the service provider while providing local control over total voice quality. Retrieved from "http://en.wikipedia.org/wiki/Downstream_QoS" DHN 9-18-07 6
  7. 7. The IP Multimedia Subsystem (IMS) is an architectural framework for delivering internet protocol (IP) multimedia to mobile users. It was originally designed by the wireless standards body 3rd Generation Partnership Project (3GPP), and is part of the vision for evolving mobile networks beyond GSM. Its original formulation (3GPP R5) represented an approach to delivering "Internet services" over GPRS. This vision was later updated by 3GPP, 3GPP2 and TISPAN by requiring support of networks other than GPRS, such as Wireless LAN, CDMA2000 and fixed line. To ease the integration with the Internet, IMS as far as possible uses IETF (i.e. Internet) protocols such as Session Initiation Protocol (SIP). According to the 3GPP[1], IMS is not intended to standardize applications itself but to aid the access of multimedia and voice applications across wireless and wireline terminals, i.e. aid a form of fixed mobile convergence (FMC). This is done by having a horizontal control layer that isolates the access network from the service layer. Services need not have their own control functions, as the control layer is a common horizontal layer. Alternative and overlapping technologies for access and provision of services across wired and wireless networks depend on the actual requirements, and include combinations of Generic Access Network, soft switches and "naked" SIP. This makes the business use of IMS less appealing. It is easier to sell services than to sell the virtues of "integrated services". But, services for IMS have not been prolific. Since IMS was conceived years ago, it is becoming increasingly easier to access content and contacts using mechanisms outside the control of traditional wireless/fixed operators, and so those operators are likely to reconsider their strategies [2]. Although it is expected that eventually IP will be available on all mobile phones and operators, it is not clear how much of the 3GPP/3GPP2/TISPAN IMS as it exists today will be deployed. "Early IMS" might be used in IMS implementations that do not yet support all "Full IMS" requirements, although it's not clearly defined what differences there might be (IPv4 support instead of IPv6 is often mentioned). DHN 9-18-07 7
  8. 8. Contents • 1 History • 2 Architecture o 2.1 Access network o 2.2 Core network  2.2.1 Home subscriber server  User identities  2.2.2 Call/session control  2.2.3 Application servers  2.2.4 Media Servers  2.2.5 Breakout Gateway  2.2.6 PSTN Gateways  2.2.7 Media Resources o 2.3 Charging o 2.4 Interfaces description • 3 Security aspects of early IMS systems • 4 Specifications o 4.1 3GPP Specs o 4.2 IETF Specs • 5 See also • 6 References • 7 External links • 8 Books History • IMS was originally defined by an industry forum called 3G.IP, formed in 1999. 3G.IP developed the initial IMS architecture, which was brought to the 3rd Generation Partnership Project (3GPP), as part of their standardization work for 3G mobile phone systems in UMTS networks. It first appeared in release 5 (evolution from 2G to 3G networks), when SIP-based multimedia was added. Support for the older GSM and GPRS networks was also provided. • 3GPP2 (a different organization) based their CDMA2000 Multimedia Domain (MMD) on 3GPP IMS, adding support for CDMA2000. • 3GPP release 6 added interworking with WLAN. • 3GPP release 7 added support for fixed networks, by working together with TISPAN release R1.1. DHN 9-18-07 8
  9. 9. Architecture 3GPP / TISPAN IMS Architectural Overview The IP Multimedia Core Network Subsystem is a collection of different functions, linked by standardized interfaces, which grouped form one IMS administrative network. A function is not a node (hardware box): an implementer is free to combine 2 functions in 1 node, or to split a single function into 2 or more nodes. Each node can also be present multiple times in a single network, for load balancing or organizational issues. Access network The user can connect to an IMS network in various ways, all of which use the standard Internet Protocol (IP). Direct IMS terminals (such as mobile phones, personal digital assistants (PDAs) and computers) can register directly on an IMS network, even when they are roaming in another network or country (the visited network). The only requirement is that they can use IPv6 (also IPv4 in early IMS) and run Session Initiation Protocol (SIP) user agents. Fixed access (e.g., Digital Subscriber Line (DSL), cable modems, Ethernet), mobile access (e.g. W-CDMA, CDMA2000, GSM, GPRS) and wireless access (e.g. WLAN, WiMAX) are all supported. Other phone systems like plain old telephone service (POTS -- the old analogue telephones), H.323 and non IMS- compatible VoIP systems, are supported through gateways. Core network Home subscriber server The Home Subscriber Server (HSS), or User Profile Server Function (UPSF), is a master user database that supports the IMS network entities that actually handle calls. It contains the subscription-related information (user profiles), performs authentication and authorization of the user, and can provide information about the user's physical location. It is similar to the GSM Home Location Register (HLR) and Authentication Centre (AUC). An SLF (Subscriber Location Function) is needed to map user addresses when multiple HSSs are used. Both the HSS and the SLF communicate through the DIAMETER protocol. DHN 9-18-07 9
  10. 10. User identities Normal 3GPP networks use the following identities: • International Mobile Subscriber Identity (IMSI) • Temporary Mobile Subscriber Identity (TMSI) • International Mobile Equipment Identity (IMEI) • Mobile Subscriber ISDN Number (MSISDN) IMSI is a unique phone identity that is stored in the SIM. To improve privacy, a TMSI is generated per geographical location. While IMSI/TMSI are used for user identification, the IMEI is a unique device identity and is phone specific. The MSISDN is the telephone number of a user. IMS also requires IP Multimedia Private Identity (IMPI) and IP Multimedia Public Identity (IMPU). Both are not phone numbers or other series of digits, but Uniform Resource Identifier (URIs), that can be digits (a tel-uri, like tel:+1-555-123-4567) or alphanumeric identifiers (a sip-uri, like sip:john.doe@example.com). There can be multiple IMPU per IMPI (often a tel-uri and a sip-uri). The IMPU can also be shared with another phone, so both can be reached with the same identity (for example, a single phone-number for an entire family). The HSS user database contains, the IMPU, IMPI, IMSI, and MSISDN and other information. DHN 9-18-07 10
  11. 11. Call/session control Several roles of Session Initiation Protocol (SIP) servers or proxies, collectively called Call Session Control Function (CSCF), are used to process SIP signalling packets in the IMS. • A Proxy-CSCF (P-CSCF) is a SIP proxy that is the first point of contact for the IMS terminal. It can be located either in the visited network (in full IMS networks) or in the home network (when the visited network isn't IMS compliant yet). Some networks may use a Session Border Controller for this function. The terminal discovers its P-CSCF with either DHCP, or it is assigned in the PDP Context (in General Packet Radio Service (GPRS). o it is assigned to an IMS terminal during registration, and does not change for the duration of the registration o it sits on the path of all signalling messages, and can inspect every message o it authenticates the user and establishes an IPsec security association with the IMS terminal. This prevents spoofing attacks and replay attacks and protects the privacy of the user. Other nodes trust the P-CSCF, and do not have to authenticate the user again. o it can also compress and decompress SIP messages using SigComp, which reduces the round-trip over slow radio links o it may include a Policy Decision Function (PDF), which authorizes media plane resources e.g. quality of service (QoS) over the media plane. It's used for policy control, bandwidth management, etc. The PDF can also be a separate function. o it also generates charging records • A Serving-CSCF (S-CSCF) is the central node of the signalling plane. It is a SIP server, but performs session control too. It is always located in the home network. It uses DIAMETER Cx and Dx interfaces to the HSS to download and upload user profiles — it has no local storage of the user. All necessary information is loaded from the HSS. o it handles SIP registrations, which allows it to bind the user location (e.g. the IP address of the terminal) and the SIP address o it sits on the path of all signaling messages, and can inspect every message o it decides to which application server(s) the SIP message will be forwarded, in order to provide their services o it provides routing services, typically using Electronic Numbering (ENUM) lookups o it enforces the policy of the network operator o there can be multiple S-CSCFs in the network for load distribution and high availability reasons. It's the HSS that assigns the S-CSCF to a user, when it's queried by the I-CSCF. DHN 9-18-07 11
  12. 12. • An I-CSCF (Interrogating-CSCF) is another SIP function located at the edge of an administrative domain. Its IP address is published in the Domain Name System (DNS) of the domain (using NAPTR and SRV type of DNS records), so that remote servers can find it, and use it as a forwarding point (e.g. registering) for SIP packets to this domain. The I-CSCF queries the HSS using the DIAMETER Cx interface to retrieve the user location (Dx interface is used from I-CSCF to SLF to locate the needed HSS only), and then routes the SIP request to its assigned S-CSCF. Up to Release 6 it can also be used to hide the internal network from the outside world (encrypting part of the SIP message), in which case it's called a THIG (Topology Hiding Inter-network Gateway). From Release 7 onwards this "entry point" function is removed from the I-CSCF and is now part of the IBCF (Interconnection Border Control Function). The IBCF is used as gateway to external networks, and provides NAT and Firewall functions (pinholing). Application servers Application servers (AS) host and execute services, and interface with the S-CSCF using Session Initiation Protocol (SIP). An example of an application server that is being developed in 3GPP is the Voice call continuity Function (VCC Server). Depending on the actual service, the AS can operate in SIP proxy mode, SIP UA (user agent) mode or SIP B2BUA (back-to-back user agent) mode. An AS can be located in the home network or in an external third-party network. If located in the home network, it can query the HSS with the DIAMETER Sh interface (for a SIP-AS) or the Mobile Application Part (MAP) interface (for IM-SSF). • SIP AS: native IMS application server • IM-SSF: an IP Multimedia Service Switching Function interfaces with Customized Applications for Mobile networks Enhanced Logic (CAMEL) Application Servers using Camel Application Part (CAP) Media Servers The MRF (Media Resource Function) provides media related functions such as media manipulation (e.g. voice stream mixing) and playing of tones and announcements. Each MRF is further divided into a Media Resource Function Controller (MRFC) and a Media Resource Function Processor (MRFP). • The MRFC is a signalling plane node that acts as a SIP User Agent to the S- CSCF, and which controls the MRFP with a H.248 interface • The MRFP is a media plane node that implements all media-related functions. DHN 9-18-07 12
  13. 13. Breakout Gateway A BGCF (Breakout Gateway Control Function) is a SIP server that includes routing functionality based on telephone numbers. It is only used when calling from the IMS to a phone in a circuit switched network, such as the Public Switched Telephone Network (PSTN) or the Public land mobile network (PLMN). PSTN Gateways A PSTN/CS gateway interfaces with PSTN circuit switched (CS) networks. For signalling, CS networks use ISDN User Part (ISUP) (or BICC) over Message Transfer Part (MTP), while IMS uses Session Initiation Protocol (SIP) over IP. For media, CS networks use Pulse-code modulation (PCM), while IMS uses Real-time Transport Protocol (RTP). • A Signalling Gateway (SGW) interfaces with the signalling plane of the CS. It transforms lower layer protocols as Stream Control Transmission Protocol (SCTP, an Internet Protocol (IP) protocol) into Message Transfer Part (MTP, an Signalling System 7 (SS7) protocol), to pass ISDN User Part (ISUP) from the MGCF to the CS network. • A Media Gateway Controller Function (MGCF) does call control protocol conversion between SIP and ISUP and interfaces with the SGW over SCTP. It also controls the resources in an MGW with an H.248 interface. • A Media Gateway (MGW) interfaces with the media plane of the CS network, by converting between RTP and PCM. It can also transcode when the codecs don't match (e.g. IMS might use AMR, PSTN might use G.711). Media Resources Media Resources are those components that operate on the media plane and are under the control of IMS Core functions. Specifically, Media Server (MS) and Media gateway (MGW) DHN 9-18-07 13
  14. 14. Charging Offline charging is applied to users who pay for their services periodically (e.g., at the end of the month). Online charging, also known as credit-based charging, is used for prepaid services, or real-time credit control of postpaid services. Both may be applied to the same session. • Offline Charging : All the SIP network entities (P-CSCF, I-CSCF, S-CSCF, BGCF, MRFC, MGCF, AS) involved in the session use the DIAMETER Rf interface to send accounting information to a CCF (Charging Collector Function) located in the same domain. The CCF will collect all this information, and build a CDR (Call Detail Record), which is sent to the billing system (BS) of the domain. Each session carries an ICID (IMS Charging Identifier) as a unique identifier. IOI (Inter Operator Identifier) parameters define the originating and terminating networks. Each domain has its own charging network. Billing systems in different domains will also exchange information, so that roaming charges can be applied. • Online charging: The S-CSCF talks to an SCF (Session Charging Function) which looks like a regular SIP application server. The SCF can signal the S-CSCF to terminate the session when the user runs out of credits during a session. The AS and MRFC use the DIAMETER Ro interface towards an ECF (Event Charging Function). o When IEC (Immediate Event Charging) is used, a number of credit units are immediately deducted from the user's account by the ECF and the MRFC or AS is then authorized to provide the service. The service is not authorized when not enough credit units are available. o When ECUR (Event Charging with Unit Reservation) is used, the ECF first reserves a number of credit units in the user's account and then authorizes the MRFC or the AS. After the service is over, the number of spent credit units is reported and deducted from the account; the reserved credit units are then cleared. DHN 9-18-07 14
  15. 15. Interfaces description Interface IMS entities Description Protocol Name HTTP over Used by MRFC to fetch documents Cr MRFC, AS dedicated (scripts and other resources) from an AS TCP/SCTP channels I-CSCF, S- Used to communicate between I-CSCF/ Cx DIAMETER CSCF, HSS S-CSCF and HSS SIP AS, OSA, Used by AS to find a correct HSS in a Dh SCF, IM-SSF, DIAMETER multi-HSS environment HSS I-CSCF, S- Used by I-CSCF/S-CSCF to find a Dx DIAMETER CSCF, SLF correct HSS in a multi-HSS environment Used to exchange messages between UE Gm UE, P-CSCF SIP and CSCFs Allows operators to control QoS in a COPS (Rel5), user plane and exchange charging Go PDF, GGSN DIAMETER correlation information between IMS (Rel6+) and GPRS network Used to exchange policy decisions- Gq P-CSCF, PDF related information between P-CSCF DIAMETER and PDF S-CSCF, I- Used to exchange messages between ISC SIP CSCF, AS CSCF and AS Used to directly forward SIP requests Ma I-CSCF -> AS which are destinated to a Public Service SIP Identity hosted by the AS MGCF converts ISUP signalling to SIP MGCF -> I- Mg signalling and forwards SIP signalling to SIP CSCF I-CSCF S-CSCF -> Used to exchange messages between S- Mi SIP BGCF CSCF and BGCF Mj BGCF -> Used to exchange messages between SIP MGCF BGCF and MGCF in the same IMS DHN 9-18-07 15
  16. 16. network BGCF -> Used to exchange messages between Mk SIP BGCF BGCFs in different IMS networks I-CSCF, S- Used for exchanging messages between Mm CSCF, external Not specified IMS and external IP networks IP network MGCF, IM- Mn Allows control of user-plane resources H.248 MGW Used to exchange messages between Mp MRFC, MRFP H.248 MRFC and MRFP S-CSCF, Used to exchange messages between S- Mr SIP MRFC CSCF and MRFC P-CSCF, I- Used to exchange messages between Mw SIP CSCF, S-CSCF CSCFs SIP AS, OSA Used to exchange information between Sh DIAMETER SCS, HSS SIP AS/OSA SCS and HSS Used to exchange information between Si IM-SSF, HSS MAP IM-SSF and HSS Used by MRFC to fetch documents Sr MRFC, AS HTTP (scripts and other resources) from an AS UE, AS (SIP Enables UE to manage information Ut AS, OSA SCS, HTTP(s) related to his services IM-SSF) Security aspects of early IMS systems It is envisaged that security defined in TS 33.203 may not be available for a while especially because of the lack of USIM/ISIM interfaces and prevalence of devices that support IPv4. For this situation, to provide some protection against the most significant threats, 3GPP defines some security mechanisms, which are informally known as "early IMS security", in TR33.978. Specifications 3GPP Specs They can be downloaded from http://www.3gpp.org/specs/numbering.htm . The list below is a small selection. DHN 9-18-07 16
  17. 17. • TR 21.905 Vocabulary for 3GPP Specifications • TS 22.066 Support of Mobile Number Portability (MNP); Stage 1 • TS 22.101 Service Aspects; Service Principles • TS 22.141 Presence Service; Stage 1 • TS 22.228 Service requirements for the IP multimedia core network subsystem; Stage 1 • TS 22.250 IMS Group Management; Stage 1 • TS 22.340 IMS Messaging; Stage 1 • TR 22.800 IMS Subscription and access scenarios • TS 23.002 Network Architecture • TS 23.003 Numbering, Addressing and Identification • TS 23.008 Organization of Subscriber Data • TS 23.107 Quality of Service (QoS) principles • TS 23.125 Overall high level functionality and architecture impacts of flow based charging; Stage 2 • TS 23.141 Presence Service; Architecture and functional description; Stage 2 • TS 23.167 IMS emergency sessions • TS 23.207 End-to-end QoS concept and architecture • TS 23.218 IMS session handling; IM call model; Stage 2 • TS 23.221 Architectural Requirements • TS 23.228 IMS stage 2 • TS 23.234 WLAN interworking • TS 23.271 Location Services (LCS); Functional description; Stage 2 • TS 23.278 Customized Applications for Mobile network Enhanced Logic (CAMEL) - IMS interworking; Stage 2 • TR 23.864 Commonality and interoperability between IMS core networks • TR 23.867 IMS emergency sessions • TR 23.917 Dynamic policy control enhancements for end-to-end QoS, Feasibility study • TR 23.979 3GPP enablers for Push-to-Talk over Cellular (PoC) services; Stage 2 • TR 23.981 Interworking aspects and migration scenarios for IPv4-based IMS implementations (early IMS) • TS 24.141 Presence Service using the IMS Core Network subsystem; Stage 3 • TS 24.147 Conferencing using the IMS Core Network subsystem • TS 24.228 Signalling flows for the IMS call control based on SIP and SDP; Stage 3 • TS 24.229 IMS call control protocol based on SIP and SDP; Stage 3 • TS 24.247 Messaging using the IMS Core Network subsystem; Stage 3 • TS 26.235 Packet switched conversational multimedia applications; Default codecs DHN 9-18-07 17
  18. 18. • TS 26.236 Packet switched conversational multimedia applications; Transport protocols • TS 29.162 Interworking between the IMS and IP networks • TS 29.163 Interworking between the IMS and Circuit Switched (CS) networks • TS 29.198 Open Service Architecture (OSA) • TS 29.207 Policy control over Go interface • TS 29.208 End-to-end QoS signalling flows • TS 29.209 Policy control over Gq interface • TS 29.228 IMS Cx and Dx interfaces : signalling flows and message contents • TS 29.229 IMS Cx and Dx interfaces based on the Diameter protocol; Protocol details • TS 29.278 CAMEL Application Part (CAP) specification for IMS • TS 29.328 IMS Sh interface : signalling flows and message content • TS 29.329 IMS Sh interface based on the Diameter protocol; Protocol details • TR 29.962 Signalling interworking between the 3GPP SIP profile and non-3GPP SIP usage • TS 31.103 Characteristics of the IMS Identity Module (ISIM) application • TS 32.240 Telecommunication management; Charging management; Charging architecture and Principles • TS 32.260 Telecommunication management; Charging management; IMS charging • TS 32.299 Telecommunication management; Charging management; Diameter charging applications • TS 32.421 Telecommunication management; Subscriber and equipment trace: Trace concepts and requirements • TS 33.102 3G security; Security architecture • TS 33.108 3G security; Handover interface for Lawful Interception (LI) • TS 33.141 Presence service; security • TS 33.203 3G security; Access security for IP-based services • TS 33.210 3G security; Network Domain Security (NDS); IP network layer security • TR 33.978 Security aspects of early IP Multimedia Subsystem (IMS) IETF Specs • RFC 2327 Session Description Protocol (SDP) • RFC 2748 Common Open Policy Server protocol (COPS) • RFC 2782 a DNS RR for specifying the location of services (SRV) • RFC 2806 URLs for telephone calls (TEL) • RFC 2915 the naming authority pointer DNS resource record (NAPTR) • RFC 2916 E.164 number and DNS • RFC 3087 Control of Service Context using SIP Request-URI DHN 9-18-07 18
  19. 19. • RFC 3261 Session Initiation Protocol (SIP) • RFC 3262 reliability of provisional responses (PRACK) • RFC 3263 locating SIP servers • RFC 3264 an offer/answer model with the Session Description Protocol • RFC 3265 SIP-Specific Event Notification • RFC 3310 HTTP Digest Authentication using Authentication and Key Agreement (AKA) • RFC 3311 update method • RFC 3312 integration of resource management and SIP • RFC 3319 DHCPv6 options for SIP servers • RFC 3320 signalling compression (SigComp) • RFC 3323 a privacy mechanism for SIP • RFC 3324 short term requirements for network asserted identity • RFC 3325 private extensions to SIP for asserted identity within trusted networks • RFC 3326 the reason header field • RFC 3327 extension header field for registering non-adjacent contacts (path header) • RFC 3329 security mechanism agreement • RFC 3420 Internet Media Type message/sipfrag • RFC 3428 SIP Extension for Instant Messaging • RFC 3455 private header extensions to SIP for 3GPP • RFC 3485 SIP and SDP static dictionary for signaling compression • RFC 3515 the SIP REFER method • RFC 3550 Real-time Transport Protocol (RTP) • RFC 3574 Transition Scenarios for 3GPP Networks • RFC 3588 DIAMETER base protocol • RFC 3589 DIAMETER command codes for 3GPP release 5 (informational) • RFC 3608 extension header field for service route discovery during registration • RFC 3665 SIP Basic Call Flow Examples • RFC 3680 SIP event package for registrations • RFC 3725 best current practices for Third Party Call Control (3pcc) in SIP • RFC 3824 using E164 numbers with SIP • RFC 3840 indicating user Agent Capabilities in SIP • RFC 3841 caller preferences for SIP • RFC 3842 SIP event package for message waiting indication and summary • RFC 3856 SIP event package for presence • RFC 3857 SIP event template-package for watcher info • RFC 3858 XML based format for watcher information • RFC 3891 the SIP Replaces Header • RFC 3903 SIP Extension for Event State Publication • RFC 3911 the SIP Join Header DHN 9-18-07 19
  20. 20. • RFC 4028 session timers in SIP • RFC 4235 an INVITE-Initiated dialog event package for SIP • RFC 4475 Session Initiation Protocol (SIP) Torture Test Messages DHN 9-18-07 20
  21. 21. An ITSP (Internet Telephony Service Provider) offers an Internet data service for making telephone calls using VoIP (Voice over IP) technology. Most ITSPs use SIP, H.323, or IAX (although H.323 use is declining) for transmitting telephone calls as IP data packets. Customers may use traditional telephones with an analog telephony adapter (ATA) providing RJ11 to Ethernet connection. In the United States, net2Phone began offering consumer VoIP service in 1995.[citation needed] Before 2003, many VoIP services required customers to make and receive phone calls through a personal computer on a LAN. ITSPs are also known as VSP (Voice Service Provider) or simply VoIP Providers. DHN 9-18-07 21
  22. 22. Lawful interception (aka wiretapping) is the interception of telecommunications by law enforcement authorities (LEA's) and intelligence services, in accordance with local law and after following due process and receiving proper authorization from competent authorities. With the existing Public Switched Telephone Network (PSTN), Wireless, and Cable Systems, Lawful Interception (LI) is generally performed by accessing the digital switches supporting the target's calls in response to a warrant from a Law Enforcement Agency (LEA). However, mobile phone and Voice over IP (VoIP) technologies have enabled the mobility of the end-user, which have introduced new challenges. Whilst the detailed requirements for LI differ from one jurisdiction to another, the general requirements are the same. The LI system must provide transparent interception of specified traffic only, and the subject must not be aware of the interception. The service provided to other users must not be affected during interception. DHN 9-18-07 22
  23. 23. Contents [hide] • 1 Technical description • 2 Laws o 2.1 United States of America o 2.2 Europe o 2.3 Elsewhere • 3 Illegal Use • 4 References • 5 See also • 6 External links DHN 9-18-07 23
  24. 24. Technical description Almost all countries have LI requirements and have adopted global LI requirements and standards developed by the European Telecommunications Standards Institute (ETSI) organization. In the USA, the requirements are governed by the Communications Assistance for Law Enforcement Act (CALEA). For an overview of laws and standards, see the Global LI Industry Forum site. In order to prevent investigations being compromised, LI systems may be designed in a manner that hides the interception from the telecommunications operator concerned. This is a requirement in some jurisdictions. To ensure systematic procedures for carrying out interception, while also lowering the costs of interception solutions, industry groups and government agencies worldwide have attempted to standardize the technical processes behind lawful interception. One organization, ETSI, has been a major driver in lawful interception standards not only for Europe, but worldwide. The following figure provides a generalized view of the lawful interception architecture as proposed by ETSI: DHN 9-18-07 24
  25. 25. This architecture attempts to define a systematic and extensible means by which network operators and law enforcement agents (LEAs) can interact, especially as networks grow in sophistication and scope of services. Note this architecture applies to not only “traditional” wireline and wireless voice calls, but to IP-based services such as Voice over IP, email, instant messaging, etc. The architecture is now applied worldwide (in some cases with slight variations in terminology), including in the United States in the context of CALEA conformance. Three stages are called for in the architecture: 1) collection where target-related “call” data and content are extracted from the network; 2) mediation where the data is formatted to conform to specific standards; and 3) delivery of the data and content to the law enforcement agency (LEA). DHN 9-18-07 25
  26. 26. The call data (known as Intercept Related Information or IRI in Europe and Call Data or CD in the US) consists of information about the targeted communications, including destination of a voice call (e.g., called party’s telephone number), source of a call (caller’s phone number), time of the call, duration, etc. Call content is namely the stream of data carrying the call. Included in the architecture is the lawful interception management function, which covers interception session set-up and tear down, scheduling, target identification, etc. Communications between the network operator and LEA are via the Handover Interfaces (designated HI). Communications data and content are typically delivered from the network operator to the LEA in an encrypted format over an IP-based VPN. The interception of traditional voice calls still often relies on the establishment of an ISDN channel that is set up at the time of the interception. As stated above, the ETSI architecture is equally applicable to IP-based services where IRI (or CD) is dependent on parameters associated with the traffic from a given application to be intercepted. For example, in the case of email IRI would be similar to the header information on an email message (e.g., destination email address, source email address, time email was transmitted) as well as pertinent header information within the IP packets conveying the message (e.g., source IP address of email server originating the email message). Of course, more in-depth information would be obtained by the interception system so as to avoid the usual email address spoofing that often takes place (e.g., spoofing of source address). Voice-over-IP likewise has its own IRI, including data derived from Session Initiation Protocol (SIP) messages that are used to set up and tear down a VOIP call. USA interception standards that help network operators and service providers conform to CALEA are mainly those specified by the CableLabs, the Alliance for Telecommunications Industry Solutions (ATIS), and the TIA. TIA's standards include J- STD-025B which updates the earlier J-STD-025A to include packetized voice and CDMA wireless interception, although it has recently been challenged as "deficient" by the U.S. Dept of Justice. Generic global standards have also been developed by the [http://www.ietf.org Internet Engineering Task Force (IETF) that provides a front-end means of supporting most LI handover standards. Although the terms are different, the concepts behind the interception architecture resemble those formulated under ETSI. More recent standards address packetized voice and data (e.g., ETSI TS102232 et seq, ATIS T1.678, T1.IAS) and interception for PacketCable. Interception standardization efforts for wireless networks are primarily overseen by the Third Generation Partnership Project (3GPP). Laws Various countries have different rules with regards to lawful interception. In the United Kingdom the law is known as RIPA (Regulation of Investigatory Powers Act), in United DHN 9-18-07 26
  27. 27. States there is an array of federal and state criminal law, in Commonwealth of Independent States countries as SORM. A subset of LI law deals with the the ability of communication providers to support interception handovers. United States of America In the United States, two laws cover most of the governance of lawful interception. The 1968 Omnibus Crime Control and Safe Streets Act, Title III pertains mainly to lawful interception criminal investigations. The second law, the 1978 Foreign Intelligence Surveillance Act, or FISA, governs wiretapping for intelligence purposes where the subject of the investigation must be a foreign (non-US) national or a person working as an agent on behalf of a foreign country. Most of the congressionally mandated wiretap records indicate that the cases are related to illegal drug distribution, with cell phones as the dominant form of intercepted communication. During the 1990s, to help law enforcement and the FBI more effectively carry out wiretap operations, especially in view of the emerging digital voice and wireless networks at the time, the US Congress passed CALEA in 1994 [1]. This act provides broad guidelines to network operators on how to assist the LEAs in setting up interceptions and the types of data to be delivered. CALEA does not, as many believe, provide specific implementation directives on interception. More recently, the US Federal Communications Commission (FCC) mandated that CALEA be extended to include interception of publicly-available broadband networks and Voice over IP services that are interconnected to the Public Switched Telephone Network (PSTN). As a response to the terrorist events of 9/11, the US Congress incorporated various provisions related to enhanced electronic surveillance in the “Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism” Act (USA Patriot Act). These wiretap provisions are mainly updates to those expressed under the FISA law. Europe In the European Union, the European Council Resolution of 17 January 1995 on the Lawful Interception of Telecommunications (Official Journal C 329) mandated similar DHN 9-18-07 27
  28. 28. measures to CALEA on a pan-European basis.[2] Although some EU member countries reluctantly accepted this resolution out of privacy concerns (which are more pronounced in Europe than the US), there appears now to be general agreement with the resolution. Interestingly enough, interception mandates in Europe are generally more rigorous than those of the US; for example, both voice and ISP public network operators in the Netherlands have been required to support interception capabilities for years. Elsewhere Most countries worldwide maintain LI requirements similar to those in the US and Europe, and have moved to the ETSI handover standards. The, for example, collaboration through the numerous ISS World forums. Illegal Use As with many law enforcement tools, LI systems may be subverted for illicit purposes. This occurred in Greece during the 2004 Olympics, the telephone operator concerned was fined US$1,000,000 in 2006[3] for failing to secure it's systems against hacking. References 1. ^ http://www.askcalea.com 2. ^ http://europa.eu.int/eur-lex/lex/LexUriServ/LexUriServ.do? uri=CELEX:31996G1104:EN:HTML 3. ^ http://news.bbc.co.uk/1/hi/business/6182647.stm DHN 9-18-07 28
  29. 29. • Handover Interface for the Lawful Interception of Telecommunications Traffic, ETSI ES-201-671, under Lawful Interception, Telecommunications Security, version 3.1.1, May 2007. • Handover Specification for IP delivery, ETSI TS-102-232-1, under Lawful Interception, Telecommunications Security, version 2.1.1, December 2006. • Lawfully Authorized Electronic Surveillance, T1P1/T1S1 joint standard, document number J-STD-025B, December 2003. • 3rd Generation Partnership Project, Technical Specification 3GPP TS 33.106 V5.1.0 (2002-09), “Lawful Interception Requirements (Release 5),” September 2003. • 3rd Generation Partnership Project, Technical Specification 3GPP TS 33.107 V6.0.0 (2003-09), “Lawful interception architecture and functions (Release 6),” September 2003. • 3rd Generation Partnership Project, Technical Specification 3GPP TS 33.108 V6.3.0 (2003-09), “Handover interface for Lawful Interception (Release 6),” September 2003. • PacketCable Electronic Surveillance Specification, PKT-SP-ESP-I03-040113, Cable Television Laboratories Inc., 13 January 2004. • T1.678, Lawfully Authorized Electronic Surveillance (LAES) for Voice over Packet Technologies in Wireline Telecommunications Networks. DHN 9-18-07 29
  30. 30. In computing, Media Gateway Control Protocol (MGCP) is a protocol used within a distributed Voice over IP system. MGCP is defined in RFC 3435, which obsoletes an earlier definition in RFC 2705. It superseded the Simple Gateway Control Protocol (SGCP). Another protocol for the same purpose is Megaco, a co-production of IETF (RFC 3525) and ITU (Recommendation H.248-1). Both protocols follow the guidelines of the API Media Gateway Control Protocol Architecture and Requirements at RFC 2805. Contents [hide] • 1 Architecture • 2 Protocol Overview • 3 Implementations • 4 RFCs • 5 See also Architecture The distributed system is composed of a Call Agent (or Media Gateway Controller), at least one Media Gateway (MG) that performs the conversion of media signals between circuits and packets, and at least one Signaling Gateway (SG) when connected to the PSTN. The Call Agent uses MGCP to tell the Media Gateway: • what events should be reported to the Call Agent • how endpoints should be connected together • what signals should be played on endpoints. MGCP also allows the Call Agent to audit the current state of endpoints on a Media Gateway. The Media Gateway uses MGCP to report events (such as off-hook, or dialed digits) to the Call Agent. (While any Signaling Gateway is usually on the same physical switch as a Media Gateway, this needn't be so. The Call Agent does not use MGCP to control the Signaling Gateway; rather, SIGTRAN protocols are used to backhaul signaling between the Signaling Gateway and Call Agent). DHN 9-18-07 30
  31. 31. In MGCP, every command has a transaction ID and receives a response. Typically, a Media Gateway is configured with a list of Call Agents from which it may accept programming (where that list normally comprises only one or two Call Agents). In principle, event notifications may be sent to different Call Agents for each endpoint on the gateway (as programmed by the Call Agents, by setting the NotifiedEntity parameter). In practice however, it is usually desirable that at any given moment all endpoints on a gateway should be controlled by the same Call Agent; other Call Agents are available only to provide redundancy in the event that the primary Call Agent fails, or loses contact with the Media Gateway. In the event of such a failure it is the backup Call Agent's responsibility to reprogram the MG so that the gateway comes under the control of the backup Call Agent. Care is needed in such cases; two Call Agents may know that they have lost contact with one another, but this does not guarantee that they are not both attempting to control the same gateway. The ability to audit the gateway to determine which Call Agent is currently controlling can be used to resolve such conflicts. MGCP assumes that the multiple Call Agents will maintain knowledge of device state among themselves (presumably with an unspecified protocol) or rebuild it if necessary (in the face of catastrophic failure). Its failover features take into account both planned and unplanned outages. Protocol Overview MGCP packets are unlike what you find in many other protocols. Usually wrapped in UDP port 2427, the MGCP datagrams are formatted with whitespace, much like you would expect to find in TCP protocols. An MGCP packet is either a command or a response. Commands begin with a four-letter verb. Responses begin with a three number response code. There are eight (8) command verbs: AUEP, AUCX, CRCX, DLCX, MDCX, NTFY, RQNT, RSIP Two verbs are used by a Call Agent to query (the state of) a Media Gateway: AUEP - Audit Endpoint AUCX - Audit Connection DHN 9-18-07 31
  32. 32. Three verbs are used by a Call Agent to manage an RTP connection on a Media Gateway (a Media Gateway can also send a DLCX when it needs to delete a connection for its self-management): CRCX - Create Connection DLCX - Delete Connection MDCX - Modify Connection One verb is used by a Call Agent to request notification of events on the Media Gateway, and to request a Media Gateway to apply signals: RQNT - Request for Notification One verb is used by a Media Gateway to indicate to the Call Agent that it has detected an event for which the Call Agent had previously requested notification of (via the RQNT command verb): NTFY - Notify One verb is used by a Media Gateway to indicate to the Call Agent that it is in the process of restarting: RSIP - Restart In Progress Implementations • Vovida MGCP RFCs • RFC 3435 - Media Gateway Control Protocol (MGCP) Version 1.0 (this supersedes RFC 2705) • RFC 3660 - Basic Media Gateway Control Protocol (MGCP) Packages (informational) • RFC 3661 - Media Gateway Control Protocol (MGCP) Return Code Usage • RFC 3064 - MGCP CAS Packages • RFC 3149 - MGCP Business Phone Packages • RFC 3991 - Media Gateway Control Protocol (MGCP) Redirect and Reset Package • RFC 3992 - Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism • RFC 2805 - Media Gateway Control Protocol Architecture and Requirements DHN 9-18-07 32
  33. 33. MGCP Information Site MGCP was originally developed to address the need of scaling ingress and egress gateways in order to meet the demands of service providers. MGCP utilizes SDP for negotiating the media streams transmitted and received on the packet network, which significantly reduces the interworking complexity between SIP-based media gateway controllers (or "call agents") and media gateways. MGCP was published by the IETF as Informational RFCs (shown on this page) and also standardized by the ITU-T and adopted for use within cable networks. MGCP is widely deployed around the world. Core Documents (IETF) RFC 2705 Media Gateway Control Protocol 1.0 (obsolete) RFC 3435 Media Gateway Control Protocol 1.0 RFC 3660 Basic Media Gateway Control Protocol Packages RFC 3661 MGCP Return Code Usage MGCP Packages RFC 2897 Proposal for an MGCP Advanced Audio Package RFC 3064 MGCP CAS Packages RFC 3149 MGCP Business Phone Packages RFC 3441 Asynchronous Transfer Mode (ATM) Package RFC 3624 Bulk Audit Package RFC 3991 Redirect and Reset Package RFC 3992 Lockstep State Reporting Mechanism Please also refer to these IANA pages:  MGCP Package Registry  MGCP LocalConnectionOptions Sub-registry PacketCable Specifications DHN 9-18-07 33
  34. 34. 1.0 Specs Network-Based Call Signaling Protocol Specification (NCS) PSTN Gateway Call Signaling Protocol Specification (TGCP) NCS Signaling MIB Specification NCS Basic Packages ... Complete List of PacketCable 1.0 Specs ... 1.5 Specs Network-Based Call Signaling Protocol Specification (NCS) PSTN Gateway Call Signaling Protocol Specification (TGCP) Audio Server Package NCS Signaling MIB Specification ... Complete List of PacketCable 1.5 Specs ... PacketCable Specifications Home Page ITU Specifications Network call signalling protocol for the delivery of time-critical services J.162 over cable television networks using cable modems J.169 IPCablecom network call signalling (NCS) MIB requirements J.171 IPcablecom trunking gateway control protocol (TGCP) J.175 Audio server protocol SCTE/ANSI Standards SCTE Network Call Signaling Protocol for the Delivery of Time-Critical 24-3 Services over Cable Television Using Data Modems SCTE IPCablecom Part 8: Network Call Signaling Management Information 24-8 Base (MIB) Requirements SCTE IPCablecom Part 12: Trunking Gateway Control Protocol (TGCP) 24-12 DHN 9-18-07 34
  35. 35. Packet Loss Concealment (PLC) is a technique to mask the effects of packet loss in VoIP communications. Because the voice signal is sent as packets on a VoIP network, they may travel different routes to get to destination. At the receiver a packet might arrive very late, corrupted or simply might not arrive. One of the situations in which the latter could happen is where a packet is rejected by a server which has a full buffer and cannot accept any more data. In a VoIP connection, error control techniques such as ARQ are not feasible and the receiver should be able to cope with packet loss. Some of PLC techniques are: • zero insertion: the lost speech frames are replaced with zero • waveform substitution: the missing gap is reconstructed by repeating a portion of already received speech. The simplest form of this would be to repeat the last received frame. Other techniques account for Fundamental frequency, gap duration, etc. Waveform substitution methods are popular because of their simplicity to understand and implement. An example of such algorithm is proposed in ITU recommendation G.711 Appendix I. • model based methods: increasing number of algorithms that take advantage of speech models of interpolating and extrapolating speech gaps are being introduced and developed. DHN 9-18-07 35
  36. 36. PacketCable is a project started by CableLabs. The purpose of the organization is to define standards for the Cable TV industry. CableLabs leads this initiative for interoperable interface specifications in order to deliver real-time multimedia services over two-way cable networks. Built on top of the industry’s DOCSIS 1.1 (Data Over Cable Service Interface Specifications) cable modem infrastructure, PacketCable networks use Internet Protocol (IP) to enable a wide range of multimedia services, such as IP telephony, multimedia conferencing, interactive gaming, and general multimedia applications. A DOCSIS 1.1 network with PacketCable extensions enables cable operators to deliver data and voice traffic efficiently using a single high-speed, quality-of-service (QoS)-enabled broadband (cable) architecture. The PacketCable effort dates back to 1997 when cable operators identified the need for a real-time multimedia architecture to support the delivery of advanced multimedia services over the DOCSIS 1.1 architecture. Contents • 1 Technical overview o 1.1 PacketCable interconnects 3 networks o 1.2 PacketCable Protocols o 1.3 PacketCable Voice Codecs per PacketCable Codec Specifications o 1.4 PacketCable 1.0 o 1.5 PacketCable 1.5 o 1.6 PacketCable 2.0 • 2 Deployment • 3 References • 4 External links • 5 Further reading Technical overview PacketCable interconnects 3 networks • Hybrid Fibre Coaxial (HFC) Access Network • Public Switched Telephone Network (PSTN) • TCP/IP Managed IP Networks DHN 9-18-07 36
  37. 37. PacketCable Protocols • DOCSIS (Data Over Cable Service Interface Specification) - standard for data over cable and details mostly the RF band • Real-time Transport Protocol (RTP) & Real Time Control Protocol (RTCP) required for media transfer • PSTN Gateway Call Signaling Protocol Specification (TGCP) which is an MGCP extension for Media Gateways • Network-Based Call Signaling Protocol Specification (NCS) which is an MGCP extension for analog residential Media Gateways - the NCS specification, which is derived from the IETF MGCP RFC 2705, details VoIP signalling. o Basically the IETF version is a subset of the NCS version. The Packet Cable group has defined more messages and features than the IETF. • Common Open Policy Service (COPS) for Quality of Service PacketCable Voice Codecs per PacketCable Codec Specifications • Required o ITU G.711 (both µ-law and A-law versions) - for V1.0 & 1.5 o iLBC - for V1.5 o BV16 - for V1.5 • Recommended o ITU G.728 o ITU G.729 Annex E • Optional o Any PacketCable 1.0 • PacketCable 1.0 comprises eleven specifications and six technical reports which define the call signaling, Quality of Service (QoS), Codec, client provisioning, billing event message collection, PSTN (Public Switched Telephone Network) interconnection, and security interfaces necessary to implement a single-zone PacketCable solution for residential Internet Protocol (IP) voice services. PacketCable 1.5 • PacketCable 1.5 contains additional capabilities that do not exist in PacketCable 1.0, and superseded previous versions (1.1, 1.2, and 1.3). • PacketCable 1.5 comprises 21 specifications and one technical report which together define the call signaling, Quality of Service (QoS), Codec, client provisioning, billing event message collection, PSTN (Public Switched Telephone DHN 9-18-07 37
  38. 38. Network) interconnection, and security interfaces necessary to implement a single-zone or multi-zone PacketCable solution for residential Internet Protocol (IP) voice services. PacketCable 2.0 • Version 2.0 of PacketCable will replace MGCP with SIP. Deployment VoIP services based on PacketCable architecture are being widely deployed by operators: • Videotron - "VoIP services" (Canada: Quebec) • Time Warner - Digital Phone (System wide) • Cablevision – Optimum Voice (System wide) • Comcast - Comcast Digital Voice (System-wide) • Cox – Cox Digital Telephone (System-wide) • Charter (St. Louis, Wisconsin) • Bright House Networks (Florida) • Liberty Cablevision (Puerto Rico) • GCI (Alaska) • Shaw - "Shaw Digital Phone" (Canada: Calgary, Edmonton, Winnipeg and Victoria.) • "BRAGATEL" / Bragatel (Braga, Portugal) • "TVCABO" / PT Multimedia (Portugal) • Rogers - Rogers Home Phone [1](Canada wide (Major cities and towns serviceable with rogers high-speed internet are eligable, still expanding, St John's, NL to Vancouver, BC Serviceable as of July 2007)) • Bresnan Communications - Bresnan Digital Phone (System wide) • CableOne - "CableONE.net" (System wide) • Casema - "Casema Telefonie" (The Netherlands) DHN 9-18-07 38
  39. 39. References • PacketCable™ 1.5 Specifications Audio/Video Codecs - PKT-SP-CODEC1.5- I01-050128 • PacketCable™ 1.5 Specifications Network-Based Call Signaling Protocol - PKT- SP-NCS1.5-I01-050128 (see external link for MGCP information) • PSTN Gateway Call Signaling Protocol Specification - PKT-SP-TGCP1.5- I01-050128 (see external link for MGCP information) DHN 9-18-07 39
  40. 40. Purple minutes in internet communications refers to IP network traffic that has a value- added component, e.g. voice, video etc. DHN 9-18-07 40
  41. 41. The Real-time Transport Protocol (or RTP) defines a standardized packet format for delivering audio and video over the Internet. It was developed by the Audio-Video Transport Working Group of the IETF and first published in 1996 as RFC 1889 which was made obsolete in 2003 by RFC 3550. Real time transport protocol can also be used in conjunction with RSVP protocol which enhances the field of multimedia applications. RTP does not have a standard TCP or UDP port on which it communicates. The only standard that it obeys is that UDP communications are done via an even port and the next higher odd port is used for RTP Control Protocol (RTCP) communications. Although there are no standards assigned, RTP is generally configured to use ports 16384-32767. RTP can carry any data with real-time characteristics, such as interactive audio and video. Call setup and tear-down is usually performed by the SIP protocol. The fact that RTP uses a dynamic port range makes it difficult for it to traverse firewalls. In order to get around this problem, it is often necessary to set up a STUN server. It was originally designed as a multicast protocol, but has since been applied in many unicast applications. It is frequently used in streaming media systems (in conjunction with RTSP) as well as videoconferencing and push to talk systems (in conjunction with H.323 or SIP), making it the technical foundation of the Voice over IP industry. It goes along with the RTCP and it's built on top of the User Datagram Protocol (UDP). Applications using RTP are less sensitive to packet loss, but typically very sensitive to delays, so UDP is a better choice than TCP for such applications. According to RFC 1889, the services provided by RTP include: • Payload-type identification - Indication of what kind of content is being carried • Sequence numbering - PDU sequence number • Time stamping - allow synchronization and jitter calculations • Delivery monitoring The protocols themselves do not provide mechanisms to ensure timely delivery. They also do not give any Quality of Service (QoS) guarantees. These things have to be provided by some other mechanism. Also, out of order delivery is still possible, and flow and congestion control are not supported directly. However, the protocols do deliver the necessary data to the application to make sure it can put the received packets in the correct order. Also, RTCP provides information about reception quality which the application can use to make local adjustments. For example if a congestion is forming, the application could decide to lower the data rate. DHN 9-18-07 41
  42. 42. RTP was also published by the ITU-T as H.225.0, but later removed once the IETF had a stable standards-track RFC published. It exists as an Internet Standard (STD 64) defined in RFC 3550 (which obsoletes RFC 1889). RFC 3551 (STD 65) (which obsoletes RFC 1890) defines a specific profile for Audio and Video Conferences with Minimal Control. RFC 3711 defines the Secure Real-time Transport Protocol (SRTP) profile (actually an extension to RTP Profile for Audio and Video Conferences) which can be used (optionally) to provide confidentiality, message authentication, and replay protection for audio and video streams being delivered. The position of RTP in the protocol stack is somewhat strange. It was decided to put RTP in user space and have it (normally) run over UDP. It operates as follows. The multimedia application consists of multiple audio, video, text, and possibly other streams. These are fed into the RTP library, which is in user space along with the application. This library then multiplexes the streams and encodes them in RTP packets, which it then stuffs into a socket. At the other end of the socket (in the operating system kernel), UDP packets are generated and embedded in IP packets. If the computer is on an Ethernet, the IP packets are then put in Ethernet frames for transmission. As a consequence of this design, it is a little hard to say which layer RTP is in. Since it runs in user space and is linked to the application program, it certainly looks like an application protocol. On the other hand, it is a generic, application-independent protocol that just provides transport facilities, so it also looks like a transport protocol. Probably the best description is that it is a transport protocol that is implemented in the application layer. DHN 9-18-07 42
  43. 43. Contents [hide] • 1 Packet structure • 2 Potential further development of RTP & RTCP • 3 Mathematical background • 4 Structure of RTP/RTCP applications • 5 See also • 6 References • 7 External links o 7.1 RFCs Packet structure + Bits 0-1 2 3 4-7 8 9-15 16-31 0 Ver. P X CC M PT Sequence Number 32 Timestamp 64 SSRC identifier 96 ... CSRC identifiers ... 96+(CC×32) Extension header (optional). 96+(CC×32) + Data (X×((EHL+1)×32)) Ver. (2 bits) indicates the version of the protocol. Current version is 2. P (one bit) is used to indicate if there are extra padding bytes at the end of the RTP packet. X (one bit) indicates if the extensions to the protocol are being used in the packet. CC (four bits) contains the number of CSRC identifiers that follow the fixed header. M (one bit) is used at the application level and is defined by a profile. If it's set, it means that the current data has some special relevance for the application. PT (7 bits) indicates the format of the payload and determines its interpretation by the application. SSRC indicates the synchronization source. The optional (see X) extension's header indicates the length of the extension (EHL=extension header length) in 32bit units. Excluding the 32 of the extension header. DHN 9-18-07 43
  44. 44. Potential further development of RTP & RTCP The Real-time Transport Protocol (RTP) and the Real-time Transport Control Protocol (RTCP) are commonly used together. RTP is used to transmit data (e.g. audio and video) and RTCP is used to monitor QoS. The monitoring of quality of service is very important for modern applications. In large scale applications (e.g. IPTV), there is an unacceptable delay between RTCP reports, which can cause quality of service related problems. For more information read about problems and potential further development of RTCP Mathematical background The equations for RTCP protocol are explained in section I. and II.A in the Optimization of Large-Scale RTCP Feedback Reporting in Fixed and Mobile Networks paper. Structure of RTP/RTCP applications RTP/RTCP protocols are commonly used to transport audio or audio/video data. Separate sessions are used for each media content (e.g. audio and video). The main advantage of this separation is to make it possible to receive only one part of the transmission, commonly audio data, which lowers the total bandwidth. See also • Real time control protocol • Real Time Streaming Protocol (RTSP) • Secure Real-time Transport Protocol • Stream Control Transmission Protocol • ZRTP References • Henning Schulzrinne and Stephen Casner. RTP: A Transport Protocol for Real- Time Applications. (1993) Internet Engineering Task Force, Internet Draft, October 20, 1993. The memo originating RTP; only an early draft, does not describe the current standard. • Perkins, Colin (2003). RTP: Audio and Video for the Internet (1st ed.) Addison- Wesley. ISBN 0-672-32249-8 DHN 9-18-07 44
  45. 45. STUN (Simple Traversal of UDP (User Datagram Protocol) through NATs (Network Address Translators)) is a network protocol allowing a client behind a NAT (or multiple NATs) to find out its public address, the type of NAT it is behind and the internet-side port associated by the NAT with a particular local port. This information is used to set up UDP communication between two hosts that are both behind NAT routers. The protocol is defined in RFC 3489. Contents • 1 Protocol overview • 2 Algorithm • 3 See also • 4 External links o 4.1 Implementations Protocol overview STUN is a client-server protocol. A VoIP phone or software package may include a STUN client, which will send a request to a STUN server. The server then reports back to the STUN client what the public IP address of the NAT router is, and what port was opened by the NAT to allow incoming traffic back in to the network. The response also allows the STUN client to determine what type of NAT is in use, as different types of NATs handle incoming UDP packets differently. It will work with three of four main types: Full Cone, Restricted Cone, and Port Restricted Cone. (In the case of Restricted Cone or Port Restricted Cone NATs, the client must send out a packet to the endpoint before the NAT will allow packets from the endpoint through to the client.) STUN will not work with Symmetric NAT (also known as bi-directional NAT) which is often found in the networks of large companies. With Symmetric NAT, the IP address of the STUN server is different than that of the endpoint, and therefore the NAT mapping the STUN server sees is different than the mapping that the endpoint would use to send packets through to the client. For details on the different types of NAT, see network address translation. Once a client has discovered its external addresses, it can relate it to its peers. If the NATs are full cone then either side can initiate communication. If they are restricted cone or restricted port cone both sides must start transmitting together. Note that using the techniques described in the STUN RFC does not necessarily require using the STUN protocol; they can be used in the design of any UDP protocol. DHN 9-18-07 45
  46. 46. Protocols like SIP use UDP packets for the transfer of sound/video/text signaling traffic over the Internet. Unfortunately as both endpoints are often behind NAT, a connection cannot be set up in the traditional way. This is where STUN is useful. The STUN server is contacted on UDP port 3478, however the server will hint clients to perform tests on alternate IP and port number too (STUN servers have two IP addresses). The RFC states that this port and IP are arbitrary. Algorithm STUN uses the following algorithm (adapted from RFC 3489) to discover the presence of NAT gateways and firewalls: Where the path through the diagram ends in a red box, UDP communication is not possible. Where the path ends in a yellow or green box, communication is possible. DHN 9-18-07 46
  47. 47. A Session Border Controller is a device used in some VoIP networks to exert control over the signaling and usually also the media streams involved in setting up, conducting, and tearing down calls. Within the context of VoIP, the word "Session" in Session Border Controller refers to a call. Each call consists of one or more call signaling streams that control the call, and one or more call media streams which carry the call's audio, video, or other data along with information concerning how that data is flowing across the network. Together, these streams make up a session, and it is the job of a Session Border Controller to exert influence over the data streams that make up one or more sessions. The word "Border" in Session Border Controller refers to a point of demarcation between one part of a network and another. As a simple example, at the edge of a corporate network, a firewall demarcs the local network (inside the corporation) from the rest of the Internet (outside the corporation). A more complex example is that of a large corporation where different departments have security needs for each location and perhaps for each kind of data. In this case, filtering routers or other network elements are used to control the flow of data streams. It is the job of a Session Border Controller to assist policy administrators in managing the flow of session data across these borders. The word "Controller" in Session Border Controller refers to the influence that Session Border Controllers have on the data streams that comprise Sessions, as they traverse borders between one part of a network and another. Additionally, Session Border Controllers often provide measurement, access control, and data conversion facilities for the calls they control. DHN 9-18-07 47
  48. 48. Contents [hide] • 1 Theory of operation • 2 Controversy • 3 Lawful Intercept and CALEA • 4 History and market • 5 References • 6 External links Theory of operation SBCs are inserted into the signaling and/or media paths between calling and called parties in a VoIP call, predominantly those using the SIP, H.323, and MGCP call signaling protocols. In some cases, the SBC acts as if it were the called VoIP phone and places a second call to the called party. In technical terms, when used within the SIP protocol, this is defined as being a Back-to-Back User-Agent, or B2BUA. The effect of this behavior is that not only the signaling traffic, but also the media traffic (voice, video etc) can be controlled by the SBC. SBCs also make it possible to redirect media traffic to a completely different element elsewhere in the network, perhaps for recording, generation of music-on-hold, or other media-related purposes. Without an SBC, the media traffic travels directly between the VoIP phones, without the in-network call signaling elements having control over their path. However, in other cases, the SBC simply modifies the stream of call control (signaling) data involved in each call, perhaps limiting the kinds of call that can be conducted, changing the codec choices, and so on. Ultimately, SBCs allow their owners to control the kinds of calls that can be placed through the networks on which they reside, fix or change protocols and protocol syntax to achieve interoperability, and also overcome some of the problems that firewalls and NAT cause for VoIP calls. DHN 9-18-07 48
  49. 49. SBCs are often used by corporations along with firewalls to enable VoIP calls to and from a protected enterprise network. VoIP service providers use SBCs to allow the use of VoIP protocols from private networks with internet connections using NAT, and also to implement strong security measures that are necessary to maintain a high quality of service. SBCs also perform the function of application-level gateways.[1] Additionally, some SBCs can also allow VoIP calls to be set up between two phones using different VoIP signaling protocols (SIP, H.323, Megaco/MGCP, etc...) as well as performing transcoding of the media stream when different codecs are in use. Many SBCs also provide firewall features for VoIP traffic (denial of service protection, call filtering, bandwidth management, etc...). In contrast to conventional phone systems, the OSI layers of a VoIP-based network need not be operated by a single company. A VoIP user may purchase their internet access from one internet service provider and their VoIP service from a second company. From an IMS architecture perspective, the SBC is the integration of the P-CSCF and C- BGF functions on the access side, and the I-BCF, IWF, and I-BGF functions on the peering side. Some SBCs can be "decomposed", meaning the signaling functions can be on a separate hardware platform than the media relay functions - in other words the P- CSCF can be separated from the C-BGF, or the I-BCF/IWF can be separated from the I- BGF functions physically. A proprietary or standards based protocol, such as the H.248 Ia profile, can be used by the signaling platform to control the media one. DHN 9-18-07 49
  50. 50. Controversy The concept of SBC is controversial to proponents of end-to-end systems and peer-to- peer networking in consideration of the following: • SBCs can extend the length of the media path (the way of media packets through the network) significantly. A long media path is undesirable, as it increases the delay of voice packets (especially if the SBC implements transcoding) and the probability of packet loss. Both effects deteriorate the voice/video quality. However, sometimes there are obstacles to communication such as firewalls between the call parties, and in these cases SBCs can be used to guide media streams towards an acceptable path between caller and callee, whereas without the SBC the call media would be blocked. Some SBCs can detect if the ends of the call are in the same subnetwork and release control of the media enabling it to flow directly between the clients, this is anti-tromboning. Also, some SBCs can create a media path where none would otherwise be allowed to exist (by virtue of various firewalls and other security apparatus between the two endpoints). Lastly, for specific VoIP network models where the service provider owns the network, SBCs can actually decrease the media path by shortcut routing approaches. • SBCs often restrict the flow of information between call endpoints, restricting end-to-end transparency. VoIP phones may not be able to use new protocol features unless they are understood by the SBC. However, some SBCs are more able than others to cope with previously unseen and unanticipated protocol features. End-to-End encryption can't be used if the SBC does not have the key, DHN 9-18-07 50
  51. 51. although some portions of the information stream in an encrypted call are not encrypted, and those portions can be used and influenced by the SBC. Some SBCs are able to offload this encryption function from other elements in the network by terminating SIP-TLS, IPSec, and/or SRTP. Furthermore, some SBCs can actually make calls and other SIP scenarios work when they couldn't have before, by performing specific protocol "normalization" or "fix-up". • In some cases, far-end or hosted NAT traversal can be done without SBCs if the VoIP phones support protocols like STUN, TURN, ICE, or Universal Plug and Play (UPnP). To date STUN, TURN, ICE and others have not seen wide deployment, and their complexity leaves much to be desired. Most of the controversy surrounding SBCs pertains to whether call control should remain solely with the two endpoints in a call (in service to their owners), or should rather be shared with other network elements owned by the organizations managing various networks involved in connecting the two call endpoints. For example, should call control remain with Alice and Bob (two callers), or should call control be shared with the operators of all the IP networks involved in connecting Alice and Bob's VoIP phones together. The debate of this point is vigorous, almost religious, in nature. Those who want control in the endpoints only, are greatly frustrated by the various realities of today's networks, such as firewalls, filtering/throttling, and the lack of adoption of a universal VoIP equivalent to the phone number. Those who want control in the middle of the call end-points, are typically trying to replicate the old-style phone system, where virtually all control rested with the service provider. So far, these views have not proven to be reconcilable. Note that it may be required for a third call control element such as an SBC to be inserted in between the two endpoints in order to satisfy local lawful interception regulations. Lawful Intercept and CALEA An SBC may provide session media (normally RTP) and signalling (normally SIP) wiretap services, which can be used by providers to enforce requests for the lawful interception of network sessions. Standards for the interception of such services are provided by CALEA and ETSI, among others. DHN 9-18-07 51
  52. 52. History and market The history of SBCs shows that several corporations were involved in creating and popularizing the SBC market segment for carriers and enterprises. The "big six" of carrier-oriented SBC companies are (or were, since several have been acquired or are defunct): Acme Packet (NASDAQ: APKT), Kagoor Networks (acquired in 2005 by Juniper Networks and later end-of-lifed), Jasomi Networks (acquired in 2005 by Ditech Communications which is now known as Ditech Networks), Netrake (acquired in 2006 by Audiocodes), NexTone, and Aravox (acquired in 2003 by Alcatel and terminated). According to Jonathan Rosenberg, the author of RFC 3261 (SIP) and numerous other related RFCs, Dynamicsoft actually developed the first working SBC in conjunction with Aravox, but the product never truly gained marketshare. Four companies also played a major role in delivering enterprise-oriented SBCs: Jasomi Networks with its PeerPoint product line, Edgewater, Borderware, and Ingate. During the evolution of SBCs, many other companies undertook software development programs to create SBCs. However, doing so turned out to be a far greater technical challenge than most had anticipated, and there were few successes. An even larger group of companies began to remarket their existing products as SBCs when it became clear that the SBC market was "hot" with respect to acquisitions and IPOs. Of these companies, Acme Packet is the market segment leader, and is the only company of the group to have had a successful IPO. With the field narrowed by acquisition, NexTone is generally considered to be in second place, although they traditionally target a different market segment, having started life as a softswitch vendor. References 1. ^ Internet Communication Using SIP (p 180), Henry Sinnreich & Alan B. Johnston, ISBN 0-471-77657-2. The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. It can be used to create two-party, multiparty, or multicast sessions that include Internet telephone calls, multimedia distribution, and multimedia conferences. (cit. RFC 3261). SIP is designed to be independent of the underlying transport layer; it can run on TCP, UDP, or SCTP. It was originally designed by Henning Schulzrinne (Columbia University) and Mark Handley (UCL) starting in 1996. The latest version of the specification is RFC 3261 from the IETF SIP Working Group. In November 2000, SIP was accepted as a 3GPP signaling protocol and permanent element of the IMS architecture. It is widely used as a signaling protocol for Voice over IP, along with H.323 and others. SIP has the following characteristics: DHN 9-18-07 52
  53. 53. • Transport-independent, because SIP can be used with UDP, TCP, ATM & so on. • Text-based, allowing for humans to read SIP messages. Contents [hide] • 1 Protocol design • 2 SIP network elements • 3 Instant messaging (IM) and presence • 4 Commercial applications • 5 See also • 6 External links Protocol design SIP clients use TCP or UDP (typically on port 5060) to connect to SIP servers and other SIP endpoints. SIP is primarily used in setting up and tearing down voice or video calls. However, it can be used in any application where session initiation is a requirement. These include Event Subscription and Notification, Terminal mobility and so on. There are a large number of SIP-related RFCs that define behavior for such applications. All voice/video communications are done over separate session protocols, typically RTP. A motivating goal for SIP was to provide a signalling and call setup protocol for IP-based communications that can support a superset of the call processing functions and features present in the public switched telephone network (PSTN). SIP by itself does not define these features; rather, its focus is call-setup and signalling. However, it has been designed to enable the building of such features in network elements known as Proxy Servers and User Agents. These are features that permit familiar telephone-like operations: dialing a number, causing a phone to ring, hearing ringback tones or a busy signal. Implementation and terminology are different in the SIP world but to the end-user, the behavior is similar. SIP-enabled telephony networks can also implement many of the more advanced call processing features present in Signalling System 7 (SS7), though the two protocols themselves are very different. SS7 is a highly centralized protocol, characterized by a highly complex central network architecture and dumb endpoints (traditional telephone handsets). SIP is a peer-to-peer protocol. As such it requires only a very simple (and thus DHN 9-18-07 53
  54. 54. highly scalable) core network with intelligence distributed to the network edge, embedded in endpoints (terminating devices built in either hardware or software). SIP features are implemented in the communicating endpoints (i.e. at the edge of the network) as opposed to traditional SS7 features, which are implemented in the network. Although many other VoIP signalling protocols exist, SIP is characterized by its proponents as having roots in the IP community rather than the telecom industry. SIP has been standardized and governed primarily by the IETF while the H.323 VoIP protocol has been traditionally more associated with the ITU. However, the two organizations have endorsed both protocols in some fashion. SIP works in concert with several other protocols and is only involved in the signalling portion of a communication session. SIP acts as a carrier for the Session Description Protocol (SDP), which describes the media content of the session, e.g. what IP ports to use, the codec being used etc. In typical use, SIP "sessions" are simply packet streams of the Real-time Transport Protocol (RTP). RTP is the carrier for the actual voice or video content itself. The first proposed standard version (SIP 2.0) was defined in RFC 2543. The protocol was further clarified in RFC 3261, although many implementations are still using interim draft versions. Note that the version number remains 2.0. SIP is similar to HTTP and shares some of its design principles: It is human readable and request-response structured. SIP shares many HTTP status codes, such as the familiar '404 not found'. SIP proponents also claim it to be simpler than H.323. However, some would counter that while SIP originally had a goal of simplicity, in its current state it has become as complex as H.323. Others would argue that SIP is a stateless protocol, hence making it possible to easily implement failover and other features that are difficult in stateful protocols such as H.323. SIP and H.323 are not limited to voice communication but can mediate any kind of communication session from voice to video or future, unrealized applications. SIP network elements Hardware endpoints — devices with the look, feel, and shape of a traditional telephone, but that use SIP and RTP for communication — are commercially available from several vendors. Some of these can use Electronic Numbering (ENUM) or DUNDi to translate existing phone numbers to SIP addresses, so calls to other SIP users can bypass the telephone network, even though your service provider might normally act as a gateway to the PSTN network for traditional phone numbers (and charge you for it). Today, software SIP endpoints are common. SIP also requires proxy and registrar network elements to work as a practical service. Although two SIP endpoints can communicate without any intervening SIP infrastructure, which is why the protocol is described as peer-to-peer, this approach is DHN 9-18-07 54
  55. 55. impractical for a public service. There are various implementations that can act as proxy and registrar. From the RFCs: "SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users." "SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. " "Since registrations play an important role in SIP, a User Agent Server that handles a REGISTER is given the special name registrar." "It is an important concept that the distinction between types of SIP servers is logical, not physical." Instant messaging (IM) and presence A standard instant messaging protocol based on SIP, called SIMPLE, has been proposed and is under development. SIMPLE can also carry presence information, conveying a person's willingness and ability to engage in communications. Presence information is most recognizable today as buddy status in IM clients. Some efforts have been made to integrate SIP-based VoIP with the XMPP specification used by Jabber. Most notably Google Talk, which extends XMPP to support voice, plans to integrate SIP. Google's XMPP extension is called Jingle and, like SIP, it acts as a Session Description Protocol carrier. SIP itself defines a method of passing instant messages between endpoints, similar to SMS messages. This is not generally supported by commercial operators. Commercial applications Firewalls typically block media packet types such as UDP, though one way around this is to use TCP tunnelling and relays for media in order to provide NAT and firewall traversal. One solution involves tunnelling the media packets within TCP or HTTP packets to a relay. This solution uses additional functionality in conjunction with SIP, and packages the media packets into a TCP stream which is then sent to the relay. The relay then extracts the packets and sends them on to the other endpoint. If the other endpoint is behind a symmetrical NAT, or corporate firewall that does not allow VOIP traffic, the relay would transfer the packets to another tunnel. One disadvantage of this approach is that TCP was not designed for real time traffic such as voice, so an optimized form of the protocol is sometimes used. DHN 9-18-07 55
  56. 56. As envisioned by its originators, SIP's peer-to-peer nature does not enable network- provided services. For example, the network can not easily support legal interception of calls (referred to in the United States by the law governing wiretaps, CALEA). Emergency calls (calls to E911 in the USA) are difficult to route. It is difficult to identify the proper Public Service Answering Point, PSAP because of the inherent mobility of IP end points and the lack of any network location capability. However, as commercial SIP services begin to take off practical solutions to these problems are being proven. Standards being developed by such organizations as 3GPP and 3GPP2 define applications of the basic SIP model which facilitate commercialization and enable support for network-centric capabilities such as CALEA. Many VoIP phone companies allow customers to bring their own SIP devices, as SIP- capable telephone sets, or softphones. The new market for consumer SIP devices continues to expand. The free software community started to provide more and more of the SIP technology required to build both end points as well as proxy and registrar servers leading to a commoditization of the technology, which accelerates global adoption. SIPfoundry has made available and actively develops a variety of SIP stacks, client applications and SDKs, in addition to entire IP PBX solutions that compete in the market against mostly proprietary IP PBX implementations from established vendors. The National Institute of Standards and Technology (NIST), Advanced Networking Technologies Division provides a public domain implementation of the JAVA Standard for SIP JAIN-SIP which serves as a reference implementation for the standard. The stack can work in proxy server or user agent scenarios and has been used in numerous commercial and research projects. It supports RFC 3261 in full and a number of extension RFCs including RFC 3265 (Subscribe / Notify) and RFC 3262 (Provisional Reliable Responses) etc. DHN 9-18-07 56
  57. 57. A Signaling Gateway is a network component solely responsible for translating signaling messages (i. e. information about call establishment and teardown) between one medium (usually IP) and another (PSTN). For example, a signaling gateway might translate between ISUP and SIP. A signaling gateway is often part of a softswitch in modern VoIP deployments. DHN 9-18-07 57