[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=205819#comment-205819 ] 

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

For me this issue is more about interoperability than standards. The progress() application in the dialplan does not work in this case and there is currently no way in Asterisk to make this work. Lync (and many other PBX's) send 183 Session Progress without SDP so Asterisk treats it as 180 instead of 183. 

This behavior is debatable but my goal is simply for Asterisk to work with Lync and the easiest way to do this would be to have a trunk variable in Asterisk (sip.conf I guess) on how to treat 183 session progress. The default could be as it is now and the other option would be to always respond to 183 with 183. That way Asterisk could be configured on a per trunk basis to be compatible with every PBX out there and the change would not affect current configurations. Since Asterisk 11 is still very much in development this seems to me a very desirable option and if you google the issue it seems this affects many Asterisk users not just us.
                
> 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