Speaking of Standards

Have you ever wanted to send information between two applications using SIP that didn’t fit into one of the existing “headers” that are using in the SIP communication exchange? Did you look through the various headers in RFC 3261 (and associated RFCs) and find that none fit exactly what you were seeking to send?

If so, what you can use instead is what is called a “private header” or “P-header” for short.

Before we jump into P-headers, let’s first take a moment to switch to the world of email. With email, there are so-called “experimental headers” that are sent in the SMTP exchange that all start with “X-”. Here are some examples:

X-Priority: 	Normal
X-Mailer: 	Apple Mail (2.753)
X-Authentication-Warning: 	blogs.voxeo.com: apache set sender to wordpress@blogs.voxeo.com using -f
X-Spam: 	exempt
X-Mail-From: 	<wordpress@blogs.voxeo.com>
X-Source-Ip: 	[(unknown)]

These “X-” headers are added by various programs to email messages that are sent and share the common characteristic that they are all informational. They do not indicate any action that has to occur. They are not SMTP commands. Each of these X-headers are purely containers of information that is passed along in the SMTP message. On the receiving end, the application accepting the SMTP connection can look at those X-headers and then potentially decide to take some action on the received message based on the contents of those X-headers. If a receiving application doesn’t no what to do with an X-header it receives, it simply ignores the header. With regard to the “informational” nature of X-headers, the idea is that if an application ignored all X-headers, the email message should still be able to be delivered. X-headers add extra information and capabilities, but don’t block the basic existing SMTP.

These “experimental” headers are now widely used by mail programs, by anti-spam software and basically all sorts of other programs that interact with email. They are a way to pass along extra information about the email message. Companies, vendors and individuals can all define and use their own X-headers to try out new services and offerings. They don’t need to check with anyone. They can just go ahead and create a new header to try it out. (Presumably checking first to see that their new name didn’t conflict with existing X-headers on their network.)

Back in the world of SIP, the IETF defined a process in RFC 3427 for extending SIP that was similar to the experimental headers of email. The fundamental difference was that in SIP instead of beginning with an “X-” the headers begin with a “P-”, as in “P-Asserted-Identity”. Otherwise, they are very similar. P-headers in SIP must, like the X-headers of email, be purely informational. They cannot be used to create new commands and must not interfere/block the regular transmission of SIP messages. They merely pass extra information that the receiving application can choose to do something with (or not).

Here are some examples:

P-Asserted-Identity: "Dan York" <sip:dan@company2.com>
P-Charge-Info: <sip:proxy1@company2.com>
P-Charging-Vector: icid-value=1234bc9876e;
                   icid-generated-at=192.0.6.8;
                   orig-ioi=home1.net
P-Visited-Network-ID: "Visited network number 1"
P-I-Made-This-Up: "Pretty silly, isn't it?"

Here is how a couple of these would look in an actual SIP message:

INVITE sip:1234@company2.com SIP/2.0
Via: SIP/2.0/UDP proxy.company2.com:5060;branch=z9hG5bK21ghi7ab34
Via: SIP/2.0/UDP sip.company1.com:5060;branch=z9hG4bKnashds7
To: sip:1234@company2.com
From: sip:dan@company1.com;tag=451248
Call-ID: 324817637683475998ababcc10
CSeq: 1 INVITE
Contact: sip:dan@company1.com
Max-Forwards: 50
P-Asserted-Identity: "Dan York" <sip:dan@company2.com>
P-Charge-Info: <sip:proxy1@company2.com>

The application receiving this SIP message can then choose to read these headers and potentially perform some action based on the contents of the headers. (If you are developing your application on our platform and using CCXML, we’ve provided instructions for how to access those SIP headers.) For instance, the “P-Asserted-Identity” header is very often used as the “Caller ID” that is displayed on the end user’s phone or other SIP device.

So what should you do if you want to start using a P-header to pass information via SIP between two applications?

First, you should head over to the IANA registry of SIP headers to see if someone has already defined a P-header that might do what you are looking to do. For instance, P-Asserted-Identity has been defined in RFC 3325. The 3GPP has defined several P-headers related to IMS in RFC 3455.

Second, if you don’t see any defined P-headers, you might want to search the IETF database of Internet-Drafts to see if there are any P-headers in a proposal stage that might work for you. The process of registering a P-header with IANA (so that people know about it and to prevent naming conflict) is documented in RFC 3427 and first involves the creation of an Internet-Draft document. For instance, I have an Internet-Draft submitted on the P-Charge-Info header that we are seeking to register with IANA.

Third, while in the IETF database you might also just want to search for the general type of information you are seeking to pass between applications. It may be that there is some work underway in an IETF Working Group that would wind up creating standard headers (versus P-headers) to pass the information you are seeking to pass.

Finally, if you are unable to find any current or in-progress P-headers, you can create your own. Keep in mind that it should start with “P-” and the general convention has been to put a dash between any words in the name and to use initial capitals, as in “P-Asserted-Identity”.

For more information about creating P-headers, please do read RFC 3427.

Technorati Tags:
sip, ietf, standards

Tags: IETF, SIP

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.