How To Get The Original SIP Result Code

Home » Asterisk Users » How To Get The Original SIP Result Code
Asterisk Users 4 Comments

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 trying to dial and failed and the original Originate request, because OriginateResponse is issued only after the failed channel was hang up. Only successful OriginateResponse will contain the unique id of the established channel.

Is there any way that my AMI application can get the original SIP response of the failed Originate action?

I’m using Asterisk 1.8.22 and slightly tweaked asterisk-java (
https://blogs.reucon.com/asterisk-java/) 1.0.0.

4 thoughts on - How To Get The Original SIP Result Code

  • You could dial a local channel instead and have that then go on and dial the destination. You will then be able to retrieve the sip response using something like :-

    [localdial]
    exten => _X.,1,Set(ddi=${CUT(EXTEN,,1)})
    exten => _X.,n,Set(carrier=${CUT(EXTEN,,2)})
    exten => _X.,n,Set(dialtime=${EPOCH})
    exten => _X.,n,Set(_MASTERCHANNEL=${CHANNEL})
    exten => _X.,n,Dial(SIP/${ddi}@${carrier})
    exten =>
    _X.,n,Set(SIPcause=${MASTER_CHANNEL(HASH(SIP_CAUSE,${CDR(dstchannel)}))}, Responsetime=$[${EPOCH}-${dialtime}])
    exten => _X.,n,Set(SIPcode=${CUT(SIPcause,” “,2)})

    However you will need to set “storesipcause=yes” in your sip.conf for this to work. It is known to have a performance hit.

    A better way would be to upgrade Asterisk and use hangup handlers. The documentation on how to do this in Asterisk 11 is poor and often wrong. I have written a blog about how we set it up as we use the feature all the time. http://gblades.blogspot.co.uk/2013/07/how-to-get-sip-response-code-in.html

  • B.H.

    Thanks for your response

    calls to a SIP trunk (using asterisk-java library to connect to AMI). 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 trying to dial and failed and the original Originate request, because OriginateResponse is issued only after the failed channel was hang up. Only successful OriginateResponse will contain the unique id of the established channel. response of the failed Originate action?
    https://blogs.reucon.com/asterisk-java/) 1.0.0. the destination. You will then be able to retrieve the sip response using something like :-
    _X.,n,Set(SIPcause=${MASTER_CHANNEL(HASH(SIP_CAUSE,${CDR(dstchannel)}))}, Responsetime=$[${EPOCH}-${dialtime}])
    this to work. It is known to have a performance hit.

    In my experience with local channels, they cause a huge performance problems, even without sipstorecause. We are dialing on about 100 channels in parallel and looks like this will kill my CPU 🙂

    documentation on how to do this in Asterisk 11 is poor and often wrong. I
    have written a blog about how we set it up as we use the feature all the time.

    This looks really promising… Thank you very much. Just I hope upgrading to 11 wouldn’t break something in our setup.

    There’s still a problem with how to link a failed dialout channel with a specific originate action from AMI, but I think I can pass the originate action id as a channel variable and then return it back to my app using AGI
    from the hungup handler.

    Thanks for the help!

  • Really?
    We had Asterisk 1.8 with this setup and pushed 250+ concurrent calls through it and it coped quite well. All these used local channels for dialling.

    Our new systems are Asterisk 11 with no Dahdi. Quad “Intel(R) Xeon(R)
    CPU E5-1410 0 @ 2.80GHz” and reached about 40% cpu with 300+ concurrent calls.

    The new systems are a complete reinstall (OS upgrade with alter kernel to take advantage of res_timerfd) but like previous versions they still suffer from a gradual rise in load average. Every month or so we need to restart asterisk to bring the load average down. No idea what the cause is but its an automated process now so has no impact.