Hi,
with our softphone implementation based on Liblinphone we encounter a broken behavior of the RingCentral servers. For incoming calls between two SIP extensions, the 200OK message from the accepting side is not acknowledged with an ACK message by the server. In about half of the calls that show this behavior, the calling party additionally cannot hear the called party. The problem can be reproduced after a waiting period of about 1h without any phone activity of the extension. This means that calls that are started/received directly after such a faulty call from/by the same extensions do not show this problem.
We have already excluded blocking of the SIP ACK message due to firewalls or NAT. SIP registrations are valid on both sides.
The message log from the called SIP phone:
RECEIVE:
INVITE sip:XXXX@192.168.178.108:20072;transport=udp SIP/2.0
Via: SIP/2.0/UDP 199.255.120.178:5090;branch=z9hG4bK48qvp220508qnod1lev0.1
Max-Forwards: 68
User-Agent: RC_SIPWRP_22.109
From: "XXX <sip:XXX@199.255.120.178>;tag=10.48.22.109-5070-4619d6d2-fce6-40bc
To: "XXX" <sip:XXXXX@87.79.77.183>
Contact: <sip:XXX@199.255.120.178:5090;transport=udp>
Call-ID: 7e989c36-a7ea-4638-a28a-f8c2162412b8
CSeq: 2999 INVITE
Call-Info: <odl9YjacY->;purpose=info
Allow: SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE, INFO
Supported: replaces, timer, diversion
Session-Expires: 14400;refresher=uac
Min-SE: 90
Content-Type: application/sdp
Content-Length: 553
P-Acme-VSA: 200:odl9YjacY-
v=0
o=- 6391771367963542640 7306023105286590707 IN IP4 199.255.120.178
s=SmcSip
c=IN IP4 199.255.120.178
t=0 0
m=audio 22960 RTP/AVP 9 0 18 96 8 109 111 101
a=rtpmap:9 g722/8000
a=rtpmap:0 pcmu/8000
a=rtpmap:18 g729/8000
a=fmtp:18 annexb=no
a=rtpmap:96 ilbc/8000
a=fmtp:96 mode=20
a=rtpmap:8 pcma/8000
a=rtpmap:109 OPUS/16000
a=fmtp:109 useinbandfec=1;usedtx=0
a=rtcp-fb:109 ccm tmmbr
a=rtpmap:111 OPUS/48000/2
a=fmtp:111 useinbandfec=1;usedtx=0
a=rtcp-fb:111 ccm tmmbr
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
SEND:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 199.255.120.178:5090;branch=z9hG4bK48qvp220508qnod1lev0.1
From: "XXX" <sip:XXX@199.255.120.178>;tag=10.48.22.109-5070-4619d6d2-fce6-40bc
To: "XXXX" <sip:XXXXXXXXXXX@87.79.77.183>
Call-ID: 7e989c36-a7ea-4638-a28a-f8c2162412b8
CSeq: 2999 INVITE
SEND:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 199.255.120.178:5090;branch=z9hG4bK48qvp220508qnod1lev0.1
From: "XXX" <sip:XXX@199.255.120.178>;tag=10.48.22.109-5070-4619d6d2-fce6-40bc
To: "XXX" <sip:XXXXXXXXXX@87.79.77.183>;tag=rxjWnWa
Call-ID: 7e989c36-a7ea-4638-a28a-f8c2162412b8
CSeq: 2999 INVITE
User-Agent: Linphone (belle-sip/4.5.0)
Supported: replaces, outbound, gruu
SEND:
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 199.255.120.178:5090;branch=z9hG4bK48qvp220508qnod1lev0.1
From: "XX" <sip:XXX@199.255.120.178>;tag=10.48.22.109-5070-4619d6d2-fce6-40bc
To: "XXX" <sip:XXXXXXXXXX@87.79.77.183>;tag=rxjWnWa
Call-ID: 7e989c36-a7ea-4638-a28a-f8c2162412b8
CSeq: 2999 INVITE
User-Agent: Linphone (belle-sip/4.5.0)
Supported: replaces, outbound, gruu
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, PRACK, UPDATE
Contact: <sip:XXXXXXXXXXX@sip.ringcentral.com;gr=urn:uuid:af78c4ce-4237-0090-9ebe-189ef3481755>
Content-Type: application/sdp
Content-Length: 212
v=0
o=XXXXXXXXXX 188 1821 IN IP4 192.168.178.108
s=Talk
c=IN IP4 192.168.178.108
t=0 0
m=audio 17200 RTP/AVP 9 0 8 101
a=rtpmap:101 telephone-event/8000
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* ccm tmmbr
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 199.255.120.178:5090;branch=z9hG4bK48qvp220508qnod1lev0.1
From: "XXX" <sip:XXX@199.255.120.178>;tag=10.48.22.109-5070-4619d6d2-fce6-40bc
To: "XXX" <sip:XXXXXXXXXXX@87.79.77.183>;tag=rxjWnWa
Call-ID: 7e989c36-a7ea-4638-a28a-f8c2162412b8
CSeq: 2999 INVITE
User-Agent: Linphone (belle-sip/4.5.0)
Supported: replaces, outbound, gruu
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, PRACK, UPDATE
Contact: <sip:XXXXXXXXXXXX@sip.ringcentral.com;gr=urn:uuid:af78c4ce-4237-0090-9ebe-189ef3481755>
Content-Type: application/sdp
Content-Length: 212
REPEATED 200OK
REPEATED 200OK
REPEATED 200OK
...
SEND:
BYE sip:XXX@199.255.120.178:5090;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.178.108:20072;branch=z9hG4bK.CjzU0Ir45;rport
From: "XXX" <sip:XXXXXXXXX@87.79.77.183>;tag=rxjWnWa
To: "XXX" <sip:XXX@199.255.120.178>;tag=10.48.22.109-5070-4619d6d2-fce6-40bc
CSeq: 111 BYE
Call-ID: 7e989c36-a7ea-4638-a28a-f8c2162412b8
Max-Forwards: 70
RECEIVED:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.178.108:20072;branch=z9hG4bK.CjzU0Ir45;rport=20072
From: "XXX" <sip:XXXXXXXX@87.79.77.183>;tag=rxjWnWa
To: "XXX" <sip:XXX@199.255.120.178>;tag=10.48.22.109-5070-4619d6d2-fce6-40bc
CSeq: 111 BYE
Call-ID: 7e989c36-a7ea-4638-a28a-f8c2162412b8
User-Agent: RC_SIPWRP_22.109
Content-Length: 0
The final SIP BYE is then confirmed again by the server.
We see this behavior on the sip30 and sip40 RC servers. Special SIP servers known to us (sip22xxxx.ringcentral.com) do not show this behavior.
Any idea what is causing this issue with the official RC servers?
Thanks