Tag Archives: Caller ID

Presenting the caller Name in IMS

IMS / VoLTE, Mobile Networks, RFCs & Standards, VoIP, , ,

SIP has got a multitude of ways of showing Caller ID, PAI, R-PAI, From, even Contact, but the other day I got a tip (Thanks John!) that you can set a name as the Caller ID in the “Username field “display name” part of the P-Asserted-Identity for the leg from the TAS to the UE, and it’ll show up on the phone, and they’re right.

For example I put:

P-Asserted-Identity: "Nick Jones" <sip:[email protected]>

And lo and behold when I called a test phone on my desk (A Samsung IMS debug phone) here’s what I saw:

There are no contacts defined in this phone, that name is just coming from the SIP INVITE that goes to the phone.

Support for this feature is hit-and-miss on different IMS stacks on different phones, and of course is Carrier Bundle dependent, but it does work.

One thing that it doesn’t do is show the name in the call history, and if you go to “Add as Contact” it still makes you enter the name, clearly that’s not linked in, but it’s a kinda neat feature.

SIP Extensions – RFC4474

RFCs & Standards, Security, VoIP, , , ,

Caller-ID spoofing has been an issue in most countries since networks went digital.

SS7 doesn’t provide any caller ID validation facilities, with the assumption that everyone you have peered with you trust the calls from. So because of this it’s up to the originating switch to verify the caller ID selected by the caller is valid and permissible, something that’s not often implemented. Some SIP providers sell the ability to present any number as your CLI as a “feature”.

There’s heaps of news articles on the topic, but I thought it’d be worth talking about RFC4474 – Designed for cryptographically identifying users that originate SIP requests. While almost never used it’s a cool solution to a problem that didn’t take off.

It does this by adding a new header field, called Identity, for conveying a signature used for validating the identity of the caller, and Identity-Info for a reference to the certificate signing authority.

The calling proxy / UA creates a hash of it’s certificate, and inserts that into the SIP message in the Identity header.

The calling proxy / UA also inserts a “Identity-Info” header containing

The called party can then independently get the certificate, create it’s own hash of it, and if they match, then the identity of the caller has been verified.