[Asterisk-video] 3G-324M video stack which can work with asterisk
IvánF G
ctz.ivanf.bis at gmail.com
Thu May 14 02:35:05 CDT 2009
Hi all,
I keep facing the problem descripted in my last mail (missing 5º octet in
Bearer Capability when I try to do an outbound call) and I have problems too
with incoming video calls; in this case the *user information layer* looks
to be correctly received but Asterisk goes freeze at h324m_gw_answer... (see
trace below)
Anyone has this scenary working (Asterisk 1.6.X + h324m stack from
sip.fontventa) for incoming/outcoming video calls? Am I trying to get
working anything not supported yet?
< Informational frame:
< SAPI: 00 C/R: 1 EA: 0
< TEI: 000 EA: 1
< N(S): 016 0: 0
< N(R): 013 P: 0
< 46 bytes of data
Handling message for SAPI/TEI=0/0
-- ACKing all packets from 12 to (but not including) 13
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
[Kserverast1*CLI> < Protocol Discriminator: Q.931 (8) len=46
< Call Ref: len= 2 (reference 8704/0x2200) (Originator)
< Message type: SETUP (5)
< [04 03 88 90 a6]
< Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer
capability: Unrestricted digital information (8)
< Ext: 1 Trans mode/rate: 64kbps, circuit-mode
(16)
< User information layer 1: H.223/H.245
Multimedia (38)
< [18 03 a1 83 85]
[Kserverast1*CLI> < Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI
Spare: 0 Preferred Dchan: 0
< ChanSel: As indicated in following octets
< Ext: 1 Coding: 0 Number Specified Channel Type: 3
< Ext: 1 Channel: 5 ]
< [6c 0b 21 83 36 39 35 35 36 33 31 37 36]
< Calling Number (len=13) [ Ext: 0 TON: National Number (2) NPI:
ISDN/Telephony Numbering Plan (E.164/E.163) (1)
< Presentation: Presentation allowed of network
provided number (3) '695563176' ]
< [70 0a a1 39 31 31 35 34 37 31 39 30]
< Called Number (len=12) [ Ext: 1 TON: National Number (2) NPI:
ISDN/Telephony Numbering Plan (E.164/E.163) (1) '911547190' ]
< [a1]
< Sending Complete (len= 1)
< [7c 03 88 90 a6]
< Low-layer Compatability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer
capability: Unrestricted digital information (8)
< Ext: 1 Trans mode/rate: 64kbps, circuit-mode
(16)
< User information layer 1: H.223/H.245
Multimedia (38)
-- Making new call for cr 8704
-- Processing Q.931 Call Setup
-- Processing IE 4 (cs0, Bearer Capability)
-- Processing IE 24 (cs0, Channel Identification)
-- Processing IE 108 (cs0, Calling Party Number)
-- Processing IE 112 (cs0, Called Party Number)
-- Processing IE 161 (cs0, Sending Complete)
-- Processing IE 124 (cs0, Low-layer Compatibility)
receive_low_layer_compatibility
LLC User layer 1: H.223/H.245 Multimedia (38)
q931.c:3751 q931_receive: call 8704 on channel 5 enters state 6 (Call
Present)
Sending Receiver Ready (17)
> [ 02 01 01 22 ]
> Supervisory frame:
> SAPI: 00 C/R: 1 EA: 0
> TEI: 000 EA: 1
[Kserverast1*CLI> > Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
> N(R): 017 P/F: 0
> 0 bytes of data
-- Restarting T203 timer
q931.c:2998 q931_call_proceeding: call 8704 on channel 5 enters state 9
(Incoming Call Proceeding)
> [ 00 01 1a 22 08 02 a2 00 02 18 03 a9 83 85 ]
> Informational frame:
> SAPI: 00 C/R: 0 EA: 0
> TEI: 000 EA: 1
> N(S): 013 0: 0
> N(R): 017 P: 0
> 10 bytes of data
Stopping T_203 timer
Starting T_200 timer
-- Restarting T200 timer
> Protocol Discriminator: Q.931 (8) len=10
[Kserverast1*CLI> > Call Ref: len= 2 (reference 8704/0x2200) (Terminator)
> Message type: CALL PROCEEDING (2)
> [18 03 a9 83 85]
> Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive
Dchan: 0
> ChanSel: As indicated in following octets
> Ext: 1 Coding: 0 Number Specified Channel Type: 3
> Ext: 1 Channel: 5 ]
[Kserverast1*CLI> -- Accepting call from '695563176' to '911547190' on
channel 0/5, span 1
-- Executing [911547190 at entrantes-pra1:1] GotoIf("DAHDI/5-1", "0?voz")
in new stack
-- Executing [911547190 at entrantes-pra1:2] GotoIf("DAHDI/5-1", "0?voz")
in new stack
-- Executing [911547190 at entrantes-pra1:3] h324m_gw("DAHDI/5-1",
"204 at default") in new stack
-- Executing [204 at default:1] h324m_gw_answer("Local/204 at default-0a31;2",
"") in new stack
[Kserverast1*CLI> q931.c:3133 q931_connect: call 8704 on channel 5 enters
state 8 (Connect Request)
> [ 00 01 1c 22 08 02 a2 00 07 18 03 a9 83 85 ]
> Informational frame:
> SAPI: 00 C/R: 0 EA: 0
> TEI: 000 EA: 1
> N(S): 014 0: 0
> N(R): 017 P: 0
> 10 bytes of data
Starting T_200 timer
[Kserverast1*CLI> -- Restarting T200 timer
> Protocol Discriminator: Q.931 (8) len=10
> Call Ref: len= 2 (reference 8704/0x2200) (Terminator)
> Message type: CONNECT (7)
> [18 03 a9 83 85]
> Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive
Dchan: 0
> ChanSel: As indicated in following octets
> Ext: 1 Coding: 0 Number Specified Channel Type: 3
> Ext: 1 Channel: 5 ]
[Kserverast1*CLI>
< [ 02 01 22 1e 08 02 22 00 0f ]
< Informational frame:
< SAPI: 00 C/R: 1 EA: 0
< TEI: 000 EA: 1
< N(S): 017 0: 0
< N(R): 015 P: 0
< 5 bytes of data
Handling message for SAPI/TEI=0/0
-- ACKing all packets from 12 to (but not including) 15
-- ACKing packet 13, new txqueue is 14 (-1 means empty)
[Kserverast1*CLI> -- ACKing packet 14, new txqueue is -1 (-1 means empty)
-- Since there was nothing left, stopping T200 counter
-- Nothing left, starting T203 counter
< Protocol Discriminator: Q.931 (8) len=5
< Call Ref: len= 2 (reference 8704/0x2200) (Originator)
< Message type: CONNECT ACKNOWLEDGE (15)
q931.c:3911 q931_receive: call 8704 on channel 5 enters state 10 (Active)
Sending Receiver Ready (18)
> [ 02 01 01 24 ]
> Supervisory frame:
> SAPI: 00 C/R: 1 EA: 0
> TEI: 000 EA: 1
> Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
> N(R): 018 P/F: 0
> 0 bytes of data
-- Restarting T203 timer
[Kserverast1*CLI>
< [ 02 01 01 1f ]
< Supervisory frame:
< SAPI: 00 C/R: 1 EA: 0
< TEI: 000 EA: 1
< Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
< N(R): 015 P/F: 1
< 0 bytes of data
Handling message for SAPI/TEI=0/0
-- ACKing all packets from 14 to (but not including) 15
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Unsolicited RR with P/F bit, responding
Sending Receiver Ready (18)
[Kserverast1*CLI>
> [ 02 01 01 25 ]
> Supervisory frame:
> SAPI: 00 C/R: 1 EA: 0
> TEI: 000 EA: 1
> Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
> N(R): 018 P/F: 1
> 0 bytes of data
-- Restarting T203 timer
[Kserverast1*CLI>
< [ 02 01 24 1e 08 02 22 00 45 08 02 80 90 ]
< Informational frame:
< SAPI: 00 C/R: 1 EA: 0
< TEI: 000 EA: 1
< N(S): 018 0: 0
< N(R): 015 P: 0
< 9 bytes of data
Handling message for SAPI/TEI=0/0
-- ACKing all packets from 14 to (but not including) 15
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
[Kserverast1*CLI> < Protocol Discriminator: Q.931 (8) len=9
< Call Ref: len= 2 (reference 8704/0x2200) (Originator)
< Message type: DISCONNECT (69)
< [08 02 80 90]
< Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0
Location: User (0)
< Ext: 1 Cause: Normal Clearing (16), class = Normal Event
(1) ]
-- Processing IE 8 (cs0, Cause)
q931.c:4026 q931_receive: call 8704 on channel 5 enters state 12 (Disconnect
Indication)
Sending Receiver Ready (19)
> [ 02 01 01 26 ]
> Supervisory frame:
> SAPI: 00 C/R: 1 EA: 0
> TEI: 000 EA: 1
> Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
> N(R): 019 P/F: 0
> 0 bytes of data
-- Restarting T203 timer
-- Channel 0/5, span 1 got hangup request, cause 16
[Kserverast1*CLI> == Spawn extension (entrantes-pra1, 911547190, 3)
exited non-zero on 'DAHDI/5-1'
[Kserverast1*CLI> NEW_HANGUP DEBUG: Calling q931_hangup, ourstate
Disconnect Indication, peerstate Disconnect Request
== Spawn extension (default, 204, 1) exited non-zero on
'Local/204 at default-0a31;2'
q931.c:3149 q931_release: call 8704 on channel 5 enters state 19 (Release
Request)
> [ 00 01 1e 26 08 02 a2 00 4d 08 02 81 90 ]
> Informational frame:
-- Executing [h at default:1] Hangup("Local/204 at default-0a31;2", "") in new
stack
> SAPI: 00 C/R: 0 EA: 0
> TEI: 000 EA: 1
== Spawn extension (default, h, 1) exited non-zero on
'Local/204 at default-0a31;2'
> N(S): 015 0: 0
> N(R): 019 P: 0
> 9 bytes of data
Stopping T_203 timer
Starting T_200 timer
-- Restarting T200 timer
> Protocol Discriminator: Q.931 (8) len=9
> Call Ref: len= 2 (reference 8704/0x2200) (Terminator)
> Message type: RELEASE (77)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0
Location: Private network serving the local user (1)
> Ext: 1 Cause: Normal Clearing (16), class = Normal Event
(1) ]
-- Hungup 'DAHDI/5-1'
[Kserverast1*CLI>
< [ 02 01 26 20 08 02 22 00 5a ]
< Informational frame:
< SAPI: 00 C/R: 1 EA: 0
< TEI: 000 EA: 1
< N(S): 019 0: 0
< N(R): 016 P: 0
< 5 bytes of data
Handling message for SAPI/TEI=0/0
-- ACKing all packets from 14 to (but not including) 16
-- ACKing packet 15, new txqueue is -1 (-1 means empty)
-- Since there was nothing left, stopping T200 counter
-- Nothing left, starting T203 counter
< Protocol Discriminator: Q.931 (8) len=5
[Kserverast1*CLI> < Call Ref: len= 2 (reference 8704/0x2200) (Originator)
< Message type: RELEASE COMPLETE (90)
q931.c:3966 q931_receive: call 8704 on channel 5 enters state 0 (Null)
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
Sending Receiver Ready (20)
Thank again...
IvanF
2009/5/8 IvánF G <ctz.ivanf.bis at gmail.com>
> Hi all...
>
> I think that I've advanced a little bit with my problem...
>
> Certainly, the libpri-1.4.10 need to be patched for LLC support, but the
> 13055-libpri-1.4.4-llc-transmit-receive-patch-0.1.txt<http://bugs.digium.com/file_download.php?file_id=19452&type=bug>looks to do the job... (the patch is applied perfectly)...
>
> About Asterisk patch for *user information layer 1*, after applied it
> manually (as I explain in the other post) and solved a couple of
> complilation errors, seems to work too... (*CHANNEL(userinformationlayer1)=38")
> *can be defined)
>
> Nevertheless, outbound calls (neither inbound one, in fact...) work. The
> cell phone receives the call but the dialplan doesn't executes anything at
> all. Seems that the *user information layer1* field is not send, as you
> can see here:
>
> Asterisk 1.4 (outbound call OK):
>
> [26G [2 at ive [42G [16Gexit [K originate local/3695563176 extension
> 803499621 at Context
> ServerAst*CLI>
> -- Executing [3695563176 at default:1]
> h324m_call("Local/3695563176 at default-2852,2", "03695563176 at salientes_video")
> in new stack
> -- Executing [03695563176 at salientes_video:1]
> Set("Local/03695563176 at salientes_video-b405,2",
> "CHANNEL(transfercapability)=DIGITAL") in new stack
> -- Executing [03695563176 at salientes_video:2]
> NoOp("Local/03695563176 at salientes_video-b405,2", "transfer=DIGITAL") in
> new stack
> -- Executing [03695563176 at salientes_video:3]
> Set("Local/03695563176 at salientes_video-b405,2",
> "CHANNEL(userinformationlayer1)=38") in new stack
> -- Executing [03695563176 at salientes_video:4]
> NoOp("Local/03695563176 at salientes_video-b405,2", "uil1=38") in new stack
> -- Executing [03695563176 at salientes_video:5]
> Dial("Local/03695563176 at salientes_video-b405,2", "Zap/g3/695563176") in
> new stack
> -- Making new call for cr 32770
> -- digital call, setting user information layer 1 to 38 (0x26)
> -- zap call: h324musellc=0, ast->userinformationlayer1=38
> -- Requested transfer capability: 0x08 - DIGITAL
>
> > [ 00 01 00 00 08 02 00 02 05 04 03 88 90 a6 18 03 a9 83 81 6c 02 00 c3 70
> 0a a1 36 39 35 35 36 33 31 37 36 a1 ]
>
> > Informational frame:
> > SAPI: 00 C/R: 0 EA: 0
> > TEI: 000 EA: 1
> > N(S): 000 0: 0
> > N(R): 000 P: 0
> > 32 bytes of data
> -- Restarting T203 counter
> Stopping T_203 timer
> Starting T_200 timer
> > Protocol Discriminator: Q.931 (8) len=32
> > Call Ref: len= 2 (reference 2/0x2) (Originator)
> > Message type: SETUP (5)
> > [04 03 88 90 a6]
> > Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer
> capability: Unrestricted digital information (8)
> > Ext: 1 Trans mode/rate: 64kbps,
> circuit-mode (16)
> > User information layer 1: H.223/H.245
> Multimedia (38)
> > [18 03 a9 83 81]
> > Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive
> Dchan: 0
> > ChanSel: Reserved
> > Ext: 1 Coding: 0 Number Specified Channel Type:
> 3
> > Ext: 1 Channel: 1 ]
>
> Asterisk 1.6 (outbound call KO):
>
> [Kserverast1*CLI> exit originate local/1695563176 extension 204
> serverast1*CLI> -- Executing [1695563176 at default:1]
> h324m_call("Local/1695563176 at default-1d04;2", "01695563176 at salientes_video")
> in new stack
> [May 8 14:33:55] DEBUG[21714]: app_h324m.c:1137 app_h324m_call: h324m_call
> -- Executing [01695563176 at salientes_video:1]
> Set("Local/01695563176 at salientes_video-3e49;2",
> "CHANNEL(transfercapability)=DIGITAL") in new stack
> -- Executing [01695563176 at salientes_video:2]
> NoOp("Local/01695563176 at salientes_video-3e49;2", "transfer=DIGITAL") in
> new stack
> -- Executing [01695563176 at salientes_video:3]
> Set("Local/01695563176 at salientes_video-3e49;2",
> "CHANNEL(userinformationlayer1)=38") in new stack
> -- Executing [01695563176 at salientes_video:4]
> NoOp("Local/01695563176 at salientes_video-3e49;2", "uil1=38") in new stack
> -- Executing [01695563176 at salientes_video:5]
> Dial("Local/01695563176 at salientes_video-3e49;2", "DAHDI/g1/695563176") in
> new stack
> [May 8 14:33:55] DEBUG[21715]: chan_dahdi.c:6302 dahdi_new: dahdi_new:
> ps.curlaw=DAHDI_LAW_ALAW, setting deflaw to AST_FORMAT_ALAW
> -- Making new call for cr 32773
> -- digital call, setting user information layer 1 to 38 (0x26)
> -- dahdi call: h324musellc=0, ast->userinformationlayer1=38
> -- Requested transfer capability: 0x08 - DIGITAL
>
> > [ 00 01 2a 3e 08 02 00 05 05 04 02 88 90 18 03 a9 83 81 6c 02 00 c3 70 0a
> a1 36 39 35 35 36 33 31 37 36 a1 ]
>
> > Informational frame:
> > SAPI: 00 C/R: 0 EA: 0
> > TEI: 000 EA: 1
> > N(S): 021 0: 0
> > N(R): 031 P: 0
> > 31 bytes of data
> Stopping T_203 timer
> Starting T_200 timer
> -- Restarting T200 timer
> > Protocol Discriminator: Q.931 (8) len=31
> > Call Ref: len= 2 (reference 5/0x5) (Originator)
> > Message type: SETUP (5)
> > [04 02 88 90]
> > Bearer Capability (len= 4) [ Ext: 1 Q.931 Std: 0 Info transfer
> capability: Unrestricted digital information (8)
> > Ext: 1 Trans mode/rate: 64kbps,
> circuit-mode (16)
> > [18 03 a9 83 81]
> > Channel ID (len= 5) [ Ext: 1 IntID: Implicit PRI Spare: 0 Exclusive
> Dchan: 0
> > ChanSel: As indicated in following octets
> > Ext: 1 Coding: 0 Number Specified Channel Type:
> 3
> > Ext: 1 Channel: 1 ]
>
> Any hint or suggestion?
>
> Thanks and nice weekend...
>
>
> 2009/5/7 Dan Julius <dan.julius at gmail.com>
>
> Hi,
>>
>> Don't know about 1.6.x
>>
>> 1.4.24.1 works for me, unfortunately I'm not sure exactly which patches I
>> had to apply.
>> I could look into this if needed.
>>
>> Dan
>>
>>
>> On Thu, May 7, 2009 at 5:43 PM, IvánF G <ctz.ivanf.bis at gmail.com> wrote:
>>
>>> Hi all...
>>>
>>> I've got a few questions related with this threat...
>>>
>>> I've got an asterisk-1.4.21.1 running on a debian machine with digium
>>> hardware and fully operative for outbounds video calls (patched libpri,
>>> patched asterisk, sip.fontventa support for amr, h324m, etc...)
>>>
>>> Now, I'm trying to get a new asterisk instalation on a diferent machine
>>> (debian + Wildcard TE220). I'm using Asterisk 1.6.0.9, libpri-1.4.10,
>>> dahdi-2.1.0.4, etc... and lastest code for the apps and support from
>>> sip.fontventa.
>>>
>>> I can confirm that AMR and MP4 support work perfectly... libh324m and
>>> app_h324m look operative too (after I solved a problem with a segmentation
>>> fault problem related to app_h324m; search for '*asterisk startup
>>> problems with latest app_h324m*')
>>>
>>> The question at this point is the needed patches of libpri and asterisk
>>> for LLC and userinformationlayer support (needed in previous version at
>>> less)... This patches are documented at:
>>>
>>> libpri: http://bugs.digium.com/view.php?id=13055
>>> asterisk: http://bugs.digium.com/view.php?id=10217
>>>
>>> The last libpri patch is for version 1.4.4... I don't know if the
>>> libpri-1.4.10 has this problem solved... Does anybody knows it? (I've
>>> applied the oficial libpri-1.4.10-patch too...)
>>>
>>> About the asterisk link, the last version of the patch is really a mess
>>> an is imposible to apply it with *patch *command (the result is
>>> incoherent...)... I've tried to apply it manually, trying to compare it with
>>> the last version of the 1.4 patch, but the compilation of asterisk crashes
>>> (as I afraid...)
>>>
>>> Does anybody knows if there is a valid patch for the 1.6.X versions of
>>> asterisk? Anybody has it working in this version? If the answer is not...
>>> which is the last asterisk version that can be *officially *patched to
>>> make the outbounds video calls work?
>>>
>>> As usual, thanks in advance and best regards...
>>>
>>> 2009/5/7 3g 2sip <3g2sip at gmail.com>
>>>
>>> Sergio,
>>>> Thanks for your good news. Another question: can we do the video call
>>>> test between two E1/ TE407P end points?
>>>> Best Regards
>>>> Mark
>>>>
>>>> On Thu, May 7, 2009 at 3:49 PM, Sergio Garcia Murillo <
>>>> sergio.garcia at fontventa.com> wrote:
>>>>
>>>>> Hi Mark,
>>>>>
>>>>> Yes it shoudl work with asterisk 16.0.1 and next versions. If you find
>>>>> any problem just let me know.
>>>>>
>>>>> Best regards
>>>>> Sergio
>>>>>
>>>>> 3g 2sip escribió:
>>>>>
>>>>> Hi,Dan,
>>>>> Thanks for your information, go through these information, found some
>>>>> notes: *Note: Currently only Asterisk 1.4 is supported.*
>>>>> Do you know the status of this project, Now we are using Asterisk 1.6,
>>>>> can we use it? thanks.
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>> On Wed, May 6, 2009 at 2:15 PM, Dan Julius <dan.julius at gmail.com>wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> check out http://sip.fontventa.com
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>> On Wed, May 6, 2009 at 6:07 AM, 3g 2sip <3g2sip at gmail.com> wrote:
>>>>>>
>>>>>>> Hello,everyone,
>>>>>>> Does here has some source code and docs for 3G-324M video stack? or
>>>>>>> any information related it, thanks.
>>>>>>> Regards
>>>>>>> Mark
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>>>>
>>>>>>> asterisk-video mailing list
>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>>>
>>>>>> asterisk-video mailing list
>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>>
>>>>> asterisk-video mailing list
>>>>> To UNSUBSCRIBE or update options visit:
>>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>>
>>>>> asterisk-video mailing list
>>>>> To UNSUBSCRIBE or update options visit:
>>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>
>>>> asterisk-video mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>>
>>>
>>>
>>> _______________________________________________
>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>
>>> asterisk-video mailing list
>>> To UNSUBSCRIBE or update options visit:
>>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>>
>>
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-video mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-video/attachments/20090514/747fa1cc/attachment-0001.htm
More information about the asterisk-video
mailing list