[asterisk-dev] [Code Review]: Add replacement for SIP_CAUSE

[Kevin Fleming]

> On March 22, 2012, 3:01 p.m., Kevin Fleming wrote:
> > Would anyone object to calling this DIAL_CAUSE? PVT_CAUSE isn't really very user friendly at all. I understand that this could end up being set via other means than Dial(), but DIAL_CAUSE seems closer to what an end-user would expect it to be named.
> 
> wdoekes wrote:
>     Wouldn't that be DIAL_RESULT then? DIAL_CAUSE makes it sound like it's something completely different from HANGUPCAUSE, while it is just a different representation.
> 
> opticron wrote:
>     I'm going to hold off on changing the name until a decision is reached, but I do agree that PVT_CAUSE should not be the final name for this.

OK, at the risk of possibly setting a bad precedent here...

Channel variable names and channel associative array names (managed with the HASH() function and related functions) are actually separate namespaces. Given that, would anyone be opposed to just calling this HASH(HANGUPCAUSE), since it conceptually is the same information as the HANGUPCAUSE variable, but split out by outbound channel?


- Kevin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1822/#review5862
-----------------------------------------------------------


On March 23, 2012, 10 a.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1822/
> -----------------------------------------------------------
> 
> (Updated March 23, 2012, 10 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Add PVT_CAUSE as a drop-in replacement for SIP_CAUSE that does not incur the overhead of the MASTER_CHANNEL dialplan function.  This feature uses control frames to pass the data and creates a mechanism by which any channel driver can report cause information.  This implementation includes only SIP, but implementations for other channel drivers will be available in the next month.
> 
> 
> This addresses bug SWP-4221.
>     https://issues.asterisk.org/jira/browse/SWP-4221
> 
> 
> Diffs
> -----
> 
>   trunk/funcs/func_frame_trace.c 360259 
>   trunk/include/asterisk/frame.h 360259 
>   trunk/main/channel.c 360259 
>   trunk/main/dial.c 360259 
>   trunk/main/features.c 360259 
>   trunk/main/file.c 360259 
>   trunk/main/rtp_engine.c 360259 
>   trunk/CHANGES 360259 
>   trunk/UPGRADE.txt 360259 
>   trunk/apps/app_dial.c 360259 
>   trunk/apps/app_followme.c 360259 
>   trunk/apps/app_queue.c 360259 
>   trunk/channels/chan_sip.c 360259 
> 
> Diff: https://reviewboard.asterisk.org/r/1822/diff
> 
> 
> Testing
> -------
> 
> Verified that this functions identically to SIP_CAUSE in single-channel dials, forked dials, and forked dials behind a local dial.
> 
> Sample dialplan:
> [foo]
> exten => s,1,Dial(SIP/bar)
>  
> exten => h,1,noop()
> exten => h,n,set(PVT_CAUSE_STRING=${HASHKEYS(PVT_CAUSE)})
> ; start loop
> exten => h,n(pvt_begin),noop()
>  
> ; check exit condition (no more array to check)
> exten => h,n,gotoif($[${LEN(${PVT_CAUSE_STRING})} = 0]?pvt_exit)
>  
> ; pull the next item
> exten => h,n,set(ARRAY(item)=${PVT_CAUSE_STRING})
> exten => h,n,set(PVT_CAUSE_STRING=${PVT_CAUSE_STRING:${LEN(${item})}})
>  
> ; display the channel ID and cause code
> exten => h,n,noop(got channel ID ${item} with pvt cause ${HASH(PVT_CAUSE,${item})})
>  
> ; check exit condition (no more array to check)
> exten => h,n,gotoif($[${LEN(${PVT_CAUSE_STRING})} = 0]?pvt_exit)
>  
> ; we still have entries to process, so strip the leading comma
> exten => h,n,set(PVT_CAUSE_STRING=${PVT_CAUSE_STRING:1})
> ; go back to the beginning of the loop
> exten => h,n,goto(pvt_begin)
> exten => h,n(pvt_exit),noop(All PVT_CAUSE entries processed)
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120323/66f05b8b/attachment-0001.htm>