Patent Application
20050190756
None
The present invention relates generally to a payload format in Real Time Protocol (RTP) messages for voice data information, such as caller-ID, to be transmitted over a packet network to an Internet Protocol (IP) telephony endpoint, such as an IP phone.
Voice over packet networks (VOPN) require that the voice or audio signal be packetized and then transmitted. The analog voice signal is first converted into a digital signal and is typically compressed in the form of a pulse code modulated (PCM) digital stream. In a voice over Internet Protocol (VoIP) network, Line Control Signaling (LCS) defines a standard for packet data transmission architecture. LCS is a description of an IP-based cable telephony service that is an extension of PacketCable 1.0 architecture. PacketCable is a set of protocols for telecommunications using packet data transmissions to a home or business over a cable network. The PacketCable standards for LCS architecture are described in the document “PacketCable Line Control Signaling System Architecture Technical Report” (PKT-TR-ARCH-LCS-V01-010730) by Cable Television Laboratories, Inc., which is incorporated herein.
The Real Time Protocol (RTP) is an Internet Protocol specified in IETF RFC 3550/3551 for end-to-end network transport functions for applications that provide real-time data transmissions over a unicast or multicast network, such as the Internet. Real-time data is data traffic that needs to be sent and received with only very short delays, in other words nearly instantaneously. RTP encapsulates real time data in a data field of an RTP packet. A header field of an RTP packet contains important information regarding the type of data in the data field. RTP packets carry data that requires playback in a receiving application in a time-sensitive mode. The types of data that use RTP include voice and video data that are sent over packet networks for assembly and playout at the receiver. RTP provides information that is sent with the data to a receiver that includes payload/data type, sequence numbering, packet time-stamping, and delivery monitoring.
On the IP network 26 side of IPDT 10, an IP network through a VoIP gateway 28 and a PacketCable network through network 18 are illustrated in
A typical packet 38 format for a VOPN is illustrated in
An RTP data unit is carried in User Datagram Protocol (UDP) and Internet Protocol (IP) data units. The message format 54 for RTP, illustrated in
Dialpad tone signals from the PSTN may be generated through a gateway prior to transmission to an IP phone. The payload formats described in RFC 2833 are useful for DTMF handling in gateways and end systems. For IP telephony, the standard specifies detecting DTMF tones by a gateway on incoming circuits and sending RTP payloads instead of regular audio packets. By using RFC 2833 for DTMF tones, an Internet end system is relieved from performing this task and allows an IP phone to emulate DTMF functionality without the burden of generating precise tone pairs and imposing tone recognition on a receiver. A gateway that sends signaling events via RTP may send both named signals and tone representation as a single RTP session, using redundancy to interleave the two representations.
However, under current Internet standards and protocols, there is no voice band protocol for transmitting voice call information such as caller ID and VMWI that are received from the PSTN to an IP phone. Current RTP protocols, such as RFC 2833 enables transmission of digits and hooking events but do not transmit caller ID data. Therefore, many telephone service features that users expect from a PSTN or cellular telephone service provider are not available for IP phones in certain architectures.
The shortcomings of conventional protocols for IP phones are overcome by the exemplary embodiment of the present invention that defines an RTP payload format for carrying voice band data transmissions that are used to carry information for telephony services that include Caller Identification (ID), Visual Message Waiting Indication (VMWI), and Advance Digital Subscriber Interface (ADSI) Systems. The present invention extends the payload format for RTP to voice band data transmissions by assigning an event code for voice band data information and defining the packet format.
Preferred embodiments of the invention are discussed hereinafter in reference to the drawings, in which:
For IP telephony architectures, like those making use of GR-303 interfaces and LCS (Line Control Signaling) of PacketCable, which do not have a fully developed signaling or call control mechanism in place, end systems such as “Internet Phones” would have to recognize the voice band data transmissions for applications (e.g., Caller-ID, Visual Message Waiting Indication (VMWI), etc.). Low bit rate voice codecs cannot be guaranteed to reproduce this information accurately enough for automatic recognition. Defining this payload format permits recognition of this data at the public switched telephone network (PSTN) boundary, and therefore accurate reproduction or display at the end system.
Media gateway 70 converts voice calls originating from PSTN 72 onto the packet network 70 using RTP protocols. The RTP message payload format identifies data formats for network data signals that represent a telephones signals (e.g., dialtones) and events (e.g., off-hook, on-hook). For example, a payload format for telephony events and tones is illustrated in
In defining the payload format for RTP messages, the present invention does not assume a particular message format or encoding rules that are used for the voice band data transmission. Hence, the payload format or encoding rules of the present invention can accommodate message formats used in different countries as long as media gateways and end systems have the capability to understand the data format and may have the capability to convert from one format to another. The Media Gateway detecting the voice band data should signal the format used for correct interpretation by the systems at the opposite end of the transmission. Without imposing any additional structure on the voice band data message, the end systems are spared the burden of translating the voice band data from one format to another for the sake of transporting the data via RTP. At the same time it permits transcoding to other mutually understandable formats for the purpose of transport or regeneration at the opposite end of a transmission.
An exemplary embodiment of the RTP payload format for the present invention is illustrated as a datagram in
The fields of the payload format for Caller-ID are formatted in the following manner. The Event field 84 occupies bits zero to seven and identifies named events as described in RFC 2833. These events include DTMF named events, data modem and fax events, line events (e.g., ringing tone, off-hook, dial tone), extended line events, and trunk events. In the example, the event code defined in RFC 2833 for voice data transmission is “113,” however the exemplary embodiment may be practiced using one of the unused event codes. The E, or end, bit 86 occupies the eight bit and has the same meaning as the payload format for named events in RFC 2833. The E bit is set to a value of one (1) to indicate if that packet contains the end of the message. If the message must be split into multiple packets for transmission, then the end bit of the last packet of the message is set to one (1). The RTP timestamp and sequence number must be incremented when the message is split among multiple packets.
Referring again to
The protocol for voice band data transmission differs depending on the hook state at the an endpoint. The end system may make use of this bit if re-generation is required and the hook state of the end system is not known to the DSP subsystem regenerating the message. For end systems such as IP phone that need only to call a display routine, this may not be applicable.
The message size field 94 occupies bits sixteen and twenty-three. The message size 94 defines the total number of bytes of the message included in the packet. If the message was split into multiple packets, then the message size defines the number of bytes included in the packet. The message format field 96 occupies bits twenty-four through thirty-one of the RTP payload format. The message format 96 for North America is set to one (1). For other countries that use different message formats, then the message format field 96 is set to the international dialing code for the country in question (i.e., for Japan the message format 96 is set to decimal 82). Below the payload format layer is the payload of data. Data are divided into bytes labeled Byte1 of Data 98, Byte 2 of Data, etc., continuing to ByteN of Data 100. Data bytes contain voice band data.
Using the RTP payload format described above, an RTP payload format for carrying voice band data transmissions over a packet network is used to carry information for IP phone applications that include Caller Identification (ID), Visual Message Waiting Indication (VMWI), and Advance Digital Subscriber Interface (ADSI) Systems.
Because many varying and different embodiments may be made within the scope of the inventive concept herein taught, and because many modifications may be made in the embodiments herein detailed in accordance with the descriptive requirements of the law, it is to be understood that the details herein are to be interpreted as illustrative and not in a limiting sense.
