Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the <pre> if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ } João Mesquita
I am deeply sorry, I've hit send too early. Damn Gmail... Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the voIpProt.SIP.useRFC2543hold option, it still sends 0.0.0.0 as follows: v=0 o=- 1167669703 1167669704 IN IP4 0.0.0.0 s=Polycom IP Phone c=IN IP4 0.0.0.0 t=0 0 m=audio 2228 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 I've also looked into FS code and I've found something on the lines of, but this is not kicking in either (granted, I am using 1.4.14 still and I really don't believe FS should cope with this crap either). if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->
sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ }
So, why am I coming to this ML for help? I wanted to know how did you guys figure this out, is there an exact firmware version where Polycom has this figured out or is it one of those long lasting ones that Polycom never cares to address? And btw, I tried with UC software version 4.0.8 and 4.0.7. Thank you, João Mesquita On Tue, Mar 24, 2015 at 12:19 PM, João Mesquita <jmesquita@freeswitch.org> wrote:
Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the
<pre> if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ } João Mesquita
Brian found this in the admin guide: Enable Call Hold Parameter Function Specify whether to use RFC 2543 (c=0.0.0.0) or RFC 3264 (a=sendonly or a=inactive) for outgoing hold signaling. Specify whether to use sendonly hold signaling. Configure local call hold reminder options. Specify the music-on-hold URI. Example Call Hold Configuration template > parameter sip-interop.cfg > voIpProt.SIP.useRFC2543hold sip-interop.cfg > voIpProt.SIP.useSendonlyHold sip-interop.cfg > call.hold.localReminder.* sip-interop.cfg > voIpProt.SIP.musicOnHold.uri
On Mar 24, 2015, at 11:25 AM, João Mesquita <jmesquita@freeswitch.org> wrote:
I am deeply sorry, I've hit send too early. Damn Gmail...
Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the voIpProt.SIP.useRFC2543hold option, it still sends 0.0.0.0 as follows:
v=0 o=- 1167669703 1167669704 IN IP4 0.0.0.0 s=Polycom IP Phone c=IN IP4 0.0.0.0 t=0 0 m=audio 2228 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000
I've also looked into FS code and I've found something on the lines of, but this is not kicking in either (granted, I am using 1.4.14 still and I really don't believe FS should cope with this crap either).
if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ }
So, why am I coming to this ML for help? I wanted to know how did you guys figure this out, is there an exact firmware version where Polycom has this figured out or is it one of those long lasting ones that Polycom never cares to address?
And btw, I tried with UC software version 4.0.8 and 4.0.7.
Thank you, João Mesquita
On Tue, Mar 24, 2015 at 12:19 PM, João Mesquita <jmesquita@freeswitch.org <mailto:jmesquita@freeswitch.org>> wrote:
Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the
<pre> if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ } João Mesquita
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Moishe, what UC software version are you using? MikeJ, I've set this on the web interface as well as provisioning and it's like it doesn't care, it will send 0.0.0.0 anyway. Knowing a firmware version that will make this work would be awesome. João Mesquita FreeSWITCH™ Solutions On Tue, Mar 24, 2015 at 12:43 PM, Michael Jerris <mike@jerris.com> wrote:
Brian found this in the admin guide:
Enable Call Hold Parameter Function Specify whether to use RFC 2543 (c=0.0.0.0) or RFC 3264 (a=sendonly or a=inactive) for outgoing hold signaling. Specify whether to use sendonly hold signaling. Configure local call hold reminder options. Specify the music-on-hold URI. Example Call Hold Configuration template > parameter sip-interop.cfg > voIpProt.SIP.useRFC2543hold sip-interop.cfg > voIpProt.SIP.useSendonlyHold sip-interop.cfg > call.hold.localReminder.* sip-interop.cfg > voIpProt.SIP.musicOnHold.uri
On Mar 24, 2015, at 11:25 AM, João Mesquita <jmesquita@freeswitch.org> wrote:
I am deeply sorry, I've hit send too early. Damn Gmail...
Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the voIpProt.SIP.useRFC2543hold option, it still sends 0.0.0.0 as follows:
v=0 o=- 1167669703 1167669704 IN IP4 0.0.0.0 s=Polycom IP Phone c=IN IP4 0.0.0.0 t=0 0 m=audio 2228 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000
I've also looked into FS code and I've found something on the lines of, but this is not kicking in either (granted, I am using 1.4.14 still and I really don't believe FS should cope with this crap either).
if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp-
sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING , "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ }
So, why am I coming to this ML for help? I wanted to know how did you guys figure this out, is there an exact firmware version where Polycom has this figured out or is it one of those long lasting ones that Polycom never cares to address?
And btw, I tried with UC software version 4.0.8 and 4.0.7.
Thank you, João Mesquita
On Tue, Mar 24, 2015 at 12:19 PM, João Mesquita <jmesquita@freeswitch.org> wrote:
Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the
<pre> if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ } João Mesquita
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hey Guys, This is working for us: voIpProt.SIP.useRFC2543hold=“0" voIpProt.SIP.useRFC3264HoldOnly=“1" voIpProt.SIP.useSendonlyHold="1" As of 4.0.3 Rev F, you need voIpProt.SIP.useRFC3264HoldOnly=“1” to force it for some reason. See: http://downloads.polycom.com/voice/voip/uc/UC_Software_Release_Notes_4_0_3_R... for details. Thanks, Spencer On Mar 24, 2015, at 9:27 AM, João Mesquita <jmesquita@freeswitch.org<mailto:jmesquita@freeswitch.org>> wrote: Moishe, what UC software version are you using? MikeJ, I've set this on the web interface as well as provisioning and it's like it doesn't care, it will send 0.0.0.0 anyway. Knowing a firmware version that will make this work would be awesome. João Mesquita FreeSWITCH™ Solutions On Tue, Mar 24, 2015 at 12:43 PM, Michael Jerris <mike@jerris.com<mailto:mike@jerris.com>> wrote: Brian found this in the admin guide: Enable Call Hold Parameter Function Specify whether to use RFC 2543 (c=0.0.0.0) or RFC 3264 (a=sendonly or a=inactive) for outgoing hold signaling. Specify whether to use sendonly hold signaling. Configure local call hold reminder options. Specify the music-on-hold URI. Example Call Hold Configuration template > parameter sip-interop.cfg > voIpProt.SIP.useRFC2543hold sip-interop.cfg > voIpProt.SIP.useSendonlyHold sip-interop.cfg > call.hold.localReminder.* sip-interop.cfg > voIpProt.SIP.musicOnHold.uri On Mar 24, 2015, at 11:25 AM, João Mesquita <jmesquita@freeswitch.org<mailto:jmesquita@freeswitch.org>> wrote: I am deeply sorry, I've hit send too early. Damn Gmail... Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the voIpProt.SIP.useRFC2543hold option, it still sends 0.0.0.0 as follows: v=0 o=- 1167669703 1167669704 IN IP4 0.0.0.0 s=Polycom IP Phone c=IN IP4 0.0.0.0 t=0 0 m=audio 2228 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 I've also looked into FS code and I've found something on the lines of, but this is not kicking in either (granted, I am using 1.4.14 still and I really don't believe FS should cope with this crap either). if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ } So, why am I coming to this ML for help? I wanted to know how did you guys figure this out, is there an exact firmware version where Polycom has this figured out or is it one of those long lasting ones that Polycom never cares to address? And btw, I tried with UC software version 4.0.8 and 4.0.7. Thank you, João Mesquita On Tue, Mar 24, 2015 at 12:19 PM, João Mesquita <jmesquita@freeswitch.org<mailto:jmesquita@freeswitch.org>> wrote: Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the <pre> if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ } João Mesquita _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com<http://www.freeswitchsolutions.com/> Official FreeSWITCH Sites http://www.freeswitch.org<http://www.freeswitch.org/> http://confluence.freeswitch.org<http://confluence.freeswitch.org/> http://www.cluecon.com<http://www.cluecon.com/> FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org<http://www.freeswitch.org/> _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com<http://www.freeswitchsolutions.com/> Official FreeSWITCH Sites http://www.freeswitch.org<http://www.freeswitch.org/> http://confluence.freeswitch.org<http://confluence.freeswitch.org/> http://www.cluecon.com<http://www.cluecon.com/> FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org<http://www.freeswitch.org/> _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
which phone models? what firmware are they on?
On Mar 24, 2015, at 12:27 PM, João Mesquita <jmesquita@freeswitch.org> wrote:
Moishe, what UC software version are you using?
MikeJ, I've set this on the web interface as well as provisioning and it's like it doesn't care, it will send 0.0.0.0 anyway. Knowing a firmware version that will make this work would be awesome.
João Mesquita FreeSWITCH™ Solutions
On Tue, Mar 24, 2015 at 12:43 PM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>> wrote: Brian found this in the admin guide:
Enable Call Hold Parameter Function Specify whether to use RFC 2543 (c=0.0.0.0) or RFC 3264 (a=sendonly or a=inactive) for outgoing hold signaling. Specify whether to use sendonly hold signaling. Configure local call hold reminder options. Specify the music-on-hold URI. Example Call Hold Configuration template > parameter sip-interop.cfg > voIpProt.SIP.useRFC2543hold sip-interop.cfg > voIpProt.SIP.useSendonlyHold sip-interop.cfg > call.hold.localReminder.* sip-interop.cfg > voIpProt.SIP.musicOnHold.uri
On Mar 24, 2015, at 11:25 AM, João Mesquita <jmesquita@freeswitch.org <mailto:jmesquita@freeswitch.org>> wrote:
I am deeply sorry, I've hit send too early. Damn Gmail...
Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the voIpProt.SIP.useRFC2543hold option, it still sends 0.0.0.0 as follows:
v=0 o=- 1167669703 1167669704 IN IP4 0.0.0.0 s=Polycom IP Phone c=IN IP4 0.0.0.0 t=0 0 m=audio 2228 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000
I've also looked into FS code and I've found something on the lines of, but this is not kicking in either (granted, I am using 1.4.14 still and I really don't believe FS should cope with this crap either).
if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ }
So, why am I coming to this ML for help? I wanted to know how did you guys figure this out, is there an exact firmware version where Polycom has this figured out or is it one of those long lasting ones that Polycom never cares to address?
And btw, I tried with UC software version 4.0.8 and 4.0.7.
Thank you, João Mesquita
On Tue, Mar 24, 2015 at 12:19 PM, João Mesquita <jmesquita@freeswitch.org <mailto:jmesquita@freeswitch.org>> wrote:
Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the
<pre> if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ } João Mesquita
They are all IP331 and IP550 on firmware 4.0.8 (latest). I am giving Spencer's suggestion for a spin and will report back ASAP. Thanks Spencer! João Mesquita FreeSWITCH™ Solutions On Tue, Mar 24, 2015 at 1:52 PM, Michael Jerris <mike@jerris.com> wrote:
which phone models? what firmware are they on?
On Mar 24, 2015, at 12:27 PM, João Mesquita <jmesquita@freeswitch.org> wrote:
Moishe, what UC software version are you using?
MikeJ, I've set this on the web interface as well as provisioning and it's like it doesn't care, it will send 0.0.0.0 anyway. Knowing a firmware version that will make this work would be awesome.
João Mesquita FreeSWITCH™ Solutions
On Tue, Mar 24, 2015 at 12:43 PM, Michael Jerris <mike@jerris.com> wrote:
Brian found this in the admin guide:
Enable Call Hold Parameter Function Specify whether to use RFC 2543 (c=0.0.0.0) or RFC 3264 (a=sendonly or a=inactive) for outgoing hold signaling. Specify whether to use sendonly hold signaling. Configure local call hold reminder options. Specify the music-on-hold URI. Example Call Hold Configuration template > parameter sip-interop.cfg > voIpProt.SIP.useRFC2543hold sip-interop.cfg > voIpProt.SIP.useSendonlyHold sip-interop.cfg > call.hold.localReminder.* sip-interop.cfg > voIpProt.SIP.musicOnHold.uri
On Mar 24, 2015, at 11:25 AM, João Mesquita <jmesquita@freeswitch.org> wrote:
I am deeply sorry, I've hit send too early. Damn Gmail...
Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the voIpProt.SIP.useRFC2543hold option, it still sends 0.0.0.0 as follows:
v=0 o=- 1167669703 1167669704 IN IP4 0.0.0.0 s=Polycom IP Phone c=IN IP4 0.0.0.0 t=0 0 m=audio 2228 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000
I've also looked into FS code and I've found something on the lines of, but this is not kicking in either (granted, I am using 1.4.14 still and I really don't believe FS should cope with this crap either).
if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp
->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ }
So, why am I coming to this ML for help? I wanted to know how did you guys figure this out, is there an exact firmware version where Polycom has this figured out or is it one of those long lasting ones that Polycom never cares to address?
And btw, I tried with UC software version 4.0.8 and 4.0.7.
Thank you, João Mesquita
On Tue, Mar 24, 2015 at 12:19 PM, João Mesquita <jmesquita@freeswitch.org
wrote:
Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the
<pre> if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ } João Mesquita
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
We are on various 4 and 5 revisions and it works. Thanks, Moishe Grunstein Tornado Computer Systems, Inc. 212.400.7650 888.IPPBX.US Service Request Email: support@nysolutions.com<mailto:support@nysolutions.com> [cid:image001.jpg@01C72F94.9EE45D60]<http://www.nysolutions.com/> Computer Networking * Managed Services * IP Video Surveillance * Network Assessments * Web Solutions * Voice over IP * Disaster Recovery * Network Security * Site Surveys * CMS From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of João Mesquita Sent: Tuesday, March 24, 2015 1:15 PM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Polycom headache They are all IP331 and IP550 on firmware 4.0.8 (latest). I am giving Spencer's suggestion for a spin and will report back ASAP. Thanks Spencer! João Mesquita FreeSWITCH™ Solutions On Tue, Mar 24, 2015 at 1:52 PM, Michael Jerris <mike@jerris.com<mailto:mike@jerris.com>> wrote: which phone models? what firmware are they on? On Mar 24, 2015, at 12:27 PM, João Mesquita <jmesquita@freeswitch.org<mailto:jmesquita@freeswitch.org>> wrote: Moishe, what UC software version are you using? MikeJ, I've set this on the web interface as well as provisioning and it's like it doesn't care, it will send 0.0.0.0 anyway. Knowing a firmware version that will make this work would be awesome. João Mesquita FreeSWITCH™ Solutions On Tue, Mar 24, 2015 at 12:43 PM, Michael Jerris <mike@jerris.com<mailto:mike@jerris.com>> wrote: Brian found this in the admin guide: Enable Call Hold Parameter Function Specify whether to use RFC 2543 (c=0.0.0.0) or RFC 3264 (a=sendonly or a=inactive) for outgoing hold signaling. Specify whether to use sendonly hold signaling. Configure local call hold reminder options. Specify the music-on-hold URI. Example Call Hold Configuration template > parameter sip-interop.cfg > voIpProt.SIP.useRFC2543hold sip-interop.cfg > voIpProt.SIP.useSendonlyHold sip-interop.cfg > call.hold.localReminder.* sip-interop.cfg > voIpProt.SIP.musicOnHold.uri On Mar 24, 2015, at 11:25 AM, João Mesquita <jmesquita@freeswitch.org<mailto:jmesquita@freeswitch.org>> wrote: I am deeply sorry, I've hit send too early. Damn Gmail... Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the voIpProt.SIP.useRFC2543hold option, it still sends 0.0.0.0 as follows: v=0 o=- 1167669703 1167669704 IN IP4 0.0.0.0 s=Polycom IP Phone c=IN IP4 0.0.0.0 t=0 0 m=audio 2228 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 I've also looked into FS code and I've found something on the lines of, but this is not kicking in either (granted, I am using 1.4.14 still and I really don't believe FS should cope with this crap either). if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ } So, why am I coming to this ML for help? I wanted to know how did you guys figure this out, is there an exact firmware version where Polycom has this figured out or is it one of those long lasting ones that Polycom never cares to address? And btw, I tried with UC software version 4.0.8 and 4.0.7. Thank you, João Mesquita On Tue, Mar 24, 2015 at 12:19 PM, João Mesquita <jmesquita@freeswitch.org<mailto:jmesquita@freeswitch.org>> wrote: Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the <pre> if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ } João Mesquita _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
For future reference, Spencer was right. Without that obscure, never mentioned option, it all works great! Thank you Spencer! Regards, João Mesquita On Tue, Mar 24, 2015 at 2:49 PM, Moishe Grunstein <max@nysolutions.com> wrote:
We are on various 4 and 5 revisions and it works.
Thanks,
Moishe Grunstein
Tornado Computer Systems, Inc.
212.400.7650 888.IPPBX.US *Service Request Email: support@nysolutions.com <support@nysolutions.com> *
[image: cid:image001.jpg@01C72F94.9EE45D60] <http://www.nysolutions.com/>
Computer Networking * Managed Services * IP Video Surveillance * Network Assessments * Web Solutions * Voice over IP * Disaster Recovery * Network Security * Site Surveys * CMS
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *João Mesquita *Sent:* Tuesday, March 24, 2015 1:15 PM *To:* FreeSWITCH Users Help *Subject:* Re: [Freeswitch-users] Polycom headache
They are all IP331 and IP550 on firmware 4.0.8 (latest). I am giving Spencer's suggestion for a spin and will report back ASAP.
Thanks Spencer!
João Mesquita FreeSWITCH™ Solutions
On Tue, Mar 24, 2015 at 1:52 PM, Michael Jerris <mike@jerris.com> wrote:
which phone models? what firmware are they on?
On Mar 24, 2015, at 12:27 PM, João Mesquita <jmesquita@freeswitch.org> wrote:
Moishe, what UC software version are you using?
MikeJ, I've set this on the web interface as well as provisioning and it's like it doesn't care, it will send 0.0.0.0 anyway. Knowing a firmware version that will make this work would be awesome.
João Mesquita FreeSWITCH™ Solutions
On Tue, Mar 24, 2015 at 12:43 PM, Michael Jerris <mike@jerris.com> wrote:
Brian found this in the admin guide:
Enable Call Hold Parameter Function
Specify whether to use RFC 2543 (c=0.0.0.0) or RFC 3264 (a=sendonly or a=inactive) for outgoing hold signaling.
Specify whether to use sendonly hold signaling. Configure local call hold reminder options. Specify the music-on-hold URI.
Example Call Hold Configuration
template > parameter
sip-interop.cfg > voIpProt.SIP.useRFC2543hold
sip-interop.cfg > voIpProt.SIP.useSendonlyHold sip-interop.cfg > call.hold.localReminder.* sip-interop.cfg > voIpProt.SIP.musicOnHold.uri
On Mar 24, 2015, at 11:25 AM, João Mesquita <jmesquita@freeswitch.org> wrote:
I am deeply sorry, I've hit send too early. Damn Gmail...
Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the voIpProt.SIP.useRFC2543hold option, it still sends 0.0.0.0 as follows:
v=0
o=- 1167669703 1167669704 IN IP4 0.0.0.0
s=Polycom IP Phone
c=IN IP4 0.0.0.0
t=0 0
m=audio 2228 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
I've also looked into FS code and I've found something on the lines of, but this is not kicking in either (granted, I am using 1.4.14 still and I really don't believe FS should cope with this crap either).
*if* ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp( sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ }
So, why am I coming to this ML for help? I wanted to know how did you guys figure this out, is there an exact firmware version where Polycom has this figured out or is it one of those long lasting ones that Polycom never cares to address?
And btw, I tried with UC software version 4.0.8 and 4.0.7.
Thank you,
João Mesquita
On Tue, Mar 24, 2015 at 12:19 PM, João Mesquita <jmesquita@freeswitch.org> wrote:
Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the
<pre> if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ }
João Mesquita
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Sorry, with that obscure, never mentioned option, not the other way around. I gotta start re-reading my emails *before* I hit send.. João Mesquita On Tue, Mar 24, 2015 at 8:47 PM, João Mesquita <jmesquita@freeswitch.org> wrote:
For future reference, Spencer was right. Without that obscure, never mentioned option, it all works great!
Thank you Spencer!
Regards, João Mesquita
On Tue, Mar 24, 2015 at 2:49 PM, Moishe Grunstein <max@nysolutions.com> wrote:
We are on various 4 and 5 revisions and it works.
Thanks,
Moishe Grunstein
Tornado Computer Systems, Inc.
212.400.7650 888.IPPBX.US *Service Request Email: support@nysolutions.com <support@nysolutions.com> *
[image: cid:image001.jpg@01C72F94.9EE45D60] <http://www.nysolutions.com/>
Computer Networking * Managed Services * IP Video Surveillance * Network Assessments * Web Solutions * Voice over IP * Disaster Recovery * Network Security * Site Surveys * CMS
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *João Mesquita *Sent:* Tuesday, March 24, 2015 1:15 PM *To:* FreeSWITCH Users Help *Subject:* Re: [Freeswitch-users] Polycom headache
They are all IP331 and IP550 on firmware 4.0.8 (latest). I am giving Spencer's suggestion for a spin and will report back ASAP.
Thanks Spencer!
João Mesquita FreeSWITCH™ Solutions
On Tue, Mar 24, 2015 at 1:52 PM, Michael Jerris <mike@jerris.com> wrote:
which phone models? what firmware are they on?
On Mar 24, 2015, at 12:27 PM, João Mesquita <jmesquita@freeswitch.org> wrote:
Moishe, what UC software version are you using?
MikeJ, I've set this on the web interface as well as provisioning and it's like it doesn't care, it will send 0.0.0.0 anyway. Knowing a firmware version that will make this work would be awesome.
João Mesquita FreeSWITCH™ Solutions
On Tue, Mar 24, 2015 at 12:43 PM, Michael Jerris <mike@jerris.com> wrote:
Brian found this in the admin guide:
Enable Call Hold Parameter Function
Specify whether to use RFC 2543 (c=0.0.0.0) or RFC 3264 (a=sendonly or a=inactive) for outgoing hold signaling.
Specify whether to use sendonly hold signaling. Configure local call hold reminder options. Specify the music-on-hold URI.
Example Call Hold Configuration
template > parameter
sip-interop.cfg > voIpProt.SIP.useRFC2543hold
sip-interop.cfg > voIpProt.SIP.useSendonlyHold sip-interop.cfg > call.hold.localReminder.* sip-interop.cfg > voIpProt.SIP.musicOnHold.uri
On Mar 24, 2015, at 11:25 AM, João Mesquita <jmesquita@freeswitch.org> wrote:
I am deeply sorry, I've hit send too early. Damn Gmail...
Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the voIpProt.SIP.useRFC2543hold option, it still sends 0.0.0.0 as follows:
v=0
o=- 1167669703 1167669704 IN IP4 0.0.0.0
s=Polycom IP Phone
c=IN IP4 0.0.0.0
t=0 0
m=audio 2228 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
I've also looked into FS code and I've found something on the lines of, but this is not kicking in either (granted, I am using 1.4.14 still and I really don't believe FS should cope with this crap either).
*if* ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp( sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING , "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ }
So, why am I coming to this ML for help? I wanted to know how did you guys figure this out, is there an exact firmware version where Polycom has this figured out or is it one of those long lasting ones that Polycom never cares to address?
And btw, I tried with UC software version 4.0.8 and 4.0.7.
Thank you,
João Mesquita
On Tue, Mar 24, 2015 at 12:19 PM, João Mesquita <jmesquita@freeswitch.org> wrote:
Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the
<pre> if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ }
João Mesquita
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
You can set the polycom config to use the other rfc, we did that here. Thanks, Moishe Grunstein Tornado Computer Systems, Inc. 212.400.7650 888.IPPBX.US Service Request Email: support@nysolutions.com<mailto:support@nysolutions.com> [cid:image001.jpg@01C72F94.9EE45D60]<http://www.nysolutions.com/> Computer Networking * Managed Services * IP Video Surveillance * Network Assessments * Web Solutions * Voice over IP * Disaster Recovery * Network Security * Site Surveys * CMS From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of João Mesquita Sent: Tuesday, March 24, 2015 11:19 AM To: freeswitch-users@lists.freeswitch.org Subject: [Freeswitch-users] Polycom headache Guys, I am sure most of you have been through this but this is my first time. I am having a HOLD problem with Polycom where they refuse to work according to the "new" RFC3624 using SDP a attributes (sendonly/recvonly) to indicate hold and keep sending 0.0.0.0 as the old RFC2543. I guess this is a known thing since I've found several hits on Google about it and they even created an option for it on their provisioning material. Unfortunately, it doesn't work. No matter what I set on the <pre> if ((sdp->sdp_connection && sdp->sdp_connection->c_address && !strcmp(sdp->sdp_connection->c_address, "0.0.0.0"))) { switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH_LOG_WARNING, "RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back.....\n"); sendonly = 2; /* global sendonly always wins */ } João Mesquita
participants (4)
-
João Mesquita
-
Michael Jerris
-
Moishe Grunstein
-
Spencer Thomason