Help=> failed to break RTP bridge

Hi, This is the scenario.
Phone 201 call —> Ring…Ring… then Phone 202 answer the call, now, transfer the call to Phone 203. (No Ring…Ring…)
When the phone 202 transfer the call to 203, 201 Just listen a Silent! Any Ring…Ring…
Then the asterisk, display the next error.

[quote]-- Executing [201@minipark:2] Queue(“SIP/201-0000003e”, “lista201,1”) in new stack
– Started music on hold, class ‘default’, on SIP/201-0000003e
== Using SIP RTP CoS mark 5
– Called SIP/201
– SIP/201-0000003f is ringing
– Stopped music on hold on SIP/201-0000003e
– Stopped music on hold on SIP/206-0000003c
[Aug 30 16:35:02] WARNING[18020]: rtp_engine.c:1206 remote_bridge_loop: Channel ‘SIP/201-0000003e’ failed to break RTP bridge
== Spawn extension (ivr, 1, 4) exited non-zero on ‘SIP/201-0000003e’
– Nobody picked up in 1000 ms
– Executing [201@minipark:3] Queue(“SIP/206-0000003c”, “lista201,5”) in new stack
– Started music on hold, class ‘default’, on SIP/206-0000003c
== Using SIP RTP CoS mark 5
– Called SIP/201
– SIP/201-00000040 is ringing
– SIP/201-00000040 answered SIP/206-0000003c
– Stopped music on hold on SIP/206-0000003c
– Remotely bridging SIP/206-0000003c and SIP/201-00000040
== Spawn extension (minipark, 201, 3) exited non-zero on ‘SIP/206-0000003c’
[/quote]

How to Fix that?

The warning is either harmless or represents a coding error. I don’t think you have the technical knowledge to fix it.

You can probably avoid the problem by using directmedia=no, if you have enough CPU power to cope with that.

Ok but… directmedia what exactly do?
Can i have future problems with this calling via SIP trunks??

What makes me think that neither a configuration error nor broken external firmware is the sole problem here is that an event is being reported against a zombie channel that involves the private data structure. In general, zombie channels should have been stripped of their private data structure, and it should have been moved to the target of the masquerade operation, before the zombie channel is both renamed and unlocked.

That suggests to me that there is bug in the locking logic, in an area of code which involves masquerading. I have made quite a few changes to the Asterisk source code and done source level debugging on it, but I still get confused by the masquerade process details.

If you do want to report a bug, you need to set a high level of debugging and run with sip debugging enabled.

Before that, you need to make sure that you are using the most recent version of Asterisk; you didn’t even say which version you were using.

For what directmedia does, see the comments in the MEDIA HANDLING section of sip.conf.sample.

Most service providers don’t support directmedia, so disabling it won’t make a real difference, and may be necessary. A trunk with directmedia is something of a contradiction in terms, as a trunk implies a shared common path, whereas directmedia implies direct, point to point, data flow.

Please note that more people will look at your support questions if you post them in the Asterisk Support forum. This forum is really for philosophical discussion about Asterisk.