[Spce-user] actual device that initiated BYE?

[Jon Bonilla (Manwe)]

El Wed, 15 Aug 2012 16:24:54 +0200
Matthew Ogden <matthew at tenacit.net> escribió:

> (By the way, its rather scary.... Asterisk is surely one of the most common
> onsite PBX's out there? That is interoperability is so bad.
> But I assume it only has the issue when dealing with things like Sipwise,
> Freeswitch and so forth which are all SEMS/Kamalio

No. I've been working with asterisk for years now. It's a mess. If you
check for "regression" in the asterisk changelog during the last years you'll
realize that. With the change of release introduced in 1.6 it became even
worse. 

It's still a godd pbx solution if you know what version use and what features
you need.

> 
> I just want to confirm with both of you... so if session-timers: refuse in
> asterisk's sip.conf this issue wont happen? Is there a downside to having
> set it though?
> 

Confirmed. If you disable session timers in sip.conf (option refuse) this won't
happen.

> As it turns out this embedded asterisk, on the MyPBX very latest firmware
> does allow setting it (yay)!
> 
> I've tested from more than one type of phone on the asterisk server (in case
> this affects it - I'm not sure who the actual end point is in the
> concersation thats sending the updates), and the calls seem to go past 12.5
> minutes.

There are different scenarios and not always the same scenario produces the
same result when we talk about asterisk session timer issues. I spent hours
testing it for a PRO customer until I had to report to Digium. Their response
so far is none. As I said it's broken long ago and seems not to be a priority
for them. 

> 
> It would be nice if the CDR gave the RTP statistics, and the termination
> reason (B2BUA detecting time out, or destination/caller sending BYE etc).
> 

Providing rtp/rtcp information is in the roadmap actually but requires a deep
change in the rtpproxy protocol. 


> Its seems complicated to dig through the logs for something trivial, I'm not
> even sure other than reviewing the SIP dialog to tell who caused the
> disconnect, other than making the assumption it was because the call
> reINVITE didn't come through. I realise Homer makes this simpler than me
> using tshark pcap files, but I haven't got round to installing it yet.
> 

ngrep for live and homer or the voisniff PRO module for tracking the calls are a
good help, yes.