[Home]

Summary:ASTERISK-24792: CLONE - app_transfer fails with PJSIP channels
Reporter:Private Name (falves11)Labels:
Date Opened:2015-02-13 20:49:10.000-0600Date Closed:2015-02-14 13:19:41.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Applications/app_transfer
Versions:SVN 12.3.2 12.5.0 Frequency of
Occurrence		Constant
Related
Issues:
is the original version of this clone:ASTERISK-24015 app_transfer fails with PJSIP channels
duplicatesASTERISK-24768 res_timing_pthread: file descriptor leak
Environment:Linux Fedora 20Attachments:
Description: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@redirect:30] Transfer("PJSIP/Client.1.1.1.1-00000002", "PJSIP/17274428141;rn=+18134029999;npdi@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@redirect:31] Verbose("PJSIP/Client.1.1.1.1-00000002", "2,Transferred: 17274428141;rn=+18134029999;npdi@1.1.1.1") in new stack
 == Transferred: 17274428141;rn=+18134029999;npdi@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@8.26.191.189>;tag=82c82c1d
t: <sip:17274428141@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,
Comments:By: Private Name (falves11) 2015-02-13 20:53:03.564-0600

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.