[asterisk-bugs] [Asterisk 0012663]: Incoming REMOTE_HOLD on Zap is always passed to the bridged channel

[noreply at bugs.digium.com]

The following issue requires your FEEDBACK. 
====================================================================== 
http://bugs.digium.com/view.php?id=12663 
====================================================================== 
Reported By:                gminet
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12663
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.17 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             05-15-2008 11:40 CDT
Last Modified:              06-02-2008 16:39 CDT
====================================================================== 
Summary:                    Incoming REMOTE_HOLD on Zap is always passed to the
bridged channel
Description: 
We have several customers using PRI E1 lines to connect to the telco
(Digium TE220B cards, E1 PRIs in Belgium).

When someone on ther side calls out using a SIP phone another party
through the telco/pri and gets placed on hold by the remote party, he hears
the local music on hold and not the remote music on hold. That's confusing
our customers as often the company name and products are often said on top
of the music.
In fact he can briefly hear the remote moh that gets replaced after half a
second by the local one.

This happens when the remote party is using a PBX on PRI, some PBX on BRI,
and also mobile phones.

In the logs I see the zap channel is receiving a REMOTE_HOLD control frame
and the the local moh is started on the bridged sip channel.

====================================================================== 

---------------------------------------------------------------------- 
 Corydon76 - 06-02-08 16:39  
---------------------------------------------------------------------- 
I'm pretty sure this is not a Zaptel problem, as there is no way to pass
that control frame through a Zaptel channel.  It's probably SIP, though I
think the way this behaves is actually a feature.  Moving to SIP.

Consider that music is not critical to be passed across a voip link, and
so to conserve bandwidth, a notification is sent that the call is on hold
instead, and so the music is generated locally.  A possible workaround
might be to set the musiconhold class to some other value (which does NOT
mention the company name) prior to outcalling.

Does this make more sense now? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-02-08 16:39  Corydon76      Note Added: 0087682                          
06-02-08 16:39  Corydon76      Status                   new => feedback     
06-02-08 16:39  Corydon76      Category                 Channels/chan_zap =>
Channels/chan_sip/General
======================================================================