[asterisk-bugs] [JIRA] (ASTERISK-24792) CLONE - app_transfer fails with PJSIP channels

Private Name (JIRA) noreply at issues.asterisk.org
Fri Feb 13 20:55:34 CST 2015


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

Private Name edited comment on ASTERISK-24792 at 2/13/15 8:53 PM:
------------------------------------------------------------------

I have a handle leak when using app_transfer, after the bug was fixed, In a matter of minutes the FIFO count goes to hundreds of thousands, from maybe 100 in regular SIP channel, same exact logic.
The dialplan all it does is transfer calls without ever answering them,   more than 100 times per second.
If somebody gives me detailed instructions I can run the process under gdb, but I need details as to what to do to determine what is leaking the handles.
 


was (Author: falves11):
I have a handle leak when using app_transfer, after the bug was fixed, In a matter of minutes the FIFO count goes to hundreds of thousands, from maybe 100 in regular SIP channel, same exact logic.
The dialplan all it does is transfer calls without ever answering them,   more than 100 times per second.
If somebody give detailed instructions I can run the process under gdb, but I need details as to what to do to determine what is leaking the handles.
 

> CLONE - app_transfer fails with PJSIP channels
> ----------------------------------------------
>
>                 Key: ASTERISK-24792
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24792
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_transfer
>    Affects Versions: SVN, 12.3.2, 12.5.0
>         Environment: Linux Fedora 20
>            Reporter: Private Name
>            Assignee: Matt Jordan
>
> When using PJSIP, the Transfer application does not behave like the when using the old SIP channel, i.e., generate 301 Redirect messages
> Here is the trace
> {noformat}
> [Jul  9 21:39:29] DEBUG[47716][C-00000002]: pbx.c:4869 pbx_extension_helper: Launching 'Transfer'
>     -- Executing [17274428141 at redirect:30] Transfer("PJSIP/Client.1.1.1.1-00000002", "PJSIP/17274428141;rn=+18134029999;npdi at 1.1.1.1") in new stack
> [Jul  9 21:39:29] DEBUG[47716][C-00000002]: pbx.c:4869 pbx_extension_helper: Launching 'Verbose'
>     -- Executing [17274428141 at redirect:31] Verbose("PJSIP/Client.1.1.1.1-00000002", "2,Transferred: 17274428141;rn=+18134029999;npdi at 1.1.1.1") in new stack
>   == Transferred: 17274428141;rn=+18134029999;npdi at 1.1.1.1
>     -- Auto fallthrough, channel 'PJSIP/Client.1.1.1.1-00000002' status is 'UNKNOWN'
> [Jul  9 21:39:29] DEBUG[47716][C-00000002]: channel.c:2597 ast_softhangup_nolock: Soft-Hanging (0x10) up channel 'PJSIP/Client.1.1.1.1-00000002'
> [Jul  9 21:39:29] DEBUG[47716][C-00000002]: channel.c:2753 ast_hangup: Hanging up channel 'PJSIP/Client.1.1.1.1-00000002'
> [Jul  9 21:39:29] DEBUG[47716][C-00000002]: chan_pjsip.c:1578 hangup_cause2sip: AST hangup cause 0 (no match found in PJSIP)
> <--- Transmitting SIP response (369 bytes) to UDP:1.1.1.1:49260 --->
> SIP/2.0 603 Decline
> v: SIP/2.0/UDP 1.1.1.1:49260;rport;received=1.1.1.1;branch=z9hG4bK-d8754z-22994e127365d474-1---d8754z-
> i: MmFjNDM4NDc2NmFhZWNiYTU2MDQ1YmNjNGVmYmMyOTY
> f: "9544447408" <sip:9544447408 at 8.26.191.189>;tag=82c82c1d
> t: <sip:17274428141 at 8.26.191.189>;tag=09f3a67a-f457-46d1-8d16-243478ac3859
> CSeq: 1 INVITE
> Reason: Q.850;cause=0
> l:  0
> {noformat}
> Note: it makes no difference if the endpoint has "allow_transfer" in false or true, yes or now. The behavior is identical.
> This issue is a blocker for me, since I process several million redirects per day. Hence the importance. I already converted everything else and it works perfectly,



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



More information about the asterisk-bugs mailing list