[VoiceOps] Caller-ID: SIP From vs. P-Asserted-Identity
Dan York
dyork at lodestar2.com
Tue Jul 24 17:31:48 EDT 2012
Jay,
I agree with Alex in that my research on the issue showed that Caller-ID was most often taken from P-A-I followed by From, with some people still using the now-deprecated RPID.
For passing the billing identifier, some network operators, carriers and ITSPs are using another header, P-Charge-Info, which I've been in the process of documenting for several years:
http://tools.ietf.org/html/draft-york-sipping-p-charge-info
(and am hoping will move along further in the next few months). The operators (and my prior employer was one of them) are using P-Charge-Info to carry a billing identifier that is completely separate from the identifier used for Caller-ID. They do that only between themselves, i.e. the header is stripped before being sent on to others.
This is certainly not the only way to pass this kind of billing identifier, but it's one of the ones out there.
Regards,
Dan
P.S. I am NOT with Sonus Networks, even though the latest version of the document looks like I am. The next version will correct that.
On Jul 23, 2012, at 5:21 PM, Alex Balashov wrote:
> Almost all commercial softswitch and SBC equipment we've run into
> prioritises CLID presentation thusly:
>
> 1. P-Asserted-Identity
> 2. Remote-Party-ID
> 3. From
>
> However, this is not so ubiquitous that it can be counted on one hundred
> percent. Some folks don't do it. Some only use RPID (even though it's
> a long-expired draft supplanted by PAI). Some expect RPID or PAI to
> play only a supplementary role, with their various screening and
> presentation options, and thus deny calls where the CLID in the PAI or
> RPID is inconsistent with the CLID in the From.
>
> Most, however, look at PAI, then RPID, then From. I can't speak to
> whether this is "correct" or is grounded in some sort of best-practical
> recommendation somewhere. It's just what they do.
>
> On 07/23/2012 05:08 PM, Jay Hennigan wrote:
>
>> Question for the experts:
>>
>> We have a scenario where a SIP user originates a call to the PSTN (not
>> 9-1-1) with a SIP From: header containing one DID and
>> P-Asserted-Identity showing a different DID.
>>
>> We expect the carrier to use the P-Asserted-Identity for billing and
>> recordkeeping but send the SIP From: out as the CLID to be displayed to
>> the called party.
>>
>> Typically this is done in a call center type scenario where an agent
>> wants the CLID to display the main number of the agent pool and not the
>> specific DID of the agent. Another scenario is a customer PRI-based PBX
>> that hairpins inbound calls back out to a traveling user and wants to
>> preserve the original caller's information.
>>
>> One of our terminating carriers uses the P-Asserted-Identity as the
>> displayed CLID and not the SIP From:. I feel that this is not correct.
>> Opinions?
>>
>> Numbers have been changed to protect the guilty...
>>
>> TO: <sip:8055550123 at www.xxx.yyy.zzz;user=phone>
>>
>> FROM: "Fred
>> Flintstone"<sip:+18055550199 at www.xxx.yyy.zzz;user=phone>;tag=1689985881-1343063740200-
>> P-Asserted-Identity: "Fred
>> Flintstone"<sip:+18055550177 at www.xxx.yyy.zzz;user=phone>
>>
>> TIME/DATE: Mon Jul 23 17:15:39 2012 (GMT)
>>
>> RESULT: Called party (8055550123) is seeing 8055550177 as calling
>> party's caller ID instead of 8055550199
>>
>>
>>
>
>
> --
> Alex Balashov - Principal
> Evariste Systems LLC
> 235 E Ponce de Leon Ave
> Suite 106
> Decatur, GA 30030
> Tel: +1-678-954-0670
> Fax: +1-404-961-1892
> Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
--
Dan York dyork at lodestar2.com
Phone: +1-802-735-1624 skype:danyork
http://www.danyork.com/
http://twitter.com/danyork
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120724/1cc561be/attachment.html>
More information about the VoiceOps
mailing list