We're moving!Blogspot has been a great way to start blogging, but it has limitations. We've just completed a brand new annex to the smartvox web site called the Smartvox Knowledgebase - it is a combined blog plus a complete archive of all the blogs and VoIP articles I've written in the last few years. Please visit the new Smartvox Knowledgebase at:http://kb.smartvox.co.uk/. To read the latest revision of this article on Caller ID in SIP and Asterisk at the new site, follow this link: http://kb.smartvox.co.uk/asterisk/how-it-works/caller-id-in-sip-and-asterisk-part-1 |
Equipment receiving calls, whether a humble handset or a sophisticated Call centre ACD system, likes to know the identity of the caller. It may simply display the caller's number on an LCD display, look it up in a directory so the caller's name can be displayed or pre-populate a screen with information about the caller recovered from a database. However, the network also needs to know the caller's identity because it may be important for billing or to notify the emergency services of the caller's location.
In the UK, a caller may choose to block their ID so it is not visible to the called party by prefixing the dialed number with 141. However, this must not interfere with the more serious network requirements like billing or 999 call location. To accommodate both requirements, telephony signalling protocols tend to use two different pieces of data - a display ID that can optionally be blocked and an asserted ID or ANI that cannot. Protocols such as ISDN also include single bit privacy flags that show if the ID should be hidden.
The SIP protocol also has elements that allow for all the caller ID requirements. The From header provides basic caller ID data but it is too easily modified, blocked or spoofed to be of use to the network. Alongside this, the SIP protocol was extended to support the use of the Remote-Party-Id (RPI) header which should be added to an Invite by the first server within the trusted network cloud. It is described in an IETF memo:
http://tools.ietf.org/id/draft-ietf-sip-privacy-04.txt
The RPI header is added by one of the network servers so it should provide a much more reliable and trustworthy identification than the From header which can be set by users at the client device. The IETF memo also makes provision for the inclusion of certain tag values on the RPI header: "privacy" indicates to what extent the ID should be hidden and "screen" indicates what level of trust the network associates with the Remote-Party-ID information.
Another approach is described in RFC 3325. It explains the requirements for provision of an authenticated caller ID within a trusted network using the P-Asserted-Identity (PAI) header to convey the authenticated identity of a caller along with a separate Privacy header to show if this data must be hidden.
Decisions about adding or removing these ID headers depend partly on whether the call is entering or leaving your own infrastructure cloud and whether the remote peer or UA is trusted or not. If necessary, servers must use authentication challenges to ensure that a remote device can be trusted and only then should they add a P-Asserted-Identity header. When a request is sent to an untrusted device, it is necessary first to delete any such headers.
What control is provided within Asterisk?
Regrettably, all I have here are questions. Lots of questions and very few answers. Lets start with some basic facts about the configuration settings available in sip.conf:
Asterisk has two parameters for controlling handling of Remote-Party-Id as follows:
sendrpid=yes¦no : If an RPI header should be sent to the peer
trustrpid=yes¦no : If the RPI from this peer can be trusted
However, I am not sure what these parameters mean in practice. For example, will Asterisk automatically add an RPI header when sendrpid is set to "yes" or will it remove the header when set to "no". When I get time I will do some testing to see how it actually behaves.
To see the results of my testing, take a look at Part 2.
How does Asterisk handle caller ID when bridging calls from SIP to ISDN? For example, does it automatically populate the ANI and other caller ID fields using data sent in the RPI and From headers? If so, does this behaviour depend on the setting of trustrpid?
Areas where Asterisk seems to be very weak include:
1. The handling of P-Asserted-Identity. The only control I am aware of is the ability to add a PAI header (and a Privacy header) using the SIPAddHeader() function. Why doesn't Asterisk have a SIPDeleteHeader() function?
2. Access to the Privacy settings of ISDN calls. You can see the setting using the pri debug command at the CLI, but there seems to be no way of accessing the data within the dial plan.
No comments:
Post a Comment