[asterisk-dev] [Code Review]: Call ID logging phase III part 1 - channel driver specific logging (SIP, IAX2, and DAHDI)

[jrose]

> On May 3, 2012, 9:21 a.m., Mark Michelson wrote:
> > /team/jrose/call_identifiers/channels/chan_iax2.c, line 2018
> > <https://reviewboard.asterisk.org/r/1886/diff/2/?file=27590#file27590line2018>
> >
> >     Get rid of the JON xxx on this comment.

Made ridden.


- jrose


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


On April 27, 2012, 1:42 p.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1886/
> -----------------------------------------------------------
> 
> (Updated April 27, 2012, 1:42 p.m.)
> 
> 
> Review request for Asterisk Developers, Mark Michelson, rmudgett, and Matt Jordan.
> 
> 
> Summary
> -------
> 
> https://wiki.asterisk.org/wiki/display/AST/Unique+Call-ID+Logging
> 
> The Unique Call ID logging patch progresses to its third phase.  In this patch, I'm concentrating on moving the concept from something that is purely in pbx threads to something that lives in the channels themselves as well.
> 
> Covered in this rendition are chan_sip, chan_dahdi, and chan_iax2.  DAHDI is somewhat unique in that it specifically targets the creation of new channels rather than through checking for new calls and requests.
> 
> 
> Diffs
> -----
> 
>   /team/jrose/call_identifiers/channels/chan_dahdi.c 363674 
>   /team/jrose/call_identifiers/channels/chan_iax2.c 363674 
>   /team/jrose/call_identifiers/channels/chan_sip.c 363674 
>   /team/jrose/call_identifiers/channels/sip/include/dialog.h 363674 
>   /team/jrose/call_identifiers/channels/sip/include/sip.h 363674 
>   /team/jrose/call_identifiers/include/asterisk/channel.h 363674 
>   /team/jrose/call_identifiers/include/asterisk/logger.h 363674 
>   /team/jrose/call_identifiers/main/channel.c 363674 
>   /team/jrose/call_identifiers/main/channel_internal_api.c 363674 
>   /team/jrose/call_identifiers/main/cli.c 363674 
>   /team/jrose/call_identifiers/main/logger.c 363674 
>   /team/jrose/call_identifiers/main/pbx.c 363674 
> 
> Diff: https://reviewboard.asterisk.org/r/1886/diff
> 
> 
> Testing
> -------
> 
> Testing has mostly involved the making of calls between various technologies and transferring. It'd be difficult to detail all of it, but some examples would include calls via dynamic pri spans in a loopback scenario, pots phones, SIP and IAX endpoints. So far most stuff is appearing about like expected.  That is to say:
> 
> 1. New calls get a callid an the channel sticks with it.  Log messages between the sandwiched binding and unbinding of callid logging get logged with the apporpriate callids.
> 2. Transfers go one of two ways. In the case of blind transfers, the original callid is usually preserved while attended transfers result in a new call (which means a new callid) and the new callid becomes dominant for the call.
> 3. There is an exception to the above rule with transferring of calls that weren't bridged between two endpoints (IE, a call to a menu or some other asterisk pbx extension without dial). In this case, the callid that started the pbx thread is the one that ends up being used.  Transferring these types of calls is a bit of a fringe case, but it's worth noting.
> 
> Any kind of bridging that involves a masqeurade is usually going to result in a new callid since fresh channels are being created for one end and/or another.
> 
> 
> Thanks,
> 
> jrose
> 
>

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