[asterisk-bugs] [JIRA] (ASTERISK-21673) 183 without SDP - Early media not properly handled on outbound TCP trunk

[dcitelecom (JIRA)]

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

dcitelecom commented on ASTERISK-21673:
---------------------------------------

Yes. It should be configurable. Lync has a fairly large (growing) user base and it would kind of make sense to be compatible with them. I do not propose to change the legacy behavior of Asterisk as that would break compatibility with other PBXs. A flag to simply let the user decide how to handle 183 would not break anything and (in my case) fix the issue. Of course if this can only be considered for Asterisk 12 then I don't know what to do as we unfortunately need a solution now.

I just wanted to get this to work. If I had a patch I would gladly share it but then I wouldn't really have a problem. It's unfortunate that there seems to be no way currently to get this to work. 
                
> 183 without SDP - Early media not properly handled on outbound TCP trunk
> ------------------------------------------------------------------------
>
>                 Key: ASTERISK-21673
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21673
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Interoperability
>    Affects Versions: 11.3.0
>         Environment: FreePBX distro 3.211.63-7
> Centos 6.3, Asterisk 11.3.0 
>            Reporter: dcitelecom
>         Attachments: Early media Asterisk 11 log.txt
>
>
> Voxbone DID (defined in inbound routes) is sent out to customer trunk ABCco (TCP) trunk. They reply with 183 session progress (early media announcement) and Asterisk sends 180 ringing back to Voxbone.
> This is problematic where the DID is forwarded to a cell phone and the phone is off or the forwarding number was entered wrong. In both cases the user should hear an early media announcement that the user is not available or the number is not in service. Instead they hear a ring tone and don't know there is a problem. Log attached
> DIALPLAN
> exten => #0216479999999,1,Set(__FROM_DID=$
> {EXTEN}
> )
> exten => #0216479999999,n,Gosub(app-blacklist-check,s,1())
> exten => #0216479999999,n,Gosub(sub-record-cancel,s,1())
> exten => #0216479999999,n,Set(__REC_POLICY_MODE=never)
> exten => #0216479999999,n,Set(CDR(did)=$
> {FROM_DID}
> )
> exten => #0216479999999,n,ExecIf($[ "$
> {CALLERID(name)}
> " = "" ] ?Set(CALLERID(name)=$
> {CALLERID(num)}
> ))
> exten => #0216479999999,n,Set(CHANNEL(musicclass)=none)
> exten => #0216479999999,n,Set(__MOHCLASS=none)
> exten => #0216479999999,n,Set(__CALLINGPRES_SV=$
> {CALLERPRES()}
> )
> exten => #0216479999999,n,Set(CALLERPRES()=allowed_not_screened)
> exten => #0216479999999,n(dest-ext),Goto(ext-trunk,5,1)
> [ABCAsia] (trunk 5)
> disallow=all
> type=peer
> host=202.xxx.xxx.xxx
> transport=tcp
> allow=alaw
> allow=ulaw
> relaxdtmf=yes
> dtmfmode=rfc2833
> directmedia=yes
> context=from-ABCco-HK

--
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