use asterisk 16.30.1 ,and config as a sip proxy.
here is the call process. callin from 103.17---->68.49–>68.56.
pic1 is the call in ,
pic1:
pic2 is answer:
pic2:
my question is 68.56 sent 2 invite every 15mins to 68.49, why 68.49 did not sent invite to 103.17?
that’s why 103.17 sent bye after 30mins
I suggest you read up on session timers.
here the pjsip setting…
timers : yes
timers_min_se : 90
timers_sess_expires : 3600
You can’t tell what the other side has negotiated, as you have only provided a summary log, not the full “psjsip set logger on” log.
export_0000798a00006718-0005-0050@10.23.7.10 (1).txt (21.2 KB)
here is the full log.please help.thx.
You are using a well past end of life version of Asterisk, and a variant of that which is only supported when used in the context of formal support contract. You need to upgrade to Asterisk 18.19.0 or 20.4.0, or wait a few days and go to Asterisk 21. Do not use certified versions unless you have a support contract with Sangoma.
Actually this seems to be vCloud, so may your provider?
I’m more familiar with reading logs from Asterisk, rather than the packet capture system.
The session time I’ve seen, so far, is 30 minutes, not 60. There are successful session timer refreshes 15 an 25 minutes into the call.
The Huawei initiates the shutdown, on the incoming leg, which causes another Re-INVITE, to remove the direct media. Again successful. The Huawei’s reason for shutting down the call is given as SBC-4416, which is a proprietary code for that device, and for which I can’t find a definition from a web search.
Your system then shuts down the outgoing leg.
no，i use asterisk 16.30.1,
the 68.49use asterisk 16.30.1，that’s the main pbx connect to
16.30.1 is 4 days beyond end of life. The ancient ones identifies itself as vCloud. I assume the 16.30.1 one is call123
There are no session timers on the incoming leg, and the call is dropped at more like 32 minutes than 30.
yes, that’s correct.
but the vloud refreshes 15 and 25 minutes into the call,why call123 not sent refreshes to 103.17(huawei side)? that’s the point. the huawei side said need to sent update or invite message at least 30 minutes.if there is no mesage,they think the call is no longer exist. and will drop the call.
Because it hasn’t asked for them. Session timer refreshes are strictly per leg.
Forget session timers. That is not what is causing the Huawei to drop the call. Unfortunately the only reference I could find to SBC-4611 was in Chinese, and it appears to be in an image, so Google translate can’t translate that part of the web site. With time, and a dictionary, or possibly pointing a mobile phone at the image, I could probably translate it, but there are too unfamiliar characters for me to read it without spending too much time.
I ASKED the Huawei side,they said if call123 sent invite or update sip/sdp ,the call will not drop.
The Huawei has not said that it supports session refreshes, let alone that it requires them, so it can’t expect them to be used:
Supported: 100rel
That’s why Asterisk has not tried to use them. I suppose you could configure Asterisk to require them, but subject to my refreshing my knowledge on how they operate, might mean the call fails during setup, because they are claiming no support.
I HAVE A question:
68.56 sent invite every 15mins to call123(49) ,
why call123(68.49) by pass sent the invite to huawei(103.17)?
Because it is a session refresh request, and also because Asterisk is a back to back user agent. Asterisk does not forward INVITEs, it turns them into internal messages, such as new calls or media destination changes, which, if the other party is SIP may then result in INVITEs. Session refreshes are only relevant to the single session so they have no effect across the Asterisk back bone.
any further advise?David551?
don’t understand.
if there anything i can change in my pjsip.conf?
or is there a way send updte/invite every 10mins ,to check weather this can fix the problem.?
The Huawei is not interested in session refreshes, so it can’t complain if it doesn’t get them.##
