[Spce-user] actual device that initiated BYE?

Jon Bonilla (Manwe) jbonilla at sipwise.com
Thu Aug 16 03:11:53 EDT 2012

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

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

> 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.

More information about the Spce-user mailing list