Set: timers_sess_expires to an appropriate value. It looks like timers=yes is on by default. Note the actual refresh happens before the expiry time. See the RFC for the detailed rules.
I set timers_sess_expires = 3600 in the [TG1-CTSIP1]
type = endpoint yesterday,it does not work.should i change 3600 to 600 ?
Assuming the Huawei doesn’t reject that value, and continues to deny any interest in session timers, and that session_timers is also on, it will cause Asterisk to send a session refresh re-INVITE, probably every 5 minutes, although up to every 10 minutes. Whether the Huawei will be affected by that is not something I can say.
I don’t understand why you would think using a longer than default value would improve things if you are assuming that the lack of refreshes is the problem.
The requirement is to refresh before the time limit is reached and the recommendation is to do so at the 50% point, but there is no absolute requirement on the second point.
just give a try on this,
cause don’t konow the sbc-4416 mean…
and the first invite give is :User-Agent: ZTE Softswitch/1.0.0
and another is HuaweiUgc3200
Any INVITE from Asterisk would have the “cal123…” user agent.
Not forwarding is expected behaviour for a back to back user agent, like Asterisk. As already explained, the two sides are independent sessions. Also, Asterisk is an ISDN PBX with SIP added on, so the internal structure is not SIP based.
ok,got it.
so you have any idea ,please give me a hint…
I working on it for two days,and have no processing…
Using SIPp, I simulated sending an INVITE request after 29 minutes into the call, and the call continued without disconnecting for one hour.
<?xml version="1.0" encoding="ISO-8859-1"?> <![CDATA[ INVITE sip:05118456677@172.22.103.21:5140 SIP/2.0 Via: SIP/2.0/UDP 172.21.21.21:5060 From: ;tag=9c920276-ba41-4296-915c-fbece9e33631 To: ;tag=0a17070a-000061e3000014cb Call-ID: 0000294100007c9c-0005-0050@10.23.7.10 CSeq: 1 INVITE Max-Forwards: 70 Content-Length: 0 ]]>Is there a way to send INVITE messages during call? @david551
It looks like you need to use the value always, rather than yes, if you want to do session refreshes when the other side claims not to support them. However, there may be a bug in this area, see:
I’m unlikely to investigate this any further, myself, and I get the impression that no bug report was ever raised. Also, Google still hasn’t caught up with recent mass URL rot in the documentation and the search feature in the documentation is not getting me to the page that documents all the res_pjsip settings, which means I can’t even get to a primary source for the “always” value.
1 Like
This is fixed in 16.28. You must use “always”. Note that it doesn’t work with some providers. The service provider has to support it.
2 Likes
changed timers=always in version 13.14.0， seams doesn’t work…
is that right?
13.14.0 predates the fix for “timers=always” by approximately 5 years.
so if want to use
> always
must use verser after 16.28?
The fix for “always” in the 16 series went in as of Asterisk 16.27.0. The fix does not exist in any version of Asterisk 13, as it went EOL before the fix was merged.
got it.Thx.
That is correct
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.