FreeSWITCH

When using Polycom phone (331) placing a call on hold does not play music

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.0.7
  • Fix Version/s: None
  • Component/s: mod_sofia
  • Labels:
    None
  • Environment:
    Polycom 331 => FS => any dest
  • Platform:
    Linux x86_64/gcc
  • Uname:
    Linux sip2.babblevoice.com 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
  • CPU Info:
    Hide
    processor : 0
    vendor_id : GenuineIntel
    cpu family : 6
    model : 15
    model name : Intel(R) Xeon(R) CPU 3050 @ 2.13GHz
    stepping : 2
    cpu MHz : 1599.000
    cache size : 2048 KB
    physical id : 0
    siblings : 2
    core id : 0
    cpu cores : 2
    apicid : 0
    fpu : yes
    fpu_exception : yes
    cpuid level : 10
    wp : yes
    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
    bogomips : 4266.81
    clflush size : 64
    cache_alignment : 64
    address sizes : 36 bits physical, 48 bits virtual
    power management:

    processor : 1
    vendor_id : GenuineIntel
    cpu family : 6
    model : 15
    model name : Intel(R) Xeon(R) CPU 3050 @ 2.13GHz
    stepping : 2
    cpu MHz : 1599.000
    cache size : 2048 KB
    physical id : 0
    siblings : 2
    core id : 1
    cpu cores : 2
    apicid : 1
    fpu : yes
    fpu_exception : yes
    cpuid level : 10
    wp : yes
    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
    bogomips : 4266.78
    clflush size : 64
    cache_alignment : 64
    address sizes : 36 bits physical, 48 bits virtual
    power management:
    Show
    processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 3050 @ 2.13GHz stepping : 2 cpu MHz : 1599.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 4266.81 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 3050 @ 2.13GHz stepping : 2 cpu MHz : 1599.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 4266.78 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
  • GCC Version:
    gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
  • FreeSWITCH GIT Revision:
    head
  • Reproduced with GIT HEAD?:
    yes
  • lsb_release:
    Hide
    LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
    Distributor ID: CentOS
    Description: CentOS release 5.5 (Final)
    Release: 5.5
    Codename: Final
    Show
    LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch Distributor ID: CentOS Description: CentOS release 5.5 (Final) Release: 5.5 Codename: Final
  • Target Version:

Description

Attached are to sip traces.

eyebeam to polycom test, in this call the eyebeam places the polycom on hold. The polycom can hear music on hold - works perfectly.

polycom to eyebeam test, in this call the polycom places the eyebeam on hold. The eyebeam hears nothing and the call will drop after a period time.

The main difference I have spotted between the two calls is the absence of a=sendonly in the SDP from the polycom.

The eyebeam is just for this example, this is replicated when the polycom has a call with other devices or destinations.
  1. Text File
    eyebeamtopolycomtest.txt
    08/Sep/11 4:37 AM
    25 kB
    Nick Knight
  2. Text File
    polycomtoeyebeamtest.txt
    08/Sep/11 4:37 AM
    16 kB
    Nick Knight

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Git added a comment -
Repository: freeswitch
Branch: refs/heads/master
Commit: 7acddfa http://fisheye.freeswitch.org/changelog/freeswitch.git/?cs=7acddfa
Closed By: anthm@freeswitch.org

Comment:
FS-3549 --resolve This patch will probably make it work but the bug is actually in the phone, the patch is simply tolerating the bad behaviour. You are correct about the a=sendonly missing, this was fixed in a later revision of the polycom firmware. I suggest that even if this patch works, that you update your phones to a newer firmware, preferably the most recent.
Show
Git added a comment - Repository: freeswitch Branch: refs/heads/master Commit: 7acddfa http://fisheye.freeswitch.org/changelog/freeswitch.git/?cs=7acddfa Closed By: anthm@freeswitch.org Comment: FS-3549 --resolve This patch will probably make it work but the bug is actually in the phone, the patch is simply tolerating the bad behaviour. You are correct about the a=sendonly missing, this was fixed in a later revision of the polycom firmware. I suggest that even if this patch works, that you update your phones to a newer firmware, preferably the most recent.
Hide
Permalink
Nick Knight added a comment -
Hi Anthony,

Thanks for your response. I wasn't sure if this was a bug in FS or Polycom. The reason: RFC 2543 (B5) states all that is needed to put a call on hold is setting the c=0.0.0.0, is it your understanding that now that has been superseded by the a=sendonly? I suppose the later RFC 3264 (5.1) has a MUST on this?

