Simultaneous Re-INVITE followed by UPDATE causes one-way audio

[zeusca]

Hi there,

Subj. Call between two Asterisks. Mid call, a change of RPID info happens, Asterisk sends two almost simultaneous (0.000087 seconds apart) in-dialog requests:

1. Re-INVITE with SDP and new RPID, Cseq 102, followed by
2. UPDATE, no SDP, just new RPID, Cseq 103)

Now, sometimes the other Asterisk appears to receive and process the UPDATE first and responds with sequentially:

1. 200 OK to the UPDATE, followed by
2. 500 Invalid CSeq to the re-INVITE

On other identical calls, the Re-INVITE appears to reach the other Asterisk before the UPDATE, so the call goes on just fine:

1. 200 OK to the re-INVITE, followed by
2. 200 OK to the UPDATE

Problem is that it’s unpredictable and when the bad flow happens, one-way audio occurs (callee asterisk stops sending media)

Question is: how to avoid this sequential re-INVITE/UPDATE for the sole purpose of RPID update, can UPDATE be disabled entirely?

Caller: Asterisk certified/13.21
Callee: Asterisk 11.6-cert11

Thanks!

[ambiorixg12]

On the documentation you have the following

Note also that while Asterisk currently will parse an Allow header to learn
; what methods an endpoint supports, the only actual use for this currently
; is for determining if Asterisk may send connected line UPDATE requests and
; MESSAGE requests. Its use may be expanded in the future.
;
; disallowed_methods = UPDATE

[zeusca]

Nice finding!

Is there a similar option in pjsip not to advertise UPDATE in Allow headers?

Also found that there is a rpid_update=no option per peer, which is probably more suitable in my case.

[zeusca]

Looks like having rpid_update=no on the peer has no effect, Asterisk keeps sending an UPDATE 1ms after the re-INVITE, occasionally triggering a 500 - Invalid Cseq from the other Asterisk. See below SIP trace graph.

Thus, the question stands: how to disable support for UPDATE method in PJSIP, either another workaround to this problem?

Thanks,