[asterisk-dev] pseudo channel

[john at spectross.com]

Hi Russell,

Thanks for the reply.
__________        ____________         _________
|                   |       |                        |       | 
|
|        A        |       |           B           |       |       C        |
|  (Phy. Ch.) |       |     (Phy. Ch.)   |        | (Phy. Ch.) |
|_________ |       |____________|       |_________|
          |                    |                  |                    |
    SUB_R         SUB_R     SUB_CW     SUB_R
          |                    |                  |                    |
    ___|___        ___|___      ___|____      ___|___
   |            |       |            |      |              |     | 
|
   | AC-R |---> | AC-R |      |AC-CW |<--|  AC-R |
   |______|       |______|      |_______|     |______|

The blocks named A, B & C are used to represent physical channels. The
blocks below represent
ast_channels (AC) corresponding to SUB_REAL (R) & SUB_CALLWAIT (CW)
sub-channels.

Could you please help me understand how could we generate a ring back tone
for 'C' by using an 'ioctl'
over the 'pseudo file decriptor' corresponding to 'SUB_CALLWAIT' of 'B'.

Well it could be possible after bridging but this case is pre-bridge i.e.
during ast_call (zt_call).

I also tried commenting this piece of code but saw no difference in the
behaviour of call-wait (i.e. RBT was always present).

After further investigation it seems that app_dial is the one responsible
for RBT generation to caller in all cases.

Plz. clarify.

Kindly also throw some light over reception of events over pseudo
file-descriptors corresponding to sub-channels.

Regds.
John

----- Original Message ----- 
From: <john at spectross.com>
To: "Russell Bryant" <russell at digium.com>; "Asterisk Developers Mailing 
List" <asterisk-dev at lists.digium.com>
Sent: Wednesday, March 18, 2009 9:36 PM
Subject: Re: [asterisk-dev] pseudo channel


> Hi Russell,
>
> Thanks for the reply.
> __________                 ________________                     __________
> |                    |                |                                | | 
> |
> |        A         |                |              B                | | 
> C         |
> |  (Phy. Ch.)  |                |        (Phy. Ch.)         | |  (Phy. 
> Ch.)  |
> |__________|                |________________| |__________|
>          |                               |                        | |
>  SUB_REAL          SUB_REAL   SUB_CALLWAIT         SUB_REAL
>          |                               |                        | |
>     ___|___                  ___|___            ___|___ ___|___
>     |            |                 |            |           | | 
> |            |
>     |AC-R  |-------- -> |AC-R  |           |AC-CW |<-----------| AC-R  |
>     |______|  app_dial  |______|           |_______|   app_dial   |______|
>
> The blocks named A, B & C are used to represent physical channels. The 
> blocks below represent
> ast_channels (AC) corresponding to SUB_REAL (R) & SUB_CALLWAIT (CW) 
> sub-channels.
>
> Could you please help me understand how could we generate a ring back tone 
> for 'C' by using an 'ioctl'
> over the 'pseudo file decriptor' corresponding to 'SUB_CALLWAIT' of 'B'.
>
> Well it could be possible after bridging but this case is pre-bridge i.e. 
> during ast_call (zt_call).
>
> I also tried commenting this piece of code but saw no difference in the 
> behaviour of call-wait (i.e. RBT was always present).
>
> After further investigation it seems that app_dial is the one responsible 
> for RBT generation to caller in all cases.
>
> Plz. clarify.
>
> Kindly also throw some light over reception of events over pseudo 
> file-descriptors corresponding to sub-channels.
>
> Regds.
> John
>
> ----- Original Message ----- 
> From: "Russell Bryant" <russell at digium.com>
> To: <john at spectross.com>; "Asterisk Developers Mailing List" 
> <asterisk-dev at lists.digium.com>
> Sent: Tuesday, March 17, 2009 10:21 PM
> Subject: Re: [asterisk-dev] pseudo channel
>
>
>> john at spectross.com wrote:
>>> /* Make ring-back */
>>> if (tone_zone_play_tone(p->subs[SUB_CALLWAIT].zfd, ZT_TONE_RINGTONE))
>>>  ast_log(LOG_WARNING, "Unable to generate call-wait ring-back on channel 
>>> %s\n", ast->name);
>>
>> If you read my previous reply, this piece of code will start to make 
>> sense.
>>
>> In this case, we're dealing with call waiting.  That means that there is 
>> an Asterisk channel already up and connected to SUB_REAL, which is the 
>> DAHDI channel associated with the physical interface.  Now, we have 
>> another call coming in destined for this interface.  We're going to go 
>> ahead and set up this call with a psuedo channel.  The piece of code you 
>> refer to tells DAHDI to send ring back to the caller.  Meanwhile, the 
>> DAHDI channel associated with the physical interface is hearing a call 
>> waiting beep.
>>
>> If this still isn't clear, I can try to draw up some ASCII art that 
>> demonstrates the audio flow here ...
>>
>> -- 
>> Russell Bryant
>> Digium, Inc. | Senior Software Engineer, Open Source Team Lead
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> Check us out at: www.digium.com & www.asterisk.org
>