Hello Alex,
it seems that we should wipe the session timers headers before the
INVITE is passed to the other side. Could you please file a report on
bugtracker.iptel.org?
Cheers
Raphael.
On 07.10.10 22:40, Alex Balashov wrote:
Greetings,
I am very impressed with the new sst_b2b implementation and all the
reworking that went into it; it is very slick! Thank you, and kudos
for a very clean implementation.
I have, however, run into one particular behaviour on the part of
sst_b2b that I am having trouble understanding. The scenario is an
INVITE flow like this:
GW A ---> SEMS (sst_b2b) ---> GW B
GW A is an origination provider UA that does not support 'timer' at
all. There is no 'Supported: timer' in the incoming INVITE from GW A.
GW B is a version of Asterisk 1.6.2.x (1.6.2.10 I believe) that
exhibits this bug:
https://issues.asterisk.org/view.php?id=17005
Long story short, Asterisk <= 1.6.2.12 has broken timer support in
such a way that upon receipt and establishment of a dialog from an
INVITE with Supported: timer + Session-Expires/Min-SE headers, the
subsequent re-invites that asterisk sends (it chooses role
refresher=uas) to SEMS contain 'Require: timer'. This is actually
kind of funny, because the Asterisk documentation on the subject
explicitly says that Asterisk will never 'Require' timer in the
interest of wider interop compatibility.
Anyway, since SEMS supports timers, I would expect that SEMS would
reply to such a reinvite with a 200 OK; SEMS supports timer, Asterisk
requires it, so everyone should be happy.
What we are seeing instead is that SEMS passes this reinvite from GW B
up to GW A in more or less unadulterated form, on the other call leg.
We know it's passing the reinvite from leg B up because the
User-Agent says 'Asterisk PBX 1.6.2.10'. GW A does not support timer,
so it promptly rejects the reinvite with 420 Bad Extension.
What is the explanation for this? Am I missing something about how
the RFC 4028 ping-pong is supposed to work in the scenario where the
UAS is the refresher?
Thank you!
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
