[asterisk-biz] Remote SIP monitor

Olle E. Johansson oej at edvina.net
Wed Jan 6 08:38:22 CST 2010


6 jan 2010 kl. 15.30 skrev Jared Smith:

> On Wed, 2010-01-06 at 09:45 +0100, Olle E. Johansson wrote:
>> I'm adding manager events and storing data in a realtime database -
>> one record per call leg. What I'm wondering is how we should handle
>> call transfers and hold situations. A call that's transferred has
>> multiple streams and RTCP is only valid for one stream.
> 
> Would it make more sense to expose the RTCP information as part of the
> CEL (Call Event Logging) infrastructure?  That way, you could tell what
> events in the call may have triggered the additional streams.  In a
> perfect world, we might even have something like:
> 
> Event: Incoming call from Alice
> Event: Outgoing call to Bob
> Event: Asterisk bridges Alice to Bob
> Event: RTCP report 
> Event: RTCP report
> Event: RTCP report
> Event: Alice places Bob on hold
> Event: RTCP report (new stream, Bob hears hold music from Asterisk)
> Event: Unhold
> Event: RTPC report (Alice and Bob, again)
> Event: Bob transfers Alice to Charlie
> Event: RTCP report (new stream, Alice and Charlie)
> Event: Hangup
> 
> Obviously that's an oversimplified example, but I really think it makes
> more sense to put the RTCP reports in the CEL logs, rather than having
> another arbitrary log for the data.  Maybe we should move this
> discussion to the -dev list to discuss the more technical details?
Well, since I'm paid to fix 1.4, CEL is out of the question at this point. When I move the code forward to trunk, CEL may be the proper way, depending on how people will work with CEL. The issue is that we get the final RTCP reports after or in close relationship to hangup.The CDR system can't handle that, and I don't know if CEL has improved this functionality.

I'm right now considering the Shakespearian question "what is a stream?". RTCP has a stream identifier and when we end a stream, we should send an RTCP goodbye. Now, when we place a stream on hold, it's not ending a stream really. In Asterisk, we're stopping both rtp and rtcp when placed on hold, which is a bug. When we transfer, it's a new stream coming up. Interesting...

> 
> Anyhoo, just wanted to add my own two cents (US cents, before interest,
> taxes, depreciation, and amortization)
Always appreciated! 
You know my paypal - oej at edvina.net :-)

/O


More information about the asterisk-biz mailing list