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