Occasionally no MOH on sip phones

Hello everyone,

Today I want to share with you an issue I have using MOH on sip phones.
Happen sometimes, to place on hold a phone and this operation results with no audio heard on the other side.
It is not systematical, I mean it is not happening all the times, instead it happens on basis of something I’ve not yet identified.
When it happens however you may read on cli something like:
– Started music on hold, class ‘default’, on SIP/nsip-208-00000001
– Locally bridging SIP/nsip-200-00000000 and SIP/nsip-208-00000001
– Stopped music on hold on SIP/nsip-208-00000001
Which is not a normal behaviour, it seems like if after placing on hold the call, the two rtp streams also have bridged eachother.
Occasionally, you may hear less than a second of music, and then silence.
In this weird status, both phones are silent.

The same situation, but saw from a cli with debug shows:
– Started music on hold, class ‘default’, on SIP/nsip-205-00000005
channel.c:3556 ast_settimeout: Scheduling timer at (50 requested / 50 actual) timer ticks per second
rtp_engine.c:1082 local_bridge_loop: rtp-engine-local-bridge: Got a FRAME_CONTROL (26) frame on channel SIP/nsip-205-00000005
channel.c:7917 ast_channel_bridge: Returning from native bridge, channels: SIP/nsip-200-00000004, SIP/nsip-205-00000005
manager.c:4699 match_filter: Examining event:
Event: MusicOnHold
Privilege: call,all
State: Start
Channel: SIP/nsip-205-00000005
UniqueID: 1386773843.5
Class: default

manager.c:4699 match_filter: Examining event:
Event: Bridge
Privilege: call,all
Bridgestate: Unlink
Bridgetype: core
Channel1: SIP/nsip-200-00000004
Channel2: SIP/nsip-205-00000005
Uniqueid1: 1386773843.4
Uniqueid2: 1386773843.5
CallerID1: 200
CallerID2: 205

manager.c:4699 match_filter: Examining event:
Event: Bridge
Privilege: call,all
Bridgestate: Link
Bridgetype: core
Channel1: SIP/nsip-200-00000004
Channel2: SIP/nsip-205-00000005
Uniqueid1: 1386773843.4
Uniqueid2: 1386773843.5
CallerID1: 200
CallerID2: 205

res_rtp_asterisk.c:2085 ast_rtp_update_source: Setting the marker bit due to a source update
res_rtp_asterisk.c:2085 ast_rtp_update_source: Setting the marker bit due to a source update
– Locally bridging SIP/nsip-200-00000004 and SIP/nsip-205-00000005
Somehow this confirms that hold has been interrupted and that asterisk is bridging something.
I guess that “Got a FRAME_CONTROL (26) frame on channel” may have something with this weird behaviour, but I’ve not found any document in regard.
I made asterisk version is 11.2-cert2 just to be sure it’s not any weird bug, but issue remains.
Does someone ever seen this kind of behaviour?

Thanks to everyone wants to share with me any information about that.
Regards
Alessandro

I think the local bridging reference refers to the re-invite to put the media path back through Asterisk. If it doesn’t do this, there could be conflicting media sources.

Actually, if I remember correctly, music on hold doesn’t break a local bridge. The request is bridged and then acted upon by the outgoing channel driver. (Just checked the 1.8 code and it does not set bridge_exit, but simply ast_indicates it downstream and continues the bridge loop. The channel should be in a local bridge during a hold.

Maybe what you are seeing is problems in undoing external bridges.

david55, Thank you for your explaination.
I’m not sure to fully understand it, maybe because I’m not sure on what actually a local bridge is.
But it seems me to read in your answer something like, “you’re pointing to a normal behaviour, that’s not the cause of your troubles”.
If it’s so, I’d like you to see the following extract from cli output; there are several attempts to put the same call on hold.

-- Started music on hold, class 'default', on SIP/nsip-208-00000001
-- Stopped music on hold on SIP/nsip-208-00000001

This one I heard the music as it is supposed to be.
– Started music on hold, class ‘default’, on SIP/nsip-208-00000001
– Stopped music on hold on SIP/nsip-208-00000001
This one I heard the music as it is supposed to be.
– Started music on hold, class ‘default’, on SIP/nsip-200-00000000
– Locally bridging SIP/nsip-200-00000000 and SIP/nsip-208-00000001
– Stopped music on hold on SIP/nsip-200-00000000
On this one I heard for less than a second the MOH and after silence.
– Started music on hold, class ‘default’, on SIP/nsip-200-00000000
– Locally bridging SIP/nsip-200-00000000 and SIP/nsip-208-00000001
– Stopped music on hold on SIP/nsip-200-00000000
On this one I heard for less than a second the MOH and after silence.
– Started music on hold, class ‘default’, on SIP/nsip-200-00000000
– Locally bridging SIP/nsip-200-00000000 and SIP/nsip-208-00000001
– Stopped music on hold on SIP/nsip-200-00000000
On this one I heard for less than a second the MOH and after silence.
– Started music on hold, class ‘default’, on SIP/nsip-208-00000001
– Locally bridging SIP/nsip-200-00000000 and SIP/nsip-208-00000001
This one I heard the music as it is supposed to be.
– Stopped music on hold on SIP/nsip-208-00000001
– Started music on hold, class ‘default’, on SIP/nsip-208-00000001
This one I heard the music as it is supposed to be.
– Started music on hold, class ‘default’, on SIP/nsip-200-00000000
– Locally bridging SIP/nsip-200-00000000 and SIP/nsip-208-00000001
– Stopped music on hold on SIP/nsip-200-00000000
On this one I heard for less than a second the MOH and after silence.
– Started music on hold, class ‘default’, on SIP/nsip-200-00000000
– Locally bridging SIP/nsip-200-00000000 and SIP/nsip-208-00000001
– Stopped music on hold on SIP/nsip-208-00000001
On this one I heard for less than a second the MOH and after silence.

On the same call just pushing the hold button.
I noticed this issue is more frequent if you put on hold by one side, and after unhold, you put on the other side; but I don’t know if it somehow related.
By the way do anyone know what that “Got a FRAME_CONTROL (26) frame on channel SIP/…” actually means?

Thank you for your help
Regards
Alessandro

Local bridge is where Asterisk relays the media stream through its core. Remote bridge is where Asterisk tells the two parties each other’s media address and lets them send media directly between themselves. There is a third possibility which is packet to packet bridging, where the SIP channel driver relays media without passing it through the Asterisk core.

You probably need to do a full packet capture and analyze it with wireshark before you can work out if the MoH media is actually not being sent, and whether the re-invite back to a local bridge is working properly.