[asterisk-bugs] [JIRA] (ASTERISK-25649) Transfer application does not work with Local channels - documentation misleading

Ivan Ullmann (JIRA) noreply at issues.asterisk.org
Wed Jan 6 09:16:34 CST 2016


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

Ivan Ullmann commented on ASTERISK-25649:
-----------------------------------------

Rusty,

That also doesn't match with documentation respecting the local channel for version 11.  From https://wiki.asterisk.org/wiki/display/AST/Local+Channel+Modifiers :

•'b' - This option causes the Local channel to return the actual channel that is behind it when queried. This is useful for transfer scenarios as the actual channel will be transferred, not the Local channel.
This option is available starting in the Asterisk 1.6.0 branch and was removed in Asterisk 12.

My call flow requires that I remove the Asterisk SIP Server from call flow (via REFER) so that the upstream SIP Server can also remove itself from call flow (via REFER as well).  This allows me to return the call to my routing SIP Server so that I can send it on to my service center (as the label implies).  So while I do agree that Dial() does work appropriately, it is not an appropriate mechanism for transfer based on my call flow needs.

Is this something where this functionality truly unsupportable, or is this something that will possibly be addressed and I should look for a new release at some point?  If this isn't something that can be done, is there another mechanism where I can intercept a request to apply the VoiceMail() application and add a timer so that I can produce an alternative action if it doesn't respond appropriately in a timeframe?

Thank you,
-Ivan


> Transfer application does not work with Local channels - documentation misleading
> ---------------------------------------------------------------------------------
>
>                 Key: ASTERISK-25649
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25649
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_transfer, Channels/chan_local, Documentation
>    Affects Versions: 11.20.0
>         Environment: Development
>            Reporter: Ivan Ullmann
>            Assignee: Unassigned
>            Severity: Minor
>         Attachments: extensions.conf, features.conf, full.asterisk-25649.txt, sip.conf, voicemail.conf
>
>
> When triggering exitcontext logic inside of the VoiceMail application, calls sent to the local channel cannot transfer.
> Call Flow:
>      1. Incoming call to Asterisk server via SIP
>      2. Call is processed appropriately to VoiceMail application via a Dial function to a local channel
>      3. Press 0
>      4. Call triggers 'toSvcCenter' dialplan logic
>      5. Transfer function triggered
>      6. Extension exits non-zero on Local channel
> {noformat}
>   == Using SIP RTP TOS bits 184
>   == Using SIP RTP CoS mark 5
>     -- Executing [9999999999 at sip:1] Wait("SIP/Asterisk_CLE-00000024", "1") in new stack
>     -- Executing [9999999999 at sip:2] Set("SIP/Asterisk_CLE-00000024", "SIP_CODEC=ulaw") in new stack
>     -- Executing [9999999999 at sip:3] Set("SIP/Asterisk_CLE-00000024", "GLOBAL(INITIAL_CHANNEL)=SIP/Asterisk_CLE-00000024") in new stack
>   == Setting global variable 'INITIAL_CHANNEL' to 'SIP/Asterisk_CLE-00000024'
>     -- Executing [9999999999 at sip:4] Set("SIP/Asterisk_CLE-00000024", "GLOBAL(INCOMING_SIP_PEER)=10.93.118.12") in new stack
>   == Setting global variable 'INCOMING_SIP_PEER' to '10.93.118.12'
>     -- Executing [9999999999 at sip:5] GotoIf("SIP/Asterisk_CLE-00000024", "0?internal:next1") in new stack
>     -- Goto (sip,9999999999,14)
>     -- Executing [9999999999 at sip:14] GotoIf("SIP/Asterisk_CLE-00000024", "0?external:customer") in new stack
>     -- Goto (sip,9999999999,17)
>     -- Executing [9999999999 at sip:17] Dial("SIP/Asterisk_CLE-00000024", "local/9999999999 at Leave_VoiceMail/b,8,r") in new stack
>     -- Called local/9999999999 at Leave_VoiceMail/b
>     -- Executing [9999999999 at Leave_VoiceMail:1] VoiceMail("Local/9999999999 at Leave_VoiceMail-00000004;2", "9999999999 at GVMA_DN,su") in new stack
>     -- Local/9999999999 at Leave_VoiceMail-00000004;1 answered SIP/Asterisk_CLE-00000024
> [Dec 29 18:06:42] NOTICE[19515][C-00000026]: chan_sip.c:7238 try_suggested_sip_codec: Changing codec to 'ulaw' for this call because of ${SIP_CODEC} variable
> [Dec 29 18:06:42] NOTICE[19515][C-00000026]: chan_sip.c:7238 try_suggested_sip_codec: Changing codec to 'ulaw' for this call because of ${SIP_CODEC} variable
>        > 0x189d30a0 -- Probation passed - setting RTP source address to 10.93.107.65:3794
>     -- <Local/9999999999 at Leave_VoiceMail-00000004;2> Playing '/var/spool/asterisk/voicemail/GVMA_DN/9999999999/unavail.slin' (language 'en')
>     -- <Local/9999999999 at Leave_VoiceMail-00000004;2> Playing 'transfer.ulaw' (language 'en')
>     -- Executing [o at toSvcCenter:1] BackGround("Local/9999999999 at Leave_VoiceMail-00000004;2", "one-moment-please") in new stack
>     -- <Local/9999999999 at Leave_VoiceMail-00000004;2> Playing 'one-moment-please.ulaw' (language 'en')
>     -- Executing [o at toSvcCenter:2] Transfer("Local/9999999999 at Leave_VoiceMail-00000004;2", "SIP/ToSvcCenter at 10.93.118.12") in new stack
>     -- Executing [o at toSvcCenter:3] Hangup("Local/9999999999 at Leave_VoiceMail-00000004;2", "") in new stack
>   == Spawn extension (toSvcCenter, o, 3) exited non-zero on 'Local/9999999999 at Leave_VoiceMail-00000004;2'
>   == Spawn extension (sip, 9999999999, 17) exited non-zero on 'SIP/Asterisk_CLE-00000024'
> {noformat}
> I am unable to perform a Transfer() back on the SIP/Asterisk_CLE-00000024 channel.  My call flow requires a SIP REFER in order to remove this server from call flow.  Dial() works, but the upstream server is expecting to produce a REFER to the originating SIP Server as well, and this results in calls being REFER'd back to Asterisk rather than upstream.



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



More information about the asterisk-bugs mailing list