[asterisk-dev] [Code Review] 2429: Pimp my SIP: Caller ID and limited connected line support

[Joshua Colp]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2429/
-----------------------------------------------------------

(Updated April 16, 2013, 10:16 p.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers and Joshua Colp.


Bugs: ASTERISK-21257
    https://issues.asterisk.org/jira/browse/ASTERISK-21257


Repository: Asterisk


Description
-------

This introduces Caller ID support into the new SIP work.

A new module, res_sip_caller_id.c has been added. It contains a session supplement that allows for caller ID and connected line information to be learned from incoming requests and responses and to be added to outbound requests and responses.

This module supports learning caller ID from the following sources:
1. P-Asserted-Identity header on an incoming INVITE
2. Remote-Party-ID header on an incoming INVITE
3. From header on an incoming INVITE
4. Configured caller ID on an endpoint.

This module is capable of learning of connected line updates in the following ways:
1. On an initial outbound INVITE, we can queue a connected line update based on the configured caller ID of the target
2. On an inbound INVITE or INVITE response, we can queue a connected line update based on Remote-Party-ID or P-Asserted-Identity headers.

Privacy is implemented here a bit differently than it is in chan_sip. Here, there are two options, trust_id_inbound, and trust_id_outbound. trust_id_inbound is similar to the trust_rpid option from chan_sip. It determines whether we use ID information from external sources when communicating caller ID and connected line information. trust_id_outbound determines if we should send identity information to an endpoint if the caller ID or connected line information is marked as private. The idea here is that we more closely follow a "trust domain" model where trust indicates whether we can forward private information along or not. If trust_id_outbound is not true, then we will only send identity information if it is not private.

One difference between this and chan_sip's implementation is that there are two separate options, send_pai and send_rpid, that determine if we should communicate caller ID and connected line via the P-Asserted-Identity or Remote-Party-ID headers, respectively. By having two options, it becomes possible to send both types of headers if we wish.

Preserved from chan_sip is the callerid_tag setting that allows for setting some sort of "tag" on the caller ID. This is never communicated externally and it cannot be set based on SIP signaling since it is an Asterisk-specific value. It is mainly useful for planning your dialplan.

What is meant by "limited" connected line support? We will communicate connected line information to a caller during initial call setup. So on INVITE responses such as 180 Ringing and 200 OK, we will send connected line information if we received it from the far end or if it was set via the CONNECTEDLINE dialplan function. We do not support "on demand" or mid-call connected line updates. In other words, if the CONNECTEDLINE dialplan function were to be called multiple times, we would not send multiple provisional responses with new connected line values to the caller. Similarly, if we were to receive a reinvite in mid-call, we would not update the connected line properly on the other side of the bridge. The reason this is missing is simply because chan_gulp does not currently handle AST_CONTROL_CONNECTED_LINE frames in gulp_indicate(). The other thing we do not support is the UPDATE method for sending or receiving connected line. This is because the session supplement in res_sip_caller_id.c only cares about the INVITE method for the time being. A second supplement could be added to work with UPDATE pretty easily.

In addition to the direct work done for caller ID, the session supplement structure has been changed. For res_sip_caller_id's supplement to function properly, it needs to run before the channel is created. This way, the session creation stasis event will have the caller ID populated properly. In order to guarantee that the new supplement runs before channel creation, I added an integer priority member to the ast_sip_session_supplement structure. The lower this number is, the earlier the supplement will execute. I devised an enum to give pre-defined values for the priorities based on certain milestones during INVITE handling. At the moment, the only such milestone is the creation of the channel. Certain supplements will likely wish to be run before channel creation, while others will wish to run after. This enum can be expanded on as new session milestones are introduced.


Diffs
-----

  /team/group/pimp_my_sip/channels/chan_gulp.c 384967 
  /team/group/pimp_my_sip/include/asterisk/res_sip.h 384967 
  /team/group/pimp_my_sip/include/asterisk/res_sip_session.h 384967 
  /team/group/pimp_my_sip/res/res_sip/sip_configuration.c 384967 
  /team/group/pimp_my_sip/res/res_sip_caller_id.c PRE-CREATION 
  /team/group/pimp_my_sip/res/res_sip_session.c 384967 

Diff: https://reviewboard.asterisk.org/r/2429/diff/


Testing
-------

I ran many calls between phones and SIPp, testing a variety of options that exercised different code paths in res_sip_callerid.c


Thanks,

Mark Michelson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130416/66b3f161/attachment.htm>