[Home]

Summary:ASTERISK-08584: [patch] Remote (called) Party Identification - chan_sip & chan_skinny implementation
Reporter:Gareth Palmer (gareth)Labels:
Date Opened:2007-01-15 18:18:25.000-0600Date Closed:2010-04-06 09:30:06
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 1.4.18.patch
( 1) 1.4.19.patch
( 2) 1.4.19-experiments.patch
( 3) 1.4.21.1.patch
( 4) 1.4.21.2.patch
( 5) 1.4.23.1.patch
( 6) 1.6.0.1.patch
( 7) 1.6.0-beta7.1.patch
( 8) asterisk_core.log
( 9) asterisk_crash.log
(10) asterisk-1.6.0-beta8-connectedline-v2.patch
(11) cancelled-semiattended-transfer.log
(12) chan_dahdi-connectedline-r162548.diff
(13) chan_zap-1.6.0-beta7.1.patch
(14) chan_zap-1.6.0-beta7.1-v2.patch
(15) connectedline_1.4_svn_2010021400.diff
(16) directcall.log
(17) issue8824-143795.patch
(18) svn-111909.patch
(19) svn-114099.patch
(20) svn-128340.patch
Description:Overview:

This patch provides the ability to rewrite the called party information on
channel types that support it.  Implementations for the SIP (see note #1)
and Skinny (see note #2) channels have been provided.

Current features are:

1. Make changes whilst the call is progessing though the dial plan, ie:

  exten => s,1,RemoteParty("Voicemail" <123>)
  exten => s,n,Answer()
  exten => s,n,VoiceMailMain()

2. When using call pickup it will rewrite the caller information showing the caller that was picked up.

3. When unparking a call it will show the caller*id of the parked call.

The ability to rewrite the calling party identification on semi-attended
transfer is planned but doesn't work yet.

Implementation:

Transmission of the remote party data is done using indications with a new
subtype of AST_CONTROL_REMOTEPARTY, format of the data is:

 "name" <number>|presentation

Any channel specific code is kept in it's _indicate() handler. Once the channel driver has received the indication it uses the method specific to it; in the case of SIP it sends a 180/183 response if possible and with Skinny it uses transmit_callinfo().

Note #1: The SIP implemenation is only able to update the remote party
before the call has been answered as there is no re-invite support yet.

Note #2: I don't have any Skinny phones so no testing has been done on that part.

****** ADDITIONAL INFORMATION ******

Bug ASTERISK-6467 contains a patch the provides some of the same functionality for
SIP channels: http://bugs.digium.com/view.php?id=6643
Comments:By: Jason Parker (jparker) 2007-01-15 18:21:16.000-0600

Why not post this patch to issue 6643?

By: Gareth Palmer (gareth) 2007-01-15 22:40:59.000-0600

I thought it would be confusing and messy to post a considerably different patch, verbose usage explaination, svn revision number and disclaimer info etc all in a note attached to that issue.

Should I post it there instead?

By: Serge Vecher (serge-v) 2007-01-16 12:35:59.000-0600

since gareth's patch looks to be more extensive with generic framework and two channel implementations vs. one-channel specific implementation (which also failed architectural review by oej), I would vote to keep this work as a separate issue.

By: Matthew Nicholson (mnicholson) 2007-01-16 12:41:47.000-0600

Nice work, it looks well designed.

By: pj (pj) 2007-01-16 14:33:54.000-0600

instead to use application RemoteParty(), what about to use this as function eg. CALLEDID(name|num), to be consistend with CALLERID(name|num)?

By: Matthew Nicholson (mnicholson) 2007-01-16 14:39:37.000-0600

That is a good idea, and would be a pretty simple change.

By: darkskiez (darkskiez) 2007-01-16 18:15:46.000-0600

From reading the cisco 79xx release notes, when they added the called party support in 7.5, they also added the support for the SIP UPDATE message RFC3311 - and implied this [may|should|could] be used for display updates mid call.

If you get the time to implement updates after attended transfer, I do not know if  either a REINVITE or an UPDATE should be used, but I thought I should point it out there was a possibility, as it may need to be a configuration option per sip device for maximal compatibility.

Thanks for the patch, looking forward to testing it.

By: Gareth Palmer (gareth) 2007-01-16 19:40:13.000-0600

pj: Constructing and sending an remote party indication is an atomic action and can't be split up into multiple calls.

Also, the remote party state is not saved anywhere so wouldn't be able to read back the value of whatever you set ${CALLEDID(num)} to.

By: pj (pj) 2007-02-01 15:07:58.000-0600

I'm little confused, how to use this app in dialplan.
here is my example, expecting, that on display on calling phone should be displayed "called name" and <number> was called, but it does nothing :-(
tried with skinny (7920) and sip (xlite softphone) as "source" (calling) phone.


 _ZXX => {
      NoOP(${CALLERID(all)});
      RemoteParty("called name" <${EXTEN}>|allowed_passed_screen);
      Dial(IAX2/bill-gw/${EXTEN});
      Congestion;
 }




  -- Executing [320@default:1] NoOp("Skinny/324@PJ-9", ""Pavel Jezek" <324>") in new stack
   -- Executing [320@default:2] RemoteParty("Skinny/324@PJ-9", ""called name" <320>|allowed_passed_screen") in new stack
   -- Executing [320@default:3] Dial("Skinny/324@PJ-9", "IAX2/bill-gw/320") in new stack
   -- Called bill-gw/320

By: pj (pj) 2007-02-19 10:42:42.000-0600

what next with this patch? feature looks very interesting, but anybody here with success testing this feature? can you post part of your dialplan?
btw, patch is not aplicable to current asterisk trunk, anybody can update?

By: Olle Johansson (oej) 2007-02-19 12:20:27.000-0600

A few random thoughts and notes:

One problem is that there's no method to update caller ID *during* a call, i.e. a call transfer, in SIP. UPDATE and re-invite's does not do that, really. SNOM has a proprietary method for doing it.

It's still up for discussion.

I don't think we should use one string for the called ID either. We have to use the same structure as caller ID to be extensible. For SIP we need UTF-8 caller/called ID Names, for zaptel ascii (or something similar) and we also need to separate numbers from the various so we can present it in various formats.

Why are you doing this change:
- privacy = "full";
- screen = "yes";
- break;
+ return "privacy=full;screen=yes";

The chan_sip changes doesn't seem well thought of, but can be fixed. You change a lot
of source code without needing to do that, and send extra 180/183 messages, which
shouldn't be needed. A more clean and surgical patch would be appreciated. If there are other
issues you're trying to fix, we can take them separately. Suddenly adding a masquerade seems
very scary.

By: Gareth Palmer (gareth) 2007-02-20 16:30:06.000-0600

Updating the caller*id during a call was planned as well, the patch was sort of a proof-of-concept as much as anything else.

The string representation of the remote party ID could be replaced with a format like IAX2's struct iax_ie_data.

The `return "privacy=full;screen=yes"' change is replacing the callingpres-to-rpid  flags part of build_rpid() and putting it in a separate function called callingpres2str() because transmit_rpid() needed to produce the same strings.

Right, it shouldn't send multiple 180 ringing responses, but if the rpid changes multiple times before the call is answered it will need to send multiple 183 progress responses.

Doing a masquerade was a hack to avoid issues I was having with queueing up an indication frame that would be passed through Dial() to the yet-unbridged channel on a semi-attended transfer.

I will split up the patch to make it easier to digest.

By: Serge Vecher (serge-v) 2007-03-14 08:48:59

gareth: any news on that new patch?

By: Gareth Palmer (gareth) 2007-03-15 21:13:33

serge-v: I'm attaching the new patch files now.

indications.diff - Defines the AST_CONTROL_REMOTEPARTY frame subtype and adds it to the various
switch statements allowing remote party indications to pass through.

transmit.diff - Adds a function to build and send remote party indications.

app_remoteparty.c - A dialplan function to send remote party indications

pickup.diff - Sets a channel variable in Dial() and Queue() that the pickup code can use to display
the callerid of the picked-up call.

chan_sip.diff - SIP support for sending Remote-Party-ID headers. RE-INVITE support works now too.

Still working on the chan_skinny part of the patch.

By: Martin Butler (mbutler) 2007-03-17 08:45:52

Anyone were able to make this work for Aastra 480i phones?

By: Serge Vecher (serge-v) 2007-03-19 08:43:24

nice job gareth, it's best to attach a unified patch containing all changes.

By: Gareth Palmer (gareth) 2007-03-20 21:34:34

serge-v: I've uploaded a unified version - unified_remote_party.patch - New version also contains the chan_skinny implementation (verified working with 7960 using the P00308000400 load).

pj: can you please test it works with your 7920?

By: Badalian Vyacheslav (slavon) 2007-03-21 02:57:47

hello gareth
sorry for offtop

i have many Cisco phones on SIP and Skinny firmware...

I can test this feature and i need it.

Realy i need this:
1. Call go to Asterisk query
2. Agent (static as SIP/101 and etc) answer
3. And transfer (attended) to some phone
4. Agent ask to Non-Agent any info and transfer.
5. On Phone need see external number (not agent that was call).Cisco CallManager work fine for this =(
I can test any patches for this feature. Thanks

PS. After patch last SVN:

[CC] app_remoteparty.c -> app_remoteparty.o
app_remoteparty.c: In function 'remoteparty_exec':
app_remoteparty.c:87: warning: implicit declaration of function 'ast_remote_party'
app_remoteparty.c: At top level:
app_remoteparty.c:145: error: redefinition of '__register_file_version'
app_remoteparty.c:36: error: previous definition of '__register_file_version' was here
app_remoteparty.c:145: error: redefinition of '__unregister_file_version'
app_remoteparty.c:36: error: previous definition of '__unregister_file_version' was here
app_remoteparty.c:161: error: redefinition of 'app'
app_remoteparty.c:52: error: previous definition of 'app' was here
app_remoteparty.c:162: error: redefinition of 'synopsis'
app_remoteparty.c:53: error: previous definition of 'synopsis' was here
app_remoteparty.c:163: error: redefinition of 'descrip'
app_remoteparty.c:54: error: previous definition of 'descrip' was here
app_remoteparty.c:169: error: redefinition of 'remoteparty_exec'
app_remoteparty.c:60: error: previous definition of 'remoteparty_exec' was here
app_remoteparty.c:209: error: redefinition of 'unload_module'
app_remoteparty.c:100: error: previous definition of 'unload_module' was here
app_remoteparty.c:214: error: redefinition of 'load_module'
app_remoteparty.c:105: error: previous definition of 'load_module' was here
app_remoteparty.c:218: error: redefinition of '__mod_info'
app_remoteparty.c:109: error: previous definition of '__mod_info' was here
app_remoteparty.c:218: error: redefinition of '__reg_module'
app_remoteparty.c:109: error: previous definition of '__reg_module' was here
app_remoteparty.c:218: error: redefinition of '__unreg_module'
app_remoteparty.c:109: error: previous definition of '__unreg_module' was here
app_remoteparty.c:218: error: redefinition of 'ast_module_info'
app_remoteparty.c:109: error: previous definition of 'ast_module_info' was here
make[1]: *** [app_remoteparty.o] Error 1

# svn info
Revision: 59083

Thanks again

By: dea (dea) 2007-03-21 15:11:27

This a really cool addition.  I've started looking to see if it can be
cleanly extended to make it 'native', without the need for app_remoteparty.

Nothing against that app, but it's en extra step in the dialplan that
would be nice to avoid, and it could still be called to force a specific
Remote Party-ID.

Is this worth exploring?

By: Serge Vecher (serge-v) 2007-03-21 15:44:50

Dan, I like your idea. The "native" way, if you find it, would be preferable from the architectural standpoint. Also, on the dialplan front, I would explore doing it via a function, similar to CALLERID.

By: pj (pj) 2007-03-21 16:41:13

I successfully patched current trunk Asterisk SVN-trunk-r59090M and tried using this simple ael dialplan:
 '959' =>          1. RemoteParty(demo <959>)                    [pbx_ael]
                   2. Playback(demo-echotest)                    [pbx_ael]
                   3. Echo()                                     [pbx_ael]
                   4. Playback(demo-echodone)                    [pbx_ael]


when I called '959' from ci$co 7920 (chan_skinny), seems it works 'demo' is on calling phone display!
but on ci$co 7940 (sip) or eyebeam sip softphone, 'demo' is not displayed on display ;(
no change, when I answer channel, before RemoteParty()
nothing interestiong about remoteparty string in sip debug
I can't test with canreinvite=yes, because I have phone behind NAT (nat=yes in my sip.conf)



By: dea (dea) 2007-03-21 17:14:30

I made a pass at it and a couple simple changes to app_dial looked
like they would be enough.  

Locating the section to add the functionality to proved easy, as
was adding the basic support.  Unfortunately at that point the out
going channel does not have the caller-id name as set in the various
config files.

I think we'd need to add a get_user_cid() to supported channels and
add that to ast_channel_tech, which is a little more involved that I'd
like to tackle.  There might be an easier way, but I do not see it.
On the bright side, I think the code it self would be reasonably simple.

By: Martin Butler (mbutler) 2007-03-23 18:17:50

Hi guys,

How easy would it be to make the modification to the Contact: instead of the Remote Party? I have an Aastra phone which looks for Contact: update...

Thanks :)

By: Yehavi Bourvine (yehavi) 2007-05-03 09:01:03

I've applied the unified patch to one of the latest trunk SVNs (62332); ofcourse I had to do it manually as the line numbers have been changed.

It works, but one gotcha: the extension has to have the option sendrpid set to true...

                      Thanks, __Yehavi:

By: pj (pj) 2007-05-03 09:20:18

Yehavi, you said, that you can see called id name displayed on calling (source) SIP phone? I had no luck with ci$co sip phones or eyebeam softphone :(
what phone do you use? can attach your dialplan?

By: Yehavi Bourvine (yehavi) 2007-05-03 09:22:38

Unfortunately it does not work on Cisco's SIP phones nor on Snom. I managed to make it work on Polycoms.

                     __Yehavi:

By: Gareth Palmer (gareth) 2007-05-03 17:08:09

I have tested the patch with Cisco phones using the SIP firmware (7940/60 and 7961/70) and it works correctly.

You need to set `remote_party_id: 1' in SIP<mac-address>.cnf for the 7940/60s and `<remotePartyId>true</remotePartyId>' in SEP<mac-address>.cnf.xml for the 7941/61/70s

By: Yehavi Bourvine (yehavi) 2007-05-07 12:04:10

With the suggested parameters it indeed works on Cisco-7960 and 7961G
(in addition to Polycom 430/501).

                  Thanks! __Yehavi:

By: savag3 (savag3) 2007-05-13 06:59:12

I have tested this patch and can confirm that it works for me using a sip trunk to a Cisco CallManager 4.2 box. The Caller Id on the phone updates as expected.

By: pj (pj) 2007-05-13 15:10:44

according to readme for ci$co 7905/12 remote party id should be supported on this phones, but it doesn't work for me, nothing is displayed on phone screen ;(
ci$co firmware readme:
Release 8.0(0) includes the following new and enhanced features:
?Remote-Party ID support has been added for incoming INVITE and UPDATE requests and 18x and 200 responses.

sip debug shows remote party id...

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.164.154:10260;branch=z9hG4bK8c7f990c4a322ae4;received=192.168.164.154
From: <sip:324@192.168.38.20;user=phone>;tag=1707488280
To: <sip:959@192.168.38.20;user=phone>;tag=as4239b2bb
Call-ID: 140577346@10.0.0.1
CSeq: 2 INVITE
User-Agent: Asterisk PBX SVN-trunk-r61708M
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:959@192.168.38.20>
Remote-Party-ID: "demo" <sip:959@192.168.38.20>;privacy=off;screen=yes

rpid is working on ci$co 7940 with same asterisk config, so I think, that something must be missing in 7912 phone config, but I can't find any option like remote_party_id as in 7940:(
as I wrote with 7940 rpid is working, but before rpid is displayed phone always rings once, even if I calling echo test app, that shouldn't have any ringback.

By: pj (pj) 2007-05-13 15:21:18

when I use RemoteParty app in dialplan without specifying callerid num, like:
RemoteParty(demo) instead of full syntax like RemoteParty(demo <959>)
it crashes asterisk, syntax errors shlould be handled better ;-)

#0  0xb7c09463 in strlen () from /lib/i686/libc.so.6
#1  0x08084932 in ast_remote_party (chan=0x81fb518, cidnum=0x0, cidname=0xb7099d50 "demo", cidpres=1) at channel.c:3673
#2  0xb72eda18 in remoteparty_exec (chan=0x81fb518, data=0xb709de78) at app_remoteparty.c:87

By: Olle Johansson (oej) 2007-05-14 07:53:10

You should have the party=called header and also make sure that we treat this right on incoming messages...

rpi-pty-type       = "party" EQUAL ("calling" / "called" / token)

http://tools.ietf.org/id/draft-ietf-sip-privacy-04.txt

By: Gareth Palmer (gareth) 2007-05-17 00:37:26

I've updated the patch to include party=<calling|called> in the header as well as fixing the bug with passing invalid callerids to RemoteParty() and incorrectly setting SIP_PROGRESS_SENT instead of SIP_RINGING when sending an 180 response.

By: Olle Johansson (oej) 2007-05-17 10:13:57

Gareth: I added some karma to award the fact that you listen and keep coming back with updated patches. Thank you for working with us.

On a side note, if you find bugs in other places that is not related to this, please upload fixes as separate patches in separate issues. We try to keep patches as small as possible to make it easier to review and commit.

By: Olle Johansson (oej) 2007-05-17 14:50:23

After reading through the code again I think we might look at a more generic approach, based on this code.
There are a few situations where we want to change CAller ID for either Called or Caller ID. During a transfer, we want to change Caller ID, in call queue situations we might want to change Called ID.

Let's make a generic CALLERIDUPDATE control message that has a payload that indicates what changed and the new requested value. It needs to be able to handle a complete caller ID structure with both numeric, name and presentation values.

We also need to handle incoming updates, not only sending updates.

What do you think?

I am also aware that there are a few different ways to do Caller/Called ID updates in SIP. I need to investigate this a bit more too. None of them seems to have become a "standard" way, if one of them ever will be...

By: pj (pj) 2007-05-25 16:38:48

gareth:
I'm aplied your new_remote_party.patch, should I see something new configurable from user perspective? Help text for app is the same.
on 7940 phone still rings once, even normaly shouldn't, probably reaction to receiving  "SIP/2.0 180 Ringing" header from asterisk, where is send "Remote-Party-ID:" to phone.
It now working even on ci$co 7912/sip, thanks! and this phone has even better behaviour than 7940, because it doesn't rings when receiving "Remote-Party-ID:" header.
if I use RemoteParty(demo) instead of RemoteParty(demo <959>) asterisk don't crashes now, but does not displays "demo", it displays only number '959' and console log:
"app_remoteparty.c:89 remoteparty_exec: invalid callerid: demo"
it is correct? shouldn't be displayed text 'demo' without number?
anyway good work, thanks again!



By: pj (pj) 2007-06-05 16:16:01

hello, what next with this patch?
here I found some reference for RPID and other Enhanced Call Identification Services from ci$co perspective:
http://www.cisco.com/en/US/partner/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00806b03e2.html
so, if RPID headers is implemented/will be worked similarly using this patch, I vote to commit:-)
tomorow, I will test this patch with my newest phone ci$co 7961, all others (7912/7940) is working with RPID correctly, as I reported before...

By: Marty Riedling (mariedling) 2007-06-19 16:22:06

gareth,

Look at the patch I posted for 6643. Just looked at your patch and it looks a little more extensive than what I was trying. But mine works with the aastra 9133i phones ( these phones will only update on a contact update in an OK or reINVITE ). Could you put this into your patch?

By: pj (pj) 2007-07-02 04:45:03

new_remote_party.patch fails to apply to current trunk (r72869).

Hunk #2 FAILED at 2571.
1 out of 2 hunks FAILED -- saving rejects to file res/res_features.c.rej

By: mimmo (mimmo) 2007-08-23 03:16:45

how can I download this patch?
I'm not able to find any link on files!

By: Gareth Palmer (gareth) 2007-08-26 05:49:50

This bug note will cover the dial-plan usage, a further note will explain the
internal API changes.

I have had some difficultly with the current trunk builds (even before I have
applied my patch) so there are two versions of this patch. One against stable
(1.4.11) and the other against trunk (80894).

Hopefully this makes it easier for interest parties to verify the patch while
till conforming to the bug submission guidelines.

Be aware, the code alters the caller ID passing mechanism in asterisk. Some
channel drivers have not been patched to support this change. Currently patched
are SIP, IAX2, Zap, Skinny, H323, Local and Phone.

For the most common case (dialing a registered peer) there is the new Dial()
flag 'u' which automatically gets the caller ID information from the dialed
channel and passes it to the calling channel.

The CALLEDID() function replaces the RemoteParty() application, it can be used
to name channels that otherwise have no set callerid such as trunks and other
internal applications (VoiceMailMain, MeetMe etc.)

And one more thing...

Updating the caller/called ID on attended transfer now works for SIP channels.

By: pj (pj) 2007-08-27 02:26:56

it sounds very good!
1) it's any reason, why to not make this feature turned on by default, ie. without needing dial() with 'u' option? in other ip pbx, eg. in ci$co callmanager is displayed called party name also by default...

