Freeswitch doesnt transcode
Hello, I have a remote sip phone (Linksys SPA3102) which only supports PCMU. When I call to this remote sip phone i get a 406 error that opus is not supported as shown by the sip trace below. However, if I force the codec to absolute like this {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.5 the call works fine. Is there anyway I can make FreeSWITCH to automatically transcode without forcing the codec string in the dial plan? The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and outbound_codec_prefs=PCMU,PCMA,GSM ---------------------------siptrace-------------------------------- recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499: ------------------------------------------------------------------------ SIP/2.0 406 Not Acceptable Via: SIP/2.0/UDP 192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q CSeq: 87372504 INVITE Content-Length: 0 ------------------------------------------------------------------------ send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591: ------------------------------------------------------------------------ ACK sip:303@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej Max-Forwards: 68 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 CSeq: 87372504 ACK Content-Length: 0 ------------------------------------------------------------------------ 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel sofia/internal/303@192.168.1.5 entering state [terminated][406] 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup sofia/internal/303@192.168.1.5 [CS_CONSUME_MEDIA] [SERVICE_NOT_IMPLEMENTED] Thanks Rajil
How you originate the call? Is a bridge? From which phone? Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com> ha scritto:
Hello,
I have a remote sip phone (Linksys SPA3102) which only supports PCMU. When I call to this remote sip phone i get a 406 error that opus is not supported as shown by the sip trace below. However, if I force the codec to absolute like this {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.5 the call works fine.
Is there anyway I can make FreeSWITCH to automatically transcode without forcing the codec string in the dial plan?
The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and outbound_codec_prefs=PCMU,PCMA,GSM
---------------------------siptrace--------------------------------
recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499: ------------------------------------------------------------------------ SIP/2.0 406 Not Acceptable Via: SIP/2.0/UDP 192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q CSeq: 87372504 INVITE Content-Length: 0
------------------------------------------------------------------------ send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591: ------------------------------------------------------------------------ ACK sip:303@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej Max-Forwards: 68 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 CSeq: 87372504 ACK Content-Length: 0
------------------------------------------------------------------------ 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel sofia/internal/303@192.168.1.5 entering state [terminated][406] 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup sofia/internal/303@192.168.1.5 [CS_CONSUME_MEDIA] [SERVICE_NOT_IMPLEMENTED]
Thanks Rajil
_________________________________________________________________________ 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
The siptrace is at http://pastebin.com/xiGqtj1Y The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545. On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com> wrote:
How you originate the call? Is a bridge? From which phone?
Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin
Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com> ha scritto:
Hello,
I have a remote sip phone (Linksys SPA3102) which only supports PCMU. When I call to this remote sip phone i get a 406 error that opus is not supported as shown by the sip trace below. However, if I force the codec to absolute like this {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.5 the call works fine.
Is there anyway I can make FreeSWITCH to automatically transcode without forcing the codec string in the dial plan?
The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and outbound_codec_prefs=PCMU,PCMA,GSM
---------------------------siptrace--------------------------------
recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499:
------------------------------------------------------------------------ SIP/2.0 406 Not Acceptable Via: SIP/2.0/UDP
192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q CSeq: 87372504 INVITE Content-Length: 0
------------------------------------------------------------------------ send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591:
------------------------------------------------------------------------ ACK sip:303@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej Max-Forwards: 68 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 CSeq: 87372504 ACK Content-Length: 0
------------------------------------------------------------------------ 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel sofia/internal/303@192.168.1.5 entering state [terminated][406] 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup sofia/internal/303@192.168.1.5 [CS_CONSUME_MEDIA] [SERVICE_NOT_IMPLEMENTED]
Thanks Rajil
_________________________________________________________________________ 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
Look at the invite starting at 480. You are only offering opus to the callee. On Feb 14, 2016 2:05 PM, "Rajil Saraswat" <rajil.s@gmail.com> wrote:
The siptrace is at http://pastebin.com/xiGqtj1Y
The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545.
On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com> wrote:
How you originate the call? Is a bridge? From which phone?
Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin
Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com> ha scritto:
Hello,
I have a remote sip phone (Linksys SPA3102) which only supports PCMU. When I call to this remote sip phone i get a 406 error that opus is not supported as shown by the sip trace below. However, if I force the codec to absolute like this {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.5 the call works fine.
Is there anyway I can make FreeSWITCH to automatically transcode without forcing the codec string in the dial plan?
The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and outbound_codec_prefs=PCMU,PCMA,GSM
---------------------------siptrace--------------------------------
recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499:
------------------------------------------------------------------------ SIP/2.0 406 Not Acceptable Via: SIP/2.0/UDP
192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej
Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q CSeq: 87372504 INVITE Content-Length: 0
------------------------------------------------------------------------ send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591:
------------------------------------------------------------------------ ACK sip:303@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej Max-Forwards: 68 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 CSeq: 87372504 ACK Content-Length: 0
------------------------------------------------------------------------ 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel sofia/internal/303@192.168.1.5 entering state [terminated][406] 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup sofia/internal/303@192.168.1.5 [CS_CONSUME_MEDIA] [SERVICE_NOT_IMPLEMENTED]
Thanks Rajil
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
_________________________________________________________________________ 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
fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation On Sun, Feb 14, 2016 at 2:04 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
The siptrace is at http://pastebin.com/xiGqtj1Y
The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545.
On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com> wrote:
How you originate the call? Is a bridge? From which phone?
Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin
Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com> ha scritto:
Hello,
I have a remote sip phone (Linksys SPA3102) which only supports PCMU. When I call to this remote sip phone i get a 406 error that opus is not supported as shown by the sip trace below. However, if I force the codec to absolute like this {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.5 the call works fine.
Is there anyway I can make FreeSWITCH to automatically transcode without forcing the codec string in the dial plan?
The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and outbound_codec_prefs=PCMU,PCMA,GSM
---------------------------siptrace--------------------------------
recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499:
------------------------------------------------------------------------ SIP/2.0 406 Not Acceptable Via: SIP/2.0/UDP
192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej
Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q CSeq: 87372504 INVITE Content-Length: 0
------------------------------------------------------------------------ send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591:
------------------------------------------------------------------------ ACK sip:303@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej Max-Forwards: 68 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 CSeq: 87372504 ACK Content-Length: 0
------------------------------------------------------------------------ 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel sofia/internal/303@192.168.1.5 entering state [terminated][406] 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup sofia/internal/303@192.168.1.5 [CS_CONSUME_MEDIA] [SERVICE_NOT_IMPLEMENTED]
Thanks Rajil
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
_________________________________________________________________________ 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
Thanks, after setting media_mix_inbound_outbound_codecs=true, transcoding happens automatically. I remember not setting this variable in other installations and transcoding used to work out of the box. Is media_mix_inbound_outbound_codecs=true default in Freeswitch? On 14 February 2016 at 13:56, Russell Treleaven <rtreleaven@bunnykick.ca> wrote:
fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation
On Sun, Feb 14, 2016 at 2:04 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
The siptrace is at http://pastebin.com/xiGqtj1Y
The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545.
On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com> wrote:
How you originate the call? Is a bridge? From which phone?
Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin
Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com> ha scritto:
Hello,
I have a remote sip phone (Linksys SPA3102) which only supports PCMU. When I call to this remote sip phone i get a 406 error that opus is not supported as shown by the sip trace below. However, if I force the codec to absolute like this {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.5 the call works fine.
Is there anyway I can make FreeSWITCH to automatically transcode without forcing the codec string in the dial plan?
The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and outbound_codec_prefs=PCMU,PCMA,GSM
---------------------------siptrace--------------------------------
recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499:
------------------------------------------------------------------------ SIP/2.0 406 Not Acceptable Via: SIP/2.0/UDP
192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q CSeq: 87372504 INVITE Content-Length: 0
------------------------------------------------------------------------ send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591:
------------------------------------------------------------------------ ACK sip:303@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej Max-Forwards: 68 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 CSeq: 87372504 ACK Content-Length: 0
------------------------------------------------------------------------ 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel sofia/internal/303@192.168.1.5 entering state [terminated][406] 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup sofia/internal/303@192.168.1.5 [CS_CONSUME_MEDIA] [SERVICE_NOT_IMPLEMENTED]
Thanks Rajil
_________________________________________________________________________ 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
_________________________________________________________________________ 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
This behavior changed a while ago. This was dictates by ever growing SDPs and exceeding MTUs causing udp fragmentation. Udp does not deal with fragmentation and everyone refuses to fully implement sip over tcp for some reason even tho a ton of things support it and the RFCs require it Sent from my iPhone
On Feb 14, 2016, at 3:37 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
Thanks, after setting media_mix_inbound_outbound_codecs=true, transcoding happens automatically. I remember not setting this variable in other installations and transcoding used to work out of the box. Is media_mix_inbound_outbound_codecs=true default in Freeswitch?
On 14 February 2016 at 13:56, Russell Treleaven <rtreleaven@bunnykick.ca> wrote: fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation
On Sun, Feb 14, 2016 at 2:04 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
The siptrace is at http://pastebin.com/xiGqtj1Y
The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545.
On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com> wrote:
How you originate the call? Is a bridge? From which phone?
Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin
Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com> ha scritto:
Hello,
I have a remote sip phone (Linksys SPA3102) which only supports PCMU. When I call to this remote sip phone i get a 406 error that opus is not supported as shown by the sip trace below. However, if I force the codec to absolute like this {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.5 the call works fine.
Is there anyway I can make FreeSWITCH to automatically transcode without forcing the codec string in the dial plan?
The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and outbound_codec_prefs=PCMU,PCMA,GSM
---------------------------siptrace--------------------------------
recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499:
------------------------------------------------------------------------ SIP/2.0 406 Not Acceptable Via: SIP/2.0/UDP
192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q CSeq: 87372504 INVITE Content-Length: 0
------------------------------------------------------------------------ send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591:
------------------------------------------------------------------------ ACK sip:303@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej Max-Forwards: 68 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 CSeq: 87372504 ACK Content-Length: 0
------------------------------------------------------------------------ 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel sofia/internal/303@192.168.1.5 entering state [terminated][406] 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup sofia/internal/303@192.168.1.5 [CS_CONSUME_MEDIA] [SERVICE_NOT_IMPLEMENTED]
Thanks Rajil
_________________________________________________________________________ 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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
So is TCP the preferred method of doing SIP these days? I like TCP with endpoints as they always break through firewalls and we never seem to have in issue with TCP. However UDP is a headache. So if you have the choice why not do TCP? I realize some devices only support UDP, but the majority of SIP phones out there today do support TCP. Plus if you use TLS for encryption and security then you are already using TCP right? On Sun, Feb 14, 2016 at 4:07 PM, Ken Rice <krice@freeswitch.org> wrote:
This behavior changed a while ago. This was dictates by ever growing SDPs and exceeding MTUs causing udp fragmentation. Udp does not deal with fragmentation and everyone refuses to fully implement sip over tcp for some reason even tho a ton of things support it and the RFCs require it
Sent from my iPhone
On Feb 14, 2016, at 3:37 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
Thanks, after setting media_mix_inbound_outbound_codecs=true, transcoding happens automatically. I remember not setting this variable in other installations and transcoding used to work out of the box. Is media_mix_inbound_outbound_codecs=true default in Freeswitch?
On 14 February 2016 at 13:56, Russell Treleaven < rtreleaven@bunnykick.ca> wrote: fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation
On Sun, Feb 14, 2016 at 2:04 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
The siptrace is at http://pastebin.com/xiGqtj1Y
The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545.
On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com> wrote:
How you originate the call? Is a bridge? From which phone?
Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin
Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com> ha scritto:
Hello,
I have a remote sip phone (Linksys SPA3102) which only supports PCMU. When I call to this remote sip phone i get a 406 error that opus is not supported as shown by the sip trace below. However, if I force
the
codec to absolute like this {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.5 the call works fine.
Is there anyway I can make FreeSWITCH to automatically transcode without forcing the codec string in the dial plan?
The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and outbound_codec_prefs=PCMU,PCMA,GSM
---------------------------siptrace--------------------------------
recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499:
SIP/2.0 406 Not Acceptable Via: SIP/2.0/UDP
192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej
Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q CSeq: 87372504 INVITE Content-Length: 0
send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591:
ACK sip:303@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej Max-Forwards: 68 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 CSeq: 87372504 ACK Content-Length: 0
2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel sofia/internal/303@192.168.1.5 entering state [terminated][406] 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup sofia/internal/303@192.168.1.5 [CS_CONSUME_MEDIA] [SERVICE_NOT_IMPLEMENTED]
Thanks Rajil
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
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
_________________________________________________________________________ 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
any device that even remotely follows sip specs supports TCP. Most phones I have seen do. On Sunday, February 14, 2016, Colton Conor <colton.conor@gmail.com> wrote:
So is TCP the preferred method of doing SIP these days? I like TCP with endpoints as they always break through firewalls and we never seem to have in issue with TCP. However UDP is a headache. So if you have the choice why not do TCP? I realize some devices only support UDP, but the majority of SIP phones out there today do support TCP.
Plus if you use TLS for encryption and security then you are already using TCP right?
On Sun, Feb 14, 2016 at 4:07 PM, Ken Rice <krice@freeswitch.org <javascript:_e(%7B%7D,'cvml','krice@freeswitch.org');>> wrote:
This behavior changed a while ago. This was dictates by ever growing SDPs and exceeding MTUs causing udp fragmentation. Udp does not deal with fragmentation and everyone refuses to fully implement sip over tcp for some reason even tho a ton of things support it and the RFCs require it
Sent from my iPhone
On Feb 14, 2016, at 3:37 PM, Rajil Saraswat <rajil.s@gmail.com <javascript:_e(%7B%7D,'cvml','rajil.s@gmail.com');>> wrote:
Thanks, after setting media_mix_inbound_outbound_codecs=true, transcoding happens automatically. I remember not setting this variable in other installations and transcoding used to work out of the box. Is media_mix_inbound_outbound_codecs=true default in Freeswitch?
On 14 February 2016 at 13:56, Russell Treleaven < rtreleaven@bunnykick.ca <javascript:_e(%7B%7D,'cvml','rtreleaven@bunnykick.ca');>> wrote: fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation
On Sun, Feb 14, 2016 at 2:04 PM, Rajil Saraswat <rajil.s@gmail.com <javascript:_e(%7B%7D,'cvml','rajil.s@gmail.com');>> wrote:
The siptrace is at http://pastebin.com/xiGqtj1Y
The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545.
On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com <javascript:_e(%7B%7D,'cvml','gmaruzz@gmail.com');>> wrote:
How you originate the call? Is a bridge? From which phone?
Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin
Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com <javascript:_e(%7B%7D,'cvml','rajil.s@gmail.com');>> ha scritto: > > Hello, > > I have a remote sip phone (Linksys SPA3102) which only supports PCMU. > When I call to this remote sip phone i get a 406 error that opus is > not supported as shown by the sip trace below. However, if I force the > codec to absolute like this > {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.5 <javascript:_e(%7B%7D,'cvml','303@192.168.1.5');> > the call works fine. > > Is there anyway I can make FreeSWITCH to automatically transcode > without forcing the codec string in the dial plan? > > The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and > outbound_codec_prefs=PCMU,PCMA,GSM > > ---------------------------siptrace-------------------------------- > > recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499: > > >
> SIP/2.0 406 Not Acceptable > Via: SIP/2.0/UDP > > > 192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej > Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 > From: "202" <sip:202@192.168.1.111 <javascript:_e(%7B%7D,'cvml','sip:202@192.168.1.111');> ;tag=DFX0FUvr2vNcm > To: <sip:303@192.168.1.5 <javascript:_e(%7B%7D,'cvml','sip:303@192.168.1.5');> ;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q > CSeq: 87372504 INVITE > Content-Length: 0 > > > >
> send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591: > > >
> ACK sip:303@192.168.1.5 <javascript:_e(%7B%7D,'cvml','sip:303@192.168.1.5');> SIP/2.0 > Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej > Max-Forwards: 68 > From: "202" <sip:202@192.168.1.111 <javascript:_e(%7B%7D,'cvml','sip:202@192.168.1.111');> ;tag=DFX0FUvr2vNcm > To: <sip:303@192.168.1.5 <javascript:_e(%7B%7D,'cvml','sip:303@192.168.1.5');> ;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q > Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 > CSeq: 87372504 ACK > Content-Length: 0 > > > >
> 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel > sofia/internal/303@192.168.1.5 <javascript:_e(%7B%7D,'cvml','303@192.168.1.5');> entering state [terminated][406] > 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup > sofia/internal/303@192.168.1.5 <javascript:_e(%7B%7D,'cvml','303@192.168.1.5');> [CS_CONSUME_MEDIA] > [SERVICE_NOT_IMPLEMENTED] > > Thanks > Rajil > > >
> Professional FreeSWITCH Consulting Services: > consulting@freeswitch.org <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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
So if the device supports TCP, is there any reason not to use TCP. AKA is there any reason to keep on using UDP. TCP seems superior. On Mon, Feb 15, 2016 at 9:33 AM, Michael Jerris <mike@jerris.com> wrote:
any device that even remotely follows sip specs supports TCP. Most phones I have seen do.
On Sunday, February 14, 2016, Colton Conor <colton.conor@gmail.com> wrote:
So is TCP the preferred method of doing SIP these days? I like TCP with endpoints as they always break through firewalls and we never seem to have in issue with TCP. However UDP is a headache. So if you have the choice why not do TCP? I realize some devices only support UDP, but the majority of SIP phones out there today do support TCP.
Plus if you use TLS for encryption and security then you are already using TCP right?
On Sun, Feb 14, 2016 at 4:07 PM, Ken Rice <krice@freeswitch.org> wrote:
This behavior changed a while ago. This was dictates by ever growing SDPs and exceeding MTUs causing udp fragmentation. Udp does not deal with fragmentation and everyone refuses to fully implement sip over tcp for some reason even tho a ton of things support it and the RFCs require it
Sent from my iPhone
On Feb 14, 2016, at 3:37 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
Thanks, after setting media_mix_inbound_outbound_codecs=true, transcoding happens automatically. I remember not setting this variable in other installations and transcoding used to work out of the box. Is media_mix_inbound_outbound_codecs=true default in Freeswitch?
On 14 February 2016 at 13:56, Russell Treleaven < rtreleaven@bunnykick.ca> wrote: fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation
On Sun, Feb 14, 2016 at 2:04 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
The siptrace is at http://pastebin.com/xiGqtj1Y
The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545.
On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com
wrote: > How you originate the call? Is a bridge? From which phone? > > Also, please pastebin the complete sip trace (from start of leg A to end > of > both legs) and put here a link to pastebin > > Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com> ha scritto: >> >> Hello, >> >> I have a remote sip phone (Linksys SPA3102) which only supports PCMU. >> When I call to this remote sip phone i get a 406 error that opus is >> not supported as shown by the sip trace below. However, if I force the >> codec to absolute like this >> {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.5 >> the call works fine. >> >> Is there anyway I can make FreeSWITCH to automatically transcode >> without forcing the codec string in the dial plan? >> >> The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and >> outbound_codec_prefs=PCMU,PCMA,GSM >> >> ---------------------------siptrace-------------------------------- >> >> recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499: >> >> >>
>> SIP/2.0 406 Not Acceptable >> Via: SIP/2.0/UDP >> >> >> 192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej >> Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 >> From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm >> To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q >> CSeq: 87372504 INVITE >> Content-Length: 0 >> >> >> >>
>> send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591: >> >> >>
>> ACK sip:303@192.168.1.5 SIP/2.0 >> Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej >> Max-Forwards: 68 >> From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm >> To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q >> Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 >> CSeq: 87372504 ACK >> Content-Length: 0 >> >> >> >>
>> 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel >> sofia/internal/303@192.168.1.5 entering state [terminated][406] >> 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup >> sofia/internal/303@192.168.1.5 [CS_CONSUME_MEDIA] >> [SERVICE_NOT_IMPLEMENTED] >> >> Thanks >> Rajil >> >> >>
>> 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
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
_________________________________________________________________________
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
_________________________________________________________________________ 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
It is heavier but I think that otherwise is superior.
On Feb 15, 2016, at 11:04 AM, Colton Conor <colton.conor@gmail.com> wrote:
So if the device supports TCP, is there any reason not to use TCP. AKA is there any reason to keep on using UDP. TCP seems superior.
On Mon, Feb 15, 2016 at 9:33 AM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>> wrote: any device that even remotely follows sip specs supports TCP. Most phones I have seen do.
On Sunday, February 14, 2016, Colton Conor <colton.conor@gmail.com <mailto:colton.conor@gmail.com>> wrote: So is TCP the preferred method of doing SIP these days? I like TCP with endpoints as they always break through firewalls and we never seem to have in issue with TCP. However UDP is a headache. So if you have the choice why not do TCP? I realize some devices only support UDP, but the majority of SIP phones out there today do support TCP.
Plus if you use TLS for encryption and security then you are already using TCP right?
On Sun, Feb 14, 2016 at 4:07 PM, Ken Rice <krice@freeswitch.org <>> wrote: This behavior changed a while ago. This was dictates by ever growing SDPs and exceeding MTUs causing udp fragmentation. Udp does not deal with fragmentation and everyone refuses to fully implement sip over tcp for some reason even tho a ton of things support it and the RFCs require it
Sent from my iPhone
On Feb 14, 2016, at 3:37 PM, Rajil Saraswat <rajil.s@gmail.com <>> wrote:
Thanks, after setting media_mix_inbound_outbound_codecs=true, transcoding happens automatically. I remember not setting this variable in other installations and transcoding used to work out of the box. Is media_mix_inbound_outbound_codecs=true default in Freeswitch?
On 14 February 2016 at 13:56, Russell Treleaven <rtreleaven@bunnykick.ca <>> wrote: fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation <https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation>
On Sun, Feb 14, 2016 at 2:04 PM, Rajil Saraswat <rajil.s@gmail.com <>> wrote:
The siptrace is at http://pastebin.com/xiGqtj1Y <http://pastebin.com/xiGqtj1Y>
The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545.
On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com <>> wrote:
How you originate the call? Is a bridge? From which phone?
Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin
Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com <>> ha scritto:
Hello,
I have a remote sip phone (Linksys SPA3102) which only supports PCMU. When I call to this remote sip phone i get a 406 error that opus is not supported as shown by the sip trace below. However, if I force the codec to absolute like this {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.5 <> the call works fine.
Is there anyway I can make FreeSWITCH to automatically transcode without forcing the codec string in the dial plan?
The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and outbound_codec_prefs=PCMU,PCMA,GSM
---------------------------siptrace--------------------------------
recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499:
------------------------------------------------------------------------ SIP/2.0 406 Not Acceptable Via: SIP/2.0/UDP
192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 From: "202" <sip:202@192.168.1.111 <>>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5 <>>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q CSeq: 87372504 INVITE Content-Length: 0
------------------------------------------------------------------------ send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591:
------------------------------------------------------------------------ ACK sip:303@192.168.1.5 <> SIP/2.0 Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej Max-Forwards: 68 From: "202" <sip:202@192.168.1.111 <>>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5 <>>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 CSeq: 87372504 ACK Content-Length: 0
------------------------------------------------------------------------ 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel sofia/internal/303@192.168.1.5 <> entering state [terminated][406] 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup sofia/internal/303@192.168.1.5 <> [CS_CONSUME_MEDIA] [SERVICE_NOT_IMPLEMENTED]
Thanks Rajil
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: 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 <> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users>
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: 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 <> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: 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 <> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: 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 <> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: 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 <> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: 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 <> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <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 <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <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
The problem isn’t necessarily the devices, but there is also the carriers… From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Colton Conor Sent: Monday, February 15, 2016 10:04 AM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Freeswitch doesnt transcode So if the device supports TCP, is there any reason not to use TCP. AKA is there any reason to keep on using UDP. TCP seems superior. On Mon, Feb 15, 2016 at 9:33 AM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com> > wrote: any device that even remotely follows sip specs supports TCP. Most phones I have seen do. On Sunday, February 14, 2016, Colton Conor <colton.conor@gmail.com <mailto:colton.conor@gmail.com> > wrote: So is TCP the preferred method of doing SIP these days? I like TCP with endpoints as they always break through firewalls and we never seem to have in issue with TCP. However UDP is a headache. So if you have the choice why not do TCP? I realize some devices only support UDP, but the majority of SIP phones out there today do support TCP. Plus if you use TLS for encryption and security then you are already using TCP right? On Sun, Feb 14, 2016 at 4:07 PM, Ken Rice <krice@freeswitch.org <mailto:krice@freeswitch.org> > wrote: This behavior changed a while ago. This was dictates by ever growing SDPs and exceeding MTUs causing udp fragmentation. Udp does not deal with fragmentation and everyone refuses to fully implement sip over tcp for some reason even tho a ton of things support it and the RFCs require it Sent from my iPhone
On Feb 14, 2016, at 3:37 PM, Rajil Saraswat <rajil.s@gmail.com <mailto:rajil.s@gmail.com> > wrote:
Thanks, after setting media_mix_inbound_outbound_codecs=true, transcoding happens automatically. I remember not setting this variable in other installations and transcoding used to work out of the box. Is media_mix_inbound_outbound_codecs=true default in Freeswitch?
On 14 February 2016 at 13:56, Russell Treleaven <rtreleaven@bunnykick.ca <mailto:rtreleaven@bunnykick.ca> > wrote: fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation
On Sun, Feb 14, 2016 at 2:04 PM, Rajil Saraswat <rajil.s@gmail.com <mailto:rajil.s@gmail.com> > wrote:
The siptrace is at http://pastebin.com/xiGqtj1Y
The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545.
On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com <mailto:gmaruzz@gmail.com> > wrote:
How you originate the call? Is a bridge? From which phone?
Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin
Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com <mailto:rajil.s@gmail.com> > ha scritto:
Hello,
I have a remote sip phone (Linksys SPA3102) which only supports PCMU. When I call to this remote sip phone i get a 406 error that opus is not supported as shown by the sip trace below. However, if I force the codec to absolute like this {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.5 the call works fine.
Is there anyway I can make FreeSWITCH to automatically transcode without forcing the codec string in the dial plan?
The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and outbound_codec_prefs=PCMU,PCMA,GSM
---------------------------siptrace--------------------------------
recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499:
------------------------------------------------------------------------ SIP/2.0 406 Not Acceptable Via: SIP/2.0/UDP
192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q CSeq: 87372504 INVITE Content-Length: 0
------------------------------------------------------------------------ send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591:
------------------------------------------------------------------------ ACK sip:303@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej Max-Forwards: 68 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 CSeq: 87372504 ACK Content-Length: 0
------------------------------------------------------------------------ 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel sofia/internal/303@192.168.1.5 <mailto:sofia/internal/303@192.168.1.5> entering state [terminated][406] 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup sofia/internal/303@192.168.1.5 <mailto:sofia/internal/303@192.168.1.5> [CS_CONSUME_MEDIA] [SERVICE_NOT_IMPLEMENTED]
Thanks Rajil
_________________________________________________________________________ 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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
_________________________________________________________________________ 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 _________________________________________________________________________ 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
True, But freeswitch talking to the carriers is almost always UPD. However, freeswitch talking to the clients I would say TCP would be idea. So its almost like freeswitch is trancoding from TCP to UDP too :) On Mon, Feb 15, 2016 at 10:25 AM, Ken Rice <krice@freeswitch.org> wrote:
The problem isn’t necessarily the devices, but there is also the carriers…
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Colton Conor *Sent:* Monday, February 15, 2016 10:04 AM *To:* FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> *Subject:* Re: [Freeswitch-users] Freeswitch doesnt transcode
So if the device supports TCP, is there any reason not to use TCP. AKA is there any reason to keep on using UDP. TCP seems superior.
On Mon, Feb 15, 2016 at 9:33 AM, Michael Jerris <mike@jerris.com> wrote:
any device that even remotely follows sip
specs supports TCP. Most phones I have seen do.
On Sunday, February 14, 2016, Colton Conor <colton.conor@gmail.com> wrote:
So is TCP the preferred method of doing SIP these days? I like TCP with endpoints as they always break through firewalls and we never seem to have in issue with TCP. However UDP is a headache. So if you have the choice why not do TCP? I realize some devices only support UDP, but the majority of SIP phones out there today do support TCP.
Plus if you use TLS for encryption and security then you are already using TCP right?
On Sun, Feb 14, 2016 at 4:07 PM, Ken Rice <krice@freeswitch.org> wrote:
This behavior changed a while ago. This was dictates by ever growing SDPs and exceeding MTUs causing udp fragmentation. Udp does not deal with fragmentation and everyone refuses to fully implement sip over tcp for some reason even tho a ton of things support it and the RFCs require it
Sent from my iPhone
On Feb 14, 2016, at 3:37 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
Thanks, after setting media_mix_inbound_outbound_codecs=true, transcoding happens automatically. I remember not setting this variable in other installations and transcoding used to work out of the box. Is media_mix_inbound_outbound_codecs=true default in Freeswitch?
On 14 February 2016 at 13:56, Russell Treleaven < rtreleaven@bunnykick.ca> wrote: fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation
On Sun, Feb 14, 2016 at 2:04 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
The siptrace is at http://pastebin.com/xiGqtj1Y
The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545.
On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com> wrote:
How you originate the call? Is a bridge? >From which phone?
Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin
Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com> ha scritto:
Hello,
I have a remote sip phone (Linksys SPA3102) which only supports PCMU. When I call to this remote sip phone i get a 406 error that opus is not supported as shown by the sip trace below. However, if I force
the
codec to absolute like this {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.5 the call works fine.
Is there anyway I can make FreeSWITCH to automatically transcode without forcing the codec string in the dial plan?
The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and outbound_codec_prefs=PCMU,PCMA,GSM
---------------------------siptrace--------------------------------
recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499:
SIP/2.0 406 Not Acceptable Via: SIP/2.0/UDP
192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej
Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q CSeq: 87372504 INVITE Content-Length: 0
send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591:
ACK sip:303@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej Max-Forwards: 68 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 CSeq: 87372504 ACK Content-Length: 0
2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel sofia/internal/303@192.168.1.5 entering state [terminated][406] 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup sofia/internal/303@192.168.1.5 [CS_CONSUME_MEDIA] [SERVICE_NOT_IMPLEMENTED]
Thanks Rajil
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
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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
The problem still exists for expanding SDPs… using TCP to the user/device then trying to send the same thing out to the carrier over UDP is what was causing the problem in the first place… so the decision was made to prevent those problems we’ll only offer what the device offers and not expand the number of codecs even further increasing the already bloated SDPs to the point where they fragment over UDP and get dropped… So is TCP better for some things, yes it is, however, the lack of market wide support for it with carriers makes it a pain in the ass even tho the RFCs specifically say you MUST support both UDP and TCP for SIP, but certain VoIP softwares out there only implemented UDP many years ago and now we’re stuck with that legacy From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Colton Conor Sent: Monday, February 15, 2016 10:30 AM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Freeswitch doesnt transcode True, But freeswitch talking to the carriers is almost always UPD. However, freeswitch talking to the clients I would say TCP would be idea. So its almost like freeswitch is trancoding from TCP to UDP too :) On Mon, Feb 15, 2016 at 10:25 AM, Ken Rice <krice@freeswitch.org <mailto:krice@freeswitch.org> > wrote: The problem isn’t necessarily the devices, but there is also the carriers… From: freeswitch-users-bounces@lists.freeswitch.org <mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org <mailto:freeswitch-users-bounces@lists.freeswitch.org> ] On Behalf Of Colton Conor Sent: Monday, February 15, 2016 10:04 AM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org> > Subject: Re: [Freeswitch-users] Freeswitch doesnt transcode So if the device supports TCP, is there any reason not to use TCP. AKA is there any reason to keep on using UDP. TCP seems superior. On Mon, Feb 15, 2016 at 9:33 AM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com> > wrote: any device that even remotely follows sip specs supports TCP. Most phones I have seen do. On Sunday, February 14, 2016, Colton Conor <colton.conor@gmail.com <mailto:colton.conor@gmail.com> > wrote: So is TCP the preferred method of doing SIP these days? I like TCP with endpoints as they always break through firewalls and we never seem to have in issue with TCP. However UDP is a headache. So if you have the choice why not do TCP? I realize some devices only support UDP, but the majority of SIP phones out there today do support TCP. Plus if you use TLS for encryption and security then you are already using TCP right? On Sun, Feb 14, 2016 at 4:07 PM, Ken Rice <krice@freeswitch.org <mailto:krice@freeswitch.org> > wrote: This behavior changed a while ago. This was dictates by ever growing SDPs and exceeding MTUs causing udp fragmentation. Udp does not deal with fragmentation and everyone refuses to fully implement sip over tcp for some reason even tho a ton of things support it and the RFCs require it Sent from my iPhone
On Feb 14, 2016, at 3:37 PM, Rajil Saraswat <rajil.s@gmail.com <mailto:rajil.s@gmail.com> > wrote:
Thanks, after setting media_mix_inbound_outbound_codecs=true, transcoding happens automatically. I remember not setting this variable in other installations and transcoding used to work out of the box. Is media_mix_inbound_outbound_codecs=true default in Freeswitch?
On 14 February 2016 at 13:56, Russell Treleaven <rtreleaven@bunnykick.ca <mailto:rtreleaven@bunnykick.ca> > wrote: fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation
On Sun, Feb 14, 2016 at 2:04 PM, Rajil Saraswat <rajil.s@gmail.com <mailto:rajil.s@gmail.com> > wrote:
The siptrace is at http://pastebin.com/xiGqtj1Y
The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545.
On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com <mailto:gmaruzz@gmail.com> > wrote:
How you originate the call? Is a bridge? >From which phone?
Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin
Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com <mailto:rajil.s@gmail.com> > ha scritto:
Hello,
I have a remote sip phone (Linksys SPA3102) which only supports PCMU. When I call to this remote sip phone i get a 406 error that opus is not supported as shown by the sip trace below. However, if I force the codec to absolute like this {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.5 <mailto:303@192.168.1.5> the call works fine.
Is there anyway I can make FreeSWITCH to automatically transcode without forcing the codec string in the dial plan?
The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and outbound_codec_prefs=PCMU,PCMA,GSM
---------------------------siptrace--------------------------------
recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499:
------------------------------------------------------------------------ SIP/2.0 406 Not Acceptable Via: SIP/2.0/UDP
192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q CSeq: 87372504 INVITE Content-Length: 0
------------------------------------------------------------------------ send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591:
------------------------------------------------------------------------ ACK sip:303@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej Max-Forwards: 68 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 CSeq: 87372504 ACK Content-Length: 0
------------------------------------------------------------------------ 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel sofia/internal/303@192.168.1.5 <mailto:sofia/internal/303@192.168.1.5> entering state [terminated][406] 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup sofia/internal/303@192.168.1.5 <mailto:sofia/internal/303@192.168.1.5> [CS_CONSUME_MEDIA] [SERVICE_NOT_IMPLEMENTED]
Thanks Rajil
_________________________________________________________________________ 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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
_________________________________________________________________________ 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 _________________________________________________________________________ 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 _________________________________________________________________________ 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
Hi Ken, Conor, folks, Along time ago in a land far away ... the [very] early history of SIP was tied up with a bunch of other multimedia SxP things. The big driver at that time was being able to do conferencing and media distribution -- after all, voice calls could be done with H.323 et al. The SDP (and SIP main part headers) were quite simple and small [**]. This was a message based scheme, and UDP is a messaging transport, as opposed to TCP which is a stream transport. IIRC, mapping from PSTN schemes (again, message-based systems) to UDP seemed simpler. TCP required maintaining transport session state in gateways, and the stacks in those gateways were primitive, to say the least. Despite that, folk pushing for TCP to be mandatory were told that it was considered 2nd class and should not be mandatory to implement); that was in '97 as I recall. Then (late 98 -> 2001) cable labs & 3GPP decided SIP was easier to bend to their will than H.323/224/..., and the number of headers grew like topsy, the complexity of the maintained state just kept on building, and we ran into fragment problems. Quick fix was header compression, but that ran into company-political issues in 3GPP and anyway couldn't keep up with the 5,000 new headers there seemed to be per week. THEN there was a drift away from UDP and towards TCP for purely practical reasons, and TCP became mandatory to implement (but NOT, of course mandatory to use, as there were any number of bits of kit out there that didn't have support for it :). Long story, but in short -- with the continued introduction of bloat (e.g., IMHO all the web RTC driven stuff) UDP is getting VERY tight on MTU limits. That shouldn't be a problem but is because frags are not dealt with well by end systems (as customer router/end system IP stacks tend to be nasty brutish and short on development). SO ... TCP has advantages (as long as your system can handle many parallel TCP sessions), is marginally slower on initial set up, but doesn't have to maintain the t30 et al timer stuff. From memory, getting the TCP stack tweaked for ultra-high load systems was a pain and led to obscure behaviour, but available TCP stacks seem generally better now. UDP was simpler to map to message based systems at gateways, didn't have to use good IP stacks as you were rolling your own logic, but given the lard that is SIP/SDP now, that's the least of your coding worries. For carriers, I understand why they have a reflex against maintaining state, and they're using kit that is "mature". It's hard to justify replacing kit that's familiar, has a management UI your staff know, and had its costs amortised away years ago; VoIP is not a high profit service so the bean counters WILL ask. => TCP may be 'better', but UDP is in kit that isn't going away soon. all the best, Lawrence **: Remember, at the time ('97-'98) Henning Schulzrinne was teaching at Columbia University a post-grad course on IP comms during which he gave "implement a SIP-based voice call system" as a [two week] homework exercise, followed by interops between the clients. It had to be simple (and he was a "hard task master" [or words to that effect]; he knew that UDP forced all the timer logic to be coded as well). On 15 Feb 2016, at 16:35, Ken Rice <krice@freeswitch.org> wrote:
The problem still exists for expanding SDPs… using TCP to the user/device then trying to send the same thing out to the carrier over UDP is what was causing the problem in the first place… so the decision was made to prevent those problems we’ll only offer what the device offers and not expand the number of codecs even further increasing the already bloated SDPs to the point where they fragment over UDP and get dropped…
So is TCP better for some things, yes it is, however, the lack of market wide support for it with carriers makes it a pain in the ass even tho the RFCs specifically say you MUST support both UDP and TCP for SIP, but certain VoIP softwares out there only implemented UDP many years ago and now we’re stuck with that legacy
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Colton Conor Sent: Monday, February 15, 2016 10:30 AM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Freeswitch doesnt transcode
True,
But freeswitch talking to the carriers is almost always UPD.
However, freeswitch talking to the clients I would say TCP would be idea. So its almost like freeswitch is trancoding from TCP to UDP too :)
On Mon, Feb 15, 2016 at 10:25 AM, Ken Rice <krice@freeswitch.org> wrote: The problem isn’t necessarily the devices, but there is also the carriers…
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Colton Conor Sent: Monday, February 15, 2016 10:04 AM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Freeswitch doesnt transcode
So if the device supports TCP, is there any reason not to use TCP. AKA is there any reason to keep on using UDP. TCP seems superior.
On Mon, Feb 15, 2016 at 9:33 AM, Michael Jerris <mike@jerris.com> wrote: any device that even remotely follows sip specs supports TCP. Most phones I have seen do.
On Sunday, February 14, 2016, Colton Conor <colton.conor@gmail.com> wrote: So is TCP the preferred method of doing SIP these days? I like TCP with endpoints as they always break through firewalls and we never seem to have in issue with TCP. However UDP is a headache. So if you have the choice why not do TCP? I realize some devices only support UDP, but the majority of SIP phones out there today do support TCP.
Plus if you use TLS for encryption and security then you are already using TCP right?
On Sun, Feb 14, 2016 at 4:07 PM, Ken Rice <krice@freeswitch.org> wrote: This behavior changed a while ago. This was dictates by ever growing SDPs and exceeding MTUs causing udp fragmentation. Udp does not deal with fragmentation and everyone refuses to fully implement sip over tcp for some reason even tho a ton of things support it and the RFCs require it
Sent from my iPhone
On Feb 14, 2016, at 3:37 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
Thanks, after setting media_mix_inbound_outbound_codecs=true, transcoding happens automatically. I remember not setting this variable in other installations and transcoding used to work out of the box. Is media_mix_inbound_outbound_codecs=true default in Freeswitch?
On 14 February 2016 at 13:56, Russell Treleaven <rtreleaven@bunnykick.ca> wrote: fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation
On Sun, Feb 14, 2016 at 2:04 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
The siptrace is at http://pastebin.com/xiGqtj1Y
The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545.
On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com> wrote:
How you originate the call? Is a bridge? >From which phone?
Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin
Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com> ha scritto:
Hello,
I have a remote sip phone (Linksys SPA3102) which only supports PCMU. When I call to this remote sip phone i get a 406 error that opus is not supported as shown by the sip trace below. However, if I force the codec to absolute like this {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.5 the call works fine.
Is there anyway I can make FreeSWITCH to automatically transcode without forcing the codec string in the dial plan?
The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and outbound_codec_prefs=PCMU,PCMA,GSM
---------------------------siptrace--------------------------------
recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499:
------------------------------------------------------------------------ SIP/2.0 406 Not Acceptable Via: SIP/2.0/UDP
192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q CSeq: 87372504 INVITE Content-Length: 0
------------------------------------------------------------------------ send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591:
------------------------------------------------------------------------ ACK sip:303@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej Max-Forwards: 68 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 CSeq: 87372504 ACK Content-Length: 0
------------------------------------------------------------------------ 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel sofia/internal/303@192.168.1.5 entering state [terminated][406] 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup sofia/internal/303@192.168.1.5 [CS_CONSUME_MEDIA] [SERVICE_NOT_IMPLEMENTED]
Thanks Rajil
_________________________________________________________________________ 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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
Lawrence, Well Said! There is one upside., atleast Microsoft pushed the TCP stuff hard with Lync so maybe we'll start seeing more traction there... In reguards to the WebRTC stuff, imho SIP over WebRTC is a bit heavy handed... something simple like Verto provides a lower overhead (in the browser) and allows for push/pull eventing... wish we would see wider adoption of such things in the near to mid terms -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Lawrence Conroy Sent: Monday, February 15, 2016 12:45 PM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] TCP vs UDP (was Re: Freeswitch doesnt transcode) Hi Ken, Conor, folks, Along time ago in a land far away ... the [very] early history of SIP was tied up with a bunch of other multimedia SxP things. The big driver at that time was being able to do conferencing and media distribution -- after all, voice calls could be done with H.323 et al. The SDP (and SIP main part headers) were quite simple and small [**]. This was a message based scheme, and UDP is a messaging transport, as opposed to TCP which is a stream transport. IIRC, mapping from PSTN schemes (again, message-based systems) to UDP seemed simpler. TCP required maintaining transport session state in gateways, and the stacks in those gateways were primitive, to say the least. Despite that, folk pushing for TCP to be mandatory were told that it was considered 2nd class and should not be mandatory to implement); that was in '97 as I recall. Then (late 98 -> 2001) cable labs & 3GPP decided SIP was easier to bend to their will than H.323/224/..., and the number of headers grew like topsy, the complexity of the maintained state just kept on building, and we ran into fragment problems. Quick fix was header compression, but that ran into company-political issues in 3GPP and anyway couldn't keep up with the 5,000 new headers there seemed to be per week. THEN there was a drift away from UDP and towards TCP for purely practical reasons, and TCP became mandatory to implement (but NOT, of course mandatory to use, as there were any number of bits of kit out there that didn't have support for it :). Long story, but in short -- with the continued introduction of bloat (e.g., IMHO all the web RTC driven stuff) UDP is getting VERY tight on MTU limits. That shouldn't be a problem but is because frags are not dealt with well by end systems (as customer router/end system IP stacks tend to be nasty brutish and short on development). SO ... TCP has advantages (as long as your system can handle many parallel TCP sessions), is marginally slower on initial set up, but doesn't have to maintain the t30 et al timer stuff. From memory, getting the TCP stack tweaked for ultra-high load systems was a pain and led to obscure behaviour, but available TCP stacks seem generally better now. UDP was simpler to map to message based systems at gateways, didn't have to use good IP stacks as you were rolling your own logic, but given the lard that is SIP/SDP now, that's the least of your coding worries. For carriers, I understand why they have a reflex against maintaining state, and they're using kit that is "mature". It's hard to justify replacing kit that's familiar, has a management UI your staff know, and had its costs amortised away years ago; VoIP is not a high profit service so the bean counters WILL ask. => TCP may be 'better', but UDP is in kit that isn't going away soon. all the best, Lawrence **: Remember, at the time ('97-'98) Henning Schulzrinne was teaching at Columbia University a post-grad course on IP comms during which he gave "implement a SIP-based voice call system" as a [two week] homework exercise, followed by interops between the clients. It had to be simple (and he was a "hard task master" [or words to that effect]; he knew that UDP forced all the timer logic to be coded as well). On 15 Feb 2016, at 16:35, Ken Rice <krice@freeswitch.org> wrote:
The problem still exists for expanding SDPs. using TCP to the user/device then trying to send the same thing out to the carrier over UDP is what was causing the problem in the first place. so the decision was made to prevent those problems we'll only offer what the device offers and not expand the number of codecs even further increasing the already bloated SDPs to the point where they fragment over UDP and get dropped.
So is TCP better for some things, yes it is, however, the lack of market wide support for it with carriers makes it a pain in the ass even tho the RFCs specifically say you MUST support both UDP and TCP for SIP, but certain VoIP softwares out there only implemented UDP many years ago and now we're stuck with that legacy
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Colton Conor Sent: Monday, February 15, 2016 10:30 AM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Freeswitch doesnt transcode
True,
But freeswitch talking to the carriers is almost always UPD.
However, freeswitch talking to the clients I would say TCP would be idea. So its almost like freeswitch is trancoding from TCP to UDP too :)
On Mon, Feb 15, 2016 at 10:25 AM, Ken Rice <krice@freeswitch.org> wrote: The problem isn't necessarily the devices, but there is also the carriers.
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Colton Conor Sent: Monday, February 15, 2016 10:04 AM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Freeswitch doesnt transcode
So if the device supports TCP, is there any reason not to use TCP. AKA is there any reason to keep on using UDP. TCP seems superior.
On Mon, Feb 15, 2016 at 9:33 AM, Michael Jerris <mike@jerris.com> wrote: any device that even remotely follows sip specs supports TCP. Most phones I have seen do.
On Sunday, February 14, 2016, Colton Conor <colton.conor@gmail.com> wrote: So is TCP the preferred method of doing SIP these days? I like TCP with endpoints as they always break through firewalls and we never seem to have in issue with TCP. However UDP is a headache. So if you have the choice why not do TCP? I realize some devices only support UDP, but the majority of SIP phones out there today do support TCP.
Plus if you use TLS for encryption and security then you are already using TCP right?
On Sun, Feb 14, 2016 at 4:07 PM, Ken Rice <krice@freeswitch.org> wrote: This behavior changed a while ago. This was dictates by ever growing SDPs and exceeding MTUs causing udp fragmentation. Udp does not deal with fragmentation and everyone refuses to fully implement sip over tcp for some reason even tho a ton of things support it and the RFCs require it
Sent from my iPhone
On Feb 14, 2016, at 3:37 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
Thanks, after setting media_mix_inbound_outbound_codecs=true, transcoding happens automatically. I remember not setting this variable in other installations and transcoding used to work out of the box. Is media_mix_inbound_outbound_codecs=true default in Freeswitch?
On 14 February 2016 at 13:56, Russell Treleaven <rtreleaven@bunnykick.ca> wrote: fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiat ion
On Sun, Feb 14, 2016 at 2:04 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
The siptrace is at http://pastebin.com/xiGqtj1Y
The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545.
On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com> wrote:
How you originate the call? Is a bridge? >From which phone?
Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin
Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com> ha scritto:
Hello,
I have a remote sip phone (Linksys SPA3102) which only supports
PCMU.
When I call to this remote sip phone i get a 406 error that opus is not supported as shown by the sip trace below. However, if I force the codec to absolute like this {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1. 5 the call works fine.
Is there anyway I can make FreeSWITCH to automatically transcode without forcing the codec string in the dial plan?
The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and outbound_codec_prefs=PCMU,PCMA,GSM
---------------------------siptrace----------------------------- ---
recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499:
SIP/2.0 406 Not Acceptable Via: SIP/2.0/UDP
192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej
Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q CSeq: 87372504 INVITE Content-Length: 0
---------------------------------------------------------------- -------- send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591:
ACK sip:303@192.168.1.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej Max-Forwards: 68 From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 CSeq: 87372504 ACK Content-Length: 0
---------------------------------------------------------------- -------- 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel sofia/internal/303@192.168.1.5 entering state [terminated][406] 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup sofia/internal/303@192.168.1.5 [CS_CONSUME_MEDIA] [SERVICE_NOT_IMPLEMENTED]
Thanks Rajil
________________________________________________________________ _________ 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/freeswit ch-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/freeswitc h-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
___________________________________________________________________ ______ 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-u sers 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-use rs 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-use rs 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-use rs 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-use rs 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
With SDP getting bigger and bigger with presence packates and large invites with many codecs or video and WebRTC TCP will become mandatory. The spec on when to use TCP is very arcane. Use UDP first unless the packet is > MTU, change to TCP. If the TCP times out (1 to 10 min) retry UDP anyway. With some fun mixed in like you MUST be under the MTU and you also MUST support packets over udp up to 64kb. Implementing that used to cause communications with asterisk to take forever because they only did UDP so bigger SDP packets would timeout on TCP first and everyone called it a bug. If you anticipate using presence or really big packets use TCP. If you use WebRTC its already TCP. On Mon, Feb 15, 2016 at 12:53 PM, Ken Rice <krice@freeswitch.org> wrote:
Lawrence,
Well Said!
There is one upside., atleast Microsoft pushed the TCP stuff hard with Lync so maybe we'll start seeing more traction there...
In reguards to the WebRTC stuff, imho SIP over WebRTC is a bit heavy handed... something simple like Verto provides a lower overhead (in the browser) and allows for push/pull eventing... wish we would see wider adoption of such things in the near to mid terms
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Lawrence Conroy Sent: Monday, February 15, 2016 12:45 PM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] TCP vs UDP (was Re: Freeswitch doesnt transcode)
Hi Ken, Conor, folks, Along time ago in a land far away ... the [very] early history of SIP was tied up with a bunch of other multimedia SxP things. The big driver at that time was being able to do conferencing and media distribution -- after all, voice calls could be done with H.323 et al. The SDP (and SIP main part headers) were quite simple and small [**]. This was a message based scheme, and UDP is a messaging transport, as opposed to TCP which is a stream transport.
IIRC, mapping from PSTN schemes (again, message-based systems) to UDP seemed simpler. TCP required maintaining transport session state in gateways, and the stacks in those gateways were primitive, to say the least.
Despite that, folk pushing for TCP to be mandatory were told that it was considered 2nd class and should not be mandatory to implement); that was in '97 as I recall.
Then (late 98 -> 2001) cable labs & 3GPP decided SIP was easier to bend to their will than H.323/224/..., and the number of headers grew like topsy, the complexity of the maintained state just kept on building, and we ran into fragment problems. Quick fix was header compression, but that ran into company-political issues in 3GPP and anyway couldn't keep up with the 5,000 new headers there seemed to be per week. THEN there was a drift away from UDP and towards TCP for purely practical reasons, and TCP became mandatory to implement (but NOT, of course mandatory to use, as there were any number of bits of kit out there that didn't have support for it :).
Long story, but in short -- with the continued introduction of bloat (e.g., IMHO all the web RTC driven stuff) UDP is getting VERY tight on MTU limits. That shouldn't be a problem but is because frags are not dealt with well by end systems (as customer router/end system IP stacks tend to be nasty brutish and short on development).
SO ... TCP has advantages (as long as your system can handle many parallel TCP sessions), is marginally slower on initial set up, but doesn't have to maintain the t30 et al timer stuff. From memory, getting the TCP stack tweaked for ultra-high load systems was a pain and led to obscure behaviour, but available TCP stacks seem generally better now. UDP was simpler to map to message based systems at gateways, didn't have to use good IP stacks as you were rolling your own logic, but given the lard that is SIP/SDP now, that's the least of your coding worries.
For carriers, I understand why they have a reflex against maintaining state, and they're using kit that is "mature". It's hard to justify replacing kit that's familiar, has a management UI your staff know, and had its costs amortised away years ago; VoIP is not a high profit service so the bean counters WILL ask.
=> TCP may be 'better', but UDP is in kit that isn't going away soon.
all the best, Lawrence
**: Remember, at the time ('97-'98) Henning Schulzrinne was teaching at Columbia University a post-grad course on IP comms during which he gave "implement a SIP-based voice call system" as a [two week] homework exercise, followed by interops between the clients. It had to be simple (and he was a "hard task master" [or words to that effect]; he knew that UDP forced all the timer logic to be coded as well).
On 15 Feb 2016, at 16:35, Ken Rice <krice@freeswitch.org> wrote:
The problem still exists for expanding SDPs. using TCP to the user/device then trying to send the same thing out to the carrier over UDP is what was causing the problem in the first place. so the decision was made to prevent those problems we'll only offer what the device offers and not expand the number of codecs even further increasing the already bloated SDPs to the point where they fragment over UDP and get dropped.
So is TCP better for some things, yes it is, however, the lack of market wide support for it with carriers makes it a pain in the ass even tho the RFCs specifically say you MUST support both UDP and TCP for SIP, but certain VoIP softwares out there only implemented UDP many years ago and now we're stuck with that legacy
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Colton Conor Sent: Monday, February 15, 2016 10:30 AM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Freeswitch doesnt transcode
True,
But freeswitch talking to the carriers is almost always UPD.
However, freeswitch talking to the clients I would say TCP would be idea. So its almost like freeswitch is trancoding from TCP to UDP too :)
On Mon, Feb 15, 2016 at 10:25 AM, Ken Rice <krice@freeswitch.org> wrote: The problem isn't necessarily the devices, but there is also the carriers.
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Colton Conor Sent: Monday, February 15, 2016 10:04 AM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Freeswitch doesnt transcode
So if the device supports TCP, is there any reason not to use TCP. AKA is there any reason to keep on using UDP. TCP seems superior.
On Mon, Feb 15, 2016 at 9:33 AM, Michael Jerris <mike@jerris.com> wrote: any device that even remotely follows sip specs supports TCP. Most phones I have seen do.
On Sunday, February 14, 2016, Colton Conor <colton.conor@gmail.com> wrote: So is TCP the preferred method of doing SIP these days? I like TCP with endpoints as they always break through firewalls and we never seem to have in issue with TCP. However UDP is a headache. So if you have the choice why not do TCP? I realize some devices only support UDP, but the majority of SIP phones out there today do support TCP.
Plus if you use TLS for encryption and security then you are already using TCP right?
On Sun, Feb 14, 2016 at 4:07 PM, Ken Rice <krice@freeswitch.org> wrote: This behavior changed a while ago. This was dictates by ever growing SDPs and exceeding MTUs causing udp fragmentation. Udp does not deal with fragmentation and everyone refuses to fully implement sip over tcp for some reason even tho a ton of things support it and the RFCs require it
Sent from my iPhone
On Feb 14, 2016, at 3:37 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
Thanks, after setting media_mix_inbound_outbound_codecs=true, transcoding happens automatically. I remember not setting this variable in other installations and transcoding used to work out of the box. Is media_mix_inbound_outbound_codecs=true default in Freeswitch?
On 14 February 2016 at 13:56, Russell Treleaven <rtreleaven@bunnykick.ca> wrote: fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiat ion
On Sun, Feb 14, 2016 at 2:04 PM, Rajil Saraswat <rajil.s@gmail.com> wrote:
The siptrace is at http://pastebin.com/xiGqtj1Y
The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545.
On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com> wrote:
How you originate the call? Is a bridge? >From which phone?
Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin
Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com> ha scritto: > > Hello, > > I have a remote sip phone (Linksys SPA3102) which only supports PCMU. > When I call to this remote sip phone i get a 406 error that opus > is not supported as shown by the sip trace below. However, if I > force the codec to absolute like this > {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1. > 5 > the call works fine. > > Is there anyway I can make FreeSWITCH to automatically transcode > without forcing the codec string in the dial plan? > > The codec preferences is set as > global_codec_prefs=OPUS,PCMU,PCMA and > outbound_codec_prefs=PCMU,PCMA,GSM > > ---------------------------siptrace----------------------------- > --- > > recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499: > > >
> SIP/2.0 406 Not Acceptable > Via: SIP/2.0/UDP > > > 192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej > Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 > From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm > To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q > CSeq: 87372504 INVITE > Content-Length: 0 > > > > ---------------------------------------------------------------- > -------- send 324 bytes to udp/[192.168.1.5]:5060 at > 08:02:16.368591: > > >
> ACK sip:303@192.168.1.5 SIP/2.0 > Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej > Max-Forwards: 68 > From: "202" <sip:202@192.168.1.111>;tag=DFX0FUvr2vNcm > To: <sip:303@192.168.1.5>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q > Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 > CSeq: 87372504 ACK > Content-Length: 0 > > > > ---------------------------------------------------------------- > -------- > 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel > sofia/internal/303@192.168.1.5 entering state [terminated][406] > 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup > sofia/internal/303@192.168.1.5 [CS_CONSUME_MEDIA] > [SERVICE_NOT_IMPLEMENTED] > > Thanks > Rajil > > > ________________________________________________________________ > _________ 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/freeswit > ch-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/freeswitc h-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
___________________________________________________________________ ______ 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-u sers 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-use rs 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-use rs 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-use rs 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-use rs 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
_________________________________________________________________________ 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
-- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬ ☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>* ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900 https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
And that’s the reason as to why Lync is TCP-only. The commonly large payloads would always be above the SIP MTU meaning they’d need to switch to TCP. Instead of dealing with the pain of doing both (and the joy of adding that to interop tests), it was easier to simply do TCP-only. And really, people should just be using TLS anyways (but UDP+IPSec seems more common). Also FWIW, it’s easier to defend some attacks on TCP than UDP; at least it eliminates IP spoofing. (Enable syn cookies versus running a most-likely-buggy SIP parser on each message.) IP frag may not actually be an issue in practise. I looked at the signaling for a VoIP company with tens of thousands of end users. About 1% of all UDP SIP signaling was IP frag’d, though usually around 576 bytes. This had no noticeable impact on service (i.e., I didn’t see any related retransmits). But this is really just an anecdote. -Michael From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Monday, 15 February, 2016 13:27 To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] TCP vs UDP (was Re: Freeswitch doesnt transcode) With SDP getting bigger and bigger with presence packates and large invites with many codecs or video and WebRTC TCP will become mandatory. The spec on when to use TCP is very arcane. Use UDP first unless the packet is > MTU, change to TCP. If the TCP times out (1 to 10 min) retry UDP anyway. With some fun mixed in like you MUST be under the MTU and you also MUST support packets over udp up to 64kb. Implementing that used to cause communications with asterisk to take forever because they only did UDP so bigger SDP packets would timeout on TCP first and everyone called it a bug. If you anticipate using presence or really big packets use TCP. If you use WebRTC its already TCP. On Mon, Feb 15, 2016 at 12:53 PM, Ken Rice <krice@freeswitch.org<mailto:krice@freeswitch.org>> wrote: Lawrence, Well Said! There is one upside., atleast Microsoft pushed the TCP stuff hard with Lync so maybe we'll start seeing more traction there... In reguards to the WebRTC stuff, imho SIP over WebRTC is a bit heavy handed... something simple like Verto provides a lower overhead (in the browser) and allows for push/pull eventing... wish we would see wider adoption of such things in the near to mid terms -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Lawrence Conroy Sent: Monday, February 15, 2016 12:45 PM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org<mailto:freeswitch-users@lists.freeswitch.org>> Subject: Re: [Freeswitch-users] TCP vs UDP (was Re: Freeswitch doesnt transcode) Hi Ken, Conor, folks, Along time ago in a land far away ... the [very] early history of SIP was tied up with a bunch of other multimedia SxP things. The big driver at that time was being able to do conferencing and media distribution -- after all, voice calls could be done with H.323 et al. The SDP (and SIP main part headers) were quite simple and small [**]. This was a message based scheme, and UDP is a messaging transport, as opposed to TCP which is a stream transport. IIRC, mapping from PSTN schemes (again, message-based systems) to UDP seemed simpler. TCP required maintaining transport session state in gateways, and the stacks in those gateways were primitive, to say the least. Despite that, folk pushing for TCP to be mandatory were told that it was considered 2nd class and should not be mandatory to implement); that was in '97 as I recall. Then (late 98 -> 2001) cable labs & 3GPP decided SIP was easier to bend to their will than H.323/224/..., and the number of headers grew like topsy, the complexity of the maintained state just kept on building, and we ran into fragment problems. Quick fix was header compression, but that ran into company-political issues in 3GPP and anyway couldn't keep up with the 5,000 new headers there seemed to be per week. THEN there was a drift away from UDP and towards TCP for purely practical reasons, and TCP became mandatory to implement (but NOT, of course mandatory to use, as there were any number of bits of kit out there that didn't have support for it :). Long story, but in short -- with the continued introduction of bloat (e.g., IMHO all the web RTC driven stuff) UDP is getting VERY tight on MTU limits. That shouldn't be a problem but is because frags are not dealt with well by end systems (as customer router/end system IP stacks tend to be nasty brutish and short on development). SO ... TCP has advantages (as long as your system can handle many parallel TCP sessions), is marginally slower on initial set up, but doesn't have to maintain the t30 et al timer stuff. From memory, getting the TCP stack tweaked for ultra-high load systems was a pain and led to obscure behaviour, but available TCP stacks seem generally better now. UDP was simpler to map to message based systems at gateways, didn't have to use good IP stacks as you were rolling your own logic, but given the lard that is SIP/SDP now, that's the least of your coding worries. For carriers, I understand why they have a reflex against maintaining state, and they're using kit that is "mature". It's hard to justify replacing kit that's familiar, has a management UI your staff know, and had its costs amortised away years ago; VoIP is not a high profit service so the bean counters WILL ask. => TCP may be 'better', but UDP is in kit that isn't going away soon. all the best, Lawrence **: Remember, at the time ('97-'98) Henning Schulzrinne was teaching at Columbia University a post-grad course on IP comms during which he gave "implement a SIP-based voice call system" as a [two week] homework exercise, followed by interops between the clients. It had to be simple (and he was a "hard task master" [or words to that effect]; he knew that UDP forced all the timer logic to be coded as well). On 15 Feb 2016, at 16:35, Ken Rice <krice@freeswitch.org<mailto:krice@freeswitch.org>> wrote:
The problem still exists for expanding SDPs. using TCP to the user/device then trying to send the same thing out to the carrier over UDP is what was causing the problem in the first place. so the decision was made to prevent those problems we'll only offer what the device offers and not expand the number of codecs even further increasing the already bloated SDPs to the point where they fragment over UDP and get dropped.
So is TCP better for some things, yes it is, however, the lack of market wide support for it with carriers makes it a pain in the ass even tho the RFCs specifically say you MUST support both UDP and TCP for SIP, but certain VoIP softwares out there only implemented UDP many years ago and now we're stuck with that legacy
From: freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Colton Conor Sent: Monday, February 15, 2016 10:30 AM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org<mailto:freeswitch-users@lists.freeswitch.org>> Subject: Re: [Freeswitch-users] Freeswitch doesnt transcode
True,
But freeswitch talking to the carriers is almost always UPD.
However, freeswitch talking to the clients I would say TCP would be idea. So its almost like freeswitch is trancoding from TCP to UDP too :)
On Mon, Feb 15, 2016 at 10:25 AM, Ken Rice <krice@freeswitch.org<mailto:krice@freeswitch.org>> wrote: The problem isn't necessarily the devices, but there is also the carriers.
From: freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Colton Conor Sent: Monday, February 15, 2016 10:04 AM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org<mailto:freeswitch-users@lists.freeswitch.org>> Subject: Re: [Freeswitch-users] Freeswitch doesnt transcode
So if the device supports TCP, is there any reason not to use TCP. AKA is there any reason to keep on using UDP. TCP seems superior.
On Mon, Feb 15, 2016 at 9:33 AM, Michael Jerris <mike@jerris.com<mailto:mike@jerris.com>> wrote: any device that even remotely follows sip specs supports TCP. Most phones I have seen do.
On Sunday, February 14, 2016, Colton Conor <colton.conor@gmail.com<mailto:colton.conor@gmail.com>> wrote: So is TCP the preferred method of doing SIP these days? I like TCP with endpoints as they always break through firewalls and we never seem to have in issue with TCP. However UDP is a headache. So if you have the choice why not do TCP? I realize some devices only support UDP, but the majority of SIP phones out there today do support TCP.
Plus if you use TLS for encryption and security then you are already using TCP right?
On Sun, Feb 14, 2016 at 4:07 PM, Ken Rice <krice@freeswitch.org<mailto:krice@freeswitch.org>> wrote: This behavior changed a while ago. This was dictates by ever growing SDPs and exceeding MTUs causing udp fragmentation. Udp does not deal with fragmentation and everyone refuses to fully implement sip over tcp for some reason even tho a ton of things support it and the RFCs require it
Sent from my iPhone
On Feb 14, 2016, at 3:37 PM, Rajil Saraswat <rajil.s@gmail.com<mailto:rajil.s@gmail.com>> wrote:
Thanks, after setting media_mix_inbound_outbound_codecs=true, transcoding happens automatically. I remember not setting this variable in other installations and transcoding used to work out of the box. Is media_mix_inbound_outbound_codecs=true default in Freeswitch?
On 14 February 2016 at 13:56, Russell Treleaven <rtreleaven@bunnykick.ca<mailto:rtreleaven@bunnykick.ca>> wrote: fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiat ion
On Sun, Feb 14, 2016 at 2:04 PM, Rajil Saraswat <rajil.s@gmail.com<mailto:rajil.s@gmail.com>> wrote:
The siptrace is at http://pastebin.com/xiGqtj1Y
The call is being made from 303 (Android/CSipsimple with OPUS codec) to 208 (pjsua test client with PCMU codec). The error is on line 545.
On 14 February 2016 at 11:28, Giovanni Maruzzelli <gmaruzz@gmail.com<mailto:gmaruzz@gmail.com>> wrote:
How you originate the call? Is a bridge? >From which phone?
Also, please pastebin the complete sip trace (from start of leg A to end of both legs) and put here a link to pastebin
Il 14/Feb/2016 03:54, "Rajil Saraswat" <rajil.s@gmail.com<mailto:rajil.s@gmail.com>> ha scritto:
Hello,
I have a remote sip phone (Linksys SPA3102) which only supports
PCMU.
When I call to this remote sip phone i get a 406 error that opus is not supported as shown by the sip trace below. However, if I force the codec to absolute like this {absolute_codec_string='PCMU,PCMA'}sofia/internal/303@192.168.1.<mailto:303@192.168.1.> 5 the call works fine.
Is there anyway I can make FreeSWITCH to automatically transcode without forcing the codec string in the dial plan?
The codec preferences is set as global_codec_prefs=OPUS,PCMU,PCMA and outbound_codec_prefs=PCMU,PCMA,GSM
---------------------------siptrace----------------------------- ---
recv 333 bytes from udp/[192.168.1.5]:5060 at 08:02:16.368499:
SIP/2.0 406 Not Acceptable Via: SIP/2.0/UDP
192.168.1.111;rport=5060;received=192.168.1.111;branch=z9hG4bKeS356tttajjej
Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 From: "202" <sip:202@192.168.1.111<mailto:sip%3A202@192.168.1.111>>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5<mailto:sip%3A303@192.168.1.5>>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q CSeq: 87372504 INVITE Content-Length: 0
---------------------------------------------------------------- -------- send 324 bytes to udp/[192.168.1.5]:5060 at 08:02:16.368591:
ACK sip:303@192.168.1.5<mailto:sip%3A303@192.168.1.5> SIP/2.0 Via: SIP/2.0/UDP 192.168.1.111;rport;branch=z9hG4bKeS356tttajjej Max-Forwards: 68 From: "202" <sip:202@192.168.1.111<mailto:sip%3A202@192.168.1.111>>;tag=DFX0FUvr2vNcm To: <sip:303@192.168.1.5<mailto:sip%3A303@192.168.1.5>>;tag=htMF9ckdglw3EJRZaILd6XWt4uVKAO8q Call-ID: 00ff246a-4d66-1234-f4b2-74d02b7a3124 CSeq: 87372504 ACK Content-Length: 0
---------------------------------------------------------------- -------- 2016-02-14 08:02:16.356283 [DEBUG] sofia.c:6760 Channel sofia/internal/303@192.168.1.5<mailto:303@192.168.1.5> entering state [terminated][406] 2016-02-14 08:02:16.356283 [NOTICE] sofia.c:7779 Hangup sofia/internal/303@192.168.1.5<mailto:303@192.168.1.5> [CS_CONSUME_MEDIA] [SERVICE_NOT_IMPLEMENTED]
Thanks Rajil
________________________________________________________________ _________ 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/freeswit ch-users 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<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitc h-users 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<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
___________________________________________________________________ ______ 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
____________________________________________________________________ _____ 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-u sers 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<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-use rs 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<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-use rs 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<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-use rs 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<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-use rs 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<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 _________________________________________________________________________ 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 -- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬ ☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net<http://irc.freenode.net> #freeswitch ☞ http://freeswitch.org/g+ ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org<mailto:sip%3A888@conference.freeswitch.org> ☎ +19193869900 https://www.youtube.com/watch?v=9XXgW34t40s https://www.youtube.com/watch?v=NLaDpGQuZDA
On Sun, Feb 14, 2016 at 1:56 PM, Russell Treleaven <rtreleaven@bunnykick.ca> wrote:
fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation
That is a really lucid and complete description of CODEC negotiation in FS. Thanks for the link, and thanks to the original author for writing it. Bob
google freeswitch behavior change we did send out warnings, change logged it, WIR'ed the change too. ;) Thanks, On Mon, Feb 15, 2016 at 12:27 PM, Bob Hartwig <bobjectsfreeswitch@gmail.com> wrote:
On Sun, Feb 14, 2016 at 1:56 PM, Russell Treleaven < rtreleaven@bunnykick.ca> wrote:
fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation
That is a really lucid and complete description of CODEC negotiation in FS. Thanks for the link, and thanks to the original author for writing it.
Bob
_________________________________________________________________________ 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
-- *Brian West* brian@freeswitch.org *Twitter: @FreeSWITCH , @briankwest* http://www.freeswitchbook.com http://www.freeswitchcookbook.com Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch> *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
What? People are supposed to pay attention to announcements that the FreeSWITCH Dev Team makes?!@ what is this tom foolery? From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Brian West Sent: Monday, February 15, 2016 1:35 PM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Freeswitch doesnt transcode google freeswitch behavior change we did send out warnings, change logged it, WIR'ed the change too. ;) Thanks, On Mon, Feb 15, 2016 at 12:27 PM, Bob Hartwig <bobjectsfreeswitch@gmail.com <mailto:bobjectsfreeswitch@gmail.com> > wrote: On Sun, Feb 14, 2016 at 1:56 PM, Russell Treleaven <rtreleaven@bunnykick.ca <mailto:rtreleaven@bunnykick.ca> > wrote: fyi https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation That is a really lucid and complete description of CODEC negotiation in FS. Thanks for the link, and thanks to the original author for writing it. Bob _________________________________________________________________________ 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 -- Brian West brian@freeswitch.org <mailto:brian@freeswitch.org> <http://billing.freeswitch.org/templates/default/img/whmcslogo.png> Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com Got Bugs? Report them here <https://freeswitch.org/jira> ! | Reddit: /r/freeswitch <https://www.reddit.com/r/freeswitch> T:+19184209001 | F:+19184209002 | M:+1918424WEST (9378) iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype:briankwest
participants (11)
-
Anthony Minessale
-
Bob Hartwig
-
Brian West
-
Colton Conor
-
Giovanni Maruzzelli
-
Ken Rice
-
Lawrence Conroy
-
Michael Giagnocavo
-
Michael Jerris
-
Rajil Saraswat
-
Russell Treleaven