We have a customer using a VVX500, running FW 126.96.36.19927.
On some of his outbound calls, he receives duplicate ringback tones.
Checking the call traces, it seems to be when the gateway is returning a 180 Ringing response code to the phone, with SDP, the phone is incorrectly generating the local ringback tone, while also passing the remote ringback tone through.
On calls where the gateway returns a 183 Session Progress response code, with SDP, the remote ringback tone alone is passed through, correctly.
This appears to be a bug in the VVX/4.1.3 FW. In the release notes for 4.0.3F, I see:
79723 The phone now plays 183 early media and 180 local ringback independently one after the other.
Can you elaborate on this ticket, in case it's related?
Solved! Go to Solution.
from a SIP standard the 180 needs to prompt the phone to play ringback as a 183 sends the media from the gateway so we are behaving correctly and I would not class this as a bug.
I would check this with the gateway provider and or take this up with your reseller / Polycom support as your VVX500 is still within warranty for sure.
According to RFC 3261, a 180 can include SDP, and doesn't necessarily require the local device to generate the ring back tone.
The UA receiving the INVITE is trying to alert the user. This response MAY be used to initiate local ringback.
So the 180 is always causing the phone to generate the local ringback, which is not what the RFC specifies, only that it MAY.
Only when there is no SDP is the local device supposed to generate the ring back tone, and in this case, there is SDP, so the phone is incorrectly generating the ring back.
The 180 packet that is being passed to the phone:
@2013-07-16_14:01:06 Received Packet from [removed]:5060 SIP/2.0 180 Ringing Via: SIP/2.0/UDP [removed]:5060;branch=z9hG4bKQEzvx2VuqBnVffJf1FCCC6 To: <sip:[removed]@[removed]>;tag=3582986465-147482 From: "[removed]" <sip:[removed]@[removed]>;tag=QEzvx2VuqBnVffJf1FCCC6 Call-ID: 20130716180103000224-09102af958e2e70d014c9e7765f3f0f9 CSeq: 201 INVITE Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH Contact: <sip:[removed]@[removed]:5060> Call-Info: <sip:[removed]>;method="NOTIFY;Event=telephone-event;Duration=1000" Content-Type: application/sdp Content-Length: 481 v=0 o=jrr-msw-02 272430080 1373997665 IN IP4 [removed] s=sip call c=IN IP4 [removed] t=0 0 m=audio 34392 RTP/AVP 18 0 127 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=cdsc:1 image udptl T38 a=rtpmap:127 telephone-event/8000 a=fmtp:127 0-15 a=silenceSupp:off - - - - a=ptime:20 a=maxptime:40 m=video 34394 RTP/AVP 109 34 a=rtpmap:109 H264/90000 a=fmtp:109 profile-level-id=42800d a=rtpmap:34 H263/90000 a=fmtp:34 CIF=1;QCIF=1;SQCIF=1
So I do feel this is a bug in the VVX firmware, since it's incorrectly implementing the RFC.
a MAY is not a MUST not.
The RFC is open to interpretation and without seeing logs and a wireshark trace (which is outside the scope of the community for myself) you should follow up as advised.
please ignore above.
Whilst the RFC is open to interpretation I checked internally and believe you are correct at this point.
Please raise a ticket with support and quote VOIP-87180 and this post.
Please ensure in the future to additionally post the whole software number like 4.1.3.xxxx or similar so in the future other users can compare what software they are running.
I went and checked on the site, and discovered that 188.8.131.5264 is available (4.1.3G).
I upgraded the affected phone, and had the customer test again, and he reports that it appears to be resolved.
I did open the support ticket however, so I'll wait for any response there, for more information.
thanks for getting back. Would you be able to use the forum mail to send me the SR number usually starting with 1- ?
I just want to ensure this is tracked correctly.