Voxeo Labs

I once saw Maya Angelou, the famous author and poet say.. “Words - are Things”. She was speaking about racism and the damage that can be done to people - with Words.

It’s easy to overlook the value of the spoken word. We often take for granted the things we say and and words we use to deal with people and things on a day-to-day basis.

Words - can be used to Kill - or to Heal.

Our spoken works carry anger, pain, resentment, confusion, hatred - or they can carry hope, care, concern, love, or edification - to those that hear them.

We are often judged by others for the words we use and chose - when speaking to others.

Words are important. The technology that we use to send such valuable objects from sender to receiver - deserves the highest quality possible from the medium.

100 years ago, the United States Government recognized the importance of the telecommunications network as a communication medium, and established rules, guidelines, and laws to ensure it’s availability and quality to all citizens.

As we are now faced with new technologies, and new ways to communicate - it’s up to our generation to decide how we will approach issues like call quality and availability. Just because we can make communication faster, cheaper, easier - it doesn’t mean we make it inherently better - unless we are sure to remember to include call Quality and Dependability in the equation.

Our words deserve the best.

Happy Easter, All
Chris

Traditional Telecom billing methods used by carriers in the past to assess TDM calls have typically used the Calling Party Number and Called number in order to determine the location from which the call is placed, and the location to which the call is being placed.

This concept is widely known as “determination of jurisdiction”. In the past, this method of assessment was used to assign Interstate or Intrastate charges to calls. Intrastate - or in-state calls - typically incur a much greater charge to the consumer because of legacy TDM tarrifs, regulations, and taxes.

In the past the Caller-ID field was a dependable constant which provided an accurate measure of location within the Telecom network. Voice over IP technologies are now becoming the common technology of choice for Telecomm. These protocols allow greater control over features and functionality, including the Caller-ID field. It is now possible to utilize the Caller-ID field in VoIP to reap additional benefits and call control functionality for voice calls.

Voxeo provides a SIP based (VoIP) Voice application platform that allows people to easily create Speech enabled automated telephony solutions. These applications perform hundreds of different kinds of automated tasks and automate transactions in every market and industry using human speech, and VoIP technology via programming languages such as Callxml, VoiceXML, and CCXML.

Voxeo allows our users to control fields such as the Caller-ID field, to maintain greater control over their application, such as to provide additional data for downstream call routing, or to provide a client with the ability to show their specific corporate number to a caller to indicate that they are placing the call.

If a user decides to populate the Caller-ID field with an Intrastate number, for example Austin - at a 512, - and place a call to a 512 -xxx number, the call would appear to the carrier to be an Intrastate call. In fact, the call actually originated from one of our data centers from outside the State of Texas.

As the call is a SIP originated call from a state other than an Intrastate location, I believe that it should be charged Interstate rates on these calls. Our carriers friends agree with us, and have worked with us to find a solution to this problem.

The solution we have found for notifying the carrier of our physical location while allowing users to specify caller-id, is a SIP header field called P-Charge-Info.

P-Charge-Info is a field in the SIP Header that allows the receiving IP switch to establish the real location of the originating call while preserving the CallerId field.

Below is an informal RCF draft regarding the P-Charge-Info header that will provide a detailed explanation of the this field.

__________________________________________________________________
Internet-Draft Voxeo

P-Charge-Info - A Private Header (P-Header) Extension to the Session

Initiation Protocol (SIP)

draft-york-sipping-p-charge-info-02

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 28, 2008.

Copyright Notice

Copyright (C) The IETF Trust (2008).

Abstract

This document describes ‘P-Charge-Info’, a private Session Initiation
Protocol (SIP) header (P-header) used by a number of equipment
vendors and carriers to convey simple billing information.

York & Asveren Expires August 28, 2008 [Page 1]

Internet-Draft P-Charge-Info, a SIP Private Header February 2008

Table of Contents

1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 4
3. The P-Charge-Info Header . . . . . . . . . . . . . . . . . . . 4
3.1. Applicability Statement for the P-Charge-Info header . . . 4
3.2. Usage of the P-Charge-Info header . . . . . . . . . . . . . 4
3.2.1. Procedures at the UA . . . . . . . . . . . . . . . . . 4
3.2.2. Procedures at the Proxy . . . . . . . . . . . . . . . . 4
3.3. Examples of Usage . . . . . . . . . . . . . . . . . . . . . 5
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 8

