Summary:	ASTERISK-20345: Prevent Music on hold from being played when a 183 response indicates the media stream should be sendonly
Reporter:	Pietro Quarantini (leone)	Labels:
Date Opened:	2012-08-30 10:09:25	Date Closed:	2012-08-31 08:31:05
Priority:	Critical	Regression?
Status:	Closed/Complete	Components:
Versions:	1.8.12.2	Frequency of Occurrence
Related Issues:
Environment:	Ubuntu Server 10.4 LTS	Attachments:
Description:	Hi all, I have the problem with my PBX. In my PBX there is asterisk 1.8.12.0 and when my ISP send the message 183 with attribute a=sendonly i don't listen the busy tone but the music on hold. I "solved" this bug with nat="no" in the trunk, but this is a rough patch!!! For my buisness this is a big problem!!! I would like have real patch!!! I have see the new realease of asterisk but i don't found the solution! Someone has an idea?
Comments:	By: David Woolley (davidw) 2012-08-30 11:19:10.794-0500 See http://forums.digium.com/viewtopic.php?f=1&t=82757 In my view, this is a feature request without patch for the ability to selectively suppress the generation of AST_CONTROL_HOLD, or maybe to modify it so that it doesn't replace the through media with a generator, but does still block the media in the reverse direction. I think it is a sufficiently rare problem that it counts as minor severity. By: Pietro Quarantini (leone) 2012-08-30 11:36:10.305-0500 David thanks for your answer! I see the topic in the forum but this solution implies lose local MOH beetween two extensions. It's not professional solution and customer asks the music on hold inside comunication. This is critical bug for two motive: 1. Asterisk violates RFC 3264 -> 5.1 Unicast Streams 2. In several office ther is need to install single remote SIP phone! With nat="no" this is major limitation! At present there is no solution in anticipation? Thanks By: David Woolley (davidw) 2012-08-30 11:52:14.686-0500 You need to wait for someone closer to the core of the development work to confirm whether this is a feature request, but if it is, you need to go to the mailing list or IRC channel to find out whether it is being addressed.  If it is a feature request, it will not be supported until the next major version, although there may be, unsupported, back ports. The severities are defined in terms of how many people are inconvenienced by a particular problem, not by the maximum inconvenience to any one person.  However, quite often, they are not corrected downwards. By: Paul Belanger (pabelanger) 2012-08-30 12:42:44.234-0500 Who said asterisk is RFC 3264 compliant?  Like David said, at best this is a feature request.  If this is impacting your business you'll want to hire somebody from the asterisk-biz list to write a patch. If we determine this to be a bug, we'll triage the issue otherwise it will be closed out as a feature request. By: Pietro Quarantini (leone) 2012-08-31 03:01:19.017-0500 With the ITALY ISP TWT i met this problem and we have tried to understand the cause. After a month of analysis and on the plotted facts with wireshark, Technical support specialist told me that the fault is due to a misinterpretation of the asterisk RFC 3264, for the reasons previously written. Dear Paul unfortunately I can not hire anyone since I'm just a simple technical and I have reported anomelia with the aim of resolving to improve asterisk. David you're right ... Let me know if it comes to functionality or bug so I act accordingly. If it can be useful to someone ISP action on the following ticket I can try to ask. thanks By: Matt Jordan (mjordan) 2012-08-31 08:29:58.369-0500 I have to agree with David.  The intended behavior of Asterisk is to treat restriction of the media stream as an indication that Asterisk should put the channel on Hold, which includes starting MOH.  This behavior has been around in Asterisk for a long, long time, and it feels as if addressing this in a release branch is liable to cause more problems than it solves. As such, yes, I agree that this is a feature request.  As such, feature requests require patches in order to be considered for inclusion in trunk.  As Paul suggested, you may want to consider contacting someone from the asterisk-biz list to write such a patch. For now, I'll be closing this issue out as a feature request until a patch is available.  When it is, I'd be happy to reopen this issue. By: Massimo Nuvoli (maxnuv) 2013-03-01 06:50:34.989-0600 I fall in the same problem of Pietro Quarantini, but i ask the provider to solve the problem. This is the response: "The problem is at Asterisk side, Asterisk is not RFC 3264 compliant: 5.1 Unicast Streams   If the offerer wishes to only send media on a stream to its peer, it   MUST mark the stream as sendonly with the "a=sendonly" attribute. So to put a call on hold the call MUST be on, not in indication state. and 8.4 Putting a Unicast Media Stream on Hold   If a party in a call wants to put the other party "on hold", i.e.,   request that it temporarily stops sending one or more unicast media   streams, a party offers the other an updated SDP.   If the stream to be placed on hold was previously a sendrecv media   stream, it is placed on hold by marking it as sendonly.  If the   stream to be placed on hold was previously a recvonly media stream,   it is placed on hold by marking it inactive. " I was thinking to open a new issue, but i found this one. I am facing a big problem, the provider (the same TWT) tell me that this is Asterisk problem, so they dont want (in short time) to solve the problem. Thnks. By: Maurizio (maurizion) 2013-04-04 02:12:54.040-0500 Hello, I have the same serious problem with the sip server res.sip.twt.it, I did tuttte the evidence listed above, but nothing changes. There is also a temporary solution to shake the problem? By: Pietro Quarantini (leone) 2013-04-04 03:30:11.838-0500 Maurizio call me 0307721399. We have same ISP! By: Pietro Quarantini (leone) 2013-04-04 10:28:18.132-0500 Hello, kindly all users who are experiencing the same problem with the same TSP call me! Thanks