Re: [asterisk-users] Issue dialing out
On Sat, Jun 15, 2013 at 04:24:21PM -0400, Andre Goree wrote: > Thanks so much for your suggestions. > > I'm running 1.0.x (yes, archaic, and in fact my actual task is > migrating this system to asterisk11+Freepbx -- very fun in and of > itself without regards to this issue...but I digress), and so I needed > to run "pri debug span ", which I've now done. I attempted the > call again have pasted the debug output here: > http://pastebin.com/cHHnMfh6 You mentioned the telco receiving a DISCONNECT almost immediatly. Your debug is only up to a PROGRESS. I only have experience with euroisdn but callflow would be: ->SETUP <-CALLPROCEDING <-PROGRESS <-CONNECT ->CONNECT ACK ->DISCONNECT (eg from caller) <-RELEASE ->RELEASE COMPLETE But PROGRESS means the recipient is generating some audio (your unreachable message?). If this is an error message you would expect a RELASE from the telco after the recording if the caller doesn't hangup first. You should study the difference of zap->zap and sip->zap callsetup. -- _ -- 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] Issue dialing out
>> Do a "pri set debug" (or whatever it is called in 1.4 (zap?)) Zap/Zap >> bridging should work, it did on my PRIs and still does with DAHDI. Only >> thing I can think of is the TON/NPI might be a problem (but doubt it >> since SIP/Zap works). >> >> > > Thanks so much for your suggestions. > > I'm running 1.0.x (yes, archaic, and in fact my actual task is > migrating this system to asterisk11+Freepbx -- very fun in and of > itself without regards to this issue...but I digress), and so I needed > to run "pri debug span ", which I've now done. I attempted the > call again have pasted the debug output here: > http://pastebin.com/cHHnMfh6 > > I can't thank you enough for your assistance, and I understand if you > wouldn't want to go through the debug output as it's LONG -- though > I'm thinking most of the pertinent info as towards the end. Dan, wanted to thank you again for your assistance. I got this worked out with our provider, it was actually an issue on their end that they've now corrected. Thanks again for your help! -- _ -- 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] Issue dialing out
On Sat, Jun 15, 2013 at 4:03 PM, Daniel Tryba wrote: > On Sat, Jun 15, 2013 at 03:02:41PM -0400, Andre Goree wrote: >> Setting the CID did not work, unfortunately :( > [...] >> I'm going to try another number that we have through them in hopes >> that it'll complete and I'll let you know if that works. Do you have >> any other suggestions on what you think they might be filtering by? >> >> In the trap given to me by the company, they show our system issuing a >> "disconnect" from our end, rather than their end dropping the call. > > Do a "pri set debug" (or whatever it is called in 1.4 (zap?)) Zap/Zap > bridging should work, it did on my PRIs and still does with DAHDI. Only > thing I can think of is the TON/NPI might be a problem (but doubt it > since SIP/Zap works). > > Thanks so much for your suggestions. I'm running 1.0.x (yes, archaic, and in fact my actual task is migrating this system to asterisk11+Freepbx -- very fun in and of itself without regards to this issue...but I digress), and so I needed to run "pri debug span ", which I've now done. I attempted the call again have pasted the debug output here: http://pastebin.com/cHHnMfh6 I can't thank you enough for your assistance, and I understand if you wouldn't want to go through the debug output as it's LONG -- though I'm thinking most of the pertinent info as towards the end. -- _ -- 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] Issue dialing out
On Sat, Jun 15, 2013 at 03:02:41PM -0400, Andre Goree wrote: > Setting the CID did not work, unfortunately :( [...] > I'm going to try another number that we have through them in hopes > that it'll complete and I'll let you know if that works. Do you have > any other suggestions on what you think they might be filtering by? > > In the trap given to me by the company, they show our system issuing a > "disconnect" from our end, rather than their end dropping the call. Do a "pri set debug" (or whatever it is called in 1.4 (zap?)) Zap/Zap bridging should work, it did on my PRIs and still does with DAHDI. Only thing I can think of is the TON/NPI might be a problem (but doubt it since SIP/Zap works). -- _ -- 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] Issue dialing out
>> They are either incompetant or lying to you. Call appears to succeed (it
>> is answered) and gets disconnected after 23s. You are not generating the
>> message, so the calls gets back to you telco.
>>
>> Most likely someone is filtering on callerID (which is a good thing IMHO).
>> Set the callerid to one of your numbers before sending it back to Zap
>> and try again.
>>
>
> You're right! Forgot to update this thread, but a tech from their
> side performed a trap on the line and attempted to recreate the issue.
> From their switch, they're seeing the call go into our asterisk
> system, then leave the asterisk system (as it tries to dial the
> outside line when reaching the specific extensions 4832), then
> receiving a disconnect from our asterisk system almost immediately. So
> it would appear that asterisk attempts to forward the call as
> expected, then immediately disconnects for some unknown reason, which
> I guess is the specific issue I need to determine the cause of and
> resolve.
>
> I'm going to try what you've suggested and set the callerid to one of
> our numbers. Will let you know of the result.
>
> Thanks!
Setting the CID did not work, unfortunately :(
Jun 15 14:50:31 VERBOSE[777]: -- Accepting call from 'XX6886' to
'XX3730' on channel 0/1, span 1
Jun 15 14:50:31 VERBOSE[31883]: -- Executing Answer("Zap/1-1", "") in new stack
Jun 15 14:50:31 VERBOSE[31883]: -- Executing Wait("Zap/1-1", "2") in new stack
Jun 15 14:50:33 VERBOSE[31883]: -- Executing Goto("Zap/1-1",
"pri-in-dids|XX3730|1") in new stack
Jun 15 14:50:33 VERBOSE[31883]: -- Goto (pri-in-dids,XX3730,1)
Jun 15 14:50:33 VERBOSE[31883]: -- Executing Goto("Zap/1-1",
"menu-v2|s|1") in new stack
Jun 15 14:50:33 VERBOSE[31883]: -- Goto (menu-v2,s,1)
Jun 15 14:50:33 VERBOSE[31883]: -- Executing BackGround("Zap/1-1",
"firstintro") in new stack
Jun 15 14:50:33 VERBOSE[31883]: -- Playing 'firstintro' (language 'en')
Jun 15 14:50:39 VERBOSE[31883]: == CDR updated on Zap/1-1
Jun 15 14:50:39 VERBOSE[31883]: -- Executing SetCIDNum("Zap/1-1",
"XX3730") in new stack
Jun 15 14:50:39 VERBOSE[31883]: -- Executing Dial("Zap/1-1",
"zap/g1/1XX|20|tT") in new stack
Jun 15 14:50:39 VERBOSE[31883]: -- Called g1/1XX
Jun 15 14:50:42 VERBOSE[31883]: -- Zap/2-1 answered Zap/1-1
Jun 15 14:50:42 VERBOSE[31883]: -- Attempting native bridge of Zap/1-1
and Zap/2-1
Jun 15 14:50:58 VERBOSE[777]: -- Channel 0/1, span 1 got hangup
Jun 15 14:50:58 VERBOSE[31883]: -- Hungup 'Zap/2-1'
Jun 15 14:50:58 VERBOSE[31883]: == Spawn extension (menu-v2, 4832, 2)
exited non-zero on 'Zap/1-1'
Jun 15 14:50:58 VERBOSE[31883]: -- Hungup 'Zap/1-1'
I'm going to try another number that we have through them in hopes
that it'll complete and I'll let you know if that works. Do you have
any other suggestions on what you think they might be filtering by?
In the trap given to me by the company, they show our system issuing a
"disconnect" from our end, rather than their end dropping the call.
Thanks for the assistance.
--
_
-- 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] Issue dialing out
On Sat, Jun 15, 2013 at 2:18 PM, Daniel Tryba wrote:
>> Jun 15 13:06:05 VERBOSE[30232]: -- Executing Dial("Zap/1-1",
>> "zap/g1/1XX|20|tT") in new stack
>> Jun 15 13:06:05 VERBOSE[30232]: -- Called g1/1XX
>> Jun 15 13:06:08 VERBOSE[30232]: -- Zap/2-1 answered Zap/1-1
>> Jun 15 13:06:08 VERBOSE[30232]: -- Attempting native bridge of Zap/1-1
>> and Zap/2-1
>> Jun 15 13:06:31 VERBOSE[30232]: -- Hungup 'Zap/2-1'
>> Jun 15 13:06:31 VERBOSE[30232]: == Spawn extension (menu-v2, 4832, 1)
>> exited non-zero on 'Zap/1-1'
>> Jun 15 13:06:31 VERBOSE[30232]: -- Hungup 'Zap/1-1'
>>
>>
>> I've contacted our PRI provider, however, they say that they do not
>> see the call reach their system. To me, it would seem like the call is
>> coming into our Asterisk system through our Zap interface on one
>> channel, then attempting to leave the system through the Zap interface
>> on another channel, and is failing to do so.
>
> They are either incompetant or lying to you. Call appears to succeed (it
> is answered) and gets disconnected after 23s. You are not generating the
> message, so the calls gets back to you telco.
>
> Most likely someone is filtering on callerID (which is a good thing IMHO).
> Set the callerid to one of your numbers before sending it back to Zap
> and try again.
>
You're right! Forgot to update this thread, but a tech from their
side performed a trap on the line and attempted to recreate the issue.
>From their switch, they're seeing the call go into our asterisk
system, then leave the asterisk system (as it tries to dial the
outside line when reaching the specific extensions 4832), then
receiving a disconnect from our asterisk system almost immediately. So
it would appear that asterisk attempts to forward the call as
expected, then immediately disconnects for some unknown reason, which
I guess is the specific issue I need to determine the cause of and
resolve.
I'm going to try what you've suggested and set the callerid to one of
our numbers. Will let you know of the result.
Thanks!
--
_
-- 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] Issue dialing out
> Jun 15 13:06:05 VERBOSE[30232]: -- Executing Dial("Zap/1-1",
> "zap/g1/1XX|20|tT") in new stack
> Jun 15 13:06:05 VERBOSE[30232]: -- Called g1/1XX
> Jun 15 13:06:08 VERBOSE[30232]: -- Zap/2-1 answered Zap/1-1
> Jun 15 13:06:08 VERBOSE[30232]: -- Attempting native bridge of Zap/1-1
> and Zap/2-1
> Jun 15 13:06:31 VERBOSE[30232]: -- Hungup 'Zap/2-1'
> Jun 15 13:06:31 VERBOSE[30232]: == Spawn extension (menu-v2, 4832, 1)
> exited non-zero on 'Zap/1-1'
> Jun 15 13:06:31 VERBOSE[30232]: -- Hungup 'Zap/1-1'
>
>
> I've contacted our PRI provider, however, they say that they do not
> see the call reach their system. To me, it would seem like the call is
> coming into our Asterisk system through our Zap interface on one
> channel, then attempting to leave the system through the Zap interface
> on another channel, and is failing to do so.
They are either incompetant or lying to you. Call appears to succeed (it
is answered) and gets disconnected after 23s. You are not generating the
message, so the calls gets back to you telco.
Most likely someone is filtering on callerID (which is a good thing IMHO).
Set the callerid to one of your numbers before sending it back to Zap
and try again.
--
_
-- 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] Issue dialing out
Hello all.
I'm having trouble resolving an issue with our Asterisk system that
seems to have popped up recently (no one knows for sure when the issue
started). I'm still somewhat of a Asterisk newb and have been tasked
with administrating the system as the previous administrator has left
the company.
Within asterisk, we have a Zap interface setup connected to a PRI that
we have through a telco. We have a certain extension setup to forward
to a users cellphone when the extension is dialed. This apparently is
no longer working, an we receive the following message when dialing
the extension:
"The number you have dialed cannot be reached by the long-distance
company you've selected. Please check the code and dial again, or call
your long-distance company for assistance. P-U-A-M-I-2-3"
This is what I see in the logs when this issue occurs (actual numbers redacted):
Jun 15 13:05:59 VERBOSE[30232]: -- Executing Answer("Zap/1-1", "") in new stack
Jun 15 13:05:59 VERBOSE[30232]: -- Executing Wait("Zap/1-1", "2") in new stack
Jun 15 13:06:01 VERBOSE[30232]: -- Executing Goto("Zap/1-1",
"pri-in-dids|XX3730|1") in new stack
Jun 15 13:06:01 VERBOSE[30232]: -- Goto (pri-in-dids,XX3730,1)
Jun 15 13:06:01 VERBOSE[30232]: -- Executing Goto("Zap/1-1",
"menu-v2|s|1") in new stack
Jun 15 13:06:01 VERBOSE[30232]: -- Goto (menu-v2,s,1)
Jun 15 13:06:01 VERBOSE[30232]: -- Executing BackGround("Zap/1-1",
"firstintro") in new stack
Jun 15 13:06:01 VERBOSE[30232]: -- Playing 'firstintro' (language 'en')
Jun 15 13:06:05 VERBOSE[30232]: == CDR updated on Zap/1-1
Jun 15 13:06:05 VERBOSE[30232]: -- Executing Dial("Zap/1-1",
"zap/g1/1XX|20|tT") in new stack
Jun 15 13:06:05 VERBOSE[30232]: -- Called g1/1XX
Jun 15 13:06:08 VERBOSE[30232]: -- Zap/2-1 answered Zap/1-1
Jun 15 13:06:08 VERBOSE[30232]: -- Attempting native bridge of Zap/1-1
and Zap/2-1
Jun 15 13:06:31 VERBOSE[30232]: -- Hungup 'Zap/2-1'
Jun 15 13:06:31 VERBOSE[30232]: == Spawn extension (menu-v2, 4832, 1)
exited non-zero on 'Zap/1-1'
Jun 15 13:06:31 VERBOSE[30232]: -- Hungup 'Zap/1-1'
I've contacted our PRI provider, however, they say that they do not
see the call reach their system. To me, it would seem like the call is
coming into our Asterisk system through our Zap interface on one
channel, then attempting to leave the system through the Zap interface
on another channel, and is failing to do so. Is there some sort of
functionality I need to enable to facilitate this? (I'd rather wait
till later to address the "why" this worked before and is no longer
working)
On thing I'll add, I can see where this DID work through what appears
to be a SIP call -- although this would be a different situation as it
comes through via SIP then leaves via the Zap interface vs. the call
coming through Zap and then also leaving via Zap:
Jun 3 09:59:09 VERBOSE[21021]: -- Executing SetVar("SIP/4851-a8e0",
"oexten=4851-a8e0") in new stack
Jun 3 09:59:09 VERBOSE[21021]: -- Executing SetVar("SIP/4851-a8e0",
"extencid=4851") in new stack
Jun 3 09:59:09 VERBOSE[21021]: -- Executing SetCIDNum("SIP/4851-a8e0",
"4851") in new stack
Jun 3 09:59:09 VERBOSE[21021]: -- Executing Goto("SIP/4851-a8e0",
"extensions|4832|1") in new stack
Jun 3 09:59:09 VERBOSE[21021]: -- Goto (extensions,4832,1)
Jun 3 09:59:09 VERBOSE[21021]: -- Executing Dial("SIP/4851-a8e0",
"zap/g1/1XX|20|tT") in new stack
Jun 3 09:59:09 VERBOSE[21021]: -- Called g1/1XX
Jun 3 09:59:12 VERBOSE[21021]: -- Zap/1-1 is ringing
Jun 3 09:59:12 VERBOSE[21021]: -- Zap/1-1 is ringing
Jun 3 09:59:18 VERBOSE[21021]: -- Zap/1-1 is ringing
Jun 3 09:59:23 VERBOSE[21021]: -- Zap/1-1 answered SIP/4851-a8e0
Jun 3 10:01:36 VERBOSE[21021]: -- Hungup 'Zap/1-1'
Jun 3 10:01:36 VERBOSE[21021]: == Spawn extension (extensions, 4832,
1) exited non-zero on 'SIP/4851-a8e0'
I'm not sure that the above is relevant, but thought I'd throw it out there.
--
_
-- 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
