Chan.masquerade - Revision history

Monica: /* Example */

2014-02-14T08:26:24Z

‎Example

Monica at 08:23, 14 February 2014

2014-02-14T08:23:23Z

Dana at 16:16, 18 January 2013

2013-01-18T16:16:41Z

Dana: /* Parameters */

2013-01-18T11:13:12Z

‎Parameters

Dana: /* Parameters */

2012-10-08T13:29:42Z

‎Parameters

Dana: /* Parameters */

2012-10-08T13:29:00Z

‎Parameters

Dana: Created page with " '''chan.masquerade''' is used when a module wants to send a message that should appear as sent from another module/channel. This is used typically by RTP to send DTMF message..."

2012-10-08T13:28:22Z

Created page with " '''chan.masquerade''' is used when a module wants to send a message that should appear as sent from another module/channel. This is used typically by RTP to send DTMF message..."

New page

'''chan.masquerade''' is used when a module wants to send a message that should appear as sent from another module/channel. This is used typically by RTP to send DTMF messages apparently from the channel the RTP stream belongs to.

Sender emits the chan.masquerade message which is modified (but not acknowledged) early (at a high priority in the chain) by the object that accepts to let masquerade. The message continues to flow trough the hub until its final destination.

=== Parameters ===

'''message'''
:::Name of the message that will be masqueraded
'''id'''
:::Id of channel that will seem to have sent the message

Since this message masks another one, the other parameters that one needs to add depend of the message type.

For example:

(generated by RTP with owner=sip/123)
RTP: chan.masquerade, userData=NULL
message=chan.dtmf
id=sip/123

(processed at level 10)
SIP: chan.dtmf, userData=this, return FALSE
id=sip/123
peerid=h323/456

(processed at level 100)
H323: chan.dtmf, userData=sip channel, return TRUE
(forwards DTMF)

Let's say you have to call legs connected: A(id=sip/1) and B(id=sip/2).
Call leg A might be a script that does something and then
you wish B to be connected to a C.
So a call from B to C should be made without B noticing this.
So A will send a chan.masquerade with the following params:

message="call.execute";
id="sip/2"; //(notice that it has B's id),
destination="sip/C@ip:port";

In Yate 0.9.x all channel objects derived from Channel implement chan.masquerade by default.

@@ Line 39: / Line 39: @@
       message="call.execute";
       id="sip/2"; //(notice that it has B's id),
-      destination="sip/C@ip:port";
+      callto="sip/C@ip:port";

@@ Line 31: / Line 31: @@
       (forwards DTMF)
-      Let's say you have to call legs connected: A(id=sip/1) and B(id=sip/2).
+      Let's say you have two call legs connected: A(id=sip/1) and B(id=sip/2).
       Call  leg A might be a script that does something and then
       you wish B to be connected to a C.

@@ Line 1: / Line 1: @@
-'''chan.masquerade''' is used when a module wants to send a message that should appear as sent from another module/channel. This is used typically by RTP to send DTMF messages apparently from the channel the RTP stream belongs to.
+'''chan.masquerade''' is used when a module wants to send a message that should appear as sent from another module/channel.<br>
-Sender emits the chan.masquerade message which is modified (but not acknowledged) early (at a high priority in the chain) by the object that accepts to let masquerade. The message continues to flow trough the hub until its final destination.
+Sender emits the chan.masquerade message which is modified (but not acknowledged) early (at a high priority in the chain) by the object that accepts to let masquerade.<br>
 === Parameters ===
@@ Line 38: / Line 40: @@
       id="sip/2"; //(notice that it has B's id),
       destination="sip/C@ip:port";

@@ Line 13: / Line 13: @@
 Since this message masks another one, the other parameters that one needs to add depend of the message type.
-For example:
+===Example===
       (generated by RTP with owner=sip/123)
@@ Line 38: / Line 38: @@
       id="sip/2"; //(notice that it has B's id),
       destination="sip/C@ip:port";

@@ Line 19: / Line 19: @@
       message=chan.dtmf
       id=sip/123
-−
       (processed at level 10)
       SIP: chan.dtmf, userData=this, return FALSE
       id=sip/123
       peerid=h323/456
-−
       (processed at level 100)
       H323: chan.dtmf, userData=sip channel, return TRUE
@@ Line 34: / Line 34: @@
       So a call from B to C should be made without B noticing this.
       So A will send a chan.masquerade with the following params:
-−
       message="call.execute";
       id="sip/2"; //(notice that it has B's id),