[asterisk-bugs] [JIRA] (ASTERISK-21912) Call hang-up when issuing mixmonitor start

[Michael L. Young (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-21912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael L. Young reassigned ASTERISK-21912:
-------------------------------------------

    Assignee:     (was: Fabrice CAHEN)
    
> Call hang-up when issuing mixmonitor start
> ------------------------------------------
>
>                 Key: ASTERISK-21912
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21912
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_mixmonitor, Channels/chan_sip/General
>    Affects Versions: 10.7.1, 10.12.2
>         Environment: Darwin PowerPC 
>            Reporter: John Covert
>
> Call drops immediately after issuing mixmonitor command:
> asterisk*CLI> mixmonitor start SIP/x37-000005dd 2013-06-14-16:30:16.59.ulaw
>     -- Native bridging SIP/x37-000005dd and SIP/von-g-000005de ended
>   == Begin MixMonitor Recording SIP/x37-000005dd
>   == Spawn extension (macro-vonout, s, 4) exited non-zero on 'SIP/x37-000005dd' in macro 'vonout'
>   == Spawn extension (dialstation, 824313034997111, 1) exited non-zero on 'SIP/x37-000005dd'
>   == MixMonitor close filestream (mixed)
>   == End MixMonitor Recording SIP/x37-000005dd
> I have just noticed that this failure occurs on an INCOMING call dialed from SIP/x37 (or any other sip device) to context dialstation37, but does not occur if the call is set up with "originate sip/x37 extension 824313034997111 at dialstation37".
> Update:
> It seems that the following creates the conditions which cause the failure:
> Executing [s at macro-vonout:2] Set("SIP/x37-0000000c", "SIP_CODEC=ulaw") in new stack
> [Jun 14 22:32:58] NOTICE[21167]: chan_sip.c:6905 try_suggested_sip_codec: Changing codec to 'ulaw' for this call because of ${SIP_CODEC} variable
> Even though this is executed in both the phone-originated (failing) and asterisk-originated case, it creates the necessary conditions for the failure only in the phone-originated case.
> It was inserted in the outgoing macro for this trunk group (which doesn't do g.722) so that the phone would set up the call in ulaw mode and not require transcoding by asterisk.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira