Re: [asterisk-users] Two calls from same server to end device

2022-12-07 Thread Jerry Geis 
On Wed, Dec 7, 2022 at 2:14 PM Jerry Geis  wrote:

> Hi All,
>
> I have a physical SIP gateway device. It has 5 SIP extensions connected to
> Asterisk 10001-10005.
> These are all registered - will call this unit the  SIPGW.
>
> If I use Two different phones one to call 10001 and keep the line open -
> then call 10002 this works. both calls are answered and speaking.
>
> So if I make a call from my asterisk server with "call files" one to the
> 10001 it answers - and one to the 10002 - at different times - BOTH work.
>
> However if I make the 10001 call - and while its still speaking I call the
> 10002 - the second call gets unanswered till the first call is completed.
>  I'm guessing that is a function of the SIPGW - good or bad
>
> Take that a step further - if I use the call file to call 10001 - it
> answers - from the polycom I call 10002 - this works also - two
> different sources I presume
>
> My question is can "in a call file" somehow - say I am a different source
> or something ?
> just like the two polycom phones that work - two different source
> addresses or something.
>
> Anyone ran into this - or thoughts on something I might try to say the
> calls are different sources ?
>
> Thank you.
>
> Jerry
>

Turns out simple setting the CALLERID to different values does the trick.
Awesome!

jerry
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] Two calls from same server to end device

2022-12-07 Thread Jerry Geis 
Hi All,

I have a physical SIP gateway device. It has 5 SIP extensions connected to
Asterisk 10001-10005.
These are all registered - will call this unit the  SIPGW.

If I use Two different phones one to call 10001 and keep the line open -
then call 10002 this works. both calls are answered and speaking.

So if I make a call from my asterisk server with "call files" one to the
10001 it answers - and one to the 10002 - at different times - BOTH work.

However if I make the 10001 call - and while its still speaking I call the
10002 - the second call gets unanswered till the first call is completed.
 I'm guessing that is a function of the SIPGW - good or bad

Take that a step further - if I use the call file to call 10001 - it
answers - from the polycom I call 10002 - this works also - two
different sources I presume

My question is can "in a call file" somehow - say I am a different source
or something ?
just like the two polycom phones that work - two different source addresses
or something.

Anyone ran into this - or thoughts on something I might try to say the
calls are different sources ?

Thank you.

