[Asterisk-video] H320

Olle E Johansson oej at edvina.net
Fri Jun 9 02:18:58 MST 2006


9 jun 2006 kl. 11.11 skrev Sergio García Murillo:

>
> Olle E Johansson wrote:
>> 9 jun 2006 kl. 10.43 skrev John Martin:
>>
>>> Good point. I was wondering this on the way into work this morning.
>>> I'm not sure how a lump of code that provided H.320 would be able to
>>> be used in both PRI and BRI channels, or if it's an app, func,
>>> channel or res?
>>>
>>> It brings up an interesting point about things like SIP, IAX and
>>> H.323 they all use IP as the transport but have their own channel
>>> drivers rather than a common IP channel driver and an
>>> app/func/res... just an observation. So things that are IP based can
>>> have their own channel drivers but ISDN based things can't :-)
>>
>> Well, I was just a bit curious. It's not obviously a new channel seen
>> with eyes from someone who does not know the details. Is the
>> signalling very much different on an ISDN video call than an audio
>> call?
>>
>> Unfortunately the API for MISDN and ZAP channels are very different.
>>
>> For IAX2, SIP and H.323 the signalling is *very* different. Do
>> remember though that SIP, H.323 and MGCP all share the RTP driver :-)
>>
>
> AFAIK, H324M and H320 just open a b channel of type Unrestricted  
> digital information (instead of the Speech that it's the one that  
> asterisk does), and on top of that channels it starts negotiating  
> the protocol.
> So having the isdn channel abstracted is a good thing as you don't  
> need to handle the all the isdn internalls.
> All we need is an isdn channel that offer a clean digital channel  
> and does the correct q931 negotiation.
Which is done in chan_zap - or?
>
> The idea of the application (for incomming calls for example) I  
> have is one like this:
>
> exten => s,1,Answer
> exten => s,2,H324MTransfer(SIP/blablabla)
Why not use dial?
>
> So you've got an isdn channel in the application with h324m, in  
> which you start the h324m negotiation.
Which may belong in the channel driver...

> You read from the channel pass it to the h324m code and viceversa.  
> Once you have the call stablished, dial the sip peer and start  
> reading the audio and video from the channle and passing it as  
> input to the h324 which will mux it and send it to the isdn part,  
> and continue reading from the isdn channel demuxing it and passing  
> the audio/video to the sip channel.
But we can't establish a call until we know we have something in the  
other end that can accept it.
We might have to send the call to voicemail or forward it somewhere  
else before we answer or simply not answer at all, because
no one is available... We don't want to re-implement app_dial, it's  
already been done once... ;-)
>
> Probably in H320 is a bit more tricky if you are going to do bonding

Sorry for all the propably stupid questions, but it is important that  
we follow the current design
of Asterisk as much as possible. I am very afraid of adding another  
layer on top.

/O


More information about the asterisk-video mailing list