[Home]

Summary:ASTERISK-24346: Using "r" option on Dial() command prevents Remote-party-ID from reaching caller
Reporter:Dennis Buteyn (dennis-xorcom)Labels:
Date Opened:2014-09-21 03:52:27Date Closed:
Priority:MinorRegression?No
Status:Open/NewComponents:Applications/app_dial
Versions:11.11.0 13.18.4 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Reproduced on generic CentOS 6.5 and Elastix 2.4.Attachments:( 0) right.pcap
( 1) wrong.pcap
Description:Background:

Customer was trying to use RPID in a two-PBX configuration with intra-company SIP trunk to provide caller with called party name. Upon testing customer found that RPID information was received by callee but caller display showed dialed number.

Configuration used to reproduce issue:

Extension A <-SIP-> PBX-A <-SIP-> PBX-B <-SIP-> Extension B

Options sendrpid=yes, trustrpid=yes defined where applicable.

Wireshark trace showed that due to Dial() command to extension B with "r" option, PBX-B sent early RINGING notification without RPID header to PBX-A. Second RINGING notification was sent to PBX-A after PBX-B received RINGING notification from Extension B. PBX-A only propagated first RINGING notification to Extension A, second RINGING notification was ignored by PBX-A.

Disabling "r" option on both systems allowed conforming SIP flow and RPID information was propagated properly to caller.

Code in question that appears to be responsible in apps/app_dial.c:
{noformat}
static struct ast_channel *wait_for_answer(struct ast_channel *in,
       struct dial_head *out_chans, int *to, struct ast_flags64 *peerflags,
       char *opt_args[],
       struct privacy_args *pa,
       const struct cause_args *num_in, int *result, char *dtmf_progress,
       const int ignore_cc,
       struct ast_party_id *forced_clid, struct ast_party_id *stored_clid)
{
 ...

 looping over frames
 ...

                       switch (f->frametype) {
                       case AST_FRAME_CONTROL:
                               switch (f->subclass.integer) {
 ...
                               case AST_CONTROL_RINGING:
                                       ++num_ringing;
                                       if (ignore_cc || cc_frame_received || num_ringing == numlines) {
                                               ast_verb(3, "%s is ringing\n", ast_channel_name(c));
                                               /* Setup early media if appropriate */
                                               if (single && !caller_entertained
                                                       && CAN_EARLY_BRIDGE(peerflags, in, c)) {
                                                       ast_channel_early_bridge(in, c);
                                               }
                                               if (!(pa->sentringing) && !ast_test_flag64(outgoing, OPT_MUSICBACK) && ast_strlen_zero(opt_args[OPT_ARG_RINGBACK])) {
                                                       ast_indicate(in, AST_CONTROL_RINGING);
                                                       pa->sentringing++;
                                               }
                                       }
                                       break;
{noformat}
Comments:By: Rusty Newton (rnewton) 2014-09-24 17:40:15.930-0500

[~dennis-xorcom] can you go ahead and attach a pcap and Asterisk log demonstrating the issue as well. Ideally showing the working and failing scenarios.

Also, thanks for the detail in your report!
By: Dennis Buteyn (dennis-xorcom) 2014-09-25 05:45:21.315-0500

Yes, of course though this will be at it's earliest on Sunday as I currently do not have access to lab equipment.
By: Dennis Buteyn (dennis-xorcom) 2014-10-07 05:17:41.159-0500

Packet captures as requested, capture made on PBX-2

Endpoint-1: 192.168.5.132
PBX-1: 192.168.0.130
PBX-2: 192.168.0.205
Endpoint-2: 192.168.6.11
By: Rusty Newton (rnewton) 2015-01-19 10:24:59.092-0600

Forgot to un-assign myself after opening the issue up.