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