[asterisk-bugs] [JIRA] (ASTERISK-21673) 183 without SDP - Early media not properly handled on outbound TCP trunk
Michael L. Young (JIRA)
noreply at issues.asterisk.org
Thu Apr 25 09:09:38 CDT 2013
[ https://issues.asterisk.org/jira/browse/ASTERISK-21673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205821#comment-205821 ]
Michael L. Young edited comment on ASTERISK-21673 at 4/25/13 9:07 AM:
----------------------------------------------------------------------
Asterisk 11 is not in development... that would be Asterisk 12. New features will not go into Asterisk 11.
The only problem I see is that we never negotiate a media session with Lynx. We make an offer but they never tell us that they accept that offer. Does Lync support the preferred audio codec that we offered? How is Asterisk to know which codec to use for the media stream? Is Asterisk supposed to just _assume_ that what it offered was acceptable and start accepting media? I could foresee a whole bunch of support issues caused by that.
I wonder which PBXs you refer to when you say "many other PBX's"? I would think those other PBXs would show up when doing research and the only PBX that popped up in my search was Lync.
I saw a post out there were someone modified their PBX / SIP Proxy (not sure if they were using Asterisk, a different PBX or a SIP proxy) to handle working with Lync by detecting that they were communicating with Lync server. Unfortunately, they felt they couldn't share it as it was a "trade secret".
It is sad that Lync decided to do things their own way instead of what is being done in the real world. I make that comment solely based on the reading I have done on this subject of 183 with or without SDP.
If what you are looking for is a feature to be added to allow this on a per peer or global basis, then we need to have a patch attached to this issue or, if you do not have a patch, discuss this openly (which would reach a greater audience) on the mailing lists (http://www.asterisk.org/support/mailing-lists). We do not accept feature requests without a patch on the issue tracker.
Hope you don't feel that I am trying to shoot this down. As you can see, it is not a simple thing to just turn on or an easy policy change.
was (Author: elguero):
Asterisk 11 is not in development... that would be Asterisk 12. New features will not go into Asterisk 11.
The only problem I see is that we never negotiate a media session with Lynx. We make an offer but they never tell us that they accept that offer. Does Lync support the preferred audio codec that we offered? How is Asterisk to know which codec to use for the media stream? Is Asterisk supposed to just _assume_ that what it offered was acceptable and start accepting media? I could foresee a whole bunch of support issues caused by that.
I wonder which PBXs you refer to when you say "many other PBX's"? I would think those other PBXs would show up when doing research and the only PBX that popped up in my search was Lync.
I saw a post out there were someone modified their PBX / SIP Proxy (not sure if they were using Asterisk, a different PBX or a SIP proxy) to handle working with Lync by detecting that they were communicating with Lync server. Unfortunately, they felt they couldn't share it as it was a "trade secret".
It is sad that Lync decided to do things their own way instead of what is being done in the real world. I make that comment solely based on the reading I have done on this subject of 183 with or without SDP.
If you are looking for is a feature to be added to allow this on a per peer or global basis, then we need to have a patch attached to this issue or, if you do not have a patch, discuss this openly (which would reach a greater audience) on the mailing lists (http://www.asterisk.org/support/mailing-lists). We do not accept feature requests without a patch on the issue tracker.
Hope you don't feel that I am trying to shoot this down. As you can see, it is not a simple thing to just turn on or an easy policy change.
> 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
More information about the asterisk-bugs
mailing list