Re: [asterisk-users] Nat=yes

2011-04-24 Thread Steve Totaro
On Thu, Apr 21, 2011 at 5:42 AM, Alexandru Oniciuc 
alexandru.onic...@trivenet.it wrote:

 Dear * users,



 in your opinion, when using a * as a public server, is good practice
 enabling nat=yes in sip.conf for all the peers?

 Can anyone imagine a scenario when enabling this parameter (even for peers
 that don’t require it) can cause problems?



 Regards and thanks in advance,

 Alex




I asked this same exact question several years ago.  There are many replies
with different takes.  I would skim through Alex's posts, there is really
nothing worth reading except it will break the SIP RFC handed down by the
internets themselves.

I use nat=yes all the time and it works just fine.

http://www.mail-archive.com/asterisk-users@lists.digium.com/msg213941.html

Nobody actually answered the question about the bad side, they just argued
about the SIP RFC.

Many others agreed to make it default behavior and that setting nat=yes
gives a an extra degree of security.

RFCs are great and all, but in the real world, phones just need to work.

Thanks,
Steve Totaro
--
_
-- 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

Re: [asterisk-users] Nat=yes

2011-04-24 Thread Muhammad Ali
Hi,

When NAT = YES, Asterisk server will extract IP from the network layer. 
 
When Nat = No, the Asterisk server will respond to the IP in the SIP header. Am 
I right?

May be such type of options can be helpful for SIP application developers.

Can't think of a scenario but If it is set to be YES for all peers, what will 
happen is that the response to all the SIP request will be routed to the IP in 
the network layer. IP's in the SIP header will be ignored,  should not create a 
problem.
 

Regards

--- On Sun, 4/24/11, Steve Totaro stot...@asteriskhelpdesk.com wrote:

From: Steve Totaro stot...@asteriskhelpdesk.com
Subject: Re: [asterisk-users] Nat=yes
To: Asterisk Users Mailing List - Non-Commercial Discussion 
asterisk-users@lists.digium.com
Date: Sunday, April 24, 2011, 2:13 PM



On Thu, Apr 21, 2011 at 5:42 AM, Alexandru Oniciuc 
alexandru.onic...@trivenet.it wrote:

Dear * users, in your opinion, when using a * as a public server, is good 
practice enabling nat=yes in sip.conf for all the peers?
Can anyone imagine a scenario when enabling this parameter (even for peers that 
don’t require it) can cause problems? 
Regards and thanks in advance,Alex 

I asked this same exact question several years ago.  There are many replies 
with different takes.  I would skim through Alex's posts, there is really 
nothing worth reading except it will break the SIP RFC handed down by the 
internets themselves.


I use nat=yes all the time and it works just fine.

http://www.mail-archive.com/asterisk-users@lists.digium.com/msg213941.html


Nobody actually answered the question about the bad side, they just argued 
about the SIP RFC.

Many others agreed to make it default behavior and that setting nat=yes gives a 
an extra degree of security.


RFCs are great and all, but in the real world, phones just need to work.

Thanks,
Steve Totaro
 


-Inline Attachment Follows-

--
_
-- 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--
_
-- 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

Re: [asterisk-users] Nat=yes

2011-04-24 Thread Steve Totaro
On Sun, Apr 24, 2011 at 5:55 AM, Muhammad Ali ali_...@yahoo.com wrote:

 Hi,

 When NAT = YES, Asterisk server will extract IP from the network layer.

 When Nat = No, the Asterisk server will respond to the IP in the SIP
 header. Am I right?

 May be such type of options can be helpful for SIP application developers.

 Can't think of a scenario but If it is set to be YES for all peers, what
 will happen is that the response to all the SIP request will be routed to
 the IP in the network layer. IP's in the SIP header will be ignored, should
 not create a problem.


 Regards

 --- On *Sun, 4/24/11, Steve Totaro stot...@asteriskhelpdesk.com* wrote:


I am unsure of what you are saying.

All I know is that setting nat=yes has never failed me when nat=no has and
we are talking countless phones and installs.

In the OSI reference model, the Network is layer 3, IP.

Call it Network, layer 3, or IP, it is the same.

nat=yes breaks the RFC due to NAT but it gets people talking.  My customers
don't really care for things that don't work.

Thanks,
Steve Totaro
--
_
-- 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

Re: [asterisk-users] Nat=yes

2011-04-24 Thread Muhammad Ali
Hi,

I am unsure of what you are saying.

Just for discussion, if one has a control on the insertion of  the IP address 
in the SIP header, then nat options working can be verified  observed.
 
In the OSI reference model, the Network is layer 3, IP.
Call it Network, layer 3, or IP, it is the same.

All-right, by IP from the network layer  I meant, the IP address in the IP 
Header/Network layer/layer 3.

  IP from SIP I meant,  SIP request generator's IP address in the SIP Header. 
I missed the word address.

My customers don't really care for things that don't work. 

May be its useful for SIP application developers rather then end customers.

Have a good time.
Regards

--- On Sun, 4/24/11, Steve Totaro stot...@asteriskhelpdesk.com wrote:

From: Steve Totaro stot...@asteriskhelpdesk.com
Subject: Re: [asterisk-users] Nat=yes
To: Asterisk Users Mailing List - Non-Commercial Discussion 
asterisk-users@lists.digium.com
Date: Sunday, April 24, 2011, 3:28 PM



On Sun, Apr 24, 2011 at 5:55 AM, Muhammad Ali ali_...@yahoo.com wrote:

Hi,

When NAT = YES, Asterisk server will extract IP from the network layer. 
 
When Nat = No, the Asterisk server will respond to the IP in the SIP header. Am 
I right?


May be such type of options can be helpful for SIP application developers.

Can't think of a scenario but If it is set to be YES for all peers, what will 
happen is that the response to all the SIP request will be routed to the IP in 
the network layer. IP's in the SIP header will be ignored,  should not create a 
problem.

 

Regards

--- On Sun, 4/24/11, Steve Totaro stot...@asteriskhelpdesk.com wrote:



I am unsure of what you are saying.  

All I know is that setting nat=yes has never failed me when nat=no has and we 
are talking countless phones and installs.  

In the OSI reference model, the Network is layer 3, IP.


Call it Network, layer 3, or IP, it is the same.

nat=yes breaks the RFC due to NAT but it gets people talking.  My customers 
don't really care for things that don't work. 

Thanks,
Steve Totaro


-Inline Attachment Follows-

--
_
-- 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--
_
-- 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

Re: [asterisk-users] call files

2011-04-24 Thread Tiago Geada
Hello,

Thanks for replying.

Answers below:

On 23 April 2011 18:29, Sherwood McGowan sherwood.mcgo...@gmail.com wrote:



 On Sat, Apr 23, 2011 at 11:20 AM, Tiago Geada tiago.ge...@gmail.comwrote:

 Hi.

 Im having trouble setting variables in channel dialplan and re-using them
 in Extension dialplan...

 Im using the following call file:

 Channel: Local/210332450@ZonNew-Outbound
 CallerID: ZonNew-Outbound:49:210332450:
 MaxRetries: 5
 RetryTime: 10
 WaitTime: 60
 Account: Outbound210332450
 Context: agents
 Extension: 888210332450
 Set: __PARTNER=ZonNew-Outbound
 Set: NUMBER=210332450


 -

 In  Local/210332450@ZonNew-Outbound I Set(bla='blabla');

 It seems I cannot re-use this var in extension _888X in context
 agents...


 Basically the Channel dialplan has a Queue() and in _888X I would
 like to know the peer (or interface) that answered it... What can I do?

 Thanks in advance


 I'm a little confused by It Seems I cannot re-use this var in extension
 _888XX in context agentsOf course you can use it...but if you
 set bla to a different value in your code where your callfile is processed,
 Asterisk will (rightfully so) just set bla = to whatever you set it to

 Now, if the callfile doesn't send a channel through the context that
 you're trying to set blah, that's a little odd...

 Now, as far as retrieving the information about the interface that answered
 the calllook in queues.conf.samplethere's a nifty configuration
 option:

 *setinterfacevar=no ; (the default is no)*

 Yes, I am aware of this and I do use it. However, I cannot use
