[Spce-user] 2 asterisk subscribers - subscriber sst setting ignored?
matthew at tenacit.net
Fri Oct 11 08:54:52 EDT 2013
Also, I find quite interesting…
Asterisk when receiving a 420, ends the call without sending a bye, and
logs a -- Got SIP response 420 "Option Disabled" back from x.x.x.x
But SPCE still thinks the call is going. I have no RTP audio from one side
now. My rtp_timeout = 60, and rtp_timeout_onhold = 3600.
The caller is still on the dead line now for 10 minutes. What registers
that the call was on hold? Because I the call was on hold at a point, but
is no longer. (Seems like it doesn’t unset this).
I’m busy testing if I never put the call on hold, if the rtp_timeout
works at 60sec. Perhaps I’m mistaken and the rtp_timeout requires both ends to
send no rtp?
*From:* Matthew Ogden [mailto:matthew at tenacit.net]
*Sent:* 11 October 2013 02:36 PM
*To:* spce-user at lists.sipwise.com
*Subject:* 2 asterisk subscribers - subscriber sst setting ignored?
I have two asterisk subscribers, and SPCE sitting in the middle. My domain
is setup to ignore SST by default and rely on SEMS to dead call detection.
The caller asterisk configuration itself has SST set to refuse. The called
party doesn’t have this set to Accept.
Then the caller calls the callee, its passing the “supported: replaces,
timer” in the INVITE to the callee. The callee asterisk box, picks this up,
an in its 200 OK, says “require: timer”. All goes well for 15 minutes, and
then the calls ends, because the callee, does a REINVITE, the REINVITE goes
through to the caller, and the caller says “420 Option Disabled”.
1) If SST is disabled, why is it passing “supported: replaces, timer”
to the callee?
2) Why is the callee reinvite being passed to the caller? (Surely the
reinvite is only for its leg of the call?)
I can disable it on my callee, but I was wondering if 1 or 2 above is
actually a bug in SPCE as well that should be looked at?
If its SPCE or Homer teammembers I can give you the pcap, and any logs you
need if you want.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Spce-user