Summary:	ASTERISK-12377: [feature request] Charge Number (ANI) is not delivered through SIP
Reporter:	olivier1010 (olivier1010)	Labels:
Date Opened:	2008-07-14 12:48:58	Date Closed:	2011-06-07 14:03:13
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
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@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@192.168.200.100>;tag=as538cf9f1 To: <sip:69@192.168.200.60:5060;transport=udp> Contact: <sip:050505@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@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@192.168.200.100>;tag=as538cf9f1 To: <sip:69@192.168.200.60:5060;transport=udp> Contact: <sip:0325484565@192.168.200.100> 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: <pre>   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.