I’m using Asterisk 13.10.0 only for voicemail/missed call notifications in a residential setup. In my dialplan I’m trying to distinguish between a caller hanging up and another SIP peer picking up somewhere else. Ideally Asterisk should do nothing if a peer picks up and send a missed call notification anytime a caller hangs up before recording a voicemail. Asterisk answers the calls with a 15 second delay.
In the Asterisk CLI SIP debug I can see that my SIP trunk sends a 6xx or 5xx CANCEL response if a peer picked up and a 1xx CANCEL if the caller hung up. How do I read these SIP response codes before a Answer() or after the caller hung up?
I’ve tried the following functions/variables but they all seem to rely on an active channel and return nothing (storesipcause=yes is set in sip.conf):
same => n,Verbose(${HANGUPCAUSE})
same => n,Verbose(${HASH(SIP_CAUSE,${CHANNEL})})
same => n,Verbose(${HANGUPCAUSE(${CHANNEL},ast)})
same => n,Verbose(${HANGUPCAUSE(${CHANNEL},tech)})
Any help is greatly appreciated - Greetings from Switzerland,
The response codes are quite random the only distinction seems to be that hang ups are answered with 1xx and for peer pickups i’ve seen 5xx and 6xx so far.
EDIT: apparently the forum software automatically removed the “To”-sections - but these should not be important anyway.
There’s nothing fundamentally different between the CANCEL requests. When you say “1xx” and “5xx/6xx” to what are you referring? The CSeq? If so that’s a sequence number, not a response code.
Three digit codes are only sent from UAS to UAC. As I understand it you are the UAS, i.e. you received the invite.
In that case, if the call is answered elsewhere, you will receive a CANCEL request, not a status code. There is no requirement in the SIP protocol to provide a reason in a CANCEL request.
1xx cause codes are not final responses, even if we were talking about the reverse direction, so can never generate a hanugp.
OK - it was a weak distinction anyway. Apparently these are arbitrary and originate from the INVITE - at which point the server obviously can’t know what will happen next.
Do you know of a standartised way to distinguish the conditions?
Thanks to the both of you for these lightning fast replies. As an amateur user it seemed tempting to have Asterisk act as a peer rather than an interconnection point. This would allow me to use my SIP trunk providers notification feature as a fallback in case Asterisk suddenly failed and the incoming/outgoing calls would not be impacted. I’ll now change some settings with my trunk provider and will try to get a proper “Reason:”-Header with the CANCEL.