ISSUE HELP -Polycom Soundpoint 650 briding held call with call to extension

[bmurray66]

Hello All,

Sorry for the long subject.

Here is the issue that we've received multple tickets on. I'm totally stumped on this one so I'm seeing if someone has come across this and what was the resolution.

Caller A (PSTN) calls Caller B (Polycom 650)

B answers and then wants to transfer that party to Caller C, B presses trnsfer, it holds A (first hold has c= 0.0.0.0). RTP stops to and from the phone

Caller B at this point has dialtone and dials to another extesnio (polycom phone) Caller C.

Caller C doesn't answer,

Caller B hangs up on that call leg to Caller C.

Caller B resumes call with Caller A

Caller B again hits trnsfer, it holds A (BUT this time the phones 2nd hold has media attribute a=sendonly), RTP continues to be delivered from SBC towarads caller B's phone.

Caller B at this point has dialtone and dials to another extension (polycom phone) Caller C

Caller C answers and an connection (2 way audio stream) is established

BUT, at this point Caller B (Polycom IP 650) hears caller A and hears Caller C.

C can't hear A and vise versa. But B can definetly hear both caller A and caller C.

When reviewing the wireshark messaging,you can hear that B can definately hear both the Caller A side and the Caller C side and the user DID not conference this media.

Has anyone heard of such an issue? 

What was the fix for this issue?

Why does the 1st hold send 0.0.0.0 then any subsequent holds be sent with attribute a=sendOnly?

As far as I can see this is not an issue in regards to my Broadsoft or ACME SBC..

Broadsoft / Acme

Polycom 650

3.2.3 SIP load, 4.1.3.0052 bootrom

1 line provisioned

BLF with multiple appearances

TCP preferred

Device is behind Cisco ASA. SIP fix-up's are turned off.

Let me know if there is something else I can add to this.

Any help would be greatly appreciated!

Thanks,
Brian

[SteffenBaierUK]

Hello Brian,

Welcome to the Polycom Community.

You mention you are using a SPIP650 with SIP 3.2.3. This SIP Version has been superseded by SIP 3.2.5 or even UCS 3.3.2.

Have you yet tried to upgrade to a newer Version and tested this issue again?

Is this issues still present and always reproducible?

As you are using this setup in a professional capacity I would recommend to contact your Polycom Reseller and/or Polycom Support directly and provide the following:

• A Wireshark Capture taken on Phone B with an unfiltered Trace starting with Booting the Phone so all SIP Traffic is captured and then reproduce the Issue
• Your <mac>-app.log and <mac>-boot.log best taken from a FTP Server as complete logs are needed
• Your sip.cfg, phone1.cfg and all other configuration Files used by the Phone
• The Software Version of your Broadworks Server
• Detailed scenario including IP Addresses of all involved units

Best Regards

Steffen Baier

[bmurray66]

Hi Steffen,

I have not tried to update this device as my entire customer base is utlizing this firmware and since this seams to be an issolated issue, I didn't want to create a bigger issue. 1 phone out of 1500 devices as far as I'm aware is having this issue. I've reset to default and local config as well as format file system. Issue still persists. This issue is sporadic and NOT easily reproducable :( .

Thanks for your input. It's definately appreciated.

Regards,

Brian

Have you yet tried to upgrade to a newer Version and tested this issue again?

Is this issues still present and always reproducible?

As you are using this setup in a professional capacity I would recommend to contact your Polycom Reseller and/or Polycom Support directly and provide the following:

• A Wireshark Capture taken on Phone B with an unfiltered Trace starting with Booting the Phone so all SIP Traffic is captured and then reproduce the Issue
• Your <mac>-app.log and <mac>-boot.log best taken from a FTP Server as complete logs are needed
• Your sip.cfg, phone1.cfg and all other configuration Files used by the Phone
• The Software Version of your Broadworks Server
• Detailed scenario including IP Addresses of all involved units

Best Regards

Steffen Baier

[drkat]

sdp connection address of 0.0.0.0 is placing the call on hold with a media attribute of a=sendonly means that you want there to be one way audio toward the endpoint.  (On-Hold Music). 

What does your SDP information say for the other instances?