Summary:ASTERISK-12377: [feature request] Charge Number (ANI) is not delivered through SIP
Reporter:olivier1010 (olivier1010)Labels:
Date Opened:2008-07-14 12:48:58Date Closed:2011-06-07 14:03:13
Versions:Frequency of
Description:With traditionnal telephony (SS7), we are using charge numbers for a clear identification of the caller.

ANI transmission is mandatory, for urgency services as well as law conformity.
Without ANI, then there is no possibility to hide the caller ID, neither to manage billing for accounts having differents Caller-ID.

The caller ID can be hided or not by the sending party, but the charge number cannot be hided.

Here is the mains fields we have in SS7 for number identification :

• Called Party Number
• Charge Number
• Originating Line Information Parameter
• Calling Party Number
• Original Called Number
• Redirecting Number

We tried this inside asterisk 1.4.21 :


exten => *889,1,Answer
exten => *889,n,Set(CALLERID(all)="Test CID"<050505>)
exten => *889,n,Set(CALLERID(ANI)=0325484565)
exten => *889,n,Dial(SIP/69,120)
exten => *889,n,Hangup

And we got this sip debug :

INVITE sip:69@;transport=udp SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK1c475f7b;rport
From: "Test CID" <sip:050505@>;tag=as538cf9f1
To: <sip:69@;transport=udp>
Contact: <sip:050505@>

We can see that the ANI (charge number) as not been set. The ANI should be present in the Contact: field . We can see that the Caller-ID number has been duplicated here.

We should have :

INVITE sip:69@;transport=udp SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK1c475f7b;rport
From: "Test CID" <sip:050505@>;tag=as538cf9f1
To: <sip:69@;transport=udp>
Contact: <sip:0325484565@>

It seems that ANI does not work over SIP.

Thanks for your listening.

Comments:By: Tilghman Lesher (tilghman) 2008-07-15 13:25:40

The RFC has this to say about the Contact header:
  Contact contains a SIP or SIPS URI that represents a direct route to
  contact Alice, usually composed of a username at a fully qualified
  domain name (FQDN).  While an FQDN is preferred, many end systems do
  not have registered domain names, so IP addresses are permitted.
  While the Via header field tells other elements where to send the
  response, the Contact header field tells other elements where to send
  future requests.</pre>
Note that ANI is nowhere in there.  I appreciate that you would like to have the ANI, but the lack of an ANI in the contact header is not a bug.  At best, this is a feature request.

By: Olle Johansson (oej) 2008-07-18 05:08:28

I don't understand why the ANI should be in the Contact. That's just plain wrong. The big question is where it should be?

By: olivier1010 (olivier1010) 2008-07-18 17:59:49

I've seen one manufacturer using the contact field for ANI and RDNIS :

contact: ANI: number

contact: RDNIS: number

It seems that this is not standardized, but there is a need for this.

Another possibility is to use a P-asserted-identity SIP header, but it would be simpler to define a charge number (ANI) mapping inside the basic SIP header set.

P-asserted-identity is not mandatory, ANI is mandatory for telephony public networks.

That's why i think that there should be something done inside SIP standard for this.

The complexity of SS7 is certainely not (yet) needed inside SIP, but some basic telephony functions like ANI should be supported.

By: Olle Johansson (oej) 2008-07-19 03:50:25

Well, there are many ways to send caller IDs - remote party ID, P-asserted-identity, the From: header and custom headers. Modifying the Contact: just does not make sense. And if you want to change the SIP standard, this bug tracker is the wrong forum. The IETF is the right forum for that.

Asterisk does support Remote party ID. You can add P-asserted-identity headers from the dial plan also, and manipulate both the display name (caller ID name) and caller ID number (from URI, username part) too.

By: Tilghman Lesher (tilghman) 2008-07-24 01:17:08

At this point, since the change is not merited, any further discussion needs to occur either on an IETF list or on the -dev list.  I am suspending this issue for the time being.  Please do not reopen this issue without discussion on a mailing list as to the correct place to transmit ANI.