Sponsor: VoiceMeUp - Corporate & Wholesale VoIP Services

VoIP Mailing List Archives
Mailing list archives for the VoIP community
 SearchSearch 

[asterisk-users] Parking in Asterisk 12.0.0


 
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> Asterisk Users
View previous topic :: View next topic  
Author Message
asterisk at adev.se
Guest





PostPosted: Thu Jan 30, 2014 3:27 pm    Post subject: [asterisk-users] Parking in Asterisk 12.0.0 Reply with quote

Hi

I'm trying to get the rebuilt parking functionality to work in Asterisk 12.0.0.

In Asterisk 11.6.0 I managed to get a call to get parked by adding a dynamic feature in features.conf for the DMTF sequence *# which called a macro in extensions.conf, which then runned the ParkAndAnnounce application, and the call got parked.

The syntax for ParkAndAnnounce I used was this (I don't want any announcement to be played):

exten => s,n,ParkAndAnnounce(,3600,SIP/100)


In the new Asterisk-version, the ParkAndAnnounce application gets called, but the call isn't parked.

The only error I can see in the messages file is a DEBUG entry saying that the channel "failed to join Bridge", like this:

[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge_channel.c:1994 bridge_channel_internal_join: Bridge 9f437397-4864-4351-bf29-b37e6ccacf12: 0x16e3768(SIP/vpn-sbc-00000001) failed to join Bridge


Anyone else that has tried to convert old parking functionality into Asterisk 12.0.0 ?



features.conf:

parkswitch => *#,callee/caller,Macro(parkswitch)


extensions.conf:

[default]
....

include => parkedcalls

[macro-parkswitch]
exten => s,1,ParkAndAnnounce(,,PARKED,SIP/100)


messages:

[Jan 30 21:00:00] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2847 create_dtmf_frame: Creating BEGIN DTMF Frame: 42 (*), at x.x.x.x:9530
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4050 __ast_read: DTMF begin '*' received on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4061 __ast_read: DTMF begin passthrough '*' on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:00] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2165 ast_rtp_update_source: Setting the marker bit due to a source update
[Jan 30 21:00:00] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2847 create_dtmf_frame: Creating END DTMF Frame: 42 (*), at x.x.x.x:9530
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:3964 __ast_read: DTMF end '*' received on SIP/at-tcty-ssw-00000000, duration 240 ms
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4005 __ast_read: DTMF end accepted with begin '*' on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4034 __ast_read: DTMF end passthrough '*' on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:00] DEBUG[7114][C-00000000]: bridge_channel.c:1174 bridge_channel_feature: DTMF feature string on 0x7f6b8c10f998(SIP/at-tcty-ssw-00000000) is now '*'
[Jan 30 21:00:00] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2847 create_dtmf_frame: Creating BEGIN DTMF Frame: 35 (#), at x.x.x.x:9530
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4050 __ast_read: DTMF begin '#' received on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4054 __ast_read: DTMF begin ignored '#' on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:01] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2847 create_dtmf_frame: Creating END DTMF Frame: 35 (#), at x.x.x.x:9530
[Jan 30 21:00:01] DTMF[7114][C-00000000]: channel.c:3964 __ast_read: DTMF end '#' received on SIP/at-tcty-ssw-00000000, duration 230 ms
[Jan 30 21:00:01] DTMF[7114][C-00000000]: channel.c:4034 __ast_read: DTMF end passthrough '#' on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:01] DEBUG[7114][C-00000000]: bridge_channel.c:1174 bridge_channel_feature: DTMF feature string on 0x7f6b8c10f998(SIP/at-tcty-ssw-00000000) is now '*#'
[Jan 30 21:00:01] DEBUG[7114][C-00000000]: bridge_channel.c:1185 bridge_channel_feature: DTMF feature hook 0x7f6b8c1d9480 matched DTMF string '*#' on 0x7f6b8c10f998(SIP/ssw-00000000)
[Jan 30 21:00:01] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2165 ast_rtp_update_source: Setting the marker bit due to a source update
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: res_rtp_asterisk.c:2165 ast_rtp_update_source: Setting the marker bit due to a source update
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: app.c:305 ast_app_exec_macro: SIP/vpn-sbc-00000001 Original location: default,,1
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: pbx.c:4875 pbx_extension_helper: Launching 'ParkAndAnnounce'
-- Executing [s@macro-parkswitch:1] ParkAndAnnounce("SIP/vpn-sbc-00000001", ",,PARKED,SIP/100") in new stack
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:486 find_best_technology: Bridge technology softmix does not have any capabilities we want.
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:486 find_best_technology: Bridge technology simple_bridge does not have any capabilities we want.
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:486 find_best_technology: Bridge technology native_rtp does not have any capabilities we want.
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:505 find_best_technology: Chose bridge technology holding_bridge
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:771 bridge_base_init: Bridge 9f437397-4864-4351-bf29-b37e6ccacf12: calling holding_bridge technology constructor
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:779 bridge_base_init: Bridge 9f437397-4864-4351-bf29-b37e6ccacf12: calling holding_bridge technology start
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge_roles.c:272 setup_bridge_role: Set role 'holding_participant'
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge_channel.c:1977 bridge_channel_internal_join: Bridge 9f437397-4864-4351-bf29-b37e6ccacf12: 0x16e3768(SIP/vpn-sbc-00000001) is joining
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge_channel.c:1994 bridge_channel_internal_join: Bridge 9f437397-4864-4351-bf29-b37e6ccacf12: 0x16e3768(SIP/vpn-sbc-00000001) failed to join Bridge
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: app_macro.c:428 _macro_exec: Spawn extension (macro-parkswitch,s,1) exited non-zero on 'SIP/vpn-sbc-00000001' in macro 'parkswitch'
== Spawn extension (macro-parkswitch, s, 1) exited non-zero on 'SIP/vpn-sbc-00000001' in macro 'parkswitch'
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: app.c:308 ast_app_exec_macro: Macro exited with status -1
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: app.c:322 ast_app_exec_macro: SIP/vpn-sbc-00000001 Ending location: default,,1
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: res_rtp_asterisk.c:2165 ast_rtp_update_source: Setting the marker bit due to a source update
[Jan 30 21:00:01] DEBUG[7119]: taskprocessor.c:484 tps_taskprocessor_destroy: destroying taskprocessor '423a711c-02c7-4b54-ab39-33e6c64e32c3'
[Jan 30 21:00:01] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:3284 ast_rtcp_read: Got RTCP report of 76 bytes
[Jan 30 21:00:02] DEBUG[7118][C-00000000]: res_rtp_asterisk.c:3284 ast_rtcp_read: Got RTCP report of 76 bytes
[Jan 30 21:00:05] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:3284 ast_rtcp_read: Got RTCP report of 76 bytes
[Jan 30 21:00:07] DEBUG[7118][C-00000000]: res_rtp_asterisk.c:3284 ast_rtcp_read: Got RTCP report of 76 bytes
[Jan 30 21:00:10] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:3284 ast_rtcp_read: Got RTCP report of 76 bytes

