Attended transfer caller ID update

if you would like to develop/breadboard something that does this we would be happy to review. While you are at it, take a look at doing the same for callpickup...

Do you think that it is mandatory to send the sip info by asterisk, or that it is possible to send it from an AGI script trigged from FreePBX dialplan ?

I'm not sure i'm able to do this. FreePBX dialplan is too much complicated for me.

Seems like Mark Michelson from Asterisk-dev group could be the person to contact to implement this.

Some usefull informations for Aastra phones implementation :

1) Do allow Caller-ID realtime update :

Set "sip update callerid: 1" in the aastra.cfg file. This is supported since may 2007, firmware release 1.4.2.

2) Then it is possible for a proxy or call server to update the Caller ID information that displays on the phone during a call, by modifying the SIP Contact header in the 200 OK message and/or in a re-INVITE message. The phone displays the updated name and number information contained within the Contact header.

3) The needed function to do this has been implemented inside Asterisk 1.8. So it should possible to include them in the FreePBX dialplan.

Asterisk 1.8 Changelog sample, Dialplan fcuntions and comments :

* Added new dialplan functions CONNECTEDLINE and REDIRECTING which permits setting various connected line and redirecting party information.

I think that "Redirecting" could be used to get the right Caller ID for call Pickup.

Redirecting is a name to describe the aspects of the common feature called RPID or remote party id. The idea is that a user can dial a number and the display on the users phone is updated during the call with the information about the called party. This is also described as reverse caller id. Regardless this feature has become complicated. The features in Asterisk 1.8 include sharing this calling information with many protocols and interfaces like DAHDI, IAX2, SIP, etc...

Some documentation about CONNECTEDLINE (Submitter: Mark Michelson in the Asterisk Reviewboard).

Connected line reception and transmission is a new feature in Asterisk 1.8 trunk. One of its shortcomings is the inability to modify received connected line information while a dialplan application is running.

Here is a common example where this may be useful. Many office environments require that a digit (such as '9') is dialled in order to reach the PSTN. The problem is that when one dials a PSTN number, the information received from the far end will not have this prefix digit. To make the lives of users easier, it would be really nice if the prefix digit could be displayed for them.

This proposed patch adds the ability to add connected line interception macros into the dialplan. When we are going to send a connected line update to someone, the administrator has the ability to run a macro which can do whatever manipulation of connected line information is necessary to appease everyone. There are four defined macros in the channelvariables.tex file.

${CONNECTED_LINE_SEND_CALLEE_MACRO} Macro to call before sending a connected line update to the callee ${CONNECTED_LINE_SEND_CALLEE_MACRO_ARGS} Arguments to pass to ${CONNECTED_LINE_SEND_CALLEE_MACRO} ${CONNECTED_LINE_SEND_CALLER_MACRO} Macro to call before sending a connected line update to the caller ${CONNECTED_LINE_SEND_CALLER_MACRO_ARGS} Arguments to pass to ${CONNECTED_LINE_SEND_CALLER_MACRO}

So in the example I gave above, the administrator could write a simple macro like this:

[macro-addnine] exten => s,1,Set(CONNECTEDLINE(num,i)=9${CONNECTEDLINE(num)}); Adds '9' to the connected line number

Then, he could add a priority before any Dial to the PSTN: exten => blah,n,Set(CONNECTED_LINE_SEND_CALLER_MACRO=addnine)

Simple as that! And of course, one is not limited to modifying just the connected line number. You could modify the name, or even information not relating to connected line information.

Please review my code and see if there is anything that needs fixing. I realize as I am typing this that I have not placed anything in the CHANGES file, so I need to do that soon.i

Testing Done:

I have tested this with a scenario similar to what I listed above. In addition, I tested features such as call pickup (both using the Pickup application and the pickupexten from features.conf), built-in blind and attended transfers, and SIP transfers.

---

Here is the informations linked here in my first message. (The link does not work).

Could be interesting as well.

Indicating Change of Caller-ID

There are certain situations when the caller-ID of a call needs to be changes. Examples include *69 or *66 (redial and call return), where the user-agent does not know a priori where the call will go. UA with RFC 4916 support

If the user agent indicates support for RFC 4916, then the PBX uses that RFC. However, the Identity-related information are not provided. UA without RFC 4916 support

SIP (RFC3261) does not permit the change of the To- and From-headers in an established dialog. Therefore, just changing the headers is no solution to the problem.

Using the Replaces header could be a solution to the problem. The PBX could initiate a new call that replaces the call which needs the caller-ID replacement. However, there are several reasons that make this approach problematic:

• Many user agents do not support the Replaces header or they do not support it properly.
• Using the Replaces header has side effects on the call-list of the user agents. Many user agents will show the incoming call as a new call and keep the old call in the call history.
• The media path must be re-negotiated. That means that there will be a short click sound during the replacement of the call.

Therefore, uses a new mechanism that only serves the purpose of changing the caller-ID on the display of the user agent. The user agent must indicate that it is able to receive these updates with a "Supported: callerid" in the INVITE request or a response to the INVITE. If this is the case, the system will send a INFO message in the dialog that has the format like in the example below:

INFO sip:123@test.com SIP/2.0 From: <sip:a@test.com>;tag=123 To: <sip:b@test.com>;tag=456 Call-ID: 123456789 CSeq: 1234 INFO Content-Length: … Content-Type: message/sipfrag

From: "A" <sip:123@test.com> To: "B" <sip:456@test.com>

The body of the message contains a SIP message fragment (RFC3420) that contains the To- and From-headers as they should look like if it was possible to change the headers in a dialog (as if they had been received in the INFO request, so that the From/To direction is clear). Tags and other parameters should not be changed. The user agent should update the display and may change the local call history. However, it should not change the To- and From-headers of the dialog.

User agents that do not show the Supported header will not receive the INFO messages, because some user agents terminate the call upon receipt of a unknown media type.

If using built in Asterisk transfer this has been implemented with the CONNECTEDLINE ability. If using phone specific, some testing I have done works, though I suspect there are probably plenty of scenarios (possibly with follow-me, etc.) that may be flawed. As specific scenarios are tested and don't conform or result in "device" <devnum> CID info, please report them with lots of details to reproduce and log traces so we can work out any kinks.

This all depends on Asterisk 1.8.