2) will be displayed called id name on sipA phone in this scenario (when sipA calls to sipB registered on another asterisk)?
sipA--->asterisk1---iax(or sip)---asterisk2--sipB

By: darkskiez (darkskiez) 2007-08-27 08:39:21

I am testing with an earlier patch, but this is causing some problems with progressinband, I believe it may be responsible for causing my Cisco 79x0's to produce ringing tones over the top of the inband progress. Setting progressinband to no or never makes no difference to this.

I will test again when the patches get made available to the public.

By: Jesus Mogollon (globalip) 2007-08-28 10:03:26

gareth:

 Where can we find the patch for 1.4.11? are the CALLEDID function and the 'u' flag in Dial available in 1.4.11? (show functions doesn't show it and the 'u' flag is not documented anywhere).



By: Jared Smith (jsmith) 2007-08-29 13:44:35

Gareth,

Can you please get the licensing situation fixed on the patches you've written?  For some reason, it says your license has been rejected.

By: Gareth Palmer (gareth) 2007-08-29 21:41:44

jsmith:

I've received a message from mpetrone@digium indicating that my licence had been formally accepted by their legal department. They haven't retroactively applied it to my patches though.

Uploaded the patches again, can you please delete the rejected versions.

By: darkskiez (darkskiez) 2007-08-30 08:52:10

I tested 1.4.11.now.with.licence.patch (against 1.4 branch head) quickly over a quiet lunch break today, and it crashed and burned asterisk instantly :( unfortunately the server got rebooted and the core files were in /tmp, so I have no backtrace :(

I definitely think the Dial option should be on by default however, or configurable to be on by default at least.

Is this ok:  Set(CALLEDID(all)="Voice Mail" <500>)

By: Michiel van Baak (mvanbaak) 2007-09-04 11:45:27

Deleted patches with rejected license per gareth's request

By: pj (pj) 2007-09-05 14:58:13

it fails to apply to current trunk (r81598), can you update the patch?
patching file apps/app_dial.c
Hunk ASTERISK-2 FAILED at 291.

By: dea (dea) 2007-09-07 19:37:26

Confirmed to work with chan_skinny and chan_sip using Cisco phones.

Older Cisco SIP images do not appear to support remote-party-id.  I am
not sure which version added it, I just upgraded to the latest for testing.

By: Yehavi Bourvine (yehavi) 2007-10-09 09:34:31

As people noted here Asterisk crashes with the latest patch, while with the
new_remote_party.patch  it was ok (but I lost it...).

It crashes in chanvars.c in function ast_var_name().

                         Thanks, __Yehavi:

By: Gareth Palmer (gareth) 2007-10-11 05:31:11

Part 2 -

Updating on transfers was never going to work because asterisk overwrites the callerid (if any) of the called channel in Dial().

To fix that, the patch makes two changes. Firstly, it makes the SIP and IAX channels store the callerid of the peer when it is allocated (most other channels already did this) and secondly, it adds a second callerid structure to the channel (dialcid) that is used to pass caller information and to store a callerid that can be set on trunk lines.

The helper function ast_copy_callerid() has been added to make it easy to copy callerid information between chan->cid and chan->diacid structures.

I will update the patches shortly, updating the callerid on SIP semi-attended-transfer now works. Note the change to the p->ocseq check in chan_sip.c that now also checks against p->lastinvite because the INVITE response will have the CSeq of the INVITE even if p->ocseq has been incremented due to an UPDATE.

By: Badalian Vyacheslav (slavon) 2007-10-12 02:19:17

aplay 1.4.13 patch

make error
app_dial.c:256: error: 'OPT_ORIGINAL_CLID' undeclared here (not in a function)
make[1]: *** [app_dial.o] Error 1
make: *** [apps] Error 2

i comment line 256 - all normal

By: Badalian Vyacheslav (slavon) 2007-10-12 03:14:09

Next scheme not work:

Have 3 sip phone Cisco 7940 (P0S3-08-6-00)

Dialplan:
exten => 352,1,Dial(SIP/352,,u)
exten => 353,1,Dial(SIP/353,,u)
exten => 354,1,Dial(SIP/354,,u)

Sheme a:
1. 352 call to 353
2. 353 Ansfer
3. 353 do atransfer to 354 (do it from CISCO button More->Transfer)
4. 354 Answer
5. 354 See that called number is 354 - wrong
6. 352 See that calling number is 353 - wrong

Sheme b:
1. 352 call to 353
2. 353 Ansfer
3. 353 do btransfer to 354 (do it from CISCO button More->bldXfr)
4. 354 Answer
5. 354 See that called number is 352 - OK
6. 352 See that calling number is 353 - wrong

By: Gareth Palmer (gareth) 2007-10-12 03:24:14

slavon - 1.4.13.fixed.patch should fix the fault that prevents compilation.

By: Badalian Vyacheslav (slavon) 2007-10-12 05:40:36

Sheme c:
1. 353 set CFWD to 354
2. 352 call to 353
3. 354 See that called (->) number is Asterisk - wrong
4. 352 See that calling (<-) number is 353 - wrong

[Oct 12 14:54:41]     -- Got SIP response 302 "Moved Temporarily" back from 87.255.0.106
[Oct 12 14:54:41]     -- Now forwarding SIP/352-082ad0b0 to 'Local/354@office' (thanks to SIP/353-083e2f18)

By: Badalian Vyacheslav (slavon) 2007-10-12 07:39:21

Sorry. New info.

vi /tftproot/SIPDefault.cnf
add:
remote_party_id: 1;

Sheme a1 (changed):
1. 352 call to 353
2. 353 Ansfer
3. 353 do atransfer to 354 (do it from CISCO button More->Transfer)
4. 354 Answer
5. 353 do atransfer (do it from CISCO button Transfer)
6. 354 See that called number is 352 - OK
7. 352 See that calling number is 354 - OK

Sheme a2 (changed):
1. 352 call to 353
2. 353 Ansfer
3. 353 do atransfer to 354 (do it from CISCO button More->Transfer)
4. 353 do atransfer (do it from CISCO button Transfer)
5. 354 Answer (ANSWER AFTER TRANSFER)
6. 354 See that called number is ASTERISK - Wrong or needed update after PICK UP Phone
7. 352 See that calling number is 354 - OK

Sheme b (changed):
1. 352 call to 353
2. 353 Ansfer
3. 353 do btransfer to 354 (do it from CISCO button More->bldXfr)
4. 354 Answer
5. 354 See that called number is 352 - OK
6. 352 See that calling number is 353 - WRONG

Sheme c:
unchanged

We see that add "remote_party_id: 1;" fix some places... its my mistake - sorry.
CALLED() function work great! Thanks.

By: Doug Lytle (lytledd) 2007-10-12 09:13:13

Yehavi,

Was there something that needed to be activated on the Polycoms before this function would work?

By: Yehavi Bourvine (yehavi) 2007-10-12 12:25:06

As far as I know there is nothing to do on Polycoms to make it working. I am using the default configs with some changes to tailor it to our environment which do not seem related to this function (like SIP server address, etc.).

                        __Yehavi:

By: Doug Lytle (lytledd) 2007-10-12 12:34:06

Then maybe someone can tell me what I'm doing wrong.

I've downloaded the current 1.4.13 along with the attached 1.4.13.fixed.patch
I've applied the patch with a patch -p1 <*.patch (It applies cleanly)

I've verified that the function CALLEDID() exists and there is now a u option under the dial application.

My dialplan is:

exten => 46,1,Set(CALLEDID(all)="Testing" <4288>)
exten => 46,n,Dial(SIP/4288,,u)

The display on the calling phone never changes beyond showing 46.  Do I have the CALLEDID string correct?

I'm using 2 Polycom IP501s with a 2.1.2 Firmware.

By: pj (pj) 2007-10-12 12:43:14

also not working for me, phone ci$co 7920 (skinny),
my dialplan:
Set(CALLEDID(name)=echo)
no error in console log, but on phone display is only number, nothing changed

Set(CALLEDID(all)=echo <959>)
also no change, not working :(

SVN-trunk-r85357M



By: Gareth Palmer (gareth) 2007-10-13 04:30:45

lytledd - have you set sendrpid=yes for that peer in sip.conf?

By: Doug Lytle (lytledd) 2007-10-13 07:25:31

I missed that in the bug report.  It's working now, VERY cool!

Thanks.

By: Andrew Lindh (andrew) 2007-10-15 09:33:14

I think this is a great and important feature for asterisk! My 15 year old PBX key system could do it... (note, do a make clean with the 1.4.13 patch) Testing it with Cisco 7960 SIP 8.8 phones and the display updates (does not update call display info during hold, a cisco bug) and Polycom SIP 2.2.0 (calls on hold do update). But when I transfered in a call from another asterisk system the call would be disconnected when the transfer is completed (eg. 301->asterisk1->asterisk2->401 transfer to 402), it seems to be related to "canreinvite=yes" which may be totally unrelated to this patch. It is nice to finally see who you are talking to...



By: Martin Butler (mbutler) 2007-10-15 09:57:17

Anyone got any luck with this patch with Aastra phones?

By: Andrew Lindh (andrew) 2007-10-15 11:03:59

I think the CALLEDID should be an automatic optional/controllable part of DIAL (the 'u' option fails if the dial does not complete). It's nice to have the caller's display update to match the name+number of where they have called. BUT there are times we may not want this. If I call an extension and it forwards to a private phone number then we need to make sure that the new number stays private and does not update the display with the real number.



By: Andrew Lindh (andrew) 2007-10-15 11:45:55

Phones tested:

Cisco 7960 with SIP 8.8: all display updates work, execpt when on hold. When the call is taken off hold the display updates.

Polycom 650 with SIP 2.2.0 and 2.1.2: all display updates work, even when on hold (some errors about UPDATE not supported).

Grandstream GXP-2000 with SIP 1.1.4.25 and 1.1.5.3: no display updates at all.

Sipura/Linksys SPA-942 with SIP 5.1.15(a), the first update works when calling out (eg. to set the called name on the display) but additional updates during transfers do not work.

Linksys WIP300 with SIP 1.00.09: no display updates at all.

eyeBeam 1.5.16.1 SIP (windows soft phone): no display updates at all.



By: Andrew Lindh (andrew) 2007-10-16 00:37:14

With the dial 'u' option (update), it does not work when music is used in the dial command or with more than one destination. I don't know why the music option stops the updates... The multi-destination is easy to fix. You can add an ast_update_callerid after the call to wait_for_answer and use the single returned peer (if answered), or add it into the answered section of wait_for_answer. This has the nice effect if letting the caller know which location answered the call.

By: Badalian Vyacheslav (slavon) 2007-10-16 01:32:45

May i request feature?

Maybe add option in extentions.conf like

allwaysupdatecid = yes

and option to Dial like U - don't update cid.

I like to update all calls (more than 1000 Dial()), but don't need update 1-2 directions. =)

By: pj (pj) 2007-10-19 13:03:55

gareth, should your patch work also for chan_skinny? what I'm doing wrong? should I turn on some option, like for SIP is sendrpid=on?
It's not working for me, please look at my message 0071894.
p.s. anybody knows about sip softphone, that supports remote party id?

By: Doug Lytle (lytledd) 2007-10-20 17:49:28

Well, after playing around with this patch and the multi-parking patch, I decided to move one of our facilities to 1.4.13 from 1.2.x

In doing so, I've discovered a bug concerning this patch.  I am no longer able to set callerid info from a .call file.  The callerid name is asterisk and there is no number.  The file is below:

Channel: Local/3501@sip/n
CallerID: Paging <44>
WaitTime: 5
MaxRetries: 0
Context: polycom-page
Extension: s
Priority: 1

I was using callerid number as the decision maker to send the auto answer sequence for my polycom phones when paging.  I've worked around it, but thought I would report it.

By: Doug Lytle (lytledd) 2007-10-27 10:16:54

New bug report for this patch.

Using the Asterisk feature "pickup extension" (mapped to *7), with this patch enabled, will causes our Polycom IP501 phone to continue ringing and act like it still has a inbound call; even though it was picked up by someone in else in it's pickup group.  I get the console error:

[Oct 27 10:56:48] WARNING[25530]: chan_sip.c:12612 handle_response: Host '10.10.10.176' does not implement 'UPDATE'

Disabling sendrpid for 4103 in sip.conf will fix the issue for that phone.

As a review:

Asterisk 1.4.13
Polycom IP501, firmware 2.1.2
3 phones for testing, exten 4103, 4109, 4190
With sendrpid=yes on all 3 phones
4109 calls 4103, name shows correctly on both displays
4190 does a *7 to pick up 4103, call is picked up and display is correct
4103 continues to ring with correct callerid on the display

Picking up handset on 4103 makes no difference, phone still shows inbound call
Pressing the Reject soft button will end the call.

Given 35 or so seconds, the phone will settle down on it's own and stop ringing and clear the display.  I see the following error on the console for 4103:

[Oct 27 10:56:48] WARNING[25530]: chan_sip.c:12612 handle_response: Host '10.10.10.176' does not implement 'UPDATE'

By: Badalian Vyacheslav (slavon) 2007-11-05 16:06:10.000-0600

Any updates? Very intresting feature for me and many other i think...

By: Andrew Lindh (andrew) 2007-11-06 20:19:49.000-0600

I have the same update and rining problem on polycom phones (2.1.2 and 2.2.0), but not cisco SIP phones. If an attended transfer is completed without being answered and then the caller hangs up then the phone keeps rining and can not be cancelled. It just has to timeout to stop...

By: Jose Luis Gomez (jlgomez) 2007-11-07 04:59:15.000-0600

Hello,

Somebody has proven it with the telephone Thomson ST 2030?

Thanks

By: Yehavi Bourvine (yehavi) 2007-11-07 05:43:33.000-0600

The Thomson 2032 and 2020 do not support this feature. Thomson is willing to do changes for customers who will order large quantities, but I cannot commit for this at present.

If you ask them also maybe they see there is a demand for this feature. Our users liked this phone but are missing the RPID functionality.

                            __Yehavi:

By: Badalian Vyacheslav (slavon) 2007-11-07 06:16:18.000-0600

anyone can give patch to current revision 89081 1.4 branch?

Patch have cross collisions (changed pached places) =(

By: Jeff Pyle (jpyle) 2007-11-07 21:09:10.000-0600

Similar to pj's question on 2007-08-27, will this patch allow incoming Remote-Party-ID updates on the outside to propagate through to phones on the inside?

I'm very pleased to say the patch appears to be working for me, first try, with semi-attended transfers.  But when I call a Broadworks user through patched Asterisk, the Remote-Party-ID that comes from Broadworks on the 180 does not make it to my Polycom.  "trustrpid" is enabled for the Broadworks peer; "trustrpid" and "sendrpid" are enabled for the Polycom.

I apologize for my denseness in advance.  My appreciation to those responsible for this fabulous feature.

By: Badalian Vyacheslav (slavon) 2007-11-13 00:38:52.000-0600

Any updates?

By: Gareth Palmer (gareth) 2007-11-19 04:25:26.000-0600

pj: I have tested the patch with a 7940/60 running 8.0.7 SCCP load and the display updates correctly.

andrew: If the Polycom phones don't support the UPDATE method the updates on semi-attended transfer unfortunately won't work.

jpyle: IAX2 channels will pass through the update indication frames, however in that version the channel cid/dialcid structure won't be updated though. The trustrpid option hasn't been modified from the previous RPID implementation.

New patch, following changes have been made:
- Removed 'u' option from Dial, updates now automatically happen unless the I option is specified.
- PBX originated calls (spool files, manager Originate) should now have the callerid set correctly.
- IAX2 channels now have cidupdate=<yes|no|send|receive> option to control how updates are processed, relevant channel callerid/dialcallerid values are now set as well.
- New helper function ast_set_dialcallerid.
- ast_indicate will update callerid structure if the channel indication handler does not support cidupdate.

By: Badalian Vyacheslav (slavon) 2007-11-19 05:37:00.000-0600

patched. compiled. work fine for me. (use SIP and Cisco 7940)

vote for apply patch to releses )

By: pj (pj) 2007-11-19 10:29:11.000-0600

asterisk (trunk revision 89403) failed to compile with svn-89403.patch:

  [CC] chan_iax2.c -> chan_iax2.o
chan_iax2.c: In function `create_addr':
chan_iax2.c:3144: error: syntax error before "IAX_SEND_CIDUPDATE"
chan_iax2.c:3144: error: syntax error before "IAX_SEND_CIDUPDATE"
make[1]: *** [chan_iax2.o] Error 1
make: *** [channels] Error 2



By: Doug Lytle (lytledd) 2007-11-19 13:08:20.000-0600

This current patch looks very good.  All of my listed issues have been fixed, and I no longer am getting the following error on my Polycom:

"WARNING[25530]: chan_sip.c:12612 handle_response: Host '10.10.10.176' does not implement 'UPDATE'"

I'll need to do more testing though.  

Thank you very much Garth!

By: goby (goby) 2007-11-22 07:38:00.000-0600

Is it possible to get it work with snom phones? My users whould like to know the number of the org. caller if a call is transfered to them.

By: Doug Lytle (lytledd) 2007-12-02 15:56:52.000-0600

This patch will not apply against 1.4.15

By: Andrew Lindh (andrew) 2007-12-04 14:27:45.000-0600

There were several changes (as always) in branch 1.4

I updated the 1.4.14.patch for branch, it seems to work for me. Some of the local channel stuff moved because for forward loop detect code changes.

It's not an official update, so use at your own risk.

http://users.netplex.net/~andrew/asterisk/

But I have had some crashes in the queue section now with the latest patch, but I think it is just bug ASTERISK-1142486



By: Doug Lytle (lytledd) 2007-12-07 08:19:32.000-0600

Thanks Andrew!  I'll give it a go.

By: Gareth Palmer (gareth) 2007-12-11 05:08:37.000-0600

New patch: incoming SIP Remote-Party-ID headers are now parsed and queued as cidupdates, set trustrpid=yes to enable.

By: savag3 (savag3) 2007-12-17 05:54:48.000-0600

The svn r92267 patch appears to have a bug in app_dial.c which causes a segfault. It the temp channel variable name is incorrect. It should be tc as tmp->chan is not set until after this code is executed.

The following patch fixes it:

--- apps/app_dial.c     (working copy)
+++ apps/app_dial.c     (working copy)
@@ -1432,9 +1432,9 @@
                       ast_set_flag64(tmp, DIAL_NOCIDUPDATE);
               }
               if (ast_test_flag64(peerflags, OPT_FORCE_CALLERID))
-                       ast_set_dialcallerid(tmp->chan, cid_num, cid_name, chan->cid.cid_pres);
+                       ast_set_dialcallerid(tc, cid_num, cid_name, chan->cid.cid_pres);
               else
-                       ast_copy_callerid(&chan->cid, &tmp->chan->dialcid);
+                       ast_copy_callerid(&chan->cid, &tc->dialcid);

               /* Copy language from incoming to outgoing */
               ast_string_field_set(tc, language, chan->language);

By: Doug Lytle (lytledd) 2007-12-19 08:22:26.000-0600

Failed to apply to 1.4.16

Hunk ASTERISK-17 FAILED at 1143.
Hunk ASTERISK-18 succeeded at 1191 (offset 17 lines).
Hunk ASTERISK-19 succeeded at 1254 (offset 17 lines).
1 out of 23 hunks FAILED -- saving rejects to file apps/app_dial.c.rej
patching file apps/app_queue.c
Hunk #1 succeeded at 1837 (offset 8 lines).
Hunk #2 FAILED at 2142.
1 out of 2 hunks FAILED -- saving rejects to file apps/app_queue.c.rej

By: R.E. van Leyden (vanleyden) 2008-01-01 09:46:12.000-0600

This patch applied well on 1.4.14 for me. I only came up with one major thing. When agent in a queue are sip phone (callback agents) and there is an inbound call the caller name and number from the calling party is always "Asterisk" "Asterisk" no mather wat settings are used or set bij CallerId or CalledId.
(sendrpid en trustrpid are set to yes in the global sip settings)

Is this solved in 1.4.15 ?



By: David Brillert (aragon) 2008-01-05 19:37:40.000-0600

I've been watching progress on this feature for what seems like forever.
I think it is a really important feature.
Most PBX's will allow you to see the name of the connected party on your display.
I think the "unknown" message on an Aastra LCD is annoying when you are connected to another lcoal extension for example...
I would love to see this feature finally implemented on Asterisk.

The patch seems to break on each new release.
I'm not at all sure if the feature works correctly on each vendor's phone product...
Does the feature work with the following?
Snom
Aastra
Polycom
Does anyone have any idea when this feature could be officially implemented?

By: Doug Lytle (lytledd) 2008-01-05 20:08:15.000-0600

I've tested it ok on our Polycom's.  No new features in 1.4.x so the earliest would be 1.6.

I'm currently stuck with 1.4.15 until a new release.

By: Bill Hackensack (billhackensack) 2008-01-05 21:00:14.000-0600

Until this patch is compatible with Zaptel devices as well, I don't think it should be included in Asterisk.  This isn't a generic implementation of something.  It's specific to sip and skinny.

By: Yehavi Bourvine (yehavi) 2008-01-06 00:57:52.000-0600

I've tested this patch with Cisco (7912, 7960, 7961), Polycom and Syslink SPA-942 and it work ok with them.

Snom does not support this feature.

                      __Yehavi:

By: pj (pj) 2008-01-06 03:03:49.000-0600

called id for zaptel, who cares? this feature is crucial for sip phones (and iax, skinny) not pstn world. I prefer to include ip only implementation, that is almost done now, instead to again wait next years.
Absence of called party info feature in current asterisk is one of the main weakness of asterisk for corporate usage. Almost all comercial pbx solutions have this funkcionality years ago.

By: David Brillert (aragon) 2008-01-07 09:49:37.000-0600

I have a strong preference to use Snom phones.
Especially with latest official version 7 firmware.
What would the Snom have to implement to support this?
Has anyone contacted Snom to implement?

Maybe the previous comment regarding zaptel/PSTN interfaces refers to telling the caller which trunk they are using.
For example I make a PRI call and the connected info tells me I am using channel 23...
Knowledge of your outgoing channel used to be crucial to avoid carrier PBX tarriffs on your outside lines when using loop start lines on key systems.

I have not tested this patch since I dont really know what stage of development it is in.

Ideally it would be nice to see the connected party as well as the bridged PSTN trunk info you are using.
Obviously no bridged PSTN trunk info is required on local extension call setup information. I just think it ought to be included when making PSTN calls.

By: Yehavi Bourvine (yehavi) 2008-01-07 13:52:34.000-0600

I've upgraded my Snom-320 to version 7.1.30 but RPID still doesn't work on it.

                  __Yehavi:



By: pj (pj) 2008-01-15 07:12:57.000-0600

gareth, could you update your patch to current trunk, that we will be able to continue testing/use?
also someone, should do code review and tell, if this work is right designed and patch have chance to be commited into trunk.

By: Doug Lytle (lytledd) 2008-01-15 07:40:45.000-0600

Yes, please!

By: Gareth Palmer (gareth) 2008-01-16 04:49:52.000-0600

billhackensack: Please submit a patch to remove all video support from asterisk as it won't work with my Zap/FXS analogue phone.

The bulk of the patch is device independent, however that does not guarantee that every channel type can be supported.

As asinine as your comments are, they have prompted me to produce the list of other channel types I investigated:

 chan_alsa & chan_oss: Trivial to have it print a message.
 chan_mgcp: Was not able to get a Cisco 7940 running 7.7.0 MGCP load.
 chan_unistim: Send_Text() function could be used. Don't have UNISTIM phone to test.
 chan_zap: PRI interfaces might be able to use FACILITY messages as a transport.

Patches have been updated for 1.4.17 and SVN/98603.

By: mimmo (mimmo) 2008-01-16 06:57:59.000-0600

Applied to 1.4.17 without issues.
Verified presence of 'u' option in Dial() and CALLEDID() function.
However, it doesn't work using X-Lite and Zoiper, using a dialplan like this:
exten => 123,1,Set(CALLEDID(name)=echo)
exten => 123,n,Dial(SIP/123,Ttu)
and setting 'sendrpid=yes' in sip.conf (among general options)

By: pj (pj) 2008-01-16 10:04:58.000-0600

mimmo, check if your softphone supports Remote Party id sip header (RPID), if yes, it should work. A months ago, I tried this witch cisco phones and it worked. after asterisk svn will be repaired, I will try again.
gareth, that you for updating patches!



By: Lacy Moore (lacym) 2008-01-18 21:21:16.000-0600

Since Beta 1.6 has been released, does that mean this didn't make it?  This is probably the most important feature lacking in Asterisk, even the Linksys LVS 9000 system does this.

By: Andrew Lindh (andrew) 2008-01-18 21:40:34.000-0600

I agree...it's needed now. They have said: "The 1.6 version will receive new functionality in smaller increments"....I hope this is not too big a change to add soon (may be it can make it into 1.6.1)

By: Earl Tom (etom) 2008-01-18 23:25:38.000-0600

I just tried this patch on 1.4.17 but had to roll it back out.
Our setup: Asterisk 1.4.17 + patch / Polycom 650's with SIP 2.1.1.0052 / sendrpid=yes and trustrpid=yes in sip.conf

Phones A, B, C

A calls B, B answers.
B does a SIP Attended Transfer (softkey on the Polycom) to C and completes the transfer before C answers.

A hears ringing (good), but then ends the call before C answers.

Result -> C's phone continues to ring even though there's no call available.  

On the plus side, after B does the transfer, A's display does show C and C's display does show A - at least the numbers, though not the names.  (That might be a setup issue, though, since our SIP authentication users are extension numbers...)

It seems really close.

Thanks, Gareth!

By: Olle Johansson (oej) 2008-01-23 06:34:15.000-0600

The patch is not very clean. In chan_sip it changes non-related functionality.

By: Olle Johansson (oej) 2008-01-23 06:41:47.000-0600

Shouldn't we use "connected ID" instead of "dialed ID" ? I think it's called Connected Line ID in ISDN.

By: Olle Johansson (oej) 2008-01-23 06:43:40.000-0600

We also need doxygen documentation on the new functions in channel.h, thanks.

By: Gareth Palmer (gareth) 2008-01-31 04:46:29.000-0600

oej:

1. I am not sure which changes to chan_sip.c you disapprove of, can you please elaborate?

2. Yes it should, Connected Line ID is _much_ better name than Dialed ID. I have reworked the patch to partially implement the name change.

3. Added some documentation to the patch, though I need to expand it to contain \param references as well.

New patches attached for SVN revision 100464 and 1.6.0-beta2. User visible changes are CALLEDID() is now LINEID() and updates will be sent even if 'r' or 'M' options were specified to Dial().

By: Olle Johansson (oej) 2008-01-31 12:27:30.000-0600

Does this part in any way relate to caller ID handling?

@@ -17595,10 +17708,10 @@
*/
int ret = 0;

- if (p->ocseq < seqno && seqno != p->lastnoninvite) {
+ if (p->ocseq < seqno && p->lastinvite != seqno && p->lastnoninvite != seqno) {
ast_debug(1, "Ignoring out of order response %d (expecting %d)\n", seqno, p->ocseq);
ret = -1;
- } else if (p->ocseq != seqno && seqno != p->lastnoninvite) {
+ } else if (p->ocseq != seqno && p->lastinvite != seqno && p->lastnoninvite != seqno) {
/* ignore means "don't do anything with it" but still have to
* respond appropriately.
* But in this case this is a response already, so we really

By: Gareth Palmer (gareth) 2008-01-31 22:05:03.000-0600

It is needed for caller ID updates on semi-attended transfers to work. Asterisk needs to accept the CSeq of the last INVITE because p->ocseq will have been incremented when sending the UPDATE request.

Here is an simplified example SIP call flow of a caller ID update during a semi-attended transfer from the perspective of the called party's side:

A --> INVITE (CSeq: 101) --> B        (Call initiated)
A <-- 180 OK (CSeq: 101 INVITE) <-- B (Ringing)
A --> UPDATE (CSeq: 102) --> B        (Update caller ID)
A <-- 200 OK (CSeq: 102 UPDATE) <-- B (Response to caller ID update)
A <-- 200 OK (CSeq: 101 INVITE) <-- B (Call answered)

By: Steve Davies (one47) 2008-02-01 05:05:39.000-0600

Is that list of transactions even legal?

The UPDATE (a new transaction?) is being started before the INVITE has been ACK'ed.  It is certinaly not allowed to start a new transaction until the old one is completed, it just remains to decide whether UPDATE is considered a transaction in that sense.

Also, if a phone device does not allow UPDATE, and requires that you send a re-INVITE (does this patch take that into account?), then you definitely cannot send it until the previous INVITE is fully ACK'ed.

By: Doug Lytle (lytledd) 2008-02-08 10:43:57.000-0600

Current 1.4.x patch will not apply to 1.4.18:

1 out of 28 hunks FAILED -- saving rejects to file channels/chan_sip.c.rej
1 out of 7 hunks FAILED -- saving rejects to file main/channel.c.rej

By: Gareth Palmer (gareth) 2008-02-21 22:15:09.000-0600

one47: a) Yes, see RFC3311 and b) No, they are not.

---

I have updated the patches (1.4.18 and SVN104031). Changes are ${LINEID()} has been renamed to ${CONNECTEDLINE()}, the original caller is updated with the new callee during a call pickup and when dialing multiple peers an update will be sent as to which peer answered.

By: Doug Lytle (lytledd) 2008-02-22 06:00:29.000-0600

Thanks for the update!  Everybody appreciates the work you've done!

By: pj (pj) 2008-02-23 04:49:14.000-0600

please can somebody tell, how to use this feature? I have successfully patched SVN-trunk-r104045, but functions like CONNECTEDLINE, LINEID, or CALLEDID doesn't exist, also I don't see any option 'u' in dial() app description.
I have 'sendrpid=yes' in sip.conf, testing with phone cisco 7940 (sip firmware).

[Feb 23 11:45:28]     -- Executing [959@testservices:2] Set("SIP/324-082344f8", "CONNECTEDLINE(name)=echo") in new stack
[Feb 23 11:45:28] ERROR[32658]: pbx.c:2380 ast_func_write: Function CONNECTEDLINE not registered
[Feb 23 11:45:28]     -- Executing [959@testservices:3] Playback("SIP/324-082344f8", "demo-echotest") in new stack

By: Raj Jain (rjain) 2008-02-23 07:03:16.000-0600

I didn't see mention of RFC 4916 (Connected Identity) in this discussion. Would it be a lot of additional work to make this patch RFC 4916 compliant? Remote-Party-Id has long been deprecated, but I realize that most phones still support it.

By: Francesco Romano (francesco_r) 2008-02-25 09:11:40.000-0600

I have tested the last patch with asterisk 1.4.18 and these phones:
Grandstream BT200/GXP series ver. 1.1.5.15
Snom 3XX series ver. 6.5.17
Siemens Optipoint 150S ver. 1.45
Siemens Gigaset 470 Cordless
Thomson ST2030 1.58
Linksys SPA941 5.1.8

But it works only with SPA941, the other phones do not support rpid. So this very useful/basic feature is unusable. Very sad.
It's possibile to update the callerid also when you pickup from the park slot?
Thank you

By: mimmo (mimmo) 2008-02-25 09:41:17.000-0600

Does Polycom IP320 support RPID?

By: Jeff Pyle (jpyle) 2008-02-26 07:43:29.000-0600

Mimmo, yes it does.

By: Andrew Lindh (andrew) 2008-03-02 07:15:10.000-0600

This new patch version crashes for me.... (at least on asterisk to asterisk calls). I'll have to test it some more.

By: Jeff Pyle (jpyle) 2008-03-12 21:05:49

The new patch crashes for me as well, although I can't identify the exact cause.  I held an asterisk-asterisk call for 10+ minutes with transcoding with no problem.  I started to play with meetme conferences and that seemed to make it rather unstable, although a few minutes later it was crashing with no meetme activity at all.

By: Yehavi Bourvine (yehavi) 2008-03-19 10:14:29

Hello,
 The asterisk-1.4 patch worked for me correctly with version 1.4.18; however, with version 1.4.18.1 it causes some crashes. I've fonud that semi-attended transfers cause it to crash.
 I enclose asterisk_crash.log which is the output of Asterisk and asterisk_core.log which is the log of the core dump.

 The logs are for a call from extension 80620 to 80623 (AudioCodes) which answers it, transfer it to 85684 and then hangs up before 85684 answers (so it is a semi-attended transfer).
                     Thanks, __Yehavi:

By: Timo Teräs (fabled) 2008-03-27 02:17:30

I'm planning on implementing called/connected id stuff on libpri/Q.SIG based on this patch. I already got the Q.SIG signalling part working (currently my code just uses channel variables for called ids). Now I just want to make it use this API.

So I'm asking what is the status of the API provided by this patch? Is there going to be still changes? Is this going to be merged soon?

By: Timo Teräs (fabled) 2008-03-31 08:04:47

Ok, I got it working with my libpri/QSIG changes. I have a libpri+asterisk patches  that enable calledname stuff (works at least with my Siemens HiPath).

I have asterisk-1.6.0_beta4 + svn-104031.patch + my patches. I noticed two bugs in the svn-104031.patch though:
1. It's missing the func_connectedline.c. I copied from 1.4.18.patch, and it's working.
2. There some sort of bug in handling of IAX_RECV_CONNECTEDLINE flag. Since I don't get the updates from IAX line unless I remove the flag checks (and yes, I have connectedline=yes in my iax.conf). Traces show that the connectedline update is sent via IAX but it's never parsed in the receiving side, unless i #if 0 the flag test.

My setup is:
Siemens HiPath 1 <S0:ISO-QSIG> Asterix1 <IAX2> Asterisk2 <S0:ISO-QSIG> Siemens HiPath 2

And calling from phone connected in HiPath1 to another extension under HiPath2 I could get the caller and called names working properly both ways.

By: Gareth Palmer (gareth) 2008-04-02 05:27:11

rjain: Implementing RFC4916 (and RFC4474 where the syntax for the Identity header is defined) would be a lot of additional work as it requires an X509 certificate authority and remembering every Call-ID value for at least an hour.

It would however, be easy to implement the P-Asserted-Identity header from RFC3325 which the later Linksys handset firmware supports.

pj: I forgot to do `svn add funcs/func_connectedline.c' so it was not included in the SVN patch. I have uploaded a newer version which has it.

fabled: The API has changed slighly in the latest version, ast_update_connectedline is now ast_connectedline_update and ast_queue_connectedline has been renamed to ast_queue_connectedline_update.

I've also changed how it sets the flags for sending/receiving connected line indications in chan_iax2, can you please test to see if that solves the issue you are having.

By: Timo Teräs (fabled) 2008-04-02 11:25:33

I have now updated my patches. Tested with 1.6.0-beta7.1. I also traced why the receiving of connected line changes do not work. It turns out, I was dialing the remote party using Dial(IAX2/host.fqdn.example/123) format. That is: using domain name as Dial parameter instead of IAX definition from iax.conf.

I thought one could specify 'connectedline=true' in [general] section of iax.conf. But that appears not to be the case. Maybe that could be added, or some other way to enable connectedline events when dialing using IP/domain name?

By: Timo Teräs (fabled) 2008-04-02 23:46:25

I've been thinking about IAX_RECV_CONNECTEDLINE flag. Do we really need it? We don't get those updates unless we made an outbound call, and in those cases the updates can be filtered in Dial app.

You might also want to add the missing ast_control_frame_type strings to channels/iax2-parser.c:iax_showframe():cmds[].

By: Timo Teräs (fabled) 2008-04-03 03:02:30

I created bug 12357 about libpri changes required for the QSIG stuff.

I attached chan_zap-1.6.0-beta7.1.patch to this bug. It modifies chan_zap (using patched libpri) to work with connectedline API.

By: Doug Lytle (lytledd) 2008-04-13 12:48:07

This patch will no longer apply to the current 1.4.19.  Fails in multiple places.

By: Gareth Palmer (gareth) 2008-04-16 06:28:42

fabled: The 'I' flag in Dial() doesn't prevent updates once the call has been bridged and it would have to have overwritten the callerid of the outgoing channel by then.

---

Patches have been updated. There was a bug in the previous patches that would have caused a segfault if trustrpid was enabled, you only really want to have that option enabled to trunks anyway.

By: Earl Tom (etom) 2008-04-21 22:43:08

I tried the 1.4.19 patch on our system and still see some problems.  I'm about to upload two debug logs that show the issues we have.

The first is a straight call from 8525 to 8581.  The call works fine, but the RPID header sent to the caller is weird.  That happens on line 324 of "directcall.log".  

The second is an aborted semiattended transfer.  8525 calls 8581, who does an attended transfer to 8544, and completes it before 8544 answers.  After that, 8525 ends the call, but still before 8544 answers.

You can see the same RPID weirdness on lines 291 and 905 for each of the two initiated legs.  But also, the UPDATE method doesn't seem to work, and after that the CANCEL results results in an Internal Server Error, and repeated attempts of 8544 to answer the call get ignored.

The phones are Polycom 650s, SIP 3.0.1 , Bootrom 4.1.0
I've had to edit the log files to declutter them and eliminate the messages from all the other phones on the system, so if there is a missing (or extra) small message, that's why.  In sip.conf sendrpid = yes but I removed the trustrpid lines I had earlier.

This is our production phone system, so I can only do limited testing, and then only after business hours.  But I'd really like to get this functionality in so let me know what I can do to help.

By: Timo Teräs (fabled) 2008-05-01 02:01:45

I added connectedline patch for 1.6.0-beta8 with following changes:
- manually resolved patch conflicts from app_dial.c
- clean up trailing whitespace at end of some lines
- fix locking problem in chan_iax2.c:socket_process(): the channel lock needs to be taken with try_lock before calling ast_set_callerid(), otherwise deadlock is possible as other code paths lock first ast_channel and then take iaxsl lock.

gareth: please update your codebase, and could you consider implementing the possibility to specify 'connectedline=true' in [general] section of iax.conf.

By: Michael Smith (asbestoshead) 2008-05-13 11:06:19

fabled: I applied your asterisk-1.6.0-beta8-connectedline-v2.patch to 1.6.0-beta8. It's been working fantastically since May 10. Thanks a lot.

I just had to set sendrpid=yes for my SIP peers and set CONNECTEDLINE in my stdexten macro:

[macro-stdexten]
;
; Standard extension macro:
;   ${ARG1} - Extension  (we could have used ${MACRO_EXTEN} here as well
;   ${ARG2} - Device(s) to ring
;
exten => s,1,Set(CONNECTEDLINE(all)=${SIPPEER(${ARG1},callerid_name)} <${ARG1}>)
exten => s,n,Dial(${ARG2},20)                   ; Ring the interface, 20 seconds
maximum
......

By: Andrew Lindh (andrew) 2008-05-14 09:53:27

I still have some functionallity issues with this patch. I'm testing with Polycom phones and Asterisk 1.4 and 1.6. The two issues I have are related to transfers. One issue is transfers of calls that I made outbound from the phone no longer work. The second one, if a call is transfered and the calling (transfered) party disconnects the phone keeps runing but can't be answered (because there's no call).

By: Wes Baehr (iwes) 2008-05-19 13:21:03

gareth: Any plans to implement P-Asserted-Identity soon? In addition to Linksys handsets, snom has told me they have no plans to support RPID, but do support P-Asserted.

By: Gareth Palmer (gareth) 2008-06-17 06:46:41

In that SIP trace the Polycom is replying with 501 to the UPDATE request even though it indicates support for UPDATE in it's OPTIONS response.

I would guess that the Polycom probably wants to see a PRACK request before and UPDATE (ie: how the RFC says UPDATE should actually be implemented).

1.4.19-experiments.patch contains two new SIP options, setting needprack=yes will send a PRACK message before an UPDATE. andrew: would you be able to test this?

The other option is rpidtype=passerted which will use the P-Asserted-Identity header instead of Remote-Party-ID. iwes: can you please confirm if that works with you SNOM's.

By: Raj Jain (rjain) 2008-06-17 07:13:43

I've not followed through this thread, but I saw mention of UPDATE (running in parallel with INVITE transaction) and PRACK in some of the notes. Adding support for these methods in Asterisk will require a fundamentally RFC 3261 compliant SIP stack where transaction and dialog states are tracked separately. The current chan_sip.c is not written to this design. I don't think we'll get very far in adding UPDATE and PRACK to the current chan_sip.c.

By: Francesco Romano (francesco_r) 2008-06-18 13:28:49

I have tested the lastest patch with a Linksys SPA941 (5.1.8) and a Snom 300 (6.5.13). The Linksys works with both RPID and P-Asserted. But still doesn't work with Snom. Perhaps is a Snom problem because in the sip header the p-asserted-field is regularly added. Following an ouput from a call pickup:

<--- Transmitting (no NAT) to 192.168.1.58:2054 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.1.58:2054;branch=z9hG4bK-j8hmxbdv1esa;received=192.168.1.58;rport=2054
From: <sip:215@192.168.1.111>;tag=ldtgvxb5uk
To: <sip:*8@192.168.1.111;user=phone>;tag=as221c5d6d
Call-ID: 3c26720ac5c1-u6v8yxd87xq7@snom300-0004132868B9
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:*8@192.168.1.111>
P-Asserted-Identity: "Interno" <sip:201@192.168.1.111>

It's possible to add in the patch the rewrite of CID when pickup from park and with app_directed_pickup?

By: Wes Baehr (iwes) 2008-06-25 14:59:33

gareth: As francesco_r said, it does not work with snoms; I tested with 6.5.17 and 7.1.30.

I submitted a ticket to snom (since they told me to use P-Asserted in the first place) on 6/17/08 but I'm still waiting for a response.

By: Olle Johansson (oej) 2008-07-01 11:32:02

Ok friends. How many different version do we have here? Which patch should I look at to start with? I need to fix these issues.

Can we remove some patches that are old from this issue to make it easier to handle?

By: Doug Lytle (lytledd) 2008-07-04 06:40:54

The 1.4.19 patch currently works with 1.4.20.1, you probably can keep that patch along with the currently 1.6.0 beta patch.

Also, I never saw your post to this bug Olle.  The only reason I came to look at the bug, was because of your DEV post.

By: Doug Lytle (lytledd) 2008-07-04 06:42:59

Looks like the bug tracker is having issues.

By: Olle Johansson (oej) 2008-07-04 09:38:04

The bug tracker has issues with report with this many users. Please check my mail on asterisk-dev today in regards to this issue. We need to make some architecture decisions amongst all developers and then move forward quickly on this. Thanks for your assistance.

A special thank you to Gareth for all of your work. I hope we can bring this to commit together soon!

/Olle

By: Michiel van Baak (mvanbaak) 2008-07-04 16:55:44

dont blame mantis, it's written in PHP.
That language has issues with a lot of stuff ;)
(I'm a fulltime PHP developer during work hours, I can know)

oej: I did not see the patch going into your branch. Is something holding you (besides the discussion on the -dev list) or does it not apply cleanly ?
I'm willing to test this one on skinny and IAX if you need it.

By: Olle Johansson (oej) 2008-07-05 03:01:12

The patch hasn't been integrated in the branch. I wanted to have the discussion first, then we will see if this is the way forward or if we have to do something else. I personally believe that we can use most of Gareth's work, but still need to understand how to best handle the AST_CONTROL and all of the needed caller IDs. Please review my document and give feedback!

By: Gareth Palmer (gareth) 2008-07-06 04:11:33

Hi oej

I have uploaded a new patch against svn trunk now (and one for 1.4.21.1), you may delete any patches previous to these two.

Some comments on your document regarding the need for struct ast_connectedline:

Most of the connected line updates are done _before_ a channel has been bridged so we cannot grab the callerid from the bridged channel. Typical call scenarios are:

1. When calling a channel, we need to pass the called party information to the new channel as we no longer overwrite that channel's callerid.

I did look at extending the prototype for ast_call to include a struct ast_callerid argument but this would have required a lot more additional code.

2. When dialing a trunk device (ie: somehing we receive callerid from) we need somewhere to store the callerid information before it has been allocated.

3. When using call pickup we are taking over the ringing channel which hasn't been bridged yet.

4. When doing a semi-attended transfer we use the connecte line information of the transferrer to tell the transferree whom they are now connected to.

I would liked to have reused struct ast_callerid, however that was undesirable due to the cid_ prefix on its members.

By: Olle Johansson (oej) 2008-07-06 04:23:11

Gareth: Thanks for your reply!

I still think we should use the same structure. There will be changes to that structure and maintaining two similar structures calls for problems, especially when we will have to duplicate functions to manage the structure. I'm thinking about UTF8 caller ID names and SIP URI's that will have to be added.

Otherwise, I see your point about having a non-bridged call. That calls for AST_CONTROL with data. Sometimes one just have to ask a lot of questions to get the full picture. Without questions, you never learn anything. :-)

By: Andrew Lindh (andrew) 2008-07-11 01:53:17

Can you update the prack version too?

By: Digium Subversion (svnbot) 2008-08-06 05:01:33

Repository: asterisk
Revision: 135997

A   team/oej/bug8824-temp/

------------------------------------------------------------------------
r135997 | oej | 2008-08-06 05:01:32 -0500 (Wed, 06 Aug 2008) | 2 lines

Temporary branch for patch in ASTERISK-8584

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=135997

By: Olle Johansson (oej) 2008-08-06 05:50:25

Mering patch into new branch. Any future patches from this moment on, please make them against the branch instead of trunk. Thanks.

By: Andrew Lindh (andrew) 2008-08-07 20:19:53

For me, when using Polycoms, if the transfered caller disconnects before the receiving phone answers then that phone keeps ringing. Has anyone else had this problem?

Example:
A calls B
B answers
B does a blind transfer to C
C rings but has not yet answered
A hangs up now
C is still rining and can not answer a call that no longer exists

By: Digium Subversion (svnbot) 2008-08-08 15:17:10

Repository: asterisk
Revision: 136851

A   team/oej/bug8824-temp/funcs/func_connectedline.c

------------------------------------------------------------------------
r136851 | russell | 2008-08-08 15:17:09 -0500 (Fri, 08 Aug 2008) | 2 lines

Add missing funcs/func_connectedline.c (issue ASTERISK-8584)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=136851

By: Russell Bryant (russell) 2008-08-11 08:06:33

I have some good news from the Digium side of things.  We now have some development resources to put toward helping getting this completed.  We have a few things on our list that we're planning on doing, including:

- adding support for this functionality to both ISDN channel drivers
- changing storage of this information on ast_channel to use a datastore
- updating _all_ call transfer implementations throughout the code base to support this new functionality
- ensuring that connected party updates get sent any time a bridge occurs
- other minor things, like reducing a bit of code duplication

I'm going to create a branch in the team/group area where we will be doing this work.  We hope to get this merged in as soon as we can!

By: Digium Subversion (svnbot) 2008-08-11 08:09:12

Repository: asterisk
Revision: 137186

A   team/group/issue8824/

------------------------------------------------------------------------
r137186 | russell | 2008-08-11 08:09:11 -0500 (Mon, 11 Aug 2008) | 2 lines

Create a branch in team/group for issue ASTERISK-8584

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=137186

By: Digium Subversion (svnbot) 2008-08-11 09:10:25

Repository: asterisk
Revision: 137190

U   team/group/issue8824/apps/app_dial.c
U   team/group/issue8824/apps/app_queue.c
U   team/group/issue8824/channels/chan_agent.c
U   team/group/issue8824/channels/chan_dahdi.c
U   team/group/issue8824/channels/chan_h323.c
U   team/group/issue8824/channels/chan_iax2.c
U   team/group/issue8824/channels/chan_local.c
U   team/group/issue8824/channels/chan_mgcp.c
U   team/group/issue8824/channels/chan_phone.c
U   team/group/issue8824/channels/chan_sip.c
U   team/group/issue8824/channels/chan_skinny.c
U   team/group/issue8824/channels/chan_unistim.c
U   team/group/issue8824/include/asterisk/channel.h
U   team/group/issue8824/include/asterisk/frame.h
U   team/group/issue8824/main/channel.c
U   team/group/issue8824/main/dial.c
U   team/group/issue8824/main/features.c
U   team/group/issue8824/main/rtp.c

------------------------------------------------------------------------
r137190 | russell | 2008-08-11 09:10:25 -0500 (Mon, 11 Aug 2008) | 3 lines

Merge changes from the latest patch on issue ASTERISK-8584, with changes to get it to
apply to the latest code and compile properly.

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=137190

By: Andrew Lindh (andrew) 2008-08-13 16:57:33

I also have problems on the polycoms when doing a transfer (transfers just don't work) and the destination SIP peer has the option "sendrpid = yes"... or so I thought.... I still have the problem, but I can't make it work any more by changing sendrpid. So it's a bug, I just don't know where.



By: Dirk Nehring (dnehring) 2008-08-16 17:18:05

FYI, the latest Aastra firmware update (2.3) contains support for identity update:

P-Asserted-Identity (PAI) Support in UPDATE In Release 2.3
the phones now support PAI header in message the UPDATE message, according to draft-ietf-sipping-update-pai-00.

By: Loic Didelot (voipgate) 2008-09-18 06:39:07

FYI,
doesn't seem that this implementation will work for SNOM phone.


http://lists.digium.com/pipermail/asterisk-users/2008-September/218530.html

By: darkskiez (darkskiez) 2008-09-18 16:39:06

The SNOM Release notes Say Under 6.0.4

# use p-asserted-identity as display name if available in INVITE/18x/200

http://wiki.snom.com/Snom360/Firmware/Release_Notes?&L=0

Whether it works just in call setup, or mid-call, or at all... I'll let you know when I get one to test with.

By: Loic Didelot (voipgate) 2008-09-19 00:52:34

On Tue, 2008-09-16 at 22:56 +0200, Christian Stredicke wrote:
> PAI is supported, but probably not in the way you expect it. We are talking about changing the caller-ID in the display. If From and PAI differ, the phone displays a warning that the network asserted identity does not match the display identity, that's it.

> The nice thing about RFC 4916 is that it is extremly simple and it essentially fixes a bug that was introduced in the first SIP RFC (1999) where From and To had no tags. The other nice thing is that it is a RFC now and clearly the way to go if you want to update the display on the phone.

By: Dirk Nehring (dnehring) 2008-09-21 15:20:21

The digium branch is broken (missing some files), the svn patches are old and do not apply on at least 1.6.0-rc6. Can anyone provide a newer patch set?

By: Gareth Palmer (gareth) 2008-09-21 19:48:16

I have uploaded new patches for 1.4.21.2 and the issue8824 branch. New features are P-Asserted-Identity support (set assertedidentity=yes in sip.conf) and updating the caller ID on directed pickup.

I verified the P-Asserted-Identity handling using an Aastra57i (2.3.1 firmware), you will need to set 'sip update callerid' to 0, otherwise the number gets overwritten by the value supplied in the Contact header.

By: Dirk Nehring (dnehring) 2008-09-23 12:29:11

Branch "issue8824" is broken (with latest patches applied), because some includes are missing, ie.:

  [CC] app_directed_pickup.c -> app_directed_pickup.o
app_directed_pickup.c: In function 'pickup_do':
app_directed_pickup.c:74: error: 'AST_CONNECTED_LINE_UPDATE_SOURCE_ANSWER' undeclared (first use in this function)
app_directed_pickup.c:74: error: (Each undeclared identifier is reported only once
app_directed_pickup.c:74: error: for each function it appears in.)
make[1]: *** [app_directed_pickup.o] Error 1

Perhaps someone should fix this. I personally have ported the patches above to 1.6.0 rc6, but they segfault.

I would like to test this feature with a 1.6 asterisk.

By: Andrew Lindh (andrew) 2008-10-08 12:08:27

The new patch seems to ignore inbound Remote-Party-ID from my AS5300 now (SIP calls from the PRI gateway to asterisk).

By: Mark Michelson (mmichelson) 2008-10-08 13:34:34

gareth: Thanks for the updated patch. Since I wasn't a watcher on this issue, I did not see that you had uploaded a new patch back on the 21st of last month. Since then, I have also added P-Asserted-Identity support into chan_sip. This is in the issue8824 branch now already, but there are a few differences between our implementations that I'd like to point out and potentially discuss since I very well may have misinterpreted what is "supposed" to be done.

1. in get_rpid, if you read a Privacy header with the value "id" in it, then you set the presentation to AST_PRES_PROHIB_USER_PASSED_SCREEN. I set the presentation to AST_PRES_PROHIB_USER_NUMBER_NOT_SCREENED instead. I imagine this is just a matter of preference since I don't know what actual significance the screening portion of caller ID presentation has anyways.

2. in add_rpid, if the presentation indicates that the call is private, then you add a "Privacy: id" header and also send the P-Asserted-Identity header. I interpreted a private presentation to mean that the P-Asserted-Identity header we send should not have the caller information in it. So I set the P-Asserted-Identity to the common "anonymous@anonymous.invalid" value.

3. in get_rpid, I also check for "anonymous@anonymous.invalid" and use that as a way of marking the presentation as private as well.

4. The way the two of us implemented the ability to send P-Asserted-Identity is different. The way I did it was to expand the sendrpid option to take either "yes" "no" "rpid" or "pai" as values. This allowed me to use space in the flags so that I didn't have to create a page 3 of flags.

I'm sorry I didn't notice this patch much earlier or else such conflicts would not exist at all. But it does open up the floor as to how to handle privacy with P-Asserted-Identity.

To dnehring: app_directed_pickup isn't compiling because it needs to #include "asterisk/callerid.h" in order to have the proper constants defined.

By: Mark Michelson (mmichelson) 2008-10-08 13:53:40

By the way, let me comment, gareth, that your patch to chan_sip for P-Asserted-Identity is really cleanly done (much more than the way I threw it together), so I'll probably do some formatting changes in the issue8824 branch to align more with how you did it in your latest patch. Great work!

By: Brad Allen (ulmo) 2008-10-12 17:23:14

Is this on track to get into Asterisk 1.6 before gareth burns out?

When I worked at Paramount Pictures in 1994, their phone system had this feature.  It's 14.5 years later, and I'm glad Asterisk might be supporting it soon, eventually, but wondering if it will take longer than the life of telephony.

I note that there is no variable "CALLEDID" in the response to "CORE SHOW FUNCTION CALLEDID" in Asterisk 1.6.0.

By: Brad Allen (ulmo) 2008-10-12 18:20:30

Getting repeatable segmentation faults attempting to use CalledID
patch 1.6.0-beta7.1.patch in Asterisk 1.6.0 (three patch rejects
applied by hand in obvious ways): SIP channel won't even come up when
I dial test extension.

Recommended debug levels would be appreciated; I only had "core set verbose 10",
which showed nothing between when I submitted the number in Twinkle and when
Asterisk segfaulted (not even a little comment).  Then, I added "sip set debug
on", and that shows:

$ asterisk -r
Asterisk 1.6.0, Copyright (C) 1999 - 2008 Digium, Inc. and others.
Created by Mark Spencer <markster@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
Connected to Asterisk 1.6.0 currently running on C (pid = 14393)
C*CLI> core set verbose 10
Verbosity was 0 and is now 10
C*CLI> sip set debug on
SIP Debugging enabled
C*CLI>
<--- SIP read from UDP://10.0.0.1:5061 --->
INVITE sip:83@10.0.0.1 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.1:5061;rport;branch=z9hG4bKaovtsfmp
Max-Forwards: 70
To: <sip:83@10.0.0.1>
From: "My Personal Name" <sip:localuserexample-twinkle@10.0.0.1>;tag=rnzqh
Call-ID: gnguuoybrzadyyq@LOCAL.DOMAIN.NAME
CSeq: 791 INVITE
Contact: <sip:localuserexample-twinkle@10.0.0.1:5061>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.3.2
Content-Length: 227

v=0
o=twinkle 998115872 281312760 IN IP4 10.0.0.1
s=-
c=IN IP4 10.0.0.1
t=0 0
m=audio 8000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

<------------->
--- (13 headers 11 lines) ---
 == Using SIP RTP TOS bits 184
 == Using SIP RTP CoS mark 5
 == Using SIP VRTP TOS bits 136
 == Using SIP VRTP CoS mark 6
Sending to 10.0.0.1 : 5061 (NAT)
Using INVITE request as basis request - gnguuoybrzadyyq@LOCAL.DOMAIN.NAME
Found user 'localuserexample-twinkle' for 'localuserexample-twinkle'

<--- Reliably Transmitting (no NAT) to 10.0.0.1:5061 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.0.0.1:5061;branch=z9hG4bKaovtsfmp;received=10.0.0.1;rport=5061
From: "My Personal Name" <sip:localuserexample-twinkle@10.0.0.1>;tag=rnzqh
To: <sip:83@10.0.0.1>;tag=as11b7c6a8
Call-ID: gnguuoybrzadyyq@LOCAL.DOMAIN.NAME
CSeq: 791 INVITE
User-Agent: Asterisk PBX 1.6.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="2cc26fa5"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog 'gnguuoybrzadyyq@LOCAL.DOMAIN.NAME' in 32000 ms (Method: INVITE)
C*CLI>
<--- SIP read from UDP://10.0.0.1:5061 --->
ACK sip:83@10.0.0.1 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.1:5061;rport;branch=z9hG4bKaovtsfmp
Max-Forwards: 70
To: <sip:83@10.0.0.1>;tag=as11b7c6a8
From: "My Personal Name" <sip:localuserexample-twinkle@10.0.0.1>;tag=rnzqh
Call-ID: gnguuoybrzadyyq@LOCAL.DOMAIN.NAME
CSeq: 791 ACK
User-Agent: Twinkle/1.3.2
Content-Length: 0


<------------->
--- (9 headers 0 lines) ---

Disconnected from Asterisk server
----------------------------------------------------------
The "Disconnected from Asterisk server" is Segmentation Fault (SEGFAULT) of the Asterisk server.

By: Gareth Palmer (gareth) 2008-10-13 23:29:51

1. PAI/RPID headers should only be used between peers in the same trust domain so they must have passed a screen of some sort (RFC3325, Sections 1 & 5).

2. The behaviour you describe doesn't seem to match that shown in the RFC. The intended use of PAI was to pass the actual callerid to a trusted peer even when presentation was prohibited. The anonymous@anonymous.invalid value is used, but in the From: header (RFC3325, Section 10).

3. You don't need to prohibit the presentation of an anonymous callerid as it doesn't have any user identifiable information in it anymore.

4. As PAI is now supported the rpid part of sendrpid & trustrpid doesn't make sense. I think it would be better to create new `identity' parameter that accepts multiple comma separated values:

    identity=send,trust,rpid
    identity=yes,pai # yes is equivalent to send,trust

And if from-change from RFC4916 ever gets implemented:

    identity=trust,from

I will set aside some time later this week to produce an updated version of the 1.6 patch.

By: pj (pj) 2008-10-24 04:36:04

for testing rpid functionality, should I try to checkout standalone branch 'issue8824': http://svn.digium.com/view/asterisk/team/group/issue8824/
or patches from this bugreport applied to vanilla asterisk trunk?
is it ready for testing?

By: Russell Bryant (russell) 2008-10-24 06:41:39

Yes, it is ready for testing and checking out that branch is the correct thing to do.

Thanks,

By: Timo Teräs (fabled) 2008-12-11 07:19:01.000-0600

I uploaded a patch to chan_dahdi that implements the connected line support using patched libpri (see issue 0012357). The added features are #ifdefed so it should compile even with vanilla libpri. Please consider applying to the svn.

By: tpm (tpm) 2008-12-19 07:37:59.000-0600

Hello,

I patch version 1.4.21.2 with 1.4.21.2.patch and it works great with Aastra phones.

Is there a way to patch other recent version like 1.4.22 ou 1.4.23


Thanks

By: Martin Butler (mbutler) 2008-12-21 13:40:00.000-0600

Was anyone able to make it work on an Aastra 480i phone? Correct me if I'm wrong but it seems that they only accept Contact header updates...

Thanks :)



By: Yehavi Bourvine (yehavi) 2009-02-04 07:26:30.000-0600

Hello,

 I'v tried this patch on both 1.4 (few versions, including 1.4.22.1) and 1.6; it works ok except that it breaks blind transfers. The transfer either ends as one-way audio or Asterisk crashes.

 I am using canreinvite=yes if this changes something.

                       Thanks, __Yehavi:

By: tpm (tpm) 2009-02-04 07:44:49.000-0600

Hello Yevahi

What is your phone ( Aastra, polycom ... ), i tried with Aastra and did not see this problem version 1.4.21.2 Aastra 57i.

Where did you get the 1.4.22.1 or 1.6 patch did you make yours ?

By: Yehavi Bourvine (yehavi) 2009-02-04 07:48:15.000-0600

I am using Polycom-501 version 2.2.2.

The patch is the latest from this page which I complete manually for the parts it fails in them.

                     Thanks, __Yehavi:

By: tpm (tpm) 2009-02-04 08:03:47.000-0600

You could tried with 1.4.21.2 with the 1.4.21.2 patch on this page.
That's work for me.
Have you got some Aastra phone ?
Because it can be the Polycom firmware or the way you're doing you patch.
regards

By: Yehavi Bourvine (yehavi) 2009-02-04 09:16:34.000-0600

Most of our phones are Polycom-501 with single samples of Cisco and SNOM. No Aastra...

Even if the problem is with Polycom's firmware - Asterisk should not choke on it... Besides that, a vanilla Asterisk (without this patch) behaves correctly.

                       Thanks, __Yehavi:

By: pj (pj) 2009-02-05 13:21:03.000-0600

Hi, should this feature also work for skinny phones?
I tried with 7940 and it doesn't work. Is there some equivalent of sendrpid/trustrpid also for skinny.conf or it is enabled "automatically"?
Currently, rpid only works with sip firmware for my 7940.
I have checked branch:
http://svn.digium.com/svn/asterisk/team/group/issue8824
and in dialplan I have added:
Set(CONNECTEDLINE(all)=Echo test <959>);

By: Gareth Palmer (gareth) 2009-02-10 21:21:19.000-0600

I've uploaded new versions of the patch for 1.4.23.1 and 1.6.0.1.

The patch now shouldn't try and send UPDATE requests to Polycom phones now, also transferring a call while the other end is ringing is a semi-attended transfer, not a blind transfer.

It probably breaks due to the minimal (or missing) handling of responses to UPDATE requests.

By: Andrew Lindh (andrew) 2009-02-11 12:50:08.000-0600

Thanks for the updates!

I use Polycom phones and it works for me when I got rid if your user agent check (using 1.4 branch). I still get the UPDATE errors (from older polycom firmware), but it works. Blind transfers work for me (the older polycom firmware seems to have some issues sometimes).



By: pj (pj) 2009-02-11 13:06:23.000-0600

gareth, you have updated also branch for this issue or only patches?
http://svn.digium.com/svn/asterisk/team/group/issue8824
some time ago, russell said here, that this branch is prefered way to test rpid feature.
I would also ask again, if this should work for skinny phones, as I wrote here in msg 99523, thanks

By: Jeff LaCoursiere (lacoursj) 2009-02-18 18:28:33.000-0600

Hi, applied this patch to 1.4.23.1 cleanly.  Have Polycom 501, Polycom 500, and Linksys PAP2T for testing.  All transfers worked fine, and directed call pickup (**ext) works fine, but a general call pickup (*8) does not.

220 (Linksys) calls 223 (IP500)
222 (IP501) dials *8

IP501's display shows 220 (correct), and appears to be in a call, but the Linksys is still ringing and there is no audio passed between them.

I actually tried this in all three possible combinations, and got the same result :)

By: Francesco Romano (francesco_r) 2009-02-19 03:54:05.000-0600

lacoursj, this is a bug of asterisk 1.4.23, not of this patch. See the issue ASTERISK-13333 i opened that was resolved after the official release.

By: Jeff LaCoursiere (lacoursj) 2009-02-19 09:06:18.000-0600

Sure enough, that patch fixed me.  Thanks gareth for the amazing work!  And thanks francesco_r for pointing this out.

The thread for this patch (which took over an hour to read through!) confuses me on the state of the patch and 1.6 release.  Is it part of 1.6 now, or still being planned?

By: Mark Michelson (mmichelson) 2009-03-17 15:20:05

All right, everyone, this issue should hopefully be coming to a close very soon. Asterisk 1.6.2 has been branched, meaning that Asterisk trunk is wide open for new feature consideration. This would be a great candidate for 1.6.3.

For a look at the actual code which is being considered for merging into Asterisk trunk, please see the branch located here:

http://svn.digium.com/svn/asterisk/team/group/issue8824

This branch is based off of the current trunk of Asterisk and contains all remote party identification modifications. The branch started based off gareth's excellent starting patches. Through testing conducted at Digium and by others, we have modified it to accurately present remote party identification through both normal calls and through features like call pickup, transfers, etc. To help fast-track this, I have placed a diff between the branch I linked above and trunk on review board, here:

http://reviewboard.digium.com/r/201/

While we have done extensive testing to be sure that we have implemented the feature correctly, we still want to hear feedback if at all possible before merging this into trunk. We expect that once the code is in trunk, there will be more people who will test and report feedback.

My plan is to wait a couple of weeks to hear feedback both here and on review board in case there are some major outstanding problems. Thanks for your patience on this one. I know this is a much sought-after feature, and hopefully it will be officially part of Asterisk very soon.

By: pj (pj) 2009-03-17 16:56:37

ok, so what about my issue, that rpid doesn't work for my skinny phones?
http://bugs.digium.com/view.php?id=8824#99523

By: Mark Michelson (mmichelson) 2009-03-17 18:14:47

@pj: I'm not too familiar with chan_skinny or skinny.conf, so I don't know if there is a special option like there is in sip.conf.

Looking briefly through the code, it looks as though we handle the case of being able to send remote identification to a skinny phone. The code looks a bit suspicious to me. I know of some people in the #asterisk-dev channel who were going to do some testing with skinny phones. They'll probably be able to give some more insight as to why the feature is not working with skinny phones.

By: pj (pj) 2009-03-24 13:40:16

somebody has tip for softphone, that support rpid feature? I tried xlite/eyebeam and twinkle with no luck, it works only with my cisco phone with sip firmware.
I tried rpid branch:
http://svn.digium.com/svn/asterisk/team/group/issue8824

By: Digium Subversion (svnbot) 2009-04-03 17:41:49

Repository: asterisk
Revision: 186525

_U  trunk/
U   trunk/CHANGES
U   trunk/apps/app_dial.c
U   trunk/apps/app_directed_pickup.c
U   trunk/apps/app_queue.c
U   trunk/channels/chan_agent.c
U   trunk/channels/chan_dahdi.c
U   trunk/channels/chan_h323.c
U   trunk/channels/chan_iax2.c
U   trunk/channels/chan_local.c
U   trunk/channels/chan_mgcp.c
U   trunk/channels/chan_misdn.c
U   trunk/channels/chan_phone.c
U   trunk/channels/chan_sip.c
U   trunk/channels/chan_skinny.c
U   trunk/channels/chan_unistim.c
U   trunk/channels/misdn/chan_misdn_config.h
U   trunk/channels/misdn/isdn_lib.c
U   trunk/channels/misdn/isdn_lib.h
U   trunk/channels/misdn/isdn_lib_intern.h
U   trunk/channels/misdn/isdn_msg_parser.c
U   trunk/channels/misdn_config.c
U   trunk/configs/misdn.conf.sample
U   trunk/configs/sip.conf.sample
U   trunk/include/asterisk/callerid.h
U   trunk/include/asterisk/channel.h
U   trunk/include/asterisk/frame.h
_U  trunk/include/asterisk/rtp_engine.h
_U  trunk/include/asterisk/stun.h
U   trunk/main/callerid.c
U   trunk/main/channel.c
U   trunk/main/dial.c
U   trunk/main/features.c
_U  trunk/main/rtp_engine.c
UU  trunk/main/stun.c
UU  trunk/res/res_rtp_asterisk.c

------------------------------------------------------------------------
r186525 | mmichelson | 2009-04-03 17:41:48 -0500 (Fri, 03 Apr 2009) | 22 lines

This commit introduces COLP/CONP and Redirecting party information into Asterisk.

The channel drivers which have been most heavily tested with these enhancements are
chan_sip and chan_misdn. Further work is being done to add Q.SIG support and will be
introduced in a later commit. chan_skinny has code added to it here, but according
to user pj, the support on chan_skinny is not working as of now. This will be fixed in
a later commit.

A special thanks goes out to bugtracker user gareth for getting the ball rolling and
providing the initial support for this work. Without his initial work on this, this would
not have been nearly as painless as it was.

This functionality has been tested by Digium's product quality department, as well as a
customer site running thousands of calls every day. In addition, many many many many bugtracker
users have tested this, too.

(closes issue ASTERISK-8584)
Reported by: gareth

Review: http://reviewboard.digium.com/r/201


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=186525

By: Digium Subversion (svnbot) 2009-04-03 17:43:20

Repository: asterisk
Revision: 186526

_U  branches/1.6.0/

------------------------------------------------------------------------
r186526 | mmichelson | 2009-04-03 17:43:20 -0500 (Fri, 03 Apr 2009) | 27 lines

Blocked revisions 186525 via svnmerge

........
 r186525 | mmichelson | 2009-04-03 17:41:46 -0500 (Fri, 03 Apr 2009) | 22 lines
 
 This commit introduces COLP/CONP and Redirecting party information into Asterisk.
 
 The channel drivers which have been most heavily tested with these enhancements are
 chan_sip and chan_misdn. Further work is being done to add Q.SIG support and will be
 introduced in a later commit. chan_skinny has code added to it here, but according
 to user pj, the support on chan_skinny is not working as of now. This will be fixed in
 a later commit.
 
 A special thanks goes out to bugtracker user gareth for getting the ball rolling and
 providing the initial support for this work. Without his initial work on this, this would
 not have been nearly as painless as it was.
 
 This functionality has been tested by Digium's product quality department, as well as a
 customer site running thousands of calls every day. In addition, many many many many bugtracker
 users have tested this, too.
 
 (closes issue ASTERISK-8584)
 Reported by: gareth
 
 Review: http://reviewboard.digium.com/r/201
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=186526

By: Digium Subversion (svnbot) 2009-04-03 17:43:47

Repository: asterisk
Revision: 186527

_U  branches/1.6.1/

------------------------------------------------------------------------
r186527 | mmichelson | 2009-04-03 17:43:47 -0500 (Fri, 03 Apr 2009) | 27 lines

Blocked revisions 186525 via svnmerge

........
 r186525 | mmichelson | 2009-04-03 17:41:46 -0500 (Fri, 03 Apr 2009) | 22 lines
 
 This commit introduces COLP/CONP and Redirecting party information into Asterisk.
 
 The channel drivers which have been most heavily tested with these enhancements are
 chan_sip and chan_misdn. Further work is being done to add Q.SIG support and will be
 introduced in a later commit. chan_skinny has code added to it here, but according
 to user pj, the support on chan_skinny is not working as of now. This will be fixed in
 a later commit.
 
 A special thanks goes out to bugtracker user gareth for getting the ball rolling and
 providing the initial support for this work. Without his initial work on this, this would
 not have been nearly as painless as it was.
 
 This functionality has been tested by Digium's product quality department, as well as a
 customer site running thousands of calls every day. In addition, many many many many bugtracker
 users have tested this, too.
 
 (closes issue ASTERISK-8584)
 Reported by: gareth
 
 Review: http://reviewboard.digium.com/r/201
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=186527

By: Digium Subversion (svnbot) 2009-04-03 17:44:09

Repository: asterisk
Revision: 186528

_U  branches/1.6.2/

------------------------------------------------------------------------
r186528 | mmichelson | 2009-04-03 17:44:09 -0500 (Fri, 03 Apr 2009) | 27 lines

Blocked revisions 186525 via svnmerge

........
 r186525 | mmichelson | 2009-04-03 17:41:46 -0500 (Fri, 03 Apr 2009) | 22 lines
 
 This commit introduces COLP/CONP and Redirecting party information into Asterisk.
 
 The channel drivers which have been most heavily tested with these enhancements are
 chan_sip and chan_misdn. Further work is being done to add Q.SIG support and will be
 introduced in a later commit. chan_skinny has code added to it here, but according
 to user pj, the support on chan_skinny is not working as of now. This will be fixed in
 a later commit.
 
 A special thanks goes out to bugtracker user gareth for getting the ball rolling and
 providing the initial support for this work. Without his initial work on this, this would
 not have been nearly as painless as it was.
 
 This functionality has been tested by Digium's product quality department, as well as a
 customer site running thousands of calls every day. In addition, many many many many bugtracker
 users have tested this, too.
 
 (closes issue ASTERISK-8584)
 Reported by: gareth
 
 Review: http://reviewboard.digium.com/r/201
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=186528

By: Michiel van Baak (mvanbaak) 2010-02-14 06:11:33.000-0600

Added patch against latest 1.4 svn trunk (requested by niekvlessert)
I had to delete one of the flags because 1.4 is still using the 32 flags.
Do not use this patch if you are using g726_nonstandard, I removed that one to make room for the connected_line flag.

Tested and ok from niekvlessert. (tested on 1.4.29)