similar to: Sip cause and response codes in dialplan

Hello, I have a broblem in asterisk 15 where an ami originate suddenly converts 58#+46435345534 to 58%23+46435345534. This happenend when upgrading asterisk 1.8 to 15. Could anyone help me with how to resolve this issue? Regards / Marcus [Beskrivning: Fogwise - logotype] Marcus Kvarsell phone: +46766350384 e-mail: marcus at fogwise.se url: http://www.fogwise.se Like us on facebook:

Hello, I read on the wiki : Asterisk 1.8 will allow to read SIP response codes in the dialplan via *${HASH(SIP_CAUSE,<channel-name>)}*. Additionally make sure you're using the destination channel, not the source channel. But when I use this in my dialplan, this 'variable' is empty. Dialplan : exten => h,n,NoOp(sip cause = ${HASH(SIP_CAUSE,${CHANNEL})}) exten =>

Thanks for you answer Marcus, So maybe this means some bug was fixed? Anyone aware of something related? >From the release notes, I couldn't find any direct change that could fix this.... Thanks, Kind regards, Patrick Wakano On 21 February 2018 at 20:29, Marcus Kvarsell <Marcus.Kvarsell at fogwise.se> wrote: > Hello, i found upgrading to asterisk 15 helped. > > > >

B.H. Hello, i'm using AMI Originate action (with async=true) to send outgoing calls to a SIP trunk (using asterisk-java library to connect to AMI). The problem is that in case of failed originate, OriginateResponse event is returning only the reason code which is sometimes not sufficient to determine the real cause of failure. Also, there's no way to link between the channel that was

Hello Everyone. In my outbound contexts, I'm using "${DIALSTATUS}" to fail over to other routes if the chosen route rejects the call. Now, My current scenario is if I get "BUSY" back from the first provider, I send a busy back to my customer. If I get something like CHANUNAVAIL (Like a SIP 503) I advance to the next carrier and attempt the call. This works

Hi All, Is there a way to change the mappings of disconnect reasons to certain SIP messages? E.G. I need to change the mapping for SIP 402 ?Payment Required? from 16 (normal termination) like it is in 1.4.24 to 21 (call rejected) as defined in RFC 3398. For me this is a big issue because my dial plan will look for alternative termination in the event of network error (e.g. reason 3 or 21 which is

Hi. I'm dialling two numbers - one that's unobtainable, one that's busy. ${DIALSTATUS} is coming back ANSWER each time right before the channels hang up. Am using the following dialplan macro to dial out. [macro-advdial] exten => s,1,Dial(${ARG1},20,g) ; Ring the interface, 20 seconds maximum exten => s,2,Goto(s-${DIALSTATUS},1) ; Jump based on status

Hello Asterisk list, I am facing some Asterisk crashes which are consistently pointing to the same backtrace, which is the following (using DONT_OPTIMIZE, BETTER_BACKTRACES and MALLOC_DEBUG): Thread 1 (Thread 0x7f1f08be8700 (LWP 1767)): #0 0x00007f1f9bed3395 in __strcasecmp_l_sse42 () from /lib64/libc.so.6 #1 0x00000000004a91ca in cdr_object_get_by_name_cb () #2 0x0000000000463c60 in

Hello, I'm trying to figure out what was the return code of SIP for a call. The problem is that HASH(SIP_CAUSE) require a peer name, but when I try to retrieve the peer name using ${CHANNEL(peername)}, I have an error message that CHANNEL does not have peername or it is not available to be used. I tried to print it with NOOP on a live channel, and also after hangup, both with the same error

Greetings, Recently a performance regression in chan_sip was discovered in Asterisk 1.8. The regression is caused by chan_sip setting MASTER_CHANNEL(HASH(SIP_CAUSE,<chan name>)) after each response received on a channel. That feature has been made optional in the latest 1.8 SVN code, but is currently still enabled by default. After some internal discussion, we decided to consider disabling

Hi! Anybody familiar with streaming rtp from asterisk. Preferably with the xorcom asterisk patch which streams rtp from asterisk to oreka audio server. Any ideas will do just fine though! Regards / Marcus

Hello, I have asterisk 1.6.0.20 and Is it possible to add Reason header on Hangup: Reason: q.850;cause=17 Thanks -- Best Regards, Giedrius -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100221/d29c02b8/attachment.htm

It is in the To: Header. -----Ursprungligt meddelande----- Fr?n: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] F?r Joshua Colp Skickat: den 19 februari 2018 11:58 Till: asterisk-users at lists.digium.com ?mne: Re: [asterisk-users] # converts to %23 On Mon, Feb 19, 2018, at 4:24 AM, Marcus Kvarsell wrote: > Hello, > > I have a broblem in

I need to access number received after a I dial a SIP or H323 call? suppose I get one of these: *404 Not found **486 Busy here **408 Request Timeout **480 Temporarily unavailable **480 Temporarily unavailable **403 Forbidden (+) ** 410 Gone **301 Moved Permanently **410 Gone ** 404 Not Found (=) **502 Bad Gateway **484 Address incomplete* How do I get the 404, 486, etc. F.A. -------------- next

I've not seen an answer to this in any forum. I make a call through Asterisk, with a VOIP phone, doesn't matter which. The call gets made, I leave a voicemail, or complete the call in some manner, and the other side hangs up. I hear a busy signal on the phone on my end. If I have an extension that looks like this, after the hangup() is executed, my phone gives busy signals until I

I think HANGUPCAUSE is channel agnostic. See: core show function HANGUPCAUSE Some thing like this IIRC: Set(my_cause=${HANGUPCAUSE(${CHANNEL(name)},tech)}) Remember the incoming leg of the call and the outgoing leg of the call are different channels. Make sure you are giving HANGUPCAUSE the correct channel. On 06/09/2018 02:01 PM, Khalil Khamlichi wrote: > It seems very weird to me

This was always possible in the past, however does not work in the current release. I believe this is a bug. To: asterisk-users at lists.digium.com From: cervajs at fpf.slu.cz Date: Fri, 9 Oct 2015 10:04:47 +0200 Subject: Re: [asterisk-users] Storing HANGUPCAUSE in CDR search in archives save the records to another table like cdr_extended Dne

Hello, On an Asterisk 1.4.33.1 in a simple scenario: [test] exten => _X.,1,Dial(SIP/12345 at peer01,,,) exten => i,1,Hangup(${HANGUPCAUSE}) exten => t,1,Hangup(${HANGUPCAUSE}) exten => h,1,Hangup(${HANGUPCAUSE}) I have noticed that no matter what value we set in the Hangup(<cause code>) commands, if the call is not answered by peer01 for any reason, the actual cause code

Hello list, Hope all doing well! I've been checking some cases when a Dial fails and dialplan execution continues to handle this. I am finding it a little confusing how we should handle the DIALSTATUS and the HANGUPCAUSE in this situation.... More specifically, I am facing a case in version 13.6.0 where I am getting a DIALSTATUS=BUSY and HANGUPCAUSE=19 after receiving a 480 SIP error. Seems

Hi, I have the following code that operates when a channel is hung-up: [record-hangupcause]exten => 1,n,Set(CDR(hangupcause)=${HANGUPCAUSE})exten => s,n,Return() Before the dial a hangup handler is registered: Set(CHANNEL(hangup_handler_push)=record-hangupcause,s,1) The routine is called and the variables are being set, however not on the channel's CDR which made the call. I believe this