Jerry
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] [External] Asterisk 18.12.1 to 18.15.0 upgrade seems to have introduced a behavior where PJSIP is unable to send a response to OPTIONS (seems to resolve after anywhere a period of

2022-12-07 Thread Dan Cropp 
Thank you Joshua.

I am going to dig some more. I can’t see anything in the logs to indicate any 
reason for why it’s suddenly able to send the OPTIONS response.  There are zero 
SIP packets from Kamailio between the one that fails to send and the one that 
succeeds.  Very strange.

If I can’t get it working, I will create an issue report.

Dan

From: asterisk-users  On Behalf Of 
Joshua C. Colp
Sent: Wednesday, December 7, 2022 9:38 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion 

Subject: Re: [External] [asterisk-users] Asterisk 18.12.1 to 18.15.0 upgrade 
seems to have introduced a behavior where PJSIP is unable to send a response to 
OPTIONS (seems to resolve after anywhere a period of time)

On Wed, Dec 7, 2022 at 11:34 AM Joshua C. Colp 
mailto:jc...@sangoma.com>> wrote:
On Wed, Dec 7, 2022 at 11:26 AM Dan Cropp 
mailto:d...@amtelco.com>> wrote:
On two VMs, we encounter a strange behavior when we upgrade from 18.12.1 to 
18.15.0 (also tried 18.15.1 last night).
When we roll the VMs back to 18.12.1, we don’t see the behavior repeat.

We have a Kamailio VM front ending the asterisk.

It sends OPTIONS messages periodically.

After startup (and also after reloading configuration settings), we see periods 
where the response can’t be sent.
After a period of time, it suddenly starts working.

 I haven't seen this before, and haven't seen any other reports of it so far. 
The OPTIONS code itself hasn't changed between the two. There was a fix for a 
crash in send_stateful_response so adding log messages to the error cases is 
likely needed to see in particular which one is failing.


Ha, those changes haven't even landed yet. It's pretty much a thin wrapper over 
PJSIP stuff in 18.15.1. The PJSIP versions are also fairly close too.

--
Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com and 
www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Asterisk 18.12.1 to 18.15.0 upgrade seems to have introduced a behavior where PJSIP is unable to send a response to OPTIONS (seems to resolve after anywhere a period of time)

2022-12-07 Thread Joshua C. Colp 
On Wed, Dec 7, 2022 at 11:34 AM Joshua C. Colp  wrote:

> On Wed, Dec 7, 2022 at 11:26 AM Dan Cropp  wrote:
>
>> On two VMs, we encounter a strange behavior when we upgrade from 18.12.1
>> to 18.15.0 (also tried 18.15.1 last night).
>>
>> When we roll the VMs back to 18.12.1, we don’t see the behavior repeat.
>>
>>
>>
>> We have a Kamailio VM front ending the asterisk.
>>
>>
>>
>> It sends OPTIONS messages periodically.
>>
>>
>>
>> After startup (and also after reloading configuration settings), we see
>> periods where the response can’t be sent.
>>
>> After a period of time, it suddenly starts working.
>>
>>
>>
>  I haven't seen this before, and haven't seen any other reports of it so
> far. The OPTIONS code itself hasn't changed between the two. There was a
> fix for a crash in send_stateful_response so adding log messages to the
> error cases is likely needed to see in particular which one is failing.
>
>
Ha, those changes haven't even landed yet. It's pretty much a thin wrapper
over PJSIP stuff in 18.15.1. The PJSIP versions are also fairly close too.

-- 
Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Asterisk 18.12.1 to 18.15.0 upgrade seems to have introduced a behavior where PJSIP is unable to send a response to OPTIONS (seems to resolve after anywhere a period of time)

2022-12-07 Thread Joshua C. Colp 
On Wed, Dec 7, 2022 at 11:26 AM Dan Cropp  wrote:

> On two VMs, we encounter a strange behavior when we upgrade from 18.12.1
> to 18.15.0 (also tried 18.15.1 last night).
>
> When we roll the VMs back to 18.12.1, we don’t see the behavior repeat.
>
>
>
> We have a Kamailio VM front ending the asterisk.
>
>
>
> It sends OPTIONS messages periodically.
>
>
>
> After startup (and also after reloading configuration settings), we see
> periods where the response can’t be sent.
>
> After a period of time, it suddenly starts working.
>
>
>
> Here is a sample of it failing, followed by it working for the next
> OPTIONS message received.
>
>
>
>
>
> [12/06 20:40:55.797] VERBOSE[186673] res_pjsip_logger.c: <--- Received SIP
> request (392 bytes) from UDP:192.168.12.10:5060 --->
>
> OPTIONS sip:box_b@192.168.12.120:5060 SIP/2.0
>
> Via: SIP/2.0/UDP
> 192.168.12.10;branch=z9hG4bK10f.4d4a0332.0
>
> To: sip:box_b@192.168.12.120:5060
>
> From:
> sip:kamailio@192.168.12.10;tag=f1bcd6806a18022e516c4139c95990f1-92130971
>
> CSeq: 10 OPTIONS
>
> Call-ID: 5ff0944d46b1692c-2858982@192.168.12.10
>
> Max-Forwards: 70
>
> Content-Length: 0
>
> User-Agent: Genesis Proxy
>
>
>
>
>
> [12/06 20:40:55.797] DEBUG[186673] res_pjsip/pjsip_distributor.c: Could
> not find matching transaction for Request msg OPTIONS/cseq=10
> (rdata0x7f88380385c8)
>
> [12/06 20:40:55.797] DEBUG[186673] res_pjsip/pjsip_distributor.c:
> Calculated serializer pjsip/distributor-02f9 to use for Request msg
> OPTIONS/cseq=10 (rdata0x7f88380385c8)
>
> [12/06 20:40:55.797] DEBUG[194583] res_pjsip_endpoint_identifier_ip.c:
> Source address 192.168.12.10:5060 does not match identify 'identify140'
>
> [12/06 20:40:55.797] DEBUG[194583] res_pjsip_endpoint_identifier_ip.c:
> Source address 192.168.12.10:5060 matches identify 'identify158'
>
> [12/06 20:40:55.797] DEBUG[194583] res_pjsip_endpoint_identifier_ip.c:
> Identify 'identify158' SIP message matched to endpoint Kamailio
>
> [12/06 20:40:55.797] DEBUG[194583] res_pjsip/pjsip_resolver.c: Performing
> SIP DNS resolution of target '192.168.12.10'
>
> [12/06 20:40:55.797] DEBUG[194583] res_pjsip/pjsip_resolver.c: Transport
> type for target '192.168.12.10' is 'UDP transport'
>
> [12/06 20:40:55.797] DEBUG[194583] res_pjsip/pjsip_resolver.c: Target
> '192.168.12.10' is an IP address, skipping resolution
>
>
>
> [12/06 20:40:55.797] ERROR[194583] res_pjsip/pjsip_options.c: Unable to
> send response (-1)
>
>
>
>
>
> Four minutes later (and ever since then), it’s been fine responding to the
> OPTIONS.
>
>
>
> [12/06 20:40:59.797] VERBOSE[186673] res_pjsip_logger.c: <--- Received SIP
> request (392 bytes) from UDP:192.168.12.10:5060 --->
>
> OPTIONS sip:box_b@192.168.12.120:5060 SIP/2.0
>
> Via: SIP/2.0/UDP
> 192.168.12.10;branch=z9hG4bK10f.4d4a0332.0
>
> To: sip:box_b@192.168.12.120:5060
>
> From:
> sip:kamailio@192.168.12.10;tag=f1bcd6806a18022e516c4139c95990f1-92130971
>
> CSeq: 10 OPTIONS
>
> Call-ID: 5ff0944d46b1692c-2858982@192.168.12.10
>
> Max-Forwards: 70
>
> Content-Length: 0
>
> User-Agent: Genesis Proxy
>
>
>
> [12/06 20:40:59.797] DEBUG[186673] res_pjsip/pjsip_distributor.c: Could
> not find matching transaction for Request msg OPTIONS/cseq=10
> (rdata0x7f8838027c18)
>
> [12/06 20:40:59.797] DEBUG[186673] res_pjsip/pjsip_distributor.c:
> Calculated serializer pjsip/distributor-02f9 to use for Request msg
> OPTIONS/cseq=10 (rdata0x7f8838027c18)
>
> [12/06 20:40:59.797] DEBUG[194583] res_pjsip_endpoint_identifier_ip.c:
> Source address 192.168.12.10:5060 does not match identify 'identify140'
>
> [12/06 20:40:59.797] DEBUG[194583] res_pjsip_endpoint_identifier_ip.c:
> Source address 192.168.12.10:5060 matches identify 'identify158'
>
> [12/06 20:40:59.797] DEBUG[194583] res_pjsip_endpoint_identifier_ip.c:
> Identify 'identify158' SIP message matched to endpoint Kamailio
>
> [12/06 20:40:59.798] DEBUG[194583] res_pjsip/pjsip_resolver.c: Performing
> SIP DNS resolution of target '192.168.12.10'
>
> [12/06 20:40:59.798] DEBUG[194583] res_pjsip/pjsip_resolver.c: Transport
> type for target '192.168.12.10' is 'UDP transport'
>
> [12/06 20:40:59.798] DEBUG[194583] res_pjsip/pjsip_resolver.c: Target
> '192.168.12.10' is an IP address, skipping resolution
>
>
>
> [12/06 20:40:59.798] VERBOSE[194583] res_pjsip_logger.c: <--- Transmitting
> SIP response (896 bytes) to UDP:192.168.12.10:5060 --->
>
> SIP/2.0 200 OK
>
> Via: SIP/2.0/UDP
> 192.168.12.10;received=192.168.12.10;branch=z9hG4bK10f.4d4a0332.0
>
> Call-ID: 5ff0944d46b1692c-2858982@192.168.12.10
>
> From:
> sip:kamailio@192.168.12.10;tag=f1bcd6806a18022e516c4139c95990f1-92130971
>
> To:
> sip:box_b@192.168.12.120;tag=z9hG4bK10f.4d4a0332.0
>
> CSeq: 10 OPTIONS
>
> Accept: application/sdp, application/dialog-info+xml,
> application/simple-message-summary, application/xpidf+xml,
> application/cpim-pidf+xml, application/pidf+xml, application/pidf+xml,
>

[asterisk-users] Asterisk 18.12.1 to 18.15.0 upgrade seems to have introduced a behavior where PJSIP is unable to send a response to OPTIONS (seems to resolve after anywhere a period of time)

2022-12-07 Thread Dan Cropp 
On two VMs, we encounter a strange behavior when we upgrade from 18.12.1 to 
18.15.0 (also tried 18.15.1 last night).
When we roll the VMs back to 18.12.1, we don't see the behavior repeat.

We have a Kamailio VM front ending the asterisk.

It sends OPTIONS messages periodically.

After startup (and also after reloading configuration settings), we see periods 
where the response can't be sent.
After a period of time, it suddenly starts working.

Here is a sample of it failing, followed by it working for the next OPTIONS 
message received.


[12/06 20:40:55.797] VERBOSE[186673] res_pjsip_logger.c: <--- Received SIP 
request (392 bytes) from UDP:192.168.12.10:5060 --->
OPTIONS sip:box_b@192.168.12.120:5060 SIP/2.0
Via: SIP/2.0/UDP 
192.168.12.10;branch=z9hG4bK10f.4d4a0332.0
To: sip:box_b@192.168.12.120:5060
From: sip:kamailio@192.168.12.10;tag=f1bcd6806a18022e516c4139c95990f1-92130971
CSeq: 10 OPTIONS
Call-ID: 
5ff0944d46b1692c-2858982@192.168.12.10
Max-Forwards: 70
Content-Length: 0
User-Agent: Genesis Proxy


[12/06 20:40:55.797] DEBUG[186673] res_pjsip/pjsip_distributor.c: Could not 
find matching transaction for Request msg OPTIONS/cseq=10 (rdata0x7f88380385c8)
[12/06 20:40:55.797] DEBUG[186673] res_pjsip/pjsip_distributor.c: Calculated 
serializer pjsip/distributor-02f9 to use for Request msg OPTIONS/cseq=10 
(rdata0x7f88380385c8)
[12/06 20:40:55.797] DEBUG[194583] res_pjsip_endpoint_identifier_ip.c: Source 
address 192.168.12.10:5060 does not match identify 'identify140'
[12/06 20:40:55.797] DEBUG[194583] res_pjsip_endpoint_identifier_ip.c: Source 
address 192.168.12.10:5060 matches identify 'identify158'
[12/06 20:40:55.797] DEBUG[194583] res_pjsip_endpoint_identifier_ip.c: Identify 
'identify158' SIP message matched to endpoint Kamailio
[12/06 20:40:55.797] DEBUG[194583] res_pjsip/pjsip_resolver.c: Performing SIP 
DNS resolution of target '192.168.12.10'
[12/06 20:40:55.797] DEBUG[194583] res_pjsip/pjsip_resolver.c: Transport type 
for target '192.168.12.10' is 'UDP transport'
[12/06 20:40:55.797] DEBUG[194583] res_pjsip/pjsip_resolver.c: Target 
'192.168.12.10' is an IP address, skipping resolution

[12/06 20:40:55.797] ERROR[194583] res_pjsip/pjsip_options.c: Unable to send 
response (-1)


Four minutes later (and ever since then), it's been fine responding to the 
OPTIONS.

[12/06 20:40:59.797] VERBOSE[186673] res_pjsip_logger.c: <--- Received SIP 
request (392 bytes) from UDP:192.168.12.10:5060 --->
OPTIONS sip:box_b@192.168.12.120:5060 SIP/2.0
Via: SIP/2.0/UDP 
192.168.12.10;branch=z9hG4bK10f.4d4a0332.0
To: sip:box_b@192.168.12.120:5060
From: sip:kamailio@192.168.12.10;tag=f1bcd6806a18022e516c4139c95990f1-92130971
CSeq: 10 OPTIONS
Call-ID: 
5ff0944d46b1692c-2858982@192.168.12.10
Max-Forwards: 70
Content-Length: 0
User-Agent: Genesis Proxy

[12/06 20:40:59.797] DEBUG[186673] res_pjsip/pjsip_distributor.c: Could not 
find matching transaction for Request msg OPTIONS/cseq=10 (rdata0x7f8838027c18)
[12/06 20:40:59.797] DEBUG[186673] res_pjsip/pjsip_distributor.c: Calculated 
serializer pjsip/distributor-02f9 to use for Request msg OPTIONS/cseq=10 
(rdata0x7f8838027c18)
[12/06 20:40:59.797] DEBUG[194583] res_pjsip_endpoint_identifier_ip.c: Source 
address 192.168.12.10:5060 does not match identify 'identify140'
[12/06 20:40:59.797] DEBUG[194583] res_pjsip_endpoint_identifier_ip.c: Source 
address 192.168.12.10:5060 matches identify 'identify158'
[12/06 20:40:59.797] DEBUG[194583] res_pjsip_endpoint_identifier_ip.c: Identify 
'identify158' SIP message matched to endpoint Kamailio
[12/06 20:40:59.798] DEBUG[194583] res_pjsip/pjsip_resolver.c: Performing SIP 
DNS resolution of target '192.168.12.10'
[12/06 20:40:59.798] DEBUG[194583] res_pjsip/pjsip_resolver.c: Transport type 
for target '192.168.12.10' is 'UDP transport'
[12/06 20:40:59.798] DEBUG[194583] res_pjsip/pjsip_resolver.c: Target 
'192.168.12.10' is an IP address, skipping resolution

[12/06 20:40:59.798] VERBOSE[194583] res_pjsip_logger.c: <--- Transmitting SIP 
response (896 bytes) to UDP:192.168.12.10:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 
192.168.12.10;received=192.168.12.10;branch=z9hG4bK10f.4d4a0332.0
Call-ID: 
5ff0944d46b1692c-2858982@192.168.12.10
From: sip:kamailio@192.168.12.10;tag=f1bcd6806a18022e516c4139c95990f1-92130971
To: sip:box_b@192.168.12.120;tag=z9hG4bK10f.4d4a0332.0
CSeq: 10 OPTIONS
Accept: application/sdp, application/dialog-info+xml, 
application/simple-message-summary, application/xpidf+xml, 
application/cpim-pidf+xml, application/pidf+xml, application/pidf+xml, 
application/dialog-info+xml, application/simple-message-summary, 
message/sipfrag;version=2.0
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, 
UPDATE, PRACK, MESSAGE, REFER
Supported:

Re: [asterisk-users] Receive DTMF and record audio at the same time

2022-12-07 Thread Rhys Hanrahan 
Doh. Don't know why I only saw 19 when I checked docs this time. Even still 
though, that's a few months away so any solution that might work with Asterisk 
11 would be amazing.

On 8/12/2022, 12:06 am, "aster...@phreaknet.org"  
wrote:

On 12/7/2022 8:00 AM, Rhys Hanrahan wrote:
>
> Hi Everyone,
>
> I am trying to find a way to build an AGI script or dialplan that can 
> handle a “please just say OR enter the post code (zip code) you want” 
> voice IVR. I already have a speech to text solution working with the 
> AGI Record command and this works. Of course a standard DTMF menu is 
> easily done, but I don’t know how to do both at the same time. I need 
> a non-blocking way to also receive the DTMF digits while listening for 
> a voice at the same time. Or I suppose a non-blocking way to record 
> audio might work, and keep the DTMF Read() as blocking?
>
> My big limitation right now is that we are still on Asterisk 11. I am 
> planning a move to Asterisk 18 but even this doesn’t seem like it 
> would support StoreDTMF which would have probably been a solution.
>

StoreDTMF is part of Asterisk 18[1].

[1] 
https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Application_StoreDTMF

> I would appreciate any ideas on how to do this.
>
>


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Receive DTMF and record audio at the same time

2022-12-07 Thread asterisk 

On 12/7/2022 8:00 AM, Rhys Hanrahan wrote:


Hi Everyone,

I am trying to find a way to build an AGI script or dialplan that can 
handle a “please just say OR enter the post code (zip code) you want” 
voice IVR. I already have a speech to text solution working with the 
AGI Record command and this works. Of course a standard DTMF menu is 
easily done, but I don’t know how to do both at the same time. I need 
a non-blocking way to also receive the DTMF digits while listening for 
a voice at the same time. Or I suppose a non-blocking way to record 
audio might work, and keep the DTMF Read() as blocking?


My big limitation right now is that we are still on Asterisk 11. I am 
planning a move to Asterisk 18 but even this doesn’t seem like it 
would support StoreDTMF which would have probably been a solution.




StoreDTMF is part of Asterisk 18[1].

[1] 
https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Application_StoreDTMF



I would appreciate any ideas on how to do this.





--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] Receive DTMF and record audio at the same time

