Summary:	ASTERISK-06467: [patch] Implement Called Party Identification
Reporter:	John Laur (gork)	Labels:
Date Opened:	2006-03-03 11:53:42.000-0600	Date Closed:	2007-08-22 15:20:35
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) calledrpid-50187.diff ( 1) chan_sip.c.patch.1.2.17 ( 2) gork-calledparty.diff ( 3) gork-calledparty.extensions ( 4) gork-calledrpid-trunk.diff
Description:	This is a patch and associated example of implementing Called Party Identification into Asterisk in a minimally-invasive way. Many clients such as the Polycom SIP hardphones have the capability of displaying information about the party a user is *calling* on their display. The patch adds an application "SIPCalledRPID" which, when called in the dialplan, causes the Remote-Party-ID header containing called party information to begin to be sent to the calling party during call progress messages: 180 Ringing, 183 Progress, and 200 OK (upon answer) The called party information may be updated throughout the call and the attached extensions example shows one way this can be done. I developed this patch with assistance from justinu who had written an earlier patch to implemented Called Party Identification. ****** ADDITIONAL INFORMATION ****** Implementing Called Party ID in a way that would not require a new application or changes to the dialplan to implement the support is possible because in theory Asterisk can in most cases determine what two endpoints are connected during a call. In practice, however, the generic message passing functions in Asterisk do not seem capable of handling this sort of thing without a fairly major change to some very core components (at least as far as I can tell). Doing this sort of thing directly in the dialplan does have some advantages, though. Future work might consist of this application causing a SIP reinvite to be sent to the caller (with all the same parameters as the current call) in order to actively update the display at any time during a call. As it is now, the only time the display would update is whenever a 180/183/200 message is sent to the phone. The application "Ringing" will cause this to happen. This patch is against Asterisk-1.2.4, primarily because I need it in my production environment. My disclaimer was sent a copule years ago and I have not submitted any patches in some time. If I have to update it or send a new one, let me know.
Comments:	By: Olle Johansson (oej) 2006-03-04 05:29:41.000-0600 All patches for new features in the bug tracker has to be for svn trunk, not the release version. Please update your patch for trunk! By: Olle Johansson (oej) 2006-03-04 05:33:37.000-0600 Some questions: - What happens if we get many different incoming "ringing" on one call? I think  this should not be triggered by a ringing, but only by on the 200 OK that we  accept. - Can we implement this in a more generic way? I generally hesitate a lot on functions  or apps that are channel-specific. It's better to update the core, then implement the  channel-specific part in the channel. Other channels may have the same functionality. - Can you point me to any documentation on this? RFC, Drafts? By: John Laur (gork) 2006-03-04 12:42:33.000-0600 I can rewrite it for trunk; should be pretty similar; just wanted to get some discussion going. If you get multiple 180 Ringing messages being sent to the calling phone the Called Party ID will be updated if it is changed. For instance if you dial a call to a person's desk phone and the call then forwwards to their cell phone, you can update the called party id to indicate this to the caller through the ringing. This is the desired behavior. If called party id is only sent upon 200 OK when the call is answered you won't know who you are connecting to until the call is answered. I have attempted to implement this in a generic manner, however the problem is that the asterisk architecture for caller ID really can't support another name/number pair and functions like ast_indicate have very little information about the call available to them in order to allow this to be implemented in a generic way. Also the implementations of called party identification are so wildly different between, say, SISP and SCCP that channel specific implementations are pretty much necessary. I'm not a big fan of the channel specific features either, but I'm the third person that I know of who has tried to implement this feature into asterisk in a generic manner and I have to admit that I'm not up for rewriting that much of the core for a feature that's basically only supported on SIP UA's anyway. Essentially what would need to happen for this to be properly implemented would be to allow any generic call progress function to look up caller id information about *both* endpoints of a call. I'm not even sure this is goal is reasonable. The header is defined in draft-ietf-privacy-.02.txt but I am unable to locate a version of this actual file online. However Cisco has a synopsis that is easier to digest: http://www.cisco-secure.net/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t13/ftsipext.htm By: Olle Johansson (oej) 2006-03-04 15:10:09.000-0600 Guess we need payload on control frames to handle this feature in a generic way. Thanks for the very complete answer, I'll look into this. The Asterisk internals can be changed if needed :-) I needed something like this for transfers, so the patch arrived in time. Let me play around with it for a while. By: John Laur (gork) 2006-03-07 13:31:49.000-0600 Updated and for SVN trunk and tested. I left the 1.2 patch in the attachments for anyone who might need it. BTW Even if the internals can be changed so that the indicate functions can lookup caller id information about the endpoints (which would be great!) it would still be useful to have this kind of app around to override it. Updating the display during call progress based on the dialplan is a really neat feature. By: Olle Johansson (oej) 2006-03-07 13:42:04.000-0600 If we can avoid dialplan functions that are dialplan specific, we will do that. This does not seem like a SIP specific function to me, so we need to look for generic solutions. By: John Laur (gork) 2006-03-07 14:01:11.000-0600 What if instead of making this specific to the Remote-Party-ID header I changed the function to behave like SIPAddHeader but to add sip headers to notifications sent to the calling channel instead of the called channel? At that point it would actually be SIP specific and allow for this Remote-Party-ID implementation among other things in the future. I understand that SIPAddHeader was to be deprecated in 1.2 but that is no longer the case in SVN, so obviously there is some elbow room for functions like this to edge in. Honestly I do not believe that Asterisk could support this functionality in a generic way without many major internal changes. I have neither the time nor the knowledge of Asterisk internals to take on such a task, so hopefully that will not mean the end of this feature. I also do not know the particulars of if or how other channels implement similar functionality either. The only easier way to make this generic that I thought of would be to maybe extend the hint context to allow for callerID information to be associated to an extension. Then there would be a generic function to return the caller ID from an extension number which could be implemented per-channel. I couldn't figure out how this would work well though and again, I do not know enough about Asterisk internals to implement this either, so that is why I used this approach. By: Olle Johansson (oej) 2006-03-28 19:16:01.000-0600 Regardless of implementation in the core/dialplan, we need to send a RPID for 200 OK as well, because that's when we really know who's answering. We might get multiple 180, but only react to the first 200 OK. By: Olle Johansson (oej) 2006-03-28 19:24:56.000-0600 sip:%s@foo.com> Hardcoding the domain is no good. By: pj (pj) 2006-03-30 06:31:43.000-0600 Hello, I'm trying this patch against trunk rev.12343 and it working fine for me, why Olle commented this patch as FAIL in functionality (& architecture) review? Is there any other way, how to display called party name on sip phone? PJ By: Paul Cadach (pcadach) 2006-03-30 07:48:55.000-0600 Probably because: 1) this functionality allowed not only for SIP channels (but H.323, ISDN, etc. too); 2) read Olle's comments carefully. By: pj (pj) 2006-03-30 08:03:38.000-0600 yes, I know, that implementing this feature in general manner would be better, but this feature is generaly wanted mainly for sip and also can be start point to generalize later... remember other patch - jitter buffer for sip - that is also working only for sip-sip and sip-zap channels and not for iax/h323 etc. and this patch is considered so perspective, that is even included in Olle's test branch... PJ By: Paul Cadach (pcadach) 2006-03-30 08:27:09.000-0600 Jitter buffer works well at least for H.323 which I tests and extends over SVN trunk (chan_h323). IAX have much different networking architecture and is not uses RTP to transport voice. Also, IAX already have its own jitter buffer (much earlier than for RTP streams). So, it's just another story. I'd just fast review the patch. My dissatisfactions: 1) It is not uses/parses information provided by another party; 2) It is not passes information between two channels; 3) It is not uses standardized name/number representations (name <number>) etc. By: darkskiez (darkskiez) 2006-04-17 04:01:45 Just have to say a big thankyou for this patch, i've been looking forward to it for some time. However, this didnt work for me on Cisco SIP firmware 8.2, It changed the display to Anonymous. I saw that in the header the phone sent, it included the privacy field. So, after adding privacy=off to the RemotePartyID string, it worked a treat. " <sip:%s@foo.com>;party=called;id-type=subscriber;privacy=off;screen=yes" So I guess this should respect the caller presentation here too? The SCCP channel uses the SetCalledParty application which uses the same format as SetCallerID, that makes more sense to me, although I guess that should in turn be a function to set this these days, no? Mark By: darkskiez (darkskiez) 2006-04-17 06:58:53 Is there any way to make the display update via the dial plan for transferred calls? I assume this would need some code changes insead. Also, for parking it would be cool, when you dial a parking slot to have the number update to the number it was parked in, and when also you dial a parking slot to retrieve a call, to update the number/name then. By: John Laur (gork) 2006-04-17 15:17:52 Good to hear that it basically works for cisco phones too after setting privacy=off. The main problem with this whole patch is that no matter how you boil it down it is just going to be a SIP specific hack/addon without substantial work. Regarding oej's comments: 1) The patch does cause RPID to send during a 200 OK when there is an actual call completion made such is caused by Answer() in the dialplan. There are multiple functions in sip.c that send 200 OK for various reasons, but the patch only sets the RPID in the one that matters, an OK response to INVITE. RPID headers in other OK messages such as those that are simply sent as ACK's seem to be ignored by the UA's I have to test with. 2) The domain is hardcoded because it is simply ignored by the UA. The purpose of this is to alllow a telephone's display to be updated with called party identification, not to properly implement called party ID in asterisk, which, as noted earlier will require substantial changes to the core in order that a call can gather information such as callerID about the remote endpoint which asterisk doesnt yet support in any clean or generic way. I can make the domain name an argument to the SetCalledRPID function, but it will not make any difference. If the code generating this header at this point were able to retrieve any information about the actual remote party, the function wouldn't be necessary in the first place. Technically a phone's display will be updated whenever it receives an updated call progress message with a different RPID header. SIP proxies do this by issuing a gratuitous REINVITE with all the information as the current call. So, yeah, the display could be updated at a call transfer (and I'd like to figure that out) but if you try to figure out how SIP transfers actually work in asterisk, you'll see why it is complicated. This behavior also requires the core to support one call getting information about the remote endpoint it is connected to. I honestly have no problems with the patch being rejected as-is. While it provides a very useful function, it is not and cannot easily be made (by me) generic. I will continue to maintain it so long as it is useful. As others have said, chan_sccp has a similar channel-specific funciton, so who knows how that passed this test? I posted it as a starting point and hopefully to spark some interest from someone that knows better how the core functionality might be extended to properly support called party id. By: Serge Vecher (serge-v) 2006-06-13 11:44:20 gork: what's the status of the work here? By: Olle Johansson (oej) 2006-06-14 09:05:03 This is waiting for my review. By: pj (pj) 2006-06-26 14:05:37 Hello, anybody here is able to update this usefull patch to work with current asterisk trunk and * stable version? Or any better solution currently exist to display called party name on dialing phone display? thx PJ By: Olle Johansson (oej) 2006-06-26 14:12:18 After a new review, I say that this code is not ready for commit. Moving it to "experimental" for now, since I do like the functionality and would like to continue this work after 1.4, based on gork's code. By: pj (pj) 2006-07-11 11:13:05 Hello, this patch is working quite well with ci$co 7912, but with ci$co 7941 I'm getting immediately reorder tone afer ringing, any idea? maybe because of hack with  <sip:@foo.com>? By: Serge Vecher (serge-v) 2006-07-11 11:47:32 pj: thanks for testing the patch. As oej said, this code is in "experimental" stage of development, so quirks are "expected." Development will pick up after 1.4 branch is forked from trunk. Unless you can work on the patch yourself, the only option is to wait or get a contractor. By: Paolo Subiaco (mesfet) 2006-08-18 14:56:14 I think that a very useful feature is the ability to change the called name  displayed in the caller phone just setting a variable like CALLEDID(num) and CALLEDID(name). Just think about the possibility to dial a "short number" in a SIP/IAX phone, and asterisk which fetch from a database the real PSTN number to call and its name: it's useful to display the called name in the caller display, to be sure that the "short dialed number" is right. I mean: ......... exten => _XXXX,n,MySQL(Fetch fetchid ${resultid} called_name called_number) exten => _XXXX,n,Set(CALLEDID(name)="${called_name}") ;exten => _XXXX,n,Set(CALLEDID(number)="${called_number}") ...... If the originator phone support this feature, send a message (SIP or other protocol) to change what is displayed in the caller phone. Thank you in advance for the very good work! By: jmls (jmls) 2006-11-01 05:32:30.000-0600 oej, what is the status with this and your review ? Thanks. By: jmls (jmls) 2007-01-07 03:15:46.000-0600 oej - where should this patch be heading ? By: Matthew Nicholson (mnicholson) 2007-01-09 16:42:29.000-0600 I added an updated version of the patch for trunk rev 50187. By: darkskiez (darkskiez) 2007-01-15 08:11:05.000-0600 I've been using this patch with great success since it was very first posted, but the privacy=off was not added to the lastest patch to work on cisco 79xx phones 7.x series firmware. Also with the 8.x series firmware the foo.com is displayed on the screen as it is different to the phones domain, therefore this must be configurable. - sprintf(rpid, "\"%s\" <sip:%s@foo.com>;party=called;id-type=subscriber;screen=yes",name, number); +       sprintf(rpid, "\"%s\" <sip:%s@foo.com>;party=called;privacy=off;id-type=subscriber;screen=yes",name, number); By: Martin Butler (mbutler) 2007-03-17 08:44:22 Hi, I'm trying this with an Aastra 480i phone that is supposed to support sip header change (have an sip update callerid function). When I try to execute SIPCalledRPID, I receive this message: This application is only useful for calls originated from SIP UA's I may be wrong, but a phone is a SIP UA, right? By: Serge Vecher (serge-v) 2007-03-19 08:40:59 mbutler: please attach a SIP debug trace illustrating the problem as per following: 1) Prepare test environment (reduce the amount of unrelated traffic on the server); 2) Make sure your logger.conf has the following line:   console => notice,warning,error,debug 3) restart Asterisk with the following command:   'asterisk -Tvvvvvdddddngc | tee /tmp/verbosedebug.txt' 4) Enable SIP transaction logging with the following CLI commands (1.4/trunk commands in parenthesis): set debug 4 (core set debug 4) set verbose 4 (core set verbose 4) sip debug (sip set debug) 5) Reproduce the problem 6) Trim startup information and attach verbosedebug.txt to the issue. By: Martin Butler (mbutler) 2007-03-25 15:43:04 I've contacted Aastra tech support and they told me that this phone is looking for  a Contact update and not Remote-Party... Is that an easy thing to modify? By: Marty Riedling (mariedling) 2007-06-15 13:45:06 You might want to change the following line: sprintf(rpid, "\"%s\" <sip:%s@foo.com>;party=called;id-type=subscriber;screen=yes",name, number); to: sprintf(rpid, "\"%s\" %s;party=called;id-type=subscriber;screen=yes",name, p->our_contact); so that the sip info gets set correctly. By: John Laur (gork) 2007-06-18 10:24:55 Interesting; the p->our_contact field was not even available when this patch was hacked together; is it a reliable SIP id when the remote contact is not a SIP peer? If you can modify 'our_contact' from the dialplan, it might seem the two biggest stumbling blocks to getting this into asterisk might be overcome -- the 'foo.com' domain hackery and the SIP-specific dialplan application, 'SIPCalledRPID'. By: pj (pj) 2007-06-18 12:52:20 I think, that would be better to continue work in another patch with similar goal - 8824, that works also with skinny phones and also with all sip phones, that supports rpid (tested with ci$co 7912/20/40/61 - sip&skinny). By: Marty Riedling (mariedling) 2007-06-19 13:51:17 I made a few changes to make this work better with what asterisk already had and added a few changes to make it work with the aastra phones. Patch chan_sip.c.patch.1.2.17. The only change to the dial plan is you need to add: exten => s,n,SipCalledRPID(${DB(AMPUSER/${EXTTOCALL}/cidname)},$EXTTOCALL)}) in macro-exten-vm after exten => s,n,Set(EXTTOCALL=${ARG2}) By: Marty Riedling (mariedling) 2007-06-19 13:55:59 pj - the patch I made for 1.2.17 should work with all sip phones that accept Remote-Party-ID (cisco, polycom, etc) P-Asserted-ID (cisco, polycom, etc) contact update (aastra) Note: aastra phones will only accept the calledid on OK. By: pj (pj) 2007-06-20 04:43:16 I think, that patches for new features, like this, must be applied to asterisk trunk, not releases. I tested this patch some months ago, with 7912 ci$co phone it works, but with new models 79x1 it doesn't, as I reported here, phone returns reorder tone. also, according to Olle comment, I think, that this implementation have no chance to appear in new asterisk release, so I think 8824 has better perspective. By: Marty Riedling (mariedling) 2007-06-20 07:36:14 After reading to code for the other I agree. I added a note yesterday to ask if my changes could be merged in. By: John Laur (gork) 2007-06-20 17:39:34 I agree that 8824 should take priority and this should be closed. The initial patch was put together when 1.2 was indeed current and Asterisk lacked many internal things necessary to make it work (for instance a thread handling a SIP channel had basically no way to discover any information about the remote channel to which it was connected) A lot of the things necessary to make this work properly have been added post-1.4 and the other patch integrates much better, though I really would like to see a way to update the Remote-Party-ID during a call when the remote end is transferred.. Ie receptionist calls to announce a caller -- Phone shows "Receptionist <0>" then when the transfer comes through the RPID header would be sent updating the phone display to "Joe Caller <800-555-5555>" By: am299 (am299) 2007-08-22 09:22:18 mariedling - I would like to try out the 1.2.17 patch but it is marked as "LICENSE NONE" and can not be downloaded. Would it be possible to sort out the license agreement? TIA. By: Marty Riedling (mariedling) 2007-08-22 11:31:35 I don't know how to change it so you can download it. Any help? By: pkempgen (pkempgen) 2007-08-22 15:00:14 See http://bugs.digium.com/main_page.php Mantis Changes -> 6) License Agreement (Disclaimer) Handling You probably need to sign the license agreement, wait for someone at Digium to accept it then upload the file again. By: Jason Parker (jparker) 2007-08-22 15:18:58 For old patches, you will have to have had a disclaimer on file before we switched to the new Mantis system. I've taken the liberty of submitting "pre-dated" license agreements for gork and mnicholson, so that their patches here can be reviewed.  However, it was not clear to me whether mariedling previously had a license agreement on file. Additionally, at the request of gork and others, I'm going to close this, in favor of ASTERISK-8584. By: Jason Parker (jparker) 2007-08-22 15:20:30 Superseded by issue 8824.