[asterisk-bugs] [JIRA] (ASTERISK-25649) VoiceMail exitcontext not able to use transfer function if local channel engaged

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


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

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

I understand now. I'm not sure why the Local channel doesn't work with Transfer. It may be because the Local channel itself has two legs and the remote party to ;2 is ;1 (the suffixes used on the Local channels).

I tested with 
{noformat}
[from_internal]
exten = 100,1,Dial(LOCAL/999 at another_context/b,8,r)

[another_context]
exten = 999,1,Voicemail(1234)

[transfer_context]
exten = o,1,Transfer(SIP/BOB)
{noformat}

I saw the same behavior as you did. I'm not sure if this is a bug or not. Feels like one but I'll have a developer take a look. Based on documentation I think this is a bug.


As a work around - Is there a particular reason why you are using Transfer? 

If you Dial the other SIP channel directly, once that end answers then the Local channel should optimize itself out of the way (leaving the two SIP channels bridged).




was (Author: rnewton):
I understand now. I'm not sure why the Local channel doesn't work with Transfer. It may be because the Local channel itself has two legs and the remote party to ;2 is ;1 (the suffixes used on the Local channels).

Is there a particular reason why you are using Transfer? 

If you Dial the other SIP channel directly, once that end answers then the Local channel should optimize itself out of the way (leaving the two SIP channels bridged).



> VoiceMail exitcontext not able to use transfer function if local channel engaged
> --------------------------------------------------------------------------------
>
>                 Key: ASTERISK-25649
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25649
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_voicemail/ODBC, Channels/chan_local, Channels/chan_sip/General
>    Affects Versions: 11.2.2
>         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