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

[Matt Jordan (JIRA)]

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

Matt Jordan edited comment on ASTERISK-21673 at 4/25/13 9:16 AM:
-----------------------------------------------------------------

This is most likely running into the patch provided for ASTERISK-14412. Ironically, that patch was provided for interoperability as opposed to standards (I sense a pattern here...), but has caused interoperability problems with other PBXs. There have been a few other complaints about this behavior.

As an aside, any time you think "we should change this just for interoperability reasons", it's good to err on the cautious side.

Essentially, Alcatel PBXs would send us a 183 with no SDP. This caused issues in that Asterisk would ignore the message and we would fail to indicate ringing or MoH to the other side. As a result, we decided to just treat it as a 180 Ringing.

As Michael has alluded to, changing this behavior to accommodate Lync would break our interoperability with legacy Alcatel PBXs. Solving an interoperability problem with Lync would simply break someone else.

As much as I hate *yet another* lever in Asterisk to pull, this should probably be configurable somehow - either we treat 183 with no SDP as a 180, OR we transmit a 183 session progress to the other side.
                
      was (Author: mjordan):
    This is most likely running into the patch provided for ASTERISK-14412. Ironically, that patch was provided for interoperability as opposed to standards (I sense a pattern here...), but has caused interoperability problems with other PBXs. There have been a few other complaints about this behavior.

As an aside, any time you think "we should change this just for interoperability reasons", it's good to err on the cautious side.

Essentially, Alcatel PBXs would send us a 183 with no SDP. This caused issues in that Asterisk would ignore the message and we would fail to indicate ringing or MoH to the other side. As a result, we decided to just treat it as a 180 Ringing.

As Michael has alluded to, changing this behavior to accomodate Lync would break our interoperability with legacy Alcatel PBXs.

As much as I hate *yet another* lever in Asterisk to pull, this should probably be configurable somehow - either we treat 183 with no SDP as a 180, OR we transmit a 183 session progress to the other side.
                  
> 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