[asterisk-bugs] [Asterisk 0013072]: [feature request] Charge Number (ANI) is not delivered through SIP

noreply at bugs.digium.com noreply at bugs.digium.com
Sat Jul 19 03:50:26 CDT 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13072 
====================================================================== 
Reported By:                olivier1010
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13072
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.21 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             07-14-2008 12:48 CDT
Last Modified:              07-19-2008 03:50 CDT
====================================================================== 
Summary:                    [feature request] Charge Number (ANI) is not
delivered through SIP
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 :

[custom-ani-test]

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 at 192.168.200.60:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.200.100:5060;branch=z9hG4bK1c475f7b;rport
From: "Test CID" <sip:050505 at 192.168.200.100>;tag=as538cf9f1
To: <sip:69 at 192.168.200.60:5060;transport=udp>
Contact: <sip:050505 at 192.168.200.100>


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 at 192.168.200.60:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.200.100:5060;branch=z9hG4bK1c475f7b;rport
From: "Test CID" <sip:050505 at 192.168.200.100>;tag=as538cf9f1
To: <sip:69 at 192.168.200.60:5060;transport=udp>
Contact: <sip:0325484565 at 192.168.200.100>

It seems that ANI does not work over SIP.



Thanks for your listening.



====================================================================== 

---------------------------------------------------------------------- 
 oej - 07-19-08 03:50  
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-19-08 03:50  oej            Note Added: 0090477                          
======================================================================




More information about the asterisk-bugs mailing list