-- Anders
Back to top
ldardini at gmail.com
Guest





PostPosted: Thu Jan 30, 2014 3:57 pm    Post subject: [asterisk-users] Parking in Asterisk 12.0.0 Reply with quote

I have converted the normal Park application and I can only alert you about the syntax change. I suspect also in the ParkAndAnnounce command, the parameters are ordered completely different.

Leandro



2014-01-30 Anders Larsson <asterisk@adev.se (asterisk@adev.se)>:
Quote:
Hi

I'm trying to get the rebuilt parking functionality to work in Asterisk 12.0.0.

In Asterisk 11.6.0 I managed to get a call to get parked by adding a dynamic feature in features.conf for the DMTF sequence *# which called a macro in extensions.conf, which then runned the ParkAndAnnounce application, and the call got parked.

The syntax for ParkAndAnnounce I used was this (I don't want any announcement to be played):

exten => s,n,ParkAndAnnounce(,3600,SIP/100)


In the new Asterisk-version, the ParkAndAnnounce application gets called, but the call isn't parked.

The only error I can see in the messages file is a DEBUG entry saying that the channel "failed to join Bridge", like this:

[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge_channel.c:1994 bridge_channel_internal_join: Bridge 9f437397-4864-4351-bf29-b37e6ccacf12: 0x16e3768(SIP/vpn-sbc-00000001) failed to join Bridge


Anyone else that has tried to convert old parking functionality into Asterisk 12.0.0 ?

 

features.conf:

parkswitch => *#,callee/caller,Macro(parkswitch)


extensions.conf:

[default]
....

include => parkedcalls

[macro-parkswitch]
exten => s,1,ParkAndAnnounce(,,PARKED,SIP/100)
 

messages:

[Jan 30 21:00:00] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2847 create_dtmf_frame: Creating BEGIN DTMF Frame: 42 (*), at x.x.x.x:9530
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4050 __ast_read: DTMF begin '*' received on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4061 __ast_read: DTMF begin passthrough '*' on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:00] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2165 ast_rtp_update_source: Setting the marker bit due to a source update
[Jan 30 21:00:00] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2847 create_dtmf_frame: Creating END DTMF Frame: 42 (*), at x.x.x.x:9530
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:3964 __ast_read: DTMF end '*' received on SIP/at-tcty-ssw-00000000, duration 240 ms
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4005 __ast_read: DTMF end accepted with begin '*' on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4034 __ast_read: DTMF end passthrough '*' on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:00] DEBUG[7114][C-00000000]: bridge_channel.c:1174 bridge_channel_feature: DTMF feature string on 0x7f6b8c10f998(SIP/at-tcty-ssw-00000000) is now '*'
[Jan 30 21:00:00] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2847 create_dtmf_frame: Creating BEGIN DTMF Frame: 35 (#), at x.x.x.x:9530
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4050 __ast_read: DTMF begin '#' received on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4054 __ast_read: DTMF begin ignored '#' on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:01] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2847 create_dtmf_frame: Creating END DTMF Frame: 35 (#), at x.x.x.x:9530
[Jan 30 21:00:01] DTMF[7114][C-00000000]: channel.c:3964 __ast_read: DTMF end '#' received on SIP/at-tcty-ssw-00000000, duration 230 ms
[Jan 30 21:00:01] DTMF[7114][C-00000000]: channel.c:4034 __ast_read: DTMF end passthrough '#' on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:01] DEBUG[7114][C-00000000]: bridge_channel.c:1174 bridge_channel_feature: DTMF feature string on 0x7f6b8c10f998(SIP/at-tcty-ssw-00000000) is now '*#'
[Jan 30 21:00:01] DEBUG[7114][C-00000000]: bridge_channel.c:1185 bridge_channel_feature: DTMF feature hook 0x7f6b8c1d9480 matched DTMF string '*#' on 0x7f6b8c10f998(SIP/ssw-00000000)
[Jan 30 21:00:01] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2165 ast_rtp_update_source: Setting the marker bit due to a source update
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: res_rtp_asterisk.c:2165 ast_rtp_update_source: Setting the marker bit due to a source update
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: app.c:305 ast_app_exec_macro: SIP/vpn-sbc-00000001 Original location: default,,1
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: pbx.c:4875 pbx_extension_helper: Launching 'ParkAndAnnounce'
    -- Executing [s@macro-parkswitch:1] ParkAndAnnounce("SIP/vpn-sbc-00000001", ",,PARKED,SIP/100") in new stack
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:486 find_best_technology: Bridge technology softmix does not have any capabilities we want.
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:486 find_best_technology: Bridge technology simple_bridge does not have any capabilities we want.
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:486 find_best_technology: Bridge technology native_rtp does not have any capabilities we want.
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:505 find_best_technology: Chose bridge technology holding_bridge
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:771 bridge_base_init: Bridge 9f437397-4864-4351-bf29-b37e6ccacf12: calling holding_bridge technology constructor
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:779 bridge_base_init: Bridge 9f437397-4864-4351-bf29-b37e6ccacf12: calling holding_bridge technology start
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge_roles.c:272 setup_bridge_role: Set role 'holding_participant'
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge_channel.c:1977 bridge_channel_internal_join: Bridge 9f437397-4864-4351-bf29-b37e6ccacf12: 0x16e3768(SIP/vpn-sbc-00000001) is joining
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge_channel.c:1994 bridge_channel_internal_join: Bridge 9f437397-4864-4351-bf29-b37e6ccacf12: 0x16e3768(SIP/vpn-sbc-00000001) failed to join Bridge
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: app_macro.c:428 _macro_exec: Spawn extension (macro-parkswitch,s,1) exited non-zero on 'SIP/vpn-sbc-00000001' in macro 'parkswitch'
  == Spawn extension (macro-parkswitch, s, 1) exited non-zero on 'SIP/vpn-sbc-00000001' in macro 'parkswitch'
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: app.c:308 ast_app_exec_macro: Macro exited with status -1
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: app.c:322 ast_app_exec_macro: SIP/vpn-sbc-00000001 Ending location: default,,1
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: res_rtp_asterisk.c:2165 ast_rtp_update_source: Setting the marker bit due to a source update
[Jan 30 21:00:01] DEBUG[7119]: taskprocessor.c:484 tps_taskprocessor_destroy: destroying taskprocessor '423a711c-02c7-4b54-ab39-33e6c64e32c3'
[Jan 30 21:00:01] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:3284 ast_rtcp_read: Got RTCP report of 76 bytes
[Jan 30 21:00:02] DEBUG[7118][C-00000000]: res_rtp_asterisk.c:3284 ast_rtcp_read: Got RTCP report of 76 bytes
[Jan 30 21:00:05] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:3284 ast_rtcp_read: Got RTCP report of 76 bytes
[Jan 30 21:00:07] DEBUG[7118][C-00000000]: res_rtp_asterisk.c:3284 ast_rtcp_read: Got RTCP report of 76 bytes
[Jan 30 21:00:10] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:3284 ast_rtcp_read: Got RTCP report of 76 bytes