2022-12-07 Thread Rhys Hanrahan 
Hi Everyone,

I am trying to find a way to build an AGI script or dialplan that can handle a 
“please just say OR enter the post code (zip code) you want” voice IVR. I 
already have a speech to text solution working with the AGI Record command and 
this works. Of course a standard DTMF menu is easily done, but I don’t know how 
to do both at the same time. I need a non-blocking way to also receive the DTMF 
digits while listening for a voice at the same time. Or I suppose a 
non-blocking way to record audio might work, and keep the DTMF Read() as 
blocking?

My big limitation right now is that we are still on Asterisk 11. I am planning 
a move to Asterisk 18 but even this doesn’t seem like it would support 
StoreDTMF which would have probably been a solution. I would appreciate any 
ideas on how to do this.

Thanks.
Rhys Hanrahan | Chief Information Officer
e: r...@nexusone.com.au

[www.nexusone.com.au]   [signature_1237010360] 


NEXUS ONE | FUSION TECHNOLOGY SOLUTIONS
p: 1800 NEXUS1 (1800 639 871) or 1800 565 845 | a: Suite 12.03 Level 12, 227 
Elizabeth Street, Sydney NSW 2000
www.nexusone.com.au | 
www.fusiontech.com.au

The information in this email and any accompanying attachments may contain; a. 
Confidential information of Fusion Technology Solutions Pty Ltd, Nexus One Pty 
Ltd or third parties; b. Legally privileged information of Fusion Technology 
Solutions Pty Ltd, Nexus One Pty Ltd or third parties; and or c. Copyright 
material Fusion Technology Solutions Pty Ltd, Nexus One Pty Ltd or third 
parties. If you have received this email in error, please notify the sender 
immediately and delete this message. Fusion Technology Solutions Pty Ltd, Nexus 
One Pty Ltd does not accept any responsibility for loss or damage arising from 
the use or distribution of this email.

Please consider the environment before printing this email.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users