[Home]

Summary:ASTERISK-11959: Incoming REMOTE_HOLD on Zap is always passed to the bridged channel
Reporter:Gaetan Minet (gminet)Labels:
Date Opened:2008-05-15 11:40:57Date Closed:2011-06-07 14:03:23
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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.


****** ADDITIONAL INFORMATION ******

I played with mohinterpret=passthrough things but it seems to be only usefull on the sending side. On the receiving side, the REMOTE_HOLD is passed as AST_CONTROL_HOLD to the sip channel and I failed to find a way to disable this behaviour.

Tested with 1.4.11 to 1.4.17. I recently compared the sources with 1.4.19 and didn't see any related modification.

I don't know if this is a feature request or a bug, but all of our customers with PRI/PRA have noticed it and chocked on this so I guess this is not an expected behavior, at least through the telco.
Comments:By: Tilghman Lesher (tilghman) 2008-06-02 16:39:22

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?
By: Gaetan Minet (gminet) 2008-06-02 17:25:26

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.
By: Gaetan Minet (gminet) 2008-06-02 17:31:56

Maybe a pri debug is more usefull:


ipbx-transinne*CLI>
< Protocol Discriminator: Q.931 (8)  len=8
< Call Ref: len= 2 (reference 5/0x5) (Terminator)
< Message type: NOTIFY (110)
< [27 01 f9]
< Notification indicator (len= 3): Ext: 1  Remote hold (121)
-- Processing IE 39 (cs0, Notification Indicator)
   -- Started music on hold, class 'default', on SIP/393-b7d57738
ipbx-transinne*CLI>
ipbx-transinne*CLI>
< Protocol Discriminator: Q.931 (8)  len=8
< Call Ref: len= 2 (reference 5/0x5) (Terminator)
< Message type: NOTIFY (110)
< [27 01 fa]
< Notification indicator (len= 3): Ext: 1  Remote retrieval (122)
-- Processing IE 39 (cs0, Notification Indicator)
   -- Stopped music on hold on SIP/393-b7d57738
ipbx-transinne*CLI>
By: Joshua C. Colp (jcolp) 2008-06-03 08:44:53

Corydon76: It is indeed possible using PRI signalling for this to happen.
By: Gaetan Minet (gminet) 2008-06-19 08:00:10

Is this "confirmed" as a bug ?
By: Tilghman Lesher (tilghman) 2008-06-19 08:14:48

I'm not sure it is.  Certainly the receipt of that signal from the PRI is having unintended consequences, but the question is, what should happen when that signal is received?  The intention of the signal for the local end to provide its own MOH, which is exactly what is happening.
By: Gaetan Minet (gminet) 2008-06-19 08:30:13

Indeed over "internal" PRI that's probably the intended behavior.
Maybe a feature request for a configuration option (i.e. the opposite of mohinterpret=passthrough) ? Or some parameter to filter selected signaling frames per span ?
Anyway I just wanted to be sure I didn't miss something obvious before going further.
Thanks.
By: Tilghman Lesher (tilghman) 2008-10-06 14:46:42

At this time, we are not prepared to implement this feature request.  If you would like, you may create a bounty request on the voip-info wiki.  At the point where a candidate patch is available, you may reopen this issue.