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