[Spce-user] actual device that initiated BYE?

[Matthew Ogden]

(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

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?

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.

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

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.

Kind Regards, and thank you for your help!






-----Original Message-----
From: Jon Bonilla (Manwe) [mailto:jbonilla at sipwise.com]
Sent: 15 August 2012 01:16 PM
To: Stefan Sayer
Cc: Matthew Ogden; spce-user at lists.sipwise.com
Subject: Re: [Spce-user] actual device that initiated BYE?

El Wed, 15 Aug 2012 10:43:23 +0200
Stefan Sayer <stefan.sayer at gmail.com> escribió:

>
> session refreshes (re-Invite, Update) are always better done
> end-to-end, as opposed to from the B2B in the middle, which is awkward
> anyway (e.g., while a refresh is in-flight, any Invite request from
> the end will be refused). Therefore SEMS tries to get out of the
> refresher role if possible.
>

>
> but I am sceptical that asterisk adds the correct refresher=uac to the
> response.
>

You have several scenarios in the issue I opened in asterisk bugtracker.
It's not about who negotiates to be refresher, Asterisk won't honour that in
any case. All the scenarios I tried are broken in different ways.

Neeed to retest some day and check what oej says in the ticket, but I'm
pretty sure it wouldn't solve anything as asterisk session timers are known
to be broken since 1.6.