-- Anders


--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
               http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users
Back to top
mjordan at digium.com
Guest





PostPosted: Thu Jan 30, 2014 4:05 pm    Post subject: [asterisk-users] Parking in Asterisk 12.0.0 Reply with quote

On Thu, Jan 30, 2014 at 2:58 PM, Leandro Dardini <ldardini@gmail.com> wrote:
Quote:
I have converted the normal Park application and I can only alert you about
the syntax change. I suspect also in the ParkAndAnnounce command, the
parameters are ordered completely different.

Leandro



Please go ahead an open an issue for this - issues.asterisk.org.

The problem here is that you are attempting to enter into a Parking
bridge while you are still technically in a bridge. The DTMF features
that account for the 'normal' mechanism of doing this - the one touch
parking feature - recognize that you are in a bridge and do a safe
transfer from the existing bridge to the parking bridge. By jumping
out to a macro/gosub and directly going in through the ParkAndAnnounce
application, you are bypassing that logic. The code in
bridge_channel_internal_join is preventing you from going into the
parking bridge as it knows that you have not yet safely left the
bridge you are in.

We'll take a look and see if there's a way to allow this to happen
again. For now, you should use the one touch parking feature.

Matt

--
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Back to top
asterisk at adev.se
Guest





PostPosted: Fri Jan 31, 2014 11:09 am    Post subject: [asterisk-users] Parking in Asterisk 12.0.0 Reply with quote