MEMBERINTERFACE variable in dialplan _888X, and that is where I'm
needing it.

Also seems that its two channel legs and the only way would be to use
IMPORT() o SHARED() and for that I would have to know the channel name...

I am right now using IMPORT() like:

Set(CALLERID(num)=${IMPORT(${CHANNEL:0:$[${LEN(${CHANNEL})} -
1]}2,MEMBERNAME)});


but I fee that it is a ugly fix. What if call leg changes from 2 to 3?


 That option, when set to yes, causes several variables to be created *just
 * prior to the caller being bridged with the queue member...

 --
 Sherwood McGowan
 Telecommunications and VOIP Consultant


 --
 _
 -- 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

--
_
-- 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

Re: [asterisk-users] DTMF not being sent ( RFC2833 )

2011-04-24 Thread David

I did more testing.

Here is a portion of extensions.conf on asterisk-pri:

exten = 5,1,Dial(DAHDI/g1/14186939930,30)
exten = 6,1,Answer
exten = 6,2,Wait(30)
exten = 7,1,Dial(DAHDI/g1/14186939930,30,D(132412983#))

Here is an expert from asterisk :

exten = 22,1,Dial(SIP/6@pri,30,D(132412983#))
exten = 24,1,Dial(SIP/5@pri,30,D(132412983#))

If I type console dial 24, the DTMFs work poorly, and I see messages 
like :


[Apr 24 11:26:20] DTMF[2691]: channel.c:2907 __ast_read: DTMF end 
emulation of '1' queued on DAHDI/1-1
[Apr 24 11:26:20] DTMF[2691]: channel.c:2802 __ast_read: DTMF end '1' 
received on SIP/omnity-0004, duration 60120 ms
[Apr 24 11:26:20] DTMF[2691]: channel.c:2842 __ast_read: DTMF end 
accepted with begin '1' on SIP/omnity-0004
[Apr 24 11:26:20] DTMF[2691]: channel.c:2858 __ast_read: DTMF end 
passthrough '1' on SIP/omnity-0004
[Apr 24 11:26:20] DTMF[2691]: channel.c:2874 __ast_read: DTMF begin '1' 
received on DAHDI/1-1
[Apr 24 11:26:20] DTMF[2691]: channel.c:2884 __ast_read: DTMF begin 
passthrough '1' on DAHDI/1-1
[Apr 24 11:26:20] DTMF[2691]: channel.c:2802 __ast_read: DTMF end '1' 
received on DAHDI/1-1, duration 39 ms
[Apr 24 11:26:20] DTMF[2691]: channel.c:2842 __ast_read: DTMF end 
accepted with begin '1' on DAHDI/1-1
[Apr 24 11:26:20] DTMF[2691]: channel.c:2851 __ast_read: DTMF end '1' 
has duration 39 but want minimum 80, emulating on DAHDI/1-1


If I type console dial 22 on asterisk, all the DTMFs are 60ms in length 
and I get no unusually long DTMFs.


If I type console dial 7 on asterisk-pri, all the DTMFs are properly 
sent, and the remote party sees my DTMFs perfectly.


So it would seem that the bug occurs when one asterisk calls the second 
asterisk which bridges to a DAHDI channel.


My next step is too compare the SIP signalling between the two calls. 
Maybe something is different.


What I find really weird is that the DTMF is incorrectly sent from the 
first asterisk only when the second asterisk bridges to DAHDI.


Any ideas?

David

On 11-04-23 11:48 AM, David wrote:

Hello,
I installed Asterisk 1.6.2.17.3 ( latest as of yesterday ) and had 
multiple problems with DTMF.
I have two machines, we'll call them asterisk and asterisk-pri. 
Asterisk does IVR and asterisk-pri has a PRI card in it and connects 
to the PSTN. The two servers communicate via SIP with RFC2833.
I setup logger.conf on both machines to display DTMF to the console. 
Both are built from source.

Asterisk : spandsp, dahdi, asterisk.
Asterisk-pri : spandsp, libpri, dahdi, asterisk wanpipe
I eliminated AGI, hard phones, network et al by setting up this 
extension :
exten = 22,1,Dial(SIP/114186939...@pri1.omnity.net,30,D(132412983 
mailto:SIP/114186939...@pri1.omnity.net,30,D%28132412983#))

in default.
The only other non default setting is in sip.conf I added a 
outboundproxy ( which does NOT do RTP, only SIP ).

I called asterisk from my hard phone ( gxp2000 ) by dialing 22.
I see the console DTMF messages indicating the DTMF was sent or 
received. ( I forgot to keep this output ).
I than watch the console DTMF output on asterisk-pri and it showed 
about half the DTMFs. The pager that was called showed the DTMFs that 
appeared on the asterisk-pri console.
So somewhere between the two machines, the DTMFs have disappeared. So 
I ran TCPDump on asterisk and saw that close to half of the DTMF 
events were never sent.

tcpdump -i eth0 -n -s 0 dst asterisk-pri-ip -vvv -w ~/dtmf.pcap
I imported the file into wireshark on my local machine and confirmed 
that the dump almost matches what I saw on asterisk-pri.

So, problem 1 : Asterisk is not sending all the DTMFs to asterisk-pri.
I compared the packet scan to what I saw on asterisk-pri and noticed 
that between 1 and 3 dtmfs were missing.

Problem 2 : Asterisk-pri loses some received DTMFs.
I also noticed that some of the DTMFs coming out of asterisk had the 
wrong Event Duration. I had one DTMF with a duration of about 58000 ( 
I believe that's 58 seconds ) but I only pressed the button for like 
1/3 of a second.
What I do not understand is that I in my final test last night was 
using asterisk 1.6 current with centos ( os that asterisk is developed 
on from my understanding ) with all default settings ( excluding 
logger.conf, dialplan and outboundproxy ) and I am having problems 
with the DTMF.
Both servers were installed with CentOS 5.5 and were updated last 
night, after which I reinstalled asterisk. This did not resolve the issue.
I am at wit's end and do not know where to go from here. I would 
really appreciate it if someone could give me some pointers on where 
to go next, what additionnal debugging steps I should perform. I would 
also really appreciate if someone could propose a solution.

Please help!
David
Never give up, never surrender


--
_
-- Bandwidth and Colocation Provided byhttp://www.api-digital.com  --
New to Asterisk? Join us for a live introductory webinar 

[asterisk-users] Best modem for chan_datacard

2011-04-24 Thread Dovid Bender
Hi List,

I am looking to play around with chan_datacard. Any advice on the best 
device to test with (that I can find on eBay) ?

Regards,

Dovid
--
_
-- 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

Re: [asterisk-users] DTMF not being sent ( RFC2833 )

2011-04-24 Thread David

Hello,

I traced the SIP packets and saw that the only difference was that the 
DAHDI channel returns 183 Session progress ( besides the obvious 
differences such as the To and from tags in sip , session id and rtp 
ports in the SDP ).


I updated my dialplan on asterisk-pri as follows :

exten = 6,1,Progress
exten = 6,n,Wait(5)
exten = 6,n,Answer
exten = 6,n,Wait(30)

This makes the local channel behave the same as the DAHDI channel. With 
this in place, the SIP packets for both test calls are identical ( 
excluding the To header, To Tag, From Tag, SDP ports, SDP session Id and 
SDP version.


Everything else is identical. So the problem appears to be caused in the 
RTP and not in the SIP. So something about the RTP packets coming from 
the DAHDI channel on asterisk-pri makes asterisk server send invalid DTMF.


David

On 11-04-24 11:42 AM, David wrote:

I did more testing.

Here is a portion of extensions.conf on asterisk-pri:

exten = 5,1,Dial(DAHDI/g1/14186939930,30)
exten = 6,1,Answer
exten = 6,2,Wait(30)
exten = 7,1,Dial(DAHDI/g1/14186939930,30,D(132412983#))

Here is an expert from asterisk :

exten = 22,1,Dial(SIP/6@pri,30,D(132412983#))
exten = 24,1,Dial(SIP/5@pri,30,D(132412983#))

If I type console dial 24, the DTMFs work poorly, and I see messages 
like :


[Apr 24 11:26:20] DTMF[2691]: channel.c:2907 __ast_read: DTMF end 
emulation of '1' queued on DAHDI/1-1
[Apr 24 11:26:20] DTMF[2691]: channel.c:2802 __ast_read: DTMF end '1' 
received on SIP/omnity-0004, duration 60120 ms
[Apr 24 11:26:20] DTMF[2691]: channel.c:2842 __ast_read: DTMF end 
accepted with begin '1' on SIP/omnity-0004
[Apr 24 11:26:20] DTMF[2691]: channel.c:2858 __ast_read: DTMF end 
passthrough '1' on SIP/omnity-0004
[Apr 24 11:26:20] DTMF[2691]: channel.c:2874 __ast_read: DTMF begin 
'1' received on DAHDI/1-1
[Apr 24 11:26:20] DTMF[2691]: channel.c:2884 __ast_read: DTMF begin 
passthrough '1' on DAHDI/1-1
[Apr 24 11:26:20] DTMF[2691]: channel.c:2802 __ast_read: DTMF end '1' 
received on DAHDI/1-1, duration 39 ms
[Apr 24 11:26:20] DTMF[2691]: channel.c:2842 __ast_read: DTMF end 
accepted with begin '1' on DAHDI/1-1
[Apr 24 11:26:20] DTMF[2691]: channel.c:2851 __ast_read: DTMF end '1' 
has duration 39 but want minimum 80, emulating on DAHDI/1-1


If I type console dial 22 on asterisk, all the DTMFs are 60ms in 
length and I get no unusually long DTMFs.


If I type console dial 7 on asterisk-pri, all the DTMFs are properly 
sent, and the remote party sees my DTMFs perfectly.


So it would seem that the bug occurs when one asterisk calls the 
second asterisk which bridges to a DAHDI channel.


My next step is too compare the SIP signalling between the two calls. 
Maybe something is different.


What I find really weird is that the DTMF is incorrectly sent from the 
first asterisk only when the second asterisk bridges to DAHDI.


Any ideas?

David

On 11-04-23 11:48 AM, David wrote:

Hello,
I installed Asterisk 1.6.2.17.3 ( latest as of yesterday ) and had 
multiple problems with DTMF.
I have two machines, we'll call them asterisk and asterisk-pri. 
Asterisk does IVR and asterisk-pri has a PRI card in it and connects 
to the PSTN. The two servers communicate via SIP with RFC2833.
I setup logger.conf on both machines to display DTMF to the console. 
Both are built from source.

Asterisk : spandsp, dahdi, asterisk.
Asterisk-pri : spandsp, libpri, dahdi, asterisk wanpipe
I eliminated AGI, hard phones, network et al by setting up this 
extension :
exten = 22,1,Dial(SIP/114186939...@pri1.omnity.net,30,D(132412983 
mailto:SIP/114186939...@pri1.omnity.net,30,D%28132412983#))

in default.
The only other non default setting is in sip.conf I added a 
outboundproxy ( which does NOT do RTP, only SIP ).

I called asterisk from my hard phone ( gxp2000 ) by dialing 22.
I see the console DTMF messages indicating the DTMF was sent or 
received. ( I forgot to keep this output ).
I than watch the console DTMF output on asterisk-pri and it showed 
about half the DTMFs. The pager that was called showed the DTMFs that 
appeared on the asterisk-pri console.
So somewhere between the two machines, the DTMFs have disappeared. So 
I ran TCPDump on asterisk and saw that close to half of the DTMF 
events were never sent.

tcpdump -i eth0 -n -s 0 dst asterisk-pri-ip -vvv -w ~/dtmf.pcap
I imported the file into wireshark on my local machine and confirmed 
that the dump almost matches what I saw on asterisk-pri.

So, problem 1 : Asterisk is not sending all the DTMFs to asterisk-pri.
I compared the packet scan to what I saw on asterisk-pri and noticed 
that between 1 and 3 dtmfs were missing.

Problem 2 : Asterisk-pri loses some received DTMFs.
I also noticed that some of the DTMFs coming out of asterisk had the 
wrong Event Duration. I had one DTMF with a duration of about 58000 ( 
I believe that's 58 seconds ) but I only pressed the button for like 
1/3 of a second.
What I do not understand is that I in my final test last night was 
using asterisk 

[asterisk-users] DTMF incorrectly sent ( RFC2833 or SIPInfo )

2011-04-24 Thread David

Hello,

I will summarize the current situation. I have reduced the bug to two 
asterisk machines. One of which has a PRI card ( DAHDI channels).


The first server calls the second server with SIP. The second server 
bridges the SIP channel to a DAHDI channel. When I send DTMFs from the 
first server ( SIP Info or RFC2833) they are incorrectly sent.


I setup a second scenario where the first server calls the second with 
SIP and the second server uses the dialplan to answer, it plays back a 
message to generate audio. The DTMFs are received perfectly.


Asterisk server that is dialing ( first server ):

exten = 22,1,Dial(SIP/6...@pri1.omnity.net,30,D(132412983#))
exten = 24,1,Dial(SIP/5...@pri1.omnity.net,30,D(132412983#))

Asterisk server that is answering ( second server ):

exten = 5,1,Dial(DAHDI/g1/14186939930,30)
exten = 6,1,Progress
exten = 6,n,Wait(5)
exten = 6,n,Answer
exten = 6,n,Playback(vm-loginvm-loginvm-loginvm-loginvm-login)
exten = 6,n,Wait(30)

Here is the latest console output, notice that the # was sent several 
times but in reality it was only sent once by the first server.


This is the scenario where I dialed 22, the DTMF ( SIP Info ) is sent 
properly.


[Apr 24 12:49:46] DTMF[2844]: channel.c:2907 __ast_read: DTMF end 
emulation of '1' queued on SIP/omnity-0022
[Apr 24 12:49:46] DTMF[2844]: channel.c:2874 __ast_read: DTMF begin '1' 
received on SIP/omnity-0022
[Apr 24 12:49:46] DTMF[2844]: channel.c:2878 __ast_read: DTMF begin 
ignored '1' on SIP/omnity-0022
[Apr 24 12:49:46] DTMF[2844]: channel.c:2802 __ast_read: DTMF end '3' 
received on SIP/omnity-0022, duration 100 ms
[Apr 24 12:49:46] DTMF[2844]: channel.c:2858 __ast_read: DTMF end 
passthrough '3' on SIP/omnity-0022
[Apr 24 12:49:46] DTMF[2844]: channel.c:2802 __ast_read: DTMF end '2' 
received on SIP/omnity-0022, duration 100 ms
[Apr 24 12:49:46] DTMF[2844]: channel.c:2858 __ast_read: DTMF end 
passthrough '2' on SIP/omnity-0022
[Apr 24 12:49:46] DTMF[2844]: channel.c:2802 __ast_read: DTMF end '4' 
received on SIP/omnity-0022, duration 100 ms
[Apr 24 12:49:46] DTMF[2844]: channel.c:2858 __ast_read: DTMF end 
passthrough '4' on SIP/omnity-0022
[Apr 24 12:49:46] DTMF[2844]: channel.c:2802 __ast_read: DTMF end '1' 
received on SIP/omnity-0022, duration 100 ms
[Apr 24 12:49:46] DTMF[2844]: channel.c:2858 __ast_read: DTMF end 
passthrough '1' on SIP/omnity-0022
[Apr 24 12:49:47] DTMF[2844]: channel.c:2802 __ast_read: DTMF end '2' 
received on SIP/omnity-0022, duration 100 ms
[Apr 24 12:49:47] DTMF[2844]: channel.c:2858 __ast_read: DTMF end 
passthrough '2' on SIP/omnity-0022
[Apr 24 12:49:47] DTMF[2844]: channel.c:2802 __ast_read: DTMF end '9' 
received on SIP/omnity-0022, duration 100 ms
[Apr 24 12:49:47] DTMF[2844]: channel.c:2858 __ast_read: DTMF end 
passthrough '9' on SIP/omnity-0022
[Apr 24 12:49:47] DTMF[2844]: channel.c:2802 __ast_read: DTMF end '8' 
received on SIP/omnity-0022, duration 100 ms
[Apr 24 12:49:47] DTMF[2844]: channel.c:2858 __ast_read: DTMF end 
passthrough '8' on SIP/omnity-0022
[Apr 24 12:49:47] DTMF[2844]: channel.c:2802 __ast_read: DTMF end '3' 
received on SIP/omnity-0022, duration 100 ms
[Apr 24 12:49:47] DTMF[2844]: channel.c:2858 __ast_read: DTMF end 
passthrough '3' on SIP/omnity-0022
[Apr 24 12:49:48] DTMF[2844]: channel.c:2802 __ast_read: DTMF end '#' 
received on SIP/omnity-0022, duration 100 ms
[Apr 24 12:49:48] DTMF[2844]: channel.c:2858 __ast_read: DTMF end 
passthrough '#' on SIP/omnity-0022


==

Here is the console from the first scenario using SIP Info :

[Apr 24 12:50:18] DTMF[2845]: channel.c:2802 __ast_read: DTMF end '1' 
received on SIP/omnity-0023, duration 100 ms
[Apr 24 12:50:18] DTMF[2845]: channel.c:2828 __ast_read: DTMF begin 
emulation of '1' with duration 100 queued on SIP/omnity-0023
[Apr 24 12:50:18] DTMF[2845]: channel.c:2874 __ast_read: DTMF begin '1' 
received on DAHDI/1-1
[Apr 24 12:50:18] DTMF[2845]: channel.c:2878 __ast_read: DTMF begin 
ignored '1' on DAHDI/1-1
[Apr 24 12:50:18] DTMF[2845]: channel.c:2802 __ast_read: DTMF end '1' 
received on DAHDI/1-1, duration 39 ms
[Apr 24 12:50:18] DTMF[2845]: channel.c:2858 __ast_read: DTMF end 
passthrough '1' on DAHDI/1-1
[Apr 24 12:50:18] DTMF[2845]: channel.c:2907 __ast_read: DTMF end 
emulation of '1' queued on SIP/omnity-0023
[Apr 24 12:50:18] DTMF[2845]: channel.c:2874 __ast_read: DTMF begin '1' 
received on DAHDI/1-1
[Apr 24 12:50:18] DTMF[2845]: channel.c:2878 __ast_read: DTMF begin 
ignored '1' on DAHDI/1-1
[Apr 24 12:50:18] DTMF[2845]: channel.c:2802 __ast_read: DTMF end '1' 
received on DAHDI/1-1, duration 80 ms
[Apr 24 12:50:18] DTMF[2845]: channel.c:2858 __ast_read: DTMF end 
passthrough '1' on DAHDI/1-1
[Apr 24 12:50:18] DTMF[2845]: channel.c:2802 __ast_read: DTMF end '3' 
received on SIP/omnity-0023, duration 100 ms
[Apr 24 12:50:18] DTMF[2845]: channel.c:2828 

[asterisk-users] Realtime and priority labels

2011-04-24 Thread Bruce Ferrell

In the following example

exten = _1NXXNXX,1,Set(GROUP(outbound)=myprovider)
exten = _1NXXNXX,n,Set(COUNT=${GROUP_COUNT(myprovider@outbound)})
exten = _1NXXNXX,n,NoOp(There are ${COUNT} calls for myprovider)
exten = _1NXXNXX,n,GotoIf($[ ${COUNT}  2 ]?denied : continue)
exten = _1NXXNXX,n(denied),NoOp(There are too many calls up)
exten = _1NXXNXX,n,Hangup()
exten = _1NXXNXX,n(continue),GoSub(callmyprovider,${EXTEN},1)

instead of sequentially numbering the priorities, the n construct is 
used.  I find that when I attempt this in the realtime extensions table 
only, the first priority step is recognized.  If I sequentially number 
the priorities and add a label, the step is no longer recognized.


Is this behavior by design or an error?

Thanks in advance

Bruce



--
_
-- 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


[asterisk-users] Repost: Jabber / facebook chat?

2011-04-24 Thread Stefan Gofferje
On Sunday 17 April 2011, Stefan Gofferje wrote:
 Hi,
 
 has anyone managed to establish an XMPP connection to the facebook
 Jabber servers?
 I'd like to send messages on missed calls vie FB.
 
 -S

-- 
 (o_   Stefan Gofferje| SCLT, MCP, CCSA
 //\   Reg'd Linux User #247167   | VCP #2263
 V_/_  Heckler  Koch - the original point and click interface 


signature.asc
Description: This is a digitally signed message part.
--
_
-- 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

[asterisk-users] Repost: Jabber / GTalk / hints

2011-04-24 Thread Stefan Gofferje
On Sunday 17 April 2011, Stefan Gofferje wrote:
 Hi!
 
 Are hints not yet implemented in res_jabber?
 I have this here:
 
 exten = 3000,hint,gtalk/gtalk_account/mari....@gmail.com
 
 But the hint doesn't show any difference. It always shows online on the
 phone and core show hints always shows that:
 
 6003@internal   : SCCP/6003  State:Unavailable Watchers  0
 6002@internal   : SCCP/6002  State:IdleWatchers  0
 6001@internal   : SCCP/6001  State:IdleWatchers  0
 6000@internal   : SCCP/6000  State:IdleWatchers  0
 6004@internal   : SIP/sgofferj   State:IdleWatchers  0
 6200@internal   : SCCP/6200  State:Unavailable Watchers  0
 3000@internal   : gtalk/gtalk_account/ State:Idle  Watchers  1
 
 Funnily, the gtalk hint is the only one with a watcher although all
 hints are hooked in various phones...
 
 Any ideas, comments, etc...?
 
 -S
-- 
 (o_   Stefan Gofferje| SCLT, MCP, CCSA
 //\   Reg'd Linux User #247167   | VCP #2263
 V_/_  Heckler  Koch - the original point and click interface 


signature.asc
Description: This is a digitally signed message part.
--
_
-- 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

[asterisk-users] (no subject)

2011-04-24 Thread Abid Saleem

HI,
I am trying to setup a Class 4 termination setup using a kind of channel 
hunting scenerio. I have some SIP DID numbers assigned from the local telecom 
provider for termination. MY call comes from my wholesale client and lands on a 
switch, then it is routed to asterisk. I want asterisk to route this call to my 
local DID provider on the next available channel with DID number as the new 
Caller ID. This is just like GSM gateway that recieves the call and then 
re-originates the call using the next available SIM card number.
Can someone help me how can I configure Asterisk to perform this?
Thanks
Abid. --
_
-- 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