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

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
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 17:25 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.

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

---------------------------------------------------------------------- 
 gminet - 06-02-08 17:25  
---------------------------------------------------------------------- 
Thank you for your time.

The hold/retrieval messages really come through the Zap channel from the
telco. Here is a debug ouput of a call to my mobile. You can see it
receives message 16 (HOLD) on Zap/1-1 when I put the call on hold on my
mobile, and immediately starts the music on hold on the bridged sip
channel.


<< [ TYPE: Control (4) SUBCLASS: Unknown control '16' (16) ] [Zap/1-1]
    -- Started music on hold, class 'default', on SIP/393-08c5fa00
[Jun  3 00:06:20] DEBUG[23808]: channel.c:2072 ast_settimeout: Scheduling
timer at 160 sample intervals
[Jun  3 00:06:20] DEBUG[23808]: channel.c:2155 ast_read_generator_actions:
Generator got voice, switching to phase locked mode
[Jun  3 00:06:20] DEBUG[23808]: channel.c:2072 ast_settimeout: Scheduling
timer at 0 sample intervals
[Jun  3 00:06:20] DEBUG[23808]: channel.c:3020 set_format: Set channel
SIP/393-08c5fa00 to write format slin
[Jun  3 00:06:20] DEBUG[23808]: res_musiconhold.c:261 ast_moh_files_next:
SIP/393-08c5fa00 Opened file 0 '/var/lib/asterisk/mohmp3/attente'
[Jun  3 00:06:21] DEBUG[23808]: rtp.c:875 ast_rtcp_read: Got RTCP report
of 176 bytes
[Jun  3 00:06:24] DEBUG[23808]: rtp.c:875 ast_rtcp_read: Got RTCP report
of 176 bytes
[Jun  3 00:06:24] DEBUG[23808]: rtp.c:875 ast_rtcp_read: Got RTCP report
of 44 bytes
[Jun  3 00:06:24] DEBUG[23808]: rtp.c:990 ast_rtcp_read: Unknown RTCP
packet (pt=207) received from 10.100.13.6:1603
[Jun  3 00:06:27] DEBUG[23808]: rtp.c:875 ast_rtcp_read: Got RTCP report
of 176 bytes
<< [ TYPE: Control (4) SUBCLASS: Unknown control '17' (17) ] [Zap/1-1]
    -- Stopped music on hold on SIP/393-08c5fa00


Here is what I think is the related code from chan_zap.c:

                                       case PRI_NOTIFY_REMOTE_HOLD:
                                                f.subclass =
AST_CONTROL_HOLD;
                                               
zap_queue_frame(pri->pvts[chanpos], &f, pri);
                                                break;
                                        case PRI_NOTIFY_REMOTE_RETRIEVAL:
                                                f.subclass =
AST_CONTROL_UNHOLD;
                                               
zap_queue_frame(pri->pvts[chanpos], &f, pri);
                                                break;

(zap_queue_frame in turn calling ast_queue_frame)

I can understand this is a feature of zap channel to conserve bandwidth
over private E1 links but do not see the point over a pstn E1 connection.

Thank you for your tip about a neutral moh class for outgoing calls. That
could minimize the problem until I find a proper solution. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-02-08 17:25  gminet         Note Added: 0087684                          
======================================================================