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

Rusty Newton (JIRA) noreply at issues.asterisk.org
Tue Jan 5 20:36:34 CST 2016


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

Rusty Newton edited comment on ASTERISK-25649 at 1/5/16 8:34 PM:
-----------------------------------------------------------------

I talked with [~jcolp] Looks like the Local channel technology does not implement the necessary transfer callback. So,  Local channel technology will not work with the Transfer application.
{quote}
Requests the remote caller be transferred to a given destination. If TECH (SIP, IAX2, LOCAL etc) is used, only an incoming call with the same channel technology will be transferred. Note that for SIP, if you transfer before call is setup, a 302 redirect SIP message will be returned to the caller.
{quote}

The documentation pretty much says that you can use Local channel tech with the application. We should fix that at least.




was (Author: rnewton):
I talked with [~jcolp] Looks like the Local channel technology does not implement the necessary transfer callback. So,  Local channel technology will not work with the Transfer application.
{quote}
Requests the remote caller be transferred to a given destination. If TECH (SIP, IAX2, LOCAL etc) is used, only an incoming call with the same channel technology will be transferred. Note that for SIP, if you transfer before call is setup, a 302 redirect SIP message will be returned to the caller.
{quote}

This issue will be used to track the documentation fix since the documentation pretty much says that you can use Local channel tech with the application.



> 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