Thank you for reply, Matt and Leandro!

The reasons I'm not using "one step parking" is that it will "speak" which parking extension it has parked the call on and I also want a channel variable to be set about the parked call, which I need in the agi-script (ParkAndAnnounce with a not valid dial string and setting a MASTER_CHANNEL() variable in the Macro solves these issues for me).

Maybe I could do a hack in the Asterisk source to achive this if there is no other solution.

The reason I tried to upgrade from 11.6 to 12.0 was that I experienced problems with lost (ignored) DTMF events after Asterisk has released the DTMF events for what it think can be a potential dynamic feature. This problem seems to be gone in Asterisk 12.0...

[Jan 30 11:13:48] DEBUG[29442][C-00000000]: features.c:3740 feature_interpret: Feature interpret: chan=SIP/at-tcty-ssw-00000000, peer=SIP/vpn-sbc-00000001, code=*8, sense=1, features=0, dynamic=parkswitch#parkswitch
[Jan 30 11:13:49] DEBUG[29445][C-00000000]: res_rtp_asterisk.c:2833 create_dtmf_frame: Creating BEGIN DTMF Frame: 50 (2), at 85.30.63.134:15870
[Jan 30 11:13:49] DTMF[29445][C-00000000]: channel.c:4171 __ast_read: DTMF begin '2' received on SIP/at-tcty-ssw-00000000
[Jan 30 11:13:49] DTMF[29445][C-00000000]: channel.c:4185 __ast_read: DTMF begin ignored '2' on SIP/at-tcty-ssw-00000000
[Jan 30 11:13:49] DEBUG[29445][C-00000000]: res_rtp_asterisk.c:3165 ast_rtcp_read: Got RTCP report of 80 bytes
[Jan 30 11:13:49] DEBUG[29445][C-00000000]: res_rtp_asterisk.c:2833 create_dtmf_frame: Creating END DTMF Frame: 50 (2), at 85.30.63.134:15870

I spoke to Olle E Johansson about this issue today and he pointed me to a SVN branch he has made for Asterisk 1.8 which should solve the ignored DTMF events (http://svnview.digium.com/svn/asterisk/team/oej/rana-dtmf-duration-1.8/)

I have now quickly tested his code and it seems to work, so I will propably go with Asterisk 1.8.

Thanks again.

-- Anders


Quote:
Quote:
On Thu, Jan 30, 2014 at 2:58 PM, Leandro Dardini <ldardini@gmail.com> (ldardini@gmail.com) wrote:
Quote:
I have converted the normal Park application and I can only alert you about
the syntax change. I suspect also in the ParkAndAnnounce command, the
parameters are ordered completely different.

Leandro



Please go ahead an open an issue for this - issues.asterisk.org.

The problem here is that you are attempting to enter into a Parking
bridge while you are still technically in a bridge. The DTMF features
that account for the 'normal' mechanism of doing this - the one touch
parking feature - recognize that you are in a bridge and do a safe
transfer from the existing bridge to the parking bridge. By jumping
out to a macro/gosub and directly going in through the ParkAndAnnounce
application, you are bypassing that logic. The code in
bridge_channel_internal_join is preventing you from going into the
parking bridge as it knows that you have not yet safely left the
bridge you are in.

We'll take a look and see if there's a way to allow this to happen
again. For now, you should use the one touch parking feature.

Matt

Back to top
Display posts from previous:   
Post new topic   Reply to topic    VoIP Mailing List Archives Forum Index -> Asterisk Users All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group

VoiceMeUp - Corporate & Wholesale VoIP Services