Hi, My client has been running FreeSWITCH with low call volume and has been stable for several months now. This Tuesday morning we switched all call volume over to FreeSWITCH and everything was running fine until this morning. Out of the blue, *all* calls started rejecting with INCOMPATIBLE_DESTINATION. Restarting FreeSWITCH fixed the problem. The version of FreeSWITCH is a trunk build from approximately 7/11/2013. Is this an issue that an update could fix? Could this be port starvation? Please assist, thanks. Here's a snippet from the freeswitch log where the first occurrence of that error: 2013-08-16 09:08:20.048687 [NOTICE] switch_channel.c:1030 New Channel sofia/external/******9333@192.168.1.212:5080[bfa3419b-0f79-4220-8807-773e3f680751] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:416 (sofia/external/******9333@192.168.1.212:5080) Running State Change CS_NEW 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:434 (sofia/external/******9333@192.168.1.212:5080) State NEW 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5793 Channel sofia/external/ ******9333@192.168.1.212:5080 entering state [received][100] 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5802 Remote SDP: v=0 o=- 1376662098 1 IN IP4 192.168.1.193 s=- c=IN IP4 192.168.1.193 t=0 0 m=audio 0 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=silenceSupp:off - - - - 2013-08-16 09:08:20.068687 [NOTICE] sofia.c:6093 Hangup sofia/external/ ******9333@192.168.1.212:5080 [CS_NEW] [INCOMPATIBLE_DESTINATION] Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
In the past I have seen INCOMPATIBLE_DESTINATION as a result of mis-matched Codecs. Try and take a look at that. Ira Tessler Lead Software Engineer ConnectMe (732) 490-9007 x2 ira@connectmevoice.com *From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Royce Mitchell III *Sent:* Friday, August 16, 2013 11:08 AM *To:* FreeSWITCH Users Help *Subject:* [Freeswitch-users] INCOMPATIBLE_DESTINATION Hi, My client has been running FreeSWITCH with low call volume and has been stable for several months now. This Tuesday morning we switched all call volume over to FreeSWITCH and everything was running fine until this morning. Out of the blue, *all* calls started rejecting with INCOMPATIBLE_DESTINATION. Restarting FreeSWITCH fixed the problem. The version of FreeSWITCH is a trunk build from approximately 7/11/2013. Is this an issue that an update could fix? Could this be port starvation? Please assist, thanks. Here's a snippet from the freeswitch log where the first occurrence of that error: 2013-08-16 09:08:20.048687 [NOTICE] switch_channel.c:1030 New Channel sofia/external/******9333@192.168.1.212:5080[bfa3419b-0f79-4220-8807-773e3f680751] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:416 (sofia/external/******9333@192.168.1.212:5080) Running State Change CS_NEW 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:434 (sofia/external/******9333@192.168.1.212:5080) State NEW 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5793 Channel sofia/external/******9333@192.168.1.212:5080 entering state [received][100] 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5802 Remote SDP: v=0 o=- 1376662098 1 IN IP4 192.168.1.193 s=- c=IN IP4 192.168.1.193 t=0 0 m=audio 0 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=silenceSupp:off - - - - 2013-08-16 09:08:20.068687 [NOTICE] sofia.c:6093 Hangup sofia/external/******9333@192.168.1.212:5080 [CS_NEW] [INCOMPATIBLE_DESTINATION] Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On 08/16/2013 05:07 PM, Royce Mitchell III wrote: [snip]
Restarting FreeSWITCH fixed the problem. The version of FreeSWITCH is a trunk build from approximately 7/11/2013.
Why do you use a development tree ("trunk") in production? Did it have some fix not available in the 1.2 branch that you needed? You do know that "trunk" is the development tree, may not be stable, have bugs and is subject to changes that may make it fall apart? Why not use the 1.2 branch which is aimed at stability? Regards, Patrick
yes I paid them to implement a needed feature. Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com On Fri, Aug 16, 2013 at 10:42 AM, Patrick Lists < freeswitch-list@puzzled.xs4all.nl> wrote:
On 08/16/2013 05:07 PM, Royce Mitchell III wrote: [snip]
Restarting FreeSWITCH fixed the problem. The version of FreeSWITCH is a trunk build from approximately 7/11/2013.
Why do you use a development tree ("trunk") in production? Did it have some fix not available in the 1.2 branch that you needed? You do know that "trunk" is the development tree, may not be stable, have bugs and is subject to changes that may make it fall apart? Why not use the 1.2 branch which is aimed at stability?
Regards, Patrick
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
INCOMPATIBLE_DESTINATION means a codec problem. The remote SDP sends they're offerring PCMU and G729. What codecs are you allowing, what codecs are you bridging with, and since G729 is on the list are you perhaps trying to transcode without using mod_com_g729+licenses? On 16 August 2013 16:07, Royce Mitchell III <royce3@gmail.com> wrote:
Hi,
My client has been running FreeSWITCH with low call volume and has been stable for several months now. This Tuesday morning we switched all call volume over to FreeSWITCH and everything was running fine until this morning.
Out of the blue, *all* calls started rejecting with INCOMPATIBLE_DESTINATION.
Restarting FreeSWITCH fixed the problem. The version of FreeSWITCH is a trunk build from approximately 7/11/2013. Is this an issue that an update could fix? Could this be port starvation? Please assist, thanks.
Here's a snippet from the freeswitch log where the first occurrence of that error:
2013-08-16 09:08:20.048687 [NOTICE] switch_channel.c:1030 New Channel sofia/external/******9333@192.168.1.212:5080[bfa3419b-0f79-4220-8807-773e3f680751] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:416 (sofia/external/******9333@192.168.1.212:5080) Running State Change CS_NEW 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:434 (sofia/external/******9333@192.168.1.212:5080) State NEW 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5793 Channel sofia/external/ ******9333@192.168.1.212:5080 entering state [received][100] 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5802 Remote SDP: v=0 o=- 1376662098 1 IN IP4 192.168.1.193 s=- c=IN IP4 192.168.1.193 t=0 0 m=audio 0 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=silenceSupp:off - - - -
2013-08-16 09:08:20.068687 [NOTICE] sofia.c:6093 Hangup sofia/external/ ******9333@192.168.1.212:5080 [CS_NEW] [INCOMPATIBLE_DESTINATION]
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
My FreeSWITCH is configured to prefer PCMU, and the devices it is talking to are Adtran 908e's. The Adtrans are configured for the default codec group which is supposed to be PCMU, but I can reconfigure them to explicitly allow only PCMU. I will try that and see if it makes a difference. Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com On Fri, Aug 16, 2013 at 11:04 AM, Steven Ayre <steveayre@gmail.com> wrote:
INCOMPATIBLE_DESTINATION means a codec problem.
The remote SDP sends they're offerring PCMU and G729.
What codecs are you allowing, what codecs are you bridging with, and since G729 is on the list are you perhaps trying to transcode without using mod_com_g729+licenses?
On 16 August 2013 16:07, Royce Mitchell III <royce3@gmail.com> wrote:
Hi,
My client has been running FreeSWITCH with low call volume and has been stable for several months now. This Tuesday morning we switched all call volume over to FreeSWITCH and everything was running fine until this morning.
Out of the blue, *all* calls started rejecting with INCOMPATIBLE_DESTINATION.
Restarting FreeSWITCH fixed the problem. The version of FreeSWITCH is a trunk build from approximately 7/11/2013. Is this an issue that an update could fix? Could this be port starvation? Please assist, thanks.
Here's a snippet from the freeswitch log where the first occurrence of that error:
2013-08-16 09:08:20.048687 [NOTICE] switch_channel.c:1030 New Channel sofia/external/******9333@192.168.1.212:5080[bfa3419b-0f79-4220-8807-773e3f680751] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:416 (sofia/external/******9333@192.168.1.212:5080) Running State Change CS_NEW 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:434 (sofia/external/******9333@192.168.1.212:5080) State NEW 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5793 Channel sofia/external/ ******9333@192.168.1.212:5080 entering state [received][100] 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5802 Remote SDP: v=0 o=- 1376662098 1 IN IP4 192.168.1.193 s=- c=IN IP4 192.168.1.193 t=0 0 m=audio 0 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=silenceSupp:off - - - -
2013-08-16 09:08:20.068687 [NOTICE] sofia.c:6093 Hangup sofia/external/ ******9333@192.168.1.212:5080 [CS_NEW] [INCOMPATIBLE_DESTINATION]
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
Hi there, Are you sure about fS allowing PCMU? According to the remote SDP, your incall is proposing PCMU as its top choice; g729 is 2nd best (quite right too :). Forcing the adtran to offer only PCMU should not make ay difference to that -- it'll still propose PCMU so no change. Either your setup is somehow blocking PCMU on the b-leg (but I'd expect to see that on the log), OR is trying to transcode because the b-leg requires some (non-PCMU) codec and can't (again, I'd expect that to be logged), OR fS is not accepting PCMU. Assuming that PCMU is in the fS vars codec lists, does your dialplan do anything funky with the codec list for an incall? all the best, Lawrence On 16 Aug 2013, at 21:06, Royce Mitchell III wrote:
My FreeSWITCH is configured to prefer PCMU, and the devices it is talking to are Adtran 908e's. The Adtrans are configured for the default codec group which is supposed to be PCMU, but I can reconfigure them to explicitly allow only PCMU. I will try that and see if it makes a difference.
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 11:04 AM, Steven Ayre <steveayre@gmail.com> wrote:
INCOMPATIBLE_DESTINATION means a codec problem.
The remote SDP sends they're offerring PCMU and G729.
What codecs are you allowing, what codecs are you bridging with, and since G729 is on the list are you perhaps trying to transcode without using mod_com_g729+licenses?
On 16 August 2013 16:07, Royce Mitchell III <royce3@gmail.com> wrote:
Hi,
My client has been running FreeSWITCH with low call volume and has been stable for several months now. This Tuesday morning we switched all call volume over to FreeSWITCH and everything was running fine until this morning.
Out of the blue, *all* calls started rejecting with INCOMPATIBLE_DESTINATION.
Restarting FreeSWITCH fixed the problem. The version of FreeSWITCH is a trunk build from approximately 7/11/2013. Is this an issue that an update could fix? Could this be port starvation? Please assist, thanks.
Here's a snippet from the freeswitch log where the first occurrence of that error:
2013-08-16 09:08:20.048687 [NOTICE] switch_channel.c:1030 New Channel sofia/external/******9333@192.168.1.212:5080[bfa3419b-0f79-4220-8807-773e3f680751] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:416 (sofia/external/******9333@192.168.1.212:5080) Running State Change CS_NEW 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:434 (sofia/external/******9333@192.168.1.212:5080) State NEW 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5793 Channel sofia/external/ ******9333@192.168.1.212:5080 entering state [received][100] 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5802 Remote SDP: v=0 o=- 1376662098 1 IN IP4 192.168.1.193 s=- c=IN IP4 192.168.1.193 t=0 0 m=audio 0 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=silenceSupp:off - - - -
2013-08-16 09:08:20.068687 [NOTICE] sofia.c:6093 Hangup sofia/external/ ******9333@192.168.1.212:5080 [CS_NEW] [INCOMPATIBLE_DESTINATION]
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
The only thing I'm doing in FS regarding codecs is I force PCMU in certain conditions ( ran into a transcoding bug in FreeSwitch between G722 HD and G711 with the Polycom phones ) Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com On Fri, Aug 16, 2013 at 3:35 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
Hi there, Are you sure about fS allowing PCMU? According to the remote SDP, your incall is proposing PCMU as its top choice; g729 is 2nd best (quite right too :). Forcing the adtran to offer only PCMU should not make ay difference to that -- it'll still propose PCMU so no change. Either your setup is somehow blocking PCMU on the b-leg (but I'd expect to see that on the log), OR is trying to transcode because the b-leg requires some (non-PCMU) codec and can't (again, I'd expect that to be logged), OR fS is not accepting PCMU. Assuming that PCMU is in the fS vars codec lists, does your dialplan do anything funky with the codec list for an incall? all the best, Lawrence
On 16 Aug 2013, at 21:06, Royce Mitchell III wrote:
My FreeSWITCH is configured to prefer PCMU, and the devices it is talking to are Adtran 908e's. The Adtrans are configured for the default codec group which is supposed to be PCMU, but I can reconfigure them to explicitly allow only PCMU. I will try that and see if it makes a difference.
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 11:04 AM, Steven Ayre <steveayre@gmail.com> wrote:
INCOMPATIBLE_DESTINATION means a codec problem.
The remote SDP sends they're offerring PCMU and G729.
What codecs are you allowing, what codecs are you bridging with, and since G729 is on the list are you perhaps trying to transcode without using mod_com_g729+licenses?
On 16 August 2013 16:07, Royce Mitchell III <royce3@gmail.com> wrote:
Hi,
My client has been running FreeSWITCH with low call volume and has been stable for several months now. This Tuesday morning we switched all call volume over to FreeSWITCH and everything was running fine until this morning.
Out of the blue, *all* calls started rejecting with INCOMPATIBLE_DESTINATION.
Restarting FreeSWITCH fixed the problem. The version of FreeSWITCH is a trunk build from approximately 7/11/2013. Is this an issue that an update could fix? Could this be port starvation? Please assist, thanks.
Here's a snippet from the freeswitch log where the first occurrence of that error:
2013-08-16 09:08:20.048687 [NOTICE] switch_channel.c:1030 New Channel sofia/external/******9333@192.168.1.212:5080 [bfa3419b-0f79-4220-8807-773e3f680751] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:416 (sofia/external/******9333@192.168.1.212:5080) Running State Change CS_NEW 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:434 (sofia/external/******9333@192.168.1.212:5080) State NEW 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5793 Channel sofia/external/ ******9333@192.168.1.212:5080 entering state [received][100] 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5802 Remote SDP: v=0 o=- 1376662098 1 IN IP4 192.168.1.193 s=- c=IN IP4 192.168.1.193 t=0 0 m=audio 0 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=silenceSupp:off - - - -
2013-08-16 09:08:20.068687 [NOTICE] sofia.c:6093 Hangup sofia/external/ ******9333@192.168.1.212:5080 [CS_NEW] [INCOMPATIBLE_DESTINATION]
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
Can you paste a debug log of the entire lifetime of the call? On 16 August 2013 21:57, Royce Mitchell III <royce3@gmail.com> wrote:
The only thing I'm doing in FS regarding codecs is I force PCMU in certain conditions ( ran into a transcoding bug in FreeSwitch between G722 HD and G711 with the Polycom phones )
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 3:35 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
Hi there, Are you sure about fS allowing PCMU? According to the remote SDP, your incall is proposing PCMU as its top choice; g729 is 2nd best (quite right too :). Forcing the adtran to offer only PCMU should not make ay difference to that -- it'll still propose PCMU so no change. Either your setup is somehow blocking PCMU on the b-leg (but I'd expect to see that on the log), OR is trying to transcode because the b-leg requires some (non-PCMU) codec and can't (again, I'd expect that to be logged), OR fS is not accepting PCMU. Assuming that PCMU is in the fS vars codec lists, does your dialplan do anything funky with the codec list for an incall? all the best, Lawrence
On 16 Aug 2013, at 21:06, Royce Mitchell III wrote:
My FreeSWITCH is configured to prefer PCMU, and the devices it is talking to are Adtran 908e's. The Adtrans are configured for the default codec group which is supposed to be PCMU, but I can reconfigure them to explicitly allow only PCMU. I will try that and see if it makes a difference.
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 11:04 AM, Steven Ayre <steveayre@gmail.com> wrote:
INCOMPATIBLE_DESTINATION means a codec problem.
The remote SDP sends they're offerring PCMU and G729.
What codecs are you allowing, what codecs are you bridging with, and since G729 is on the list are you perhaps trying to transcode without using mod_com_g729+licenses?
On 16 August 2013 16:07, Royce Mitchell III <royce3@gmail.com> wrote:
Hi,
My client has been running FreeSWITCH with low call volume and has been stable for several months now. This Tuesday morning we switched all call volume over to FreeSWITCH and everything was running fine until this morning.
Out of the blue, *all* calls started rejecting with INCOMPATIBLE_DESTINATION.
Restarting FreeSWITCH fixed the problem. The version of FreeSWITCH is a trunk build from approximately 7/11/2013. Is this an issue that an update could fix? Could this be port starvation? Please assist, thanks.
Here's a snippet from the freeswitch log where the first occurrence of that error:
2013-08-16 09:08:20.048687 [NOTICE] switch_channel.c:1030 New Channel sofia/external/******9333@192.168.1.212:5080 [bfa3419b-0f79-4220-8807-773e3f680751] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:416 (sofia/external/******9333@192.168.1.212:5080) Running State Change CS_NEW 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:434 (sofia/external/******9333@192.168.1.212:5080) State NEW 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5793 Channel sofia/external/ ******9333@192.168.1.212:5080 entering state [received][100] 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5802 Remote SDP: v=0 o=- 1376662098 1 IN IP4 192.168.1.193 s=- c=IN IP4 192.168.1.193 t=0 0 m=audio 0 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=silenceSupp:off - - - -
2013-08-16 09:08:20.068687 [NOTICE] sofia.c:6093 Hangup sofia/external/ ******9333@192.168.1.212:5080 [CS_NEW] [INCOMPATIBLE_DESTINATION]
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
Here is one example, thanks Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com On Fri, Aug 16, 2013 at 4:12 PM, Steven Ayre <steveayre@gmail.com> wrote:
Can you paste a debug log of the entire lifetime of the call?
On 16 August 2013 21:57, Royce Mitchell III <royce3@gmail.com> wrote:
The only thing I'm doing in FS regarding codecs is I force PCMU in certain conditions ( ran into a transcoding bug in FreeSwitch between G722 HD and G711 with the Polycom phones )
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 3:35 PM, Lawrence Conroy <lconroy@insensate.co.uk
wrote:
Hi there, Are you sure about fS allowing PCMU? According to the remote SDP, your incall is proposing PCMU as its top choice; g729 is 2nd best (quite right too :). Forcing the adtran to offer only PCMU should not make ay difference to that -- it'll still propose PCMU so no change. Either your setup is somehow blocking PCMU on the b-leg (but I'd expect to see that on the log), OR is trying to transcode because the b-leg requires some (non-PCMU) codec and can't (again, I'd expect that to be logged), OR fS is not accepting PCMU. Assuming that PCMU is in the fS vars codec lists, does your dialplan do anything funky with the codec list for an incall? all the best, Lawrence
On 16 Aug 2013, at 21:06, Royce Mitchell III wrote:
My FreeSWITCH is configured to prefer PCMU, and the devices it is talking to are Adtran 908e's. The Adtrans are configured for the default codec group which is supposed to be PCMU, but I can reconfigure them to explicitly allow only PCMU. I will try that and see if it makes a difference.
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 11:04 AM, Steven Ayre <steveayre@gmail.com> wrote:
INCOMPATIBLE_DESTINATION means a codec problem.
The remote SDP sends they're offerring PCMU and G729.
What codecs are you allowing, what codecs are you bridging with, and since G729 is on the list are you perhaps trying to transcode without using mod_com_g729+licenses?
On 16 August 2013 16:07, Royce Mitchell III <royce3@gmail.com> wrote:
Hi,
My client has been running FreeSWITCH with low call volume and has been stable for several months now. This Tuesday morning we switched all call volume over to FreeSWITCH and everything was running fine until this morning.
Out of the blue, *all* calls started rejecting with INCOMPATIBLE_DESTINATION.
Restarting FreeSWITCH fixed the problem. The version of FreeSWITCH is a trunk build from approximately 7/11/2013. Is this an issue that an update could fix? Could this be port starvation? Please assist, thanks.
Here's a snippet from the freeswitch log where the first occurrence of that error:
2013-08-16 09:08:20.048687 [NOTICE] switch_channel.c:1030 New Channel sofia/external/******9333@192.168.1.212:5080 [bfa3419b-0f79-4220-8807-773e3f680751] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:416 (sofia/external/******9333@192.168.1.212:5080) Running State Change CS_NEW 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:434 (sofia/external/******9333@192.168.1.212:5080) State NEW 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5793 Channel sofia/external/ ******9333@192.168.1.212:5080 entering state [received][100] 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5802 Remote SDP: v=0 o=- 1376662098 1 IN IP4 192.168.1.193 s=- c=IN IP4 192.168.1.193 t=0 0 m=audio 0 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=silenceSupp:off - - - -
2013-08-16 09:08:20.068687 [NOTICE] sofia.c:6093 Hangup sofia/external/ ******9333@192.168.1.212:5080 [CS_NEW] [INCOMPATIBLE_DESTINATION]
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
Hi, It looks like the remote SDP does not contain correct rtp port information. You have: m=audio 0 RTP/AVP 0 18 101 The first '0' should be the rtp port normally. I am not sure but it does not looks correct and may be the cause of the incompatible destination error. Hope this helps. -- Best Regards, Vallimamod . On Aug 19, 2013, at 2:59 PM, Royce Mitchell III <royce3@gmail.com> wrote:
Here is one example, thanks
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 4:12 PM, Steven Ayre <steveayre@gmail.com> wrote: Can you paste a debug log of the entire lifetime of the call?
On 16 August 2013 21:57, Royce Mitchell III <royce3@gmail.com> wrote: The only thing I'm doing in FS regarding codecs is I force PCMU in certain conditions ( ran into a transcoding bug in FreeSwitch between G722 HD and G711 with the Polycom phones )
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 3:35 PM, Lawrence Conroy <lconroy@insensate.co.uk> wrote: Hi there, Are you sure about fS allowing PCMU? According to the remote SDP, your incall is proposing PCMU as its top choice; g729 is 2nd best (quite right too :). Forcing the adtran to offer only PCMU should not make ay difference to that -- it'll still propose PCMU so no change. Either your setup is somehow blocking PCMU on the b-leg (but I'd expect to see that on the log), OR is trying to transcode because the b-leg requires some (non-PCMU) codec and can't (again, I'd expect that to be logged), OR fS is not accepting PCMU. Assuming that PCMU is in the fS vars codec lists, does your dialplan do anything funky with the codec list for an incall? all the best, Lawrence
On 16 Aug 2013, at 21:06, Royce Mitchell III wrote:
My FreeSWITCH is configured to prefer PCMU, and the devices it is talking to are Adtran 908e's. The Adtrans are configured for the default codec group which is supposed to be PCMU, but I can reconfigure them to explicitly allow only PCMU. I will try that and see if it makes a difference.
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 11:04 AM, Steven Ayre <steveayre@gmail.com> wrote:
INCOMPATIBLE_DESTINATION means a codec problem.
The remote SDP sends they're offerring PCMU and G729.
What codecs are you allowing, what codecs are you bridging with, and since G729 is on the list are you perhaps trying to transcode without using mod_com_g729+licenses?
On 16 August 2013 16:07, Royce Mitchell III <royce3@gmail.com> wrote:
Hi,
My client has been running FreeSWITCH with low call volume and has been stable for several months now. This Tuesday morning we switched all call volume over to FreeSWITCH and everything was running fine until this morning.
Out of the blue, *all* calls started rejecting with INCOMPATIBLE_DESTINATION.
Restarting FreeSWITCH fixed the problem. The version of FreeSWITCH is a trunk build from approximately 7/11/2013. Is this an issue that an update could fix? Could this be port starvation? Please assist, thanks.
Here's a snippet from the freeswitch log where the first occurrence of that error:
2013-08-16 09:08:20.048687 [NOTICE] switch_channel.c:1030 New Channel sofia/external/******9333@192.168.1.212:5080[bfa3419b-0f79-4220-8807-773e3f680751] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_session.c:1006 Send signal sofia/external/******9333@192.168.1.212:5080 [BREAK] 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:416 (sofia/external/******9333@192.168.1.212:5080) Running State Change CS_NEW 2013-08-16 09:08:20.048687 [DEBUG] switch_core_state_machine.c:434 (sofia/external/******9333@192.168.1.212:5080) State NEW 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5793 Channel sofia/external/ ******9333@192.168.1.212:5080 entering state [received][100] 2013-08-16 09:08:20.068687 [DEBUG] sofia.c:5802 Remote SDP: v=0 o=- 1376662098 1 IN IP4 192.168.1.193 s=- c=IN IP4 192.168.1.193 t=0 0 m=audio 0 RTP/AVP 0 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=silenceSupp:off - - - -
2013-08-16 09:08:20.068687 [NOTICE] sofia.c:6093 Hangup sofia/external/ ******9333@192.168.1.212:5080 [CS_NEW] [INCOMPATIBLE_DESTINATION]
AFAIK port zero is a method of putting the call on hold in a reinvite, and shouldn't be in the initial invite. Without a port you can only receive audio not send it (as you have nowhere to send to). Your SDP shows the phone is hiding its model - what is it? There's a 2011 mailing list thread suggesting it may be an issue with a bad firmware on a type of phone. On Monday, August 19, 2013, Vallimamod ABDULLAH wrote:
Hi,
It looks like the remote SDP does not contain correct rtp port information. You have:
m=audio 0 RTP/AVP 0 18 101
The first '0' should be the rtp port normally. I am not sure but it does not looks correct and may be the cause of the incompatible destination error. Hope this helps.
-- Best Regards, Vallimamod .
On Aug 19, 2013, at 2:59 PM, Royce Mitchell III <royce3@gmail.com> wrote:
Here is one example, thanks
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 4:12 PM, Steven Ayre <steveayre@gmail.com> wrote:
Can you paste a debug log of the entire lifetime of the call?
On 16 August 2013 21:57, Royce Mitchell III <royce3@gmail.com> wrote:
The only thing I'm doing in FS regarding codecs is I force PCMU in certain conditions ( ran into a transcoding bug in FreeSwitch between G722 HD and G711 with the Polycom phones )
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 3:35 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
Hi there, Are you sure about fS allowing PCMU? According to the remote SDP, your incall is proposing PCMU as its top choice; g729 is 2nd best (quite right too :). Forcing the adtran to offer only PCMU should not make ay difference to that -- it'll still propose PCMU so no change. Either your setup is somehow blocking PCMU on the b-leg (but I'd expect to see that on the log), OR is trying to transcode because the b-leg requires some (non-PCMU) codec and can't (again, I'd expect that to be logged), OR fS is not accepting PCMU. Assuming that PCMU is in the fS vars codec lists, does your dialplan do anything funky with the codec list for an incall? all the best, Lawrence
On 16 Aug 2013, at 21:06, Royce Mitchell III wrote:
My FreeSWITCH is configured to prefer PCMU, and the devices it is talking to are Adtran 908e's. The Adtrans are configured for the default codec group which is supposed to be PCMU, but I can reconfigure them to explicitly allow only PCMU. I will try that and see if it makes a difference.
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 11:04 AM, Steven Ayre <steveayre@gmail.com> wrote:
INCOMPATIBLE_DESTINATION means a codec problem.
The remote SDP sends they're offerring PCMU and G729.
What codecs are you allowing, what codecs are you bridging with, and since G729 is on the list are you perhaps trying to transcode without using mod_com_g729+licenses?
On 16 August 2013 16:07, Royce Mitchell III <
The other device is not a phone, but a pair of Adtran 908e 2nd Gen doing basic PRI to VoIP conversion. All of a sudden all calls were rejecting like this, but when I restarted FreeSWITCH everything started working fine again. I did not reboot or otherwise do anything to the Adtrans. The Adtrans are sending early media and have no reason to receive it, yet, so that might explain why they are sending the 0. On another note, I just searched a recent log file, and I don't find the string "m=audio 0" anywhere in the file. Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com On Mon, Aug 19, 2013 at 11:45 AM, Steven Ayre <steveayre@gmail.com> wrote:
AFAIK port zero is a method of putting the call on hold in a reinvite, and shouldn't be in the initial invite.
Without a port you can only receive audio not send it (as you have nowhere to send to).
Your SDP shows the phone is hiding its model - what is it? There's a 2011 mailing list thread suggesting it may be an issue with a bad firmware on a type of phone.
On Monday, August 19, 2013, Vallimamod ABDULLAH wrote:
Hi,
It looks like the remote SDP does not contain correct rtp port information. You have:
m=audio 0 RTP/AVP 0 18 101
The first '0' should be the rtp port normally. I am not sure but it does not looks correct and may be the cause of the incompatible destination error. Hope this helps.
-- Best Regards, Vallimamod .
On Aug 19, 2013, at 2:59 PM, Royce Mitchell III <royce3@gmail.com> wrote:
Here is one example, thanks
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 4:12 PM, Steven Ayre <steveayre@gmail.com> wrote:
Can you paste a debug log of the entire lifetime of the call?
On 16 August 2013 21:57, Royce Mitchell III <royce3@gmail.com> wrote:
The only thing I'm doing in FS regarding codecs is I force PCMU in certain conditions ( ran into a transcoding bug in FreeSwitch between G722 HD and G711 with the Polycom phones )
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 3:35 PM, Lawrence Conroy <lconroy@insensate.co.uk
wrote:
Hi there, Are you sure about fS allowing PCMU? According to the remote SDP, your incall is proposing PCMU as its top choice; g729 is 2nd best (quite right too :). Forcing the adtran to offer only PCMU should not make ay difference to that -- it'll still propose PCMU so no change. Either your setup is somehow blocking PCMU on the b-leg (but I'd expect to see that on the log), OR is trying to transcode because the b-leg requires some (non-PCMU) codec and can't (again, I'd expect that to be logged), OR fS is not accepting PCMU. Assuming that PCMU is in the fS vars codec lists, does your dialplan do anything funky with the codec list for an incall? all the best, Lawrence
On 16 Aug 2013, at 21:06, Royce Mitchell III wrote:
My FreeSWITCH is configured to prefer PCMU, and the devices it is talking to are Adtran 908e's. The Adtrans are configured for the default codec group which is supposed to be PCMU, but I can reconfigure them to explicitly allow only PCMU. I will try that and see if it makes a difference.
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 11:04 AM, Steven Ayre <steveayre@gmail.com> wrote:
INCOMPATIBLE_DESTINATION means a codec problem.
The remote SDP sends they're offerring PCMU and G729.
What codecs are you allowing, what codecs are you bridging with, and since G729 is on the list are you perhaps trying to transcode without using mod_com_g729+licenses?
On 16 August 2013 16:07, Royce Mitchell III <
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
There is one bit of setting this up that I'm having trouble finding good examples - and perhaps the weakest part of the book. I have a real firewall (not a router with some hacked up Linux kernel) that I DNAT the appropriate ports to the freeswitch server. I would think there would be some place in the default configs where one would/could specify four things: Server host name as seen from LAN Server IP address as seen from LAN Public FQDN as seen from Internet Public IP address as seen from Internet There is something - in the book here there is a brief mention of : ext-sip-ip and ext-rtp-ip and more at https://wiki.freeswitch.org/wiki/Sofia.conf.xml#ext-rtp-ip I'm assuming that the parameter sip-ip means internal-sip-ip and rtp-ip means internal-rtp-ip ? If I directly define these will I mess up NAT transversal on a external phone that is behind NAT? ( At one time I actually understood how a stun router worked - the insight might have only lasted for a day, but I can understand this stuff). These are seperately defined in: /etc/freeswitch/sip_profiles/external.xml and /etc/freeswitch/sip_profiles/internal.xml Which makes me think I don't understand the context of 'internal' and 'external' as used for sip profiles? I was assuming that external was for calls from the public internet and internal were for calls from the local LAN - but I'm not sure anymore. This combined with the use of <domain name="$${domain}"> at the top of directory/default.xml - which IP address should it be? - Should there be two similar sections - one for the internal IP address and a second for the external IP address? What if I go on a trip and want to register my extension from outside? - just what is domain used for in the directory? and also the line in directory/default.xml <param name="dial-string" value="{^^:sip_invite_domain=${dialed_domain}:presence_id=${dialed_user}@${dialed_domain}}${sofia_contact(*/${dialed_user}@${dialed_domain})}"/> </params> I think it defines the sip invitation string? - should it be different for the internal/vs external IP addresses? I have a feeling like there is something obvious that I don't get. I think it is important to know what is going on here before I start working with the ALCs -------------------------------------------------------------------------------- Karl Schmidt EMail Karl@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 It is a miracle that curiosity survives formal education. -Albert Einstein --------------------------------------------------------------------------------
It happened again this morning. I enabled console loglevel debug and placed a test call. Then, to try something different, I rebooted the primary adtran instead of FreeSWITCH. Just like when I restarted FreeSWITCH the first time, rebooting the Adtran fixed the problem, as calls started rolling in normally once it came back up. Given that the adtran is sending these "0" port packets, I think I need to open a ticket with them. Can I get some advice on what to tell them as to why sending a one-way audio packet during early media is a problem ( or am I even describing the problem correctly )? Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com On Mon, Aug 19, 2013 at 12:59 PM, Royce Mitchell III <royce3@gmail.com>wrote:
The other device is not a phone, but a pair of Adtran 908e 2nd Gen doing basic PRI to VoIP conversion. All of a sudden all calls were rejecting like this, but when I restarted FreeSWITCH everything started working fine again. I did not reboot or otherwise do anything to the Adtrans. The Adtrans are sending early media and have no reason to receive it, yet, so that might explain why they are sending the 0.
On another note, I just searched a recent log file, and I don't find the string "m=audio 0" anywhere in the file.
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Mon, Aug 19, 2013 at 11:45 AM, Steven Ayre <steveayre@gmail.com> wrote:
AFAIK port zero is a method of putting the call on hold in a reinvite, and shouldn't be in the initial invite.
Without a port you can only receive audio not send it (as you have nowhere to send to).
Your SDP shows the phone is hiding its model - what is it? There's a 2011 mailing list thread suggesting it may be an issue with a bad firmware on a type of phone.
On Monday, August 19, 2013, Vallimamod ABDULLAH wrote:
Hi,
It looks like the remote SDP does not contain correct rtp port information. You have:
m=audio 0 RTP/AVP 0 18 101
The first '0' should be the rtp port normally. I am not sure but it does not looks correct and may be the cause of the incompatible destination error. Hope this helps.
-- Best Regards, Vallimamod .
On Aug 19, 2013, at 2:59 PM, Royce Mitchell III <royce3@gmail.com> wrote:
Here is one example, thanks
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 4:12 PM, Steven Ayre <steveayre@gmail.com>wrote:
Can you paste a debug log of the entire lifetime of the call?
On 16 August 2013 21:57, Royce Mitchell III <royce3@gmail.com> wrote:
The only thing I'm doing in FS regarding codecs is I force PCMU in certain conditions ( ran into a transcoding bug in FreeSwitch between G722 HD and G711 with the Polycom phones )
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 3:35 PM, Lawrence Conroy < lconroy@insensate.co.uk> wrote:
Hi there, Are you sure about fS allowing PCMU? According to the remote SDP, your incall is proposing PCMU as its top choice; g729 is 2nd best (quite right too :). Forcing the adtran to offer only PCMU should not make ay difference to that -- it'll still propose PCMU so no change. Either your setup is somehow blocking PCMU on the b-leg (but I'd expect to see that on the log), OR is trying to transcode because the b-leg requires some (non-PCMU) codec and can't (again, I'd expect that to be logged), OR fS is not accepting PCMU. Assuming that PCMU is in the fS vars codec lists, does your dialplan do anything funky with the codec list for an incall? all the best, Lawrence
On 16 Aug 2013, at 21:06, Royce Mitchell III wrote:
My FreeSWITCH is configured to prefer PCMU, and the devices it is talking to are Adtran 908e's. The Adtrans are configured for the default codec group which is supposed to be PCMU, but I can reconfigure them to explicitly allow only PCMU. I will try that and see if it makes a difference.
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 11:04 AM, Steven Ayre <steveayre@gmail.com> wrote:
INCOMPATIBLE_DESTINATION means a codec problem.
The remote SDP sends they're offerring PCMU and G729.
What codecs are you allowing, what codecs are you bridging with, and since G729 is on the list are you perhaps trying to transcode without using mod_com_g729+licenses?
On 16 August 2013 16:07, Royce Mitchell III <
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
Hi, What is really strange is that your problem does not happen consistently. Have you checked for any sip enabled firewall or rtp proxy on the call path? You can make a sip trace with ngrep on the interface connected to the pri gateway and check if you get the 0 port sdp everytime from the adtran or only when you get the error on freeswitch (in wich case, you can point that to their support.) Make also ngrep trace on the freeswith interface and on any router in the middle to check if your invite is modified along the path. -- Cheers, Vallimamod . On Aug 20, 2013, at 6:01 PM, Royce Mitchell III <royce3@gmail.com> wrote:
It happened again this morning. I enabled console loglevel debug and placed a test call. Then, to try something different, I rebooted the primary adtran instead of FreeSWITCH. Just like when I restarted FreeSWITCH the first time, rebooting the Adtran fixed the problem, as calls started rolling in normally once it came back up.
Given that the adtran is sending these "0" port packets, I think I need to open a ticket with them. Can I get some advice on what to tell them as to why sending a one-way audio packet during early media is a problem ( or am I even describing the problem correctly )?
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Mon, Aug 19, 2013 at 12:59 PM, Royce Mitchell III <royce3@gmail.com> wrote: The other device is not a phone, but a pair of Adtran 908e 2nd Gen doing basic PRI to VoIP conversion. All of a sudden all calls were rejecting like this, but when I restarted FreeSWITCH everything started working fine again. I did not reboot or otherwise do anything to the Adtrans. The Adtrans are sending early media and have no reason to receive it, yet, so that might explain why they are sending the 0.
On another note, I just searched a recent log file, and I don't find the string "m=audio 0" anywhere in the file.
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Mon, Aug 19, 2013 at 11:45 AM, Steven Ayre <steveayre@gmail.com> wrote: AFAIK port zero is a method of putting the call on hold in a reinvite, and shouldn't be in the initial invite.
Without a port you can only receive audio not send it (as you have nowhere to send to).
Your SDP shows the phone is hiding its model - what is it? There's a 2011 mailing list thread suggesting it may be an issue with a bad firmware on a type of phone.
On Monday, August 19, 2013, Vallimamod ABDULLAH wrote: Hi,
It looks like the remote SDP does not contain correct rtp port information. You have:
m=audio 0 RTP/AVP 0 18 101
The first '0' should be the rtp port normally. I am not sure but it does not looks correct and may be the cause of the incompatible destination error. Hope this helps.
-- Best Regards, Vallimamod .
On Aug 19, 2013, at 2:59 PM, Royce Mitchell III <royce3@gmail.com> wrote:
Here is one example, thanks
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 4:12 PM, Steven Ayre <steveayre@gmail.com> wrote: Can you paste a debug log of the entire lifetime of the call?
On 16 August 2013 21:57, Royce Mitchell III <royce3@gmail.com> wrote: The only thing I'm doing in FS regarding codecs is I force PCMU in certain conditions ( ran into a transcoding bug in FreeSwitch between G722 HD and G711 with the Polycom phones )
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 3:35 PM, Lawrence Conroy <lconroy@insensate.co.uk> wrote: Hi there, Are you sure about fS allowing PCMU? According to the remote SDP, your incall is proposing PCMU as its top choice; g729 is 2nd best (quite right too :). Forcing the adtran to offer only PCMU should not make ay difference to that -- it'll still propose PCMU so no change. Either your setup is somehow blocking PCMU on the b-leg (but I'd expect to see that on the log), OR is trying to transcode because the b-leg requires some (non-PCMU) codec and can't (again, I'd expect that to be logged), OR fS is not accepting PCMU. Assuming that PCMU is in the fS vars codec lists, does your dialplan do anything funky with the codec list for an incall? all the best, Lawrence
On 16 Aug 2013, at 21:06, Royce Mitchell III wrote:
My FreeSWITCH is configured to prefer PCMU, and the devices it is talking to are Adtran 908e's. The Adtrans are configured for the default codec group which is supposed to be PCMU, but I can reconfigure them to explicitly allow only PCMU. I will try that and see if it makes a difference.
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 11:04 AM, Steven Ayre <steveayre@gmail.com> wrote:
INCOMPATIBLE_DESTINATION means a codec problem.
The remote SDP sends they're offerring PCMU and G729.
What codecs are you allowing, what codecs are you bridging with, and since G729 is on the list are you perhaps trying to transcode without using mod_com_g729+licenses?
On 16 August 2013 16:07, Royce Mitchell III <
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
I agree, the inconsistency is really baffling. I am intimately familiar with this environment and can assure there is nothing but basic network switches between the Adtrans and the FreeSWITCH instances. They are all in the same rack and plugged into Dell PowerEdge switches. Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com On Tue, Aug 20, 2013 at 3:52 PM, Vallimamod ABDULLAH < vallimamod.abdullah@imtelecom.fr> wrote:
Hi,
What is really strange is that your problem does not happen consistently.
Have you checked for any sip enabled firewall or rtp proxy on the call path? You can make a sip trace with ngrep on the interface connected to the pri gateway and check if you get the 0 port sdp everytime from the adtran or only when you get the error on freeswitch (in wich case, you can point that to their support.) Make also ngrep trace on the freeswith interface and on any router in the middle to check if your invite is modified along the path.
-- Cheers, Vallimamod .
On Aug 20, 2013, at 6:01 PM, Royce Mitchell III <royce3@gmail.com> wrote:
It happened again this morning. I enabled console loglevel debug and placed a test call. Then, to try something different, I rebooted the primary adtran instead of FreeSWITCH. Just like when I restarted FreeSWITCH the first time, rebooting the Adtran fixed the problem, as calls started rolling in normally once it came back up.
Given that the adtran is sending these "0" port packets, I think I need to open a ticket with them. Can I get some advice on what to tell them as to why sending a one-way audio packet during early media is a problem ( or am I even describing the problem correctly )?
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Mon, Aug 19, 2013 at 12:59 PM, Royce Mitchell III <royce3@gmail.com>wrote:
The other device is not a phone, but a pair of Adtran 908e 2nd Gen doing basic PRI to VoIP conversion. All of a sudden all calls were rejecting like this, but when I restarted FreeSWITCH everything started working fine again. I did not reboot or otherwise do anything to the Adtrans. The Adtrans are sending early media and have no reason to receive it, yet, so that might explain why they are sending the 0.
On another note, I just searched a recent log file, and I don't find the string "m=audio 0" anywhere in the file.
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Mon, Aug 19, 2013 at 11:45 AM, Steven Ayre <steveayre@gmail.com>wrote:
AFAIK port zero is a method of putting the call on hold in a reinvite, and shouldn't be in the initial invite.
Without a port you can only receive audio not send it (as you have nowhere to send to).
Your SDP shows the phone is hiding its model - what is it? There's a 2011 mailing list thread suggesting it may be an issue with a bad firmware on a type of phone.
On Monday, August 19, 2013, Vallimamod ABDULLAH wrote:
Hi,
It looks like the remote SDP does not contain correct rtp port information. You have:
m=audio 0 RTP/AVP 0 18 101
The first '0' should be the rtp port normally. I am not sure but it does not looks correct and may be the cause of the incompatible destination error. Hope this helps.
-- Best Regards, Vallimamod .
On Aug 19, 2013, at 2:59 PM, Royce Mitchell III <royce3@gmail.com> wrote:
Here is one example, thanks
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 4:12 PM, Steven Ayre <steveayre@gmail.com>wrote:
Can you paste a debug log of the entire lifetime of the call?
On 16 August 2013 21:57, Royce Mitchell III <royce3@gmail.com> wrote:
The only thing I'm doing in FS regarding codecs is I force PCMU in certain conditions ( ran into a transcoding bug in FreeSwitch between G722 HD and G711 with the Polycom phones )
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 3:35 PM, Lawrence Conroy < lconroy@insensate.co.uk> wrote:
Hi there, Are you sure about fS allowing PCMU? According to the remote SDP, your incall is proposing PCMU as its top choice; g729 is 2nd best (quite right too :). Forcing the adtran to offer only PCMU should not make ay difference to that -- it'll still propose PCMU so no change. Either your setup is somehow blocking PCMU on the b-leg (but I'd expect to see that on the log), OR is trying to transcode because the b-leg requires some (non-PCMU) codec and can't (again, I'd expect that to be logged), OR fS is not accepting PCMU. Assuming that PCMU is in the fS vars codec lists, does your dialplan do anything funky with the codec list for an incall? all the best, Lawrence
On 16 Aug 2013, at 21:06, Royce Mitchell III wrote:
My FreeSWITCH is configured to prefer PCMU, and the devices it is talking to are Adtran 908e's. The Adtrans are configured for the default codec group which is supposed to be PCMU, but I can reconfigure them to explicitly allow only PCMU. I will try that and see if it makes a difference.
Royce Mitchell, IT Consultant ITAS Solutions royce3@itas-solutions.com
On Fri, Aug 16, 2013 at 11:04 AM, Steven Ayre <steveayre@gmail.com> wrote:
INCOMPATIBLE_DESTINATION means a codec problem.
The remote SDP sends they're offerring PCMU and G729.
What codecs are you allowing, what codecs are you bridging with, and since G729 is on the list are you perhaps trying to transcode without using mod_com_g729+licenses?
On 16 August 2013 16:07, Royce Mitchell III <
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
participants (7)
-
Ira Tessler
-
Karl Schmidt
-
Lawrence Conroy
-
Patrick Lists
-
Royce Mitchell III
-
Steven Ayre
-
Vallimamod ABDULLAH