Internet-Draft P-Charge-Info, a SIP Private Header February 2008

1. Overview

In certain network configurations, it is desirable to decouple the
Caller ID from the number used for billing purposes. This document
describes the current usage of ‘P-Charge-Info’, a private SIP header,
to provide simple billing information and requests the registration
of this header with IANA as required by section 4.1 of RFC 3427
[RFC3427].

In a typical configuration, “Caller ID” is derived from one of the
following SIP headers:

o P-Asserted-Identity

o From (in the absence of P-Asserted-Identity)

(NOTE: Some service providers today also use the “Remote-Party-ID”
header but this was replaced by P-Asserted-Identity in RFC 3325 and
should no longer be used.)

This number is typically presented to the receiving UA where it is
usually displayed for the end user. It is also typically used for
billing purposes by the network entities involved in carrying the
session.

However, in a distributed environment the “Caller ID” presented to
the receiving UA may not reflect the actual reality of the underlying
network in terms of costs incurred on the PSTN. This may result in
excessive charging of one carrier by another based on the erroneous
assumption that the call was originating from a different point on
the PSTN.

There exists a need for a way to pass an additional billing
identifier that can be used between network entities in order to
correctly bill for services. At least one equipment provider, Sonus
Networks, and several carriers have been using the “P-Charge-Info”
header for the last 2-3 years as a simple mechanism to exchange this
billing identifier.

Note that the 3GPP has also recognized the need for such a billing
identifier and in section 4.6 of RFC 3455 [RFC3455] established a SIP
P-Header, “P-Charging-Vector”, to provide similar information. There
are, however, some differences in the semantics associated with
P-Charging-Vector and P-Charge-Info. P-Charging-Vector is mainly
used to carry information for correlation of multiple charging
records generated for a single session. On the other hand, P-Charge-
Info is used to convey information about the party to be billed for a
call. Furthermore, P-Charging-Vector has a mandatory icid-value

York & Asveren Expires August 28, 2008 [Page 3]

Internet-Draft P-Charge-Info, a SIP Private Header February 2008

parameter, which is a globally unique value to identify the session,
for which the charging information is generated. Such an identifier
is not necessary when carrying information about the user to be
billed.

2. Requirements Language

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in RFC 2119.

3. The P-Charge-Info Header

3.1. Applicability Statement for the P-Charge-Info header

The P-Charge-Info header is applicable within a single private
administrative domain or between different administrative domains
where there is a trust relationship between the domains.

3.2. Usage of the P-Charge-Info header

The P-Charge-Info header is used to convey information related to
billing record for a particular call. The P-Charge-Info header is
typically inserted by the SIP proxy on the originating network.

3.2.1. Procedures at the UA

The P-Charge-Info header may be inserted by PSTN gateways acting as a
SIP UA, either through local policy or as a result of information
received via PSTN signaling, e.g. the charge parameter in an ISUP IAM
message.

The P-Charge-Info header is not used/interpreted by a regular (i.e.
non-gateway) UA and should not normally be seen by such a UA. If the
header is transmitted to such a UA, the UA should ignore the header.

3.2.2. Procedures at the Proxy

A SIP proxy that supports this extension and receives a request,
typically a SIP INVITE, without the P-Charge-Info header MAY insert a
P-Charge-Info header. The contents of the inserted header may be
decided based on local policy or by querying an external entity.

A SIP proxy that does not support this extension will pass any
received P-Charge-Info header unmodified in compliance with RFC 3261.

York & Asveren Expires August 28, 2008 [Page 4]

Internet-Draft P-Charge-Info, a SIP Private Header February 2008

3.3. Examples of Usage

The content of the P-Charge-Info header is typically simply a SIP URI
used as a billing indicator. As such, an example would be as simple
as:

P-Charge-Info:

Any other applicable SIP URI could be used.

P-Charge-Info optionally includes the numbering plan indicator as an
additional parameter. This is used when an ISUP message is built
from a SIP message for scenarios where SIP is used to connect two
PSTN segments and needs to pass charging information between them.
An example of the usage of the optional header is:

P-Charge-Info:

4. Formal Syntax

The Private Header specified in this document is described in both
prose and an augmented Backus-Naur Form (BNF) defined in RFC 2234.
Further, several BNF definitions are inherited from SIP and are not
repeated here. Implementors need to be familiar with the notation
and contents of SIP [1] and RFC 2234 [3] to understand this document.

The syntax of the P-Charge-Info header is described as follows:

P-Charge-Info = “P-Charge-Info” HCOLON (name-addr / addr-spec)*
(SEMI charge-param)
; name-addr and addr-spec are specified in RFC 3261
charge-param = ((”npi” EQUAL npi-value) / generic-param)
; generic-param is specifed in RFC 3261
npi-value = (”ISDN” / “DATA” / “TELEX” / “PRIVATE” /
“SPARE0″ / “SPARE1″ / “SPARE2″ / “SPARE3″ /
“SPARE4″ / “SPARE5″ / “SPARE6″ / “SPARE7″ )

5. IANA Considerations

This document defines a private SIP extension header field (beginning
with the prefixe “P-”).

The extension is registered as a private extension field:

RFC Number: RFCXXXX [Note to IANA: Please fill in with the RFC number
of this specification.

York & Asveren Expires August 28, 2008 [Page 5]

Internet-Draft P-Charge-Info, a SIP Private Header February 2008

Header Field Name: P-Charge-Info

Compact Form: none

6. Security Considerations

Given that the information contained in the P-Charge-Info header will
be used for billing purposes the proxies that share this information
MUST have a trust relationship.

If an untrusted entity were inserted between the trusted entities, it
could potentially interfere with the billing records for the call.
If the SIP connections are not made over a private WAN, a mechanism
for securing the confidentiality and integrity of the SIP connection
should be used to protect the information.

7. Acknowledgements

The authors thank Miguel Garcia, Christer Holmberg and Paul Kyzivat,
who, while not necessarily agreeing with the need for this header,
did provide substantial input and also corrected and greatly improved
the ABNF notation.

8. References

8.1. Normative References

[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
and B. Rosen, “Change Process for the Session Initiation
Protocol (SIP)”, BCP 67, RFC 3427, December 2002.

8.2. Informative References

[RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, “Private
Header (P-Header) Extensions to the Session Initiation
Protocol (SIP) for the 3rd-Generation Partnership Project
(3GPP)”, RFC 3455, January 2003.

______________________
Additional Info
______________________

Below is a SIP log detailing the use of P-Charge-Info in an actual log.

Details

CSeq: 1 INVITE
Contact:
Supported: 100rel
Supported: timer
Supported: replaces
Supported: histinfo
User-Agent: CommuniGatePro-callLeg/5.2.1a
Allow: INVITE
Allow: ACK
Allow: BYE
Allow: CANCEL
Allow: OPTIONS
Allow: INFO
Allow: MESSAGE
Allow: SUBSCRIBE
Allow: NOTIFY
Allow: PRACK
Allow: REFER
Content-Type: application/sdp
Content-Length: 273

v=0
o=Sonus_UAC 1114763139 557381571 IN IP4 207.155.147.30
s=SIP 200.123.456.789 Capabilities
c=IN IP4 207.155.147.10
t=0 0
m=audio 8126 RTP/AVP 0 101
c=IN IP4 207.155.147.10
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20

CCX/voxeo-3v3lmzwxb/2008.02.15.15.38.00.531/:a6ab2d5524a338534dd26e4aa70fb032:-1:1/14/CTA-9399e7868dd4e81ed19774d438019f39/CTManager:SIP message(o):
ACK sip:signode-34-B35F42D3@216.22.104.35 SIP/2.0
Via: SIP/2.0/UDP
To: ;tag=000000000000034-2E6C87E6-B35F42D3
From: ;tag=0-13c4-47b5b1c6-3c83246-6784
CSeq: 1 ACK
Call-ID: 0-13c4-47b5b1c6-3c83246-18be-18aac060
Contact:
P-CGP-Private: 200.123.456.789
P-Charge-Info: 9991234567@sipproxy.foo.net
Reason: 5125555555@sipproxy.foo.net
Content-Length: 0

VoIP networks are easier to create than ever before, in fact - many VoIP providers you encounter in the SMB market are actually “Resellers” who are providing transport access to one - or a variety of larger carriers.

How does this work?

Let’s say I want to open up Chris’ SuperVoIPWorld and provide Voice over IP Transport Services to small IP switch folks..

First, I get a switch. I then create a web interface and billing system to take your money, next - I contact the large VoIP carriers and negotiate services. I would probably pick 2 or 3 carriers to create redundancy and offer a mix of routes with varying levels of service, silver - gold - and platinum.. depending on quality of service.

Then, I allow you to access my system via your own account so that you can send calls from your device to the outside world on the carrier accounts I’ve acquired.

Essentially - I’m reselling the services of an existing VoIP network. I can then buy my yacht and paint “SuperVoIPWorld” on the back of it.

When you are shopping for VoIP, if you are a small business or individual user - you will usually encounter these providers. Why? Because it’s difficult - if not impossible - to get VoIP service in the form of 4 lines from Level3 or Verizon. They simply don’t want to sell services to individual users.

So - if you must deal with “Resellers”, what do you need to know?

1. Who are their source carriers? Are they quality providers such as established carriers, or are they other resellers?

2. How long have they been in business?

3. Are they reliable? What do others have to say about them?

4. Do they support the major codex and features on all subsequent routes? Do they have cheap routes that will drop your calls because they don’t have your codex?

5. What is their Service Level Agreement? Will they guarantee service or refund for outages?

6. Is their Price fair - or are you paying a significant overage for this “resold” service?

In many cases, it’s not easy to find reliable carrier VoIP services. If you are shopping for transport, keep in mind that your phoneline is the lifeline of your business or home. You should demand reliable service from your provider and make sure you choose a provider with a solid record of outstanding service.

After all, since it’s easy to start SuperVoIPWorld - it’s also easy to take your money and sail away - leaving you without service.

Good Luck!

SIP comes in many flavors. This isn’t unusual because as you probably know, traditional Telephony comes in many flavors. The difference here is that TDM based telephony has had about century to evolve into relatively standard Vanilla, Chocolate, and Strawberry flavors.

VoIP is rapidly evolving so it’s possible to get Skypeberry, Googleroni, or Vonagenut, or any number of other exciting new flavors.

At Voxeo we speak SIP. Session Initiation Protocol is an IEFT (Internet Engineering Task Force) defined signaling protocol which is described in RFC 3261. The SIP RFC is a set of rules for how the protocol should operate and is open to interpretation by the party creating the SIP device or SIP code stack. So - how SIP functions can vary between device or software. We use a common set of rules in our SIP stack in order to play nicely with the rest of the SIP world and as such are compatible with most devices and providers that work with the G.711u codex.

However, sometimes we encounter inconsistencies in how our SIP works with different providers and devices. In fact, the primary purpose of the Voxeo lab is to test providers and devices for VoIP compatibility.

Voxeo Prophecy, as a SIP device (some like to call it an IVR - but I know it’s much more.. ) is able to accept SIP media in one of two ways, through SIP Registration or SIP Trunking. I’d like to take a moment to define these two transport mechanisms so that we can carry on future discussions with a common foundation. I believe this is needed because I regularly encounter different terms for the same things in VoIP - and unfortunately - it’s confusing, therefore - I’d like to clear the air and help define what we are doing at Voxeo with Prophecy.

SIP Registration is a way to establish and maintain a constant state-ful media transmission connection between a SIP Host (Server) and SIP device (Client). In SIP Registration, a SIP device will transmit a username and account password that is authenticated by the SIP Host. If the account and password is valid, the connection is accepted and calls may be passed between the two devices. If the authentication is rejected, calls will not be allowed. In SIP Registration, a constant state of communication is created and the pipe is monitored at regular intervals for availability.

SIP registration is normally used for one or several SIP devices - often SIP phones, that maintain a constant state of connectivity with an IP switch or SIP provider. Prophecy is able to utilize SIP registration to provide transport for small usage systems deployments, with usually less than 10 concurrent calls.

SIP TRunking uses IP Authentication between 2 devices, in order to establish authentication and allow transmission and receipt of data packets to occur. In effect, the IP Gateway of a SIP provider is known by the transmitting SIP device so that the media is allowed to pass. This method of transport requires the specific IP address knowledge of the SIP provider, and SIP end user device - so that a direct connection can occur between the 2 points.

Wholesale or large scale VoIP service providers and customers typically use this kind of VoIP transmission in order to allow large volumes of traffic to pass quickly through IP Gateways.

In most cases, small scale Prophecy deployments are able to effectively use SIP Registration services, while large scale deployments will utilize SIP Trunking scenarios for transport.

In future posts I will address both SIP Registration and SIP Trunking, as I discuss various topics around how Prophecy works with other VoIP Providers and Devices.

Until then, try out our BusinessVoIP service - which uses SIP Registration to maintain a state-ful connection to our Voxeo BusinessVoIP network. Just a teaser, there are many cool things that you can do with a state-ful connection to a VoIP Network.

VoIP is Tricky. While we’ve come a long way in just a few years and have seen great technological change and mass acceptance happen relatively “overnight” compared to the prior industry changes, we still have a few things to settle.

I spent much of 2007 in a unique position that provided an incredible view into the emerging VoIP Market.. I started a large scale carrier review to find VoIP capacity for the Voxeo Network. Voxeo is a SIP based platform, therefore - it speaks native VoIP. Any other transport medium (TDM) apart from VoIP that terminates into our platform must be converted to VoIP so we can receive and send calls. This is a relatively unique (and fortunate from our perspective) requirement, and it has enabled me to embark upon an epic quest to seek out Carriers of all kinds in an effort to acquire “VoIP Minutes” for our platform.

Essentially, in early 2007 - I began my journey by seeking out every major carrier in an effort to find out where they were with VoIP - and how I could acquire services and minutes from each carrier.

I began with the major players, AT&T, Verizon, XO, Qwest, etc.. and moved on to regional players, “B” grade carriers, Resellers, Garage Telco’s, as well as new and emerging Hybrid and pure VoIP carriers and Peering Players. Some of my exploration has taken my studies overseas to look into the International market.

My Journey was (and still is) filled with drama, adventure, deception, hope and dashed dreams - and of course humor.. in short - it’s been quite a task to really get the true answers on 1. availability. 2. capacity. 3. potential expansion capability. 4. pricing (oh boy - that’s a saga..) 5. platform architectures 6. feature availability and 7. standards and compatibility.

In future blogs I’ll go further into these adventures, but I’d like to begin this saga by describing the exact treasure it is that I have been seeking. Is it minutes? No. Ports? No. Is it concurrent calls? No. Is it Bandwidth or capacity? No.

The real “prize” that allows a carrier accept calls in a robust fashion is something often overlooked by carriers and IP Switch vendors alike. It is “Call Setups Per Second”. In the modern world - automated devices such as the Voxeo hosted network don’t have a problem receiving or making calls, but VoIP resources which receive and handle all these calls - are right now (in 2007-2008) - limited.

Call Setups per Second is the ability of an IP switch to process multiple calls initiations while handling other processing functions required by the device. In short, there are vendors that do this well, and vendors that do not. The ability of a VoIP network to handle vast amounts of VoIP calls often comes down to 1. the device that is handling the traffic and 2. the number of Call Setups per second that this device can process.

There are other variables that affect performance of IP Gateway and IP Switch devices such as call duration, and Codex used, and eventually - final destination of the call. However - the blocking factor of any inbound call to an IP Switch usually comes down to the Call Setup Per Second threshold.

So, CPS is the “Golden Egg” that I’ve been looking for from all of the major VoIP carriers.. Calls per Second. Ultimately - how each of the carriers that I’ve reviewed have responded to the test for this “treasure” has allowed me to measure the capacity, durability and scalability of their VoIP networks.

The big surprise - which brings me back to my opening sentence (VoIP is Tricky) - is that each Carrier has designed and built their network in very different ways, using different technology, and often operating on very different principles of functionality. Sometimes - the big guys got it wrong and the little guys got it right.. sometimes the choices made by “folks in the know” were surprisingly short-sighted and placed very limiting restrictions on future build-out. The fun part of all this, has been figuring out from the the classic analogy of the can of Crisco shortening- that the pie on the front of the can isn’t really what’s inside.
Chris Maxwell