PacketCable 2.0

DOCSIS® is the architecture for data forwarding over cable access networks. On top of DOCSIS, PacketCable™ provides a standardised telephony service. The earlier versions 1.0 and 1.5 of PacketCable use MGCP/NCS as signaling protocol. The latest version 2.0 uses SIP for signaling in a network architecture based on 3GPP IMS (IP Multimedia Subsystem).

Devices that implement PacketCable 2.0 are called EDVAs (Embedded Digital Voice Adapter). The legacy version 1.0 and 1.5 devices are called EMTAs (Embedded Multimedia Terminal Adapter). In either case, the device needs a configuration file that contains the necessary operational parameters. This blog focusses on the PacketCable 2.0 configuration files. We will build an example from scratch, with assembly instructions included.

Lots of MIBs

Legacy PacketCable configuration files can be quite short. Just add enough SNMP MIBs to:

  • Enable the device
  • Add security parameters if needed
  • Configure the Call Agent

…and you’re pretty much done to get a minimum working setup. Other MIBs might be added to set values different than the default, but that depends on local necessity. A typical PacketCable 2.0 configuration file is many times larger than that. Let’s cut a typical 2.0 configuration file into bitesize pieces and take a closer look at some details.

At the device level

The device in this case is an EDVA that accommodates two telephony users.

The device is enabled and now belongs to a domain. Notice the red index indicator. It matches to other entries in the config file where the index is used with the same operator domain index.

The P-CSCF server

At this point, any user linked to the operator domain will contact this P-CSCF (Proxy-Call Session Control Function). This means it will be the target for SIP messages, starting with the REGISTER request.


PacketCable 2.0 uses SIP and hence is based on the concept of users.

Two users are now linked to the operator domain, with telephone numbers 1111 and 2222 respectively. Each of them has been uniquely assigned to an endpoint of the EDVA. Note the link to the operator domain (see red indexing) that was added in the beginning. A public user identity is something other users can see, for example when using Caller ID. The public user identities are linked to private user identities (see the blue indexing) for parameters that must not be exposed.

Private user information is used for authentication purposes. The credentials play a key role in this for digest calculations. To protect this vital secret, an EDVA will return an empty string when trying to retrieve the credentials MIB.

Applications and profiles

PacketCable 2.0 provisioning uses applications to configure telephony functionality on the device. A set of desired functions will be placed into what is called a profile. This allows multiple users to get the same functionality (i.e. the same applications) by simply pointing them to the same profile.

We have now established that both our users use the same profile. This implies they will both have access to the same set of applications (read “call features”).

The profile contains two call features, “Digit Map” and “Basic Call”. An alternative situation could have required that user 1 has a different digit map than user 2, but both still shared the basic call functions. In that case, two profiles would have been created. The second digit map would have been defined in pktcEUERSTDigitMapProfileTable.2. Both profiles would then share pktcEUERSTBasicCallTable.1

Under normal circumstances, the digit map is quite an extensive mass of text that has a ‘regular-expression-like’ appearance. We won’t go into the details of it here because we want to focus on the EDVA provisioning. The digit map itslef might be the subject of a future separate blog post.

The error signal timers determine when error signals are played after a phone line has been inadvertedly left off the hook.

Signal configuration

EDVAs support the MIBs specified by CableLabs and located under the CableLabs branch In addition, device provisioning and limited tone configuration are defined by the IETF under the IETF branch according to RFC 5098 and RFC 4682. EDVAs deployed in European networks must support some additional tables to allow international signal and tone configurations.

Do you want to know more?

We can provide PacketCable 2.0 example config files. Just send us an email ( and mention this blog post. You may also be interested in our PacketCable 2.0 testing services or PacketCable 2.0 training.


Reader interactions

4 Replies to “PacketCable 2.0 EDVA Config Files”

  1. Gabsi Mansour June 5, 2017 at 5:59 am

    Could you please share an example of config-file for PacketCable 2.0



  2. Hi,
    Could you please share an example of config-file for PacketCable 2.0


  3. Florian Schlums April 2, 2020 at 6:00 am

    Could you please share an example of config-file for PacketCable 2.0
    Thank you


  4. Could you please share an example of config-file for PacketCable 2.0?


Leave a Reply

Your email address will not be published. Required fields are marked *

The reCAPTCHA verification period has expired. Please reload the page.