[asterisk-bugs] [JIRA] (ASTERISK-24795) When a call is dialed using a gosub to a different context using the switch/goto statement and the call is parked, recovering the call gives a wrong callerid

Rusty Newton (JIRA) noreply at issues.asterisk.org
Thu Apr 2 17:53:33 CDT 2015


    [ https://issues.asterisk.org/jira/browse/ASTERISK-24795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225756#comment-225756 ] 

Rusty Newton edited comment on ASTERISK-24795 at 4/2/15 5:53 PM:
-----------------------------------------------------------------

An issue in the open state does not mean it is being actively worked on.

An open issue is waiting for a developer to take on the issue and begin investigation of the problem. I'm sending the issue back to triage as your recent comments regarding reproduction of the issue without use of pbx_ael requires that we look at it again.

I've attempted reproduction of the issue using your provided extensions.conf dialplan and a sip.conf of my own. I cannot reproduce the issue exactly. Using your dialplan in reproduction I can see that the CallerID for the called party's channel (let us say Channel B) is '_X.' from the very beginning and when recovering the party call it is it then expected to see '_X.' as the CallerID on Channel B.

The Party B peer that I am dialing does not have an Asterisk configured CallerID and does not send RPID or PAI to Asterisk. Therefore _X. is Asterisk's best guess (as it is the extension that did the Dial) and remains the CallerID for the Channel B the from the Dial onward through to finally recovery of the parked call. Of course, if you configure CallerID in sip.conf that would change this behavior.. but we don't have your sip.conf to see. I'm also curious what your trustrpid option is set to?

In your full debug log I don't see where the called party sends any RPID or PAI headers to Asterisk. Therefore I'm not sure why you would expect the Channel B CallerID information to change or update from the original _X. ?



was (Author: rnewton):
An issue in the open state does not mean it is being actively worked on.

An open issue is waiting for a developer to take on the issue and being investigation of the problem. I'm sending the issue back to triage as your recent comments regarding reproduction of the issue without use pbx_ael requires that we look at it again.

I've attempted reproduction of the issue using your provided extensions.conf dialplan and a sip.conf of my own. I cannot reproduce the issue exactly. Using your dialplan in reproduction I can see that the CallerID for the called party's channel (let us say Channel B) is '_X.' from the very beginning and when recovering the party call it is it then expected to see '_X.' as the CallerID on Channel B.

The Party B peer that I am dialing does not have an Asterisk configured CallerID and does not send RPID or PAI to Asterisk. Therefore _X. is Asterisk's best guess (as it is the extension that did the Dial) and remains the CallerID for the Channel B the from the Dial onward through to finally recovery of the parked call. Of course, if you configure CallerID in sip.conf that would change this behavior.. but we don't have your sip.conf to see. I'm also curious what your trustrpid option is set to?

In your full debug log I don't see where the called party sends any RPID or PAI headers to Asterisk. Therefore I'm not sure why you would expect the Channel B CallerID information to change or update from the original _X. ?


> When a call is dialed using a gosub to a different context using the switch/goto statement and the call is parked, recovering the call gives a wrong callerid
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-24795
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24795
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: PBX/pbx_ael, Resources/res_parking
>    Affects Versions: 11.12.0, 12.8.1, 13.2.0
>         Environment: CentOS 6 64 bit
>            Reporter: Leandro Dardini
>            Assignee: Rusty Newton
>            Severity: Minor
>         Attachments: fulldebug
>
>
> Using AEL language, If an extension calls a number XXX and then park the call, the number XXX being dialed is saved in the parking lot. When the call parked is recovered, the number XXX is transmitted to the calling extension using RPID. If the extension calls the number using a context reached using a gosub and in that context a switch statement is used, the number XXX is lost and being replaced by internal dialplan data, like SW_549_SIP or _X.
> Probably the application breaking the RPID is the "Goto".
> This bad behavior can be tested using this minimal diaplan:
> {code}
> context doDialing {
>         _X. => {
>             Set(a=5);
>             switch (${a}) {
>               case 1: NoOp(one);
>                    break;
>               case 2: NoOp(two);
>                    break;
>               case 3: NoOp(three);
>                    break;
>               case 4: NoOp(four);
>                    break;
>               case 5: NoOp(five);
>                        break;
>             }
>             Dial(SIP/onlytest/998474638374);
>         }
> }
> context internal {
>     104 => {
>        gosub(doDialing,104,1);
>     } 
>     *7 => {
>         Park();
>     }
>  
>     *8 => {
>         ParkedCall();
>     }
> }
> {code}
> And dialing from an extension in the "internal" context the number 104, then transferring to *7 and then recovering the call with *8
> This is the output of the CLI during the call:
> {code}
>     -- Executing [104 at authenticated:1] Gosub("SIP/110-DEVEL-00000016", "doDialing,104,1") in new stack
>     -- Executing [104 at doDialing:1] MSet("SIP/110-DEVEL-00000016", "~~EXTEN~~=104") in new stack
>     -- Executing [104 at doDialing:2] Set("SIP/110-DEVEL-00000016", "a=5") in new stack
>     -- Executing [104 at doDialing:3] Goto("SIP/110-DEVEL-00000016", "sw_4335_5,10") in new stack
>     -- Goto (doDialing,sw_4335_5,10)
>     -- Executing [sw_4335_5 at doDialing:10] NoOp("SIP/110-DEVEL-00000016", "five") in new stack
>     -- Executing [sw_4335_5 at doDialing:11] Goto("SIP/110-DEVEL-00000016", "_X.,4") in new stack
>     -- Goto (doDialing,_X.,4)
>     -- Executing [_X. at doDialing:4] NoOp("SIP/110-DEVEL-00000016", "Finish switch_doDialing_4335") in new stack
>     -- Executing [_X. at doDialing:5] Dial("SIP/110-DEVEL-00000016", "SIP/onlytest/998474638374") in new stack
> {code}
> When getting back the call with *8 the callerid connected appears to be "_X.". 
> This doesn't happen if the call is made without using the switch/goto statement. This doesn't happen if the call is made without using the gosub. This doesn't happen if the dialed number transmit RPID once reconnected.



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list