I noticed you put your change in git so you must not be too concerned about it rolling out?

I will be trialling an update to the phones as well, but just curious on your views above - on what is the correct thing (is my interpretation correct).

Thanks again.

Nick
Show
Nick Knight added a comment - Hi Anthony, Thanks for your response. I wasn't sure if this was a bug in FS or Polycom. The reason: RFC 2543 (B5) states all that is needed to put a call on hold is setting the c=0.0.0.0, is it your understanding that now that has been superseded by the a=sendonly? I suppose the later RFC 3264 (5.1) has a MUST on this? I noticed you put your change in git so you must not be too concerned about it rolling out? I will be trialling an update to the phones as well, but just curious on your views above - on what is the correct thing (is my interpretation correct). Thanks again. Nick
Hide
Permalink
Anthony Minessale II added a comment -
We try to follow the traditional principle of be strict in what you send and liberal in what you accept, so regardless of the specific absolute perfect way to do it, I am happy to just let both ways work. I do note, there have been no reports on this for years so it's pretty rare that any phones use 0.0.0.0 only anymore.

Show
Anthony Minessale II added a comment - We try to follow the traditional principle of be strict in what you send and liberal in what you accept, so regardless of the specific absolute perfect way to do it, I am happy to just let both ways work. I do note, there have been no reports on this for years so it's pretty rare that any phones use 0.0.0.0 only anymore.
Hide
Permalink
Nick Knight added a comment -
Hi Anthony,

I did a git update last night to roll this out, I think you put it in git, so if so the patch didn't work. I do want to update phones as well - but I have quite a number across a few sites, it would be great to get the patch working.

Nick
Show
Nick Knight added a comment - Hi Anthony, I did a git update last night to roll this out, I think you put it in git, so if so the patch didn't work. I do want to update phones as well - but I have quite a number across a few sites, it would be great to get the patch working. Nick
Hide
Permalink
Anthony Minessale II added a comment -
You would have to collect a new console trace.

sofia global siptrace on
console loglevel debug

The patch is there to look for the explicit string "0.0.0.0" in the connection addr among all the other ways to detect hold.
Show
Anthony Minessale II added a comment - You would have to collect a new console trace. sofia global siptrace on console loglevel debug The patch is there to look for the explicit string "0.0.0.0" in the connection addr among all the other ways to detect hold.
Hide
Permalink
Nick Knight added a comment -
Hi Anthony,

I have found the problem, and you have my apologies for wasting your time.

I had been using tcpdump to capture traffic, and after turning on the sip trace on the console I noticed that the c= line in the SDP had been rewrote, tcpdump was reporting it as 0.0.0.0 whilst the application was reporting it as the IP address of the other end.

The kernel had managed to load ip_conntrack_sip and ip_nat_sip and even the the box is not performing any NATing is managing to rewrite the packets. Unloaded and it all sprang into life.

At least I hope others may find this thread useful...

Thanks

Nick
Show
Nick Knight added a comment - Hi Anthony, I have found the problem, and you have my apologies for wasting your time. I had been using tcpdump to capture traffic, and after turning on the sip trace on the console I noticed that the c= line in the SDP had been rewrote, tcpdump was reporting it as 0.0.0.0 whilst the application was reporting it as the IP address of the other end. The kernel had managed to load ip_conntrack_sip and ip_nat_sip and even the the box is not performing any NATing is managing to rewrite the packets. Unloaded and it all sprang into life. At least I hope others may find this thread useful... Thanks Nick
Hide
Permalink
Auto Admin added a comment -
Due to a long period of inactivity (13 or more days), this issue is due to be automatically close within 24 hours.
If this issue is not actually resolved, please reopen it and add appropriate comments to help developers fix the issue.

Thanks,
  Jira Admin
Show
Auto Admin added a comment - Due to a long period of inactivity (13 or more days), this issue is due to be automatically close within 24 hours. If this issue is not actually resolved, please reopen it and add appropriate comments to help developers fix the issue. Thanks,   Jira Admin
Hide
Permalink
Auto Admin added a comment -
Since there has been no change to the status of this issue, it is being closed for inactivity

Thanks,
  Jira Admin
Show
Auto Admin added a comment - Since there has been no change to the status of this issue, it is being closed for inactivity Thanks,   Jira Admin

People

  • Assignee:
    Anthony Minessale II
    Reporter:
    Nick Knight
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
1d
Original Estimate - 1 day
Remaining:
1d
Remaining Estimate - 1 day
Logged:
Not Specified
Time Spent - Not Specified