[Freeswitch-users] WebRTC Calls via Kamailio rejecting with 488
Michael Jerris
mike at jerris.com
Thu Aug 21 20:23:57 MSD 2014
There is an option in sipml5 to make it not send it like that, i think we have that \option set on ours.
On Aug 21, 2014, at 11:00 AM, Brian West <brian at freeswitch.org> wrote:
> We should support UDP/TLS/RTP/SAVPF without much issue, So i'm puzzled as to why you've had a problem, We have sipml5/jssip/sipjs all working without a problem direct to WSS/WS to FreeSWITCH.
>
>
> On Wed, Aug 20, 2014 at 4:47 PM, Kamrul Khan <dodul at live.com> wrote:
> No thats not what we want to do. But, we figured out the issue. Our sipml5 webclient is sending media profile thats not supported by slandered SIP. sipml5 sends something like,
>
> m=audio 56381 UDP/TLS/RTP/SAVPF 109 0 8 101
>
> However, as far as we concern, according to standard SIP definition, the UDP/TLS/ part shouldn't be there. (Probably this is an addition for webRTP). Our Asterisk server took the call cause we had SRTP-DTLS configured there.
>
> So, now we stripped off the UDP/TLS/ part from kamailio (sending RTP/AVP only) and now calls are going through.
>
> Thanks for your help guys!
>
>
> --Forwarded Message Attachment--
> From: brian at freeswitch.org
> To: freeswitch-users at lists.freeswitch.org
> Date: Wed, 20 Aug 2014 15:59:41 -0500
>
> Subject: Re: [Freeswitch-users] WebRTC Calls via Kamailio rejecting with 488
>
> have you tried talking directly to FreeSWITCH via websockets?
>
>
> On Wed, Aug 20, 2014 at 3:23 PM, Kamrul Khan <dodul at live.com> wrote:
>
> No I didnt
>
>
> --Forwarded Message Attachment--
> From: brian at freeswitch.org
> To: freeswitch-users at lists.freeswitch.org
> Date: Wed, 20 Aug 2014 14:03:43 -0500
> Subject: Re: [Freeswitch-users] WebRTC Calls via Kamailio rejecting with 488
>
>
> Have you modified the default sofia profile codec preferences at all?
>
>
> On Wed, Aug 20, 2014 at 1:47 PM, Kamrul Khan <dodul at live.com> wrote:
> Hi,
>
> This is the continuation of my previous mail, "Freeswitch srtp rejecting SRTP with 488". I have changed the subject line as according to the feedback from this mailing list Im convinced its not a SRTP issue. Let me describe my scenario a bit more detail.
>
> I am generating call from a webclient using simpl5. The call then hits a Kamailio server and Kamailio here acts like a webRTC proxy that forwards the call to Freeswitch. Freeswitch receives the call on udp port 5060. (not over websocket)
>
> We tested the same thing with asterisk and thats working fine. but when we try it with Freeswitch it rejects the call with 488. And in console log it shows [CS_NEW] [INCOMPATIBLE_DESTINATION]
>
> Now, we assume (as per the feedback from this mailing list) the issue is not with SRTP but with codec negotiation. Therefore, for testing purpose we stripped off all the codec attributes from our INVITE leaving only rtpmap:0 PCMU/8000 and tested again. We were hoping to see something new in our console log this time but surprisingly it showed up the exact same log as before. The console log is given below. Please somebody give us some clue whats going wrong? Thanks in advanced.
>
> 2014-08-20 05:03:42.183856 [DEBUG] sofia.c:5847 IP 192.168.146.133 Rejected by acl "domains". Falling back to Digest auth.
> 2014-08-20 05:03:42.253550 [DEBUG] sofia.c:5847 IP 192.168.146.133 Rejected by acl "domains". Falling back to Digest auth.
> 2014-08-20 05:03:42.269373 [NOTICE] switch_channel.c:669 New Channel sofia/internal/alice at 192.168.146.133 [07526f12-2862-11e4-8afd-9de9b4eb98f8]
> 2014-08-20 05:03:42.272360 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/alice at 192.168.146.133) Running State Change CS_NEW
> 2014-08-20 05:03:42.272360 [DEBUG] switch_core_state_machine.c:320 (sofia/internal/alice at 192.168.146.133) State NEW
> 2014-08-20 05:03:42.281094 [DEBUG] sofia.c:4153 Channel sofia/internal/alice at 192.168.146.133 entering state [received][100]
> 2014-08-20 05:03:42.281094 [DEBUG] sofia.c:4164 Remote SDP:
> v=0
> o=Mozilla-SIPUA-31.0 20849 1 IN IP4 0.0.0.0
> s=Doubango Telecom - firefox
> t=0 0
> a=ice-ufrag:ca607972
> a=ice-pwd:dd5932ce75801e50fae435678cd6755b
> a=fingerprint:sha-256 8B:B0:38:A0:DA:3D:7C:DE:7F:76:F0:35:AF:1A:DE:E9:25:8C:16:E7:D4:3F:75:B2:64:56:79:21:2D:16:7D:05
> m=audio 57096 UDP/RTP 0
> c=IN IP4 184.69.59.132
> a=ptime:20
> a=rtpmap:0 PCMU/8000
> a=fmtp:101 0-15
> a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
> a=setup:actpass
> a=candidate:0 1 UDP 2128609535 172.16.1.188 57096 typ host
> a=candidate:1 1 UDP 1692467199 184.69.59.132 57096 typ srflx raddr 172.16.1.188 rport 57096
> a=candidate:5 1 UDP 2128543999 192.168.56.1 57097 typ host
> a=candidate:10 1 UDP 2128478463 192.168.232.1 57098 typ host
> a=candidate:15 1 UDP 2128412927 192.168.146.1 57099 typ host
> a=candidate:0 2 UDP 2128609534 172.16.1.188 57100 typ host
> a=candidate:1 2 UDP 1692467198 184.69.59.132 57100 typ srflx raddr 172.16.1.188 rport 57100
> a=candidate:5 2 UDP 2128543998 192.168.56.1 57101 typ host
> a=candidate:10 2 UDP 2128478462 192.168.232.1 57102 typ host
> a=candidate:15 2 UDP 2128412926 192.168.146.1 57103 typ host
> a=rtcp-mux
>
> 2014-08-20 05:03:42.281094 [NOTICE] sofia.c:4354 Hangup sofia/internal/alice at 192.168.146.133 [CS_NEW] [INCOMPATIBLE_DESTINATION]
> 2014-08-20 05:03:42.281094 [DEBUG] switch_channel.c:2102 Send signal sofia/internal/alice at 192.168.146.133 [KILL]
> 2014-08-20 05:03:42.282146 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/alice at 192.168.146.133 [BREAK]
> 2014-08-20 05:03:42.282146 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/alice at 192.168.146.133) Running State Change CS_HANGUP
> 2014-08-20 05:03:42.282146 [DEBUG] switch_core_state_machine.c:499 (sofia/internal/alice at 192.168.146.133) State HANGUP
> 2014-08-20 05:03:42.282146 [DEBUG] mod_sofia.c:414 Channel sofia/internal/alice at 192.168.146.133 hanging up, cause: INCOMPATIBLE_DESTINATION
> 2014-08-20 05:03:42.328550 [DEBUG] mod_sofia.c:476 Responding to INVITE with: 488
> 2014-08-20 05:03:42.328550 [DEBUG] switch_core_state_machine.c:46 sofia/internal/alice at 192.168.146.133 Standard HANGUP, cause: INCOMPATIBLE_DESTINATION
> 2014-08-20 05:03:42.328550 [DEBUG] switch_core_state_machine.c:499 (sofia/internal/alice at 192.168.146.133) State HANGUP going to sleep
> 2014-08-20 05:03:42.328550 [DEBUG] switch_core_state_machine.c:333 (sofia/internal/alice at 192.168.146.133) State Change CS_HANGUP -> CS_REPORTING
> 2014-08-20 05:03:42.328550 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/alice at 192.168.146.133 [BREAK]
> 2014-08-20 05:03:42.328550 [DEBUG] switch_core_state_machine.c:314 (sofia/internal/alice at 192.168.146.133) Running State Change CS_REPORTING
> 2014-08-20 05:03:42.328550 [DEBUG] switch_core_state_machine.c:590 (sofia/internal/alice at 192.168.146.133) State REPORTING
> 2014-08-20 05:03:42.328550 [DEBUG] switch_core_state_machine.c:53 sofia/internal/alice at 192.168.146.133 Standard REPORTING, cause: INCOMPATIBLE_DESTINATION
> 2014-08-20 05:03:42.328550 [DEBUG] switch_core_state_machine.c:590 (sofia/internal/alice at 192.168.146.133) State REPORTING going to sleep
> 2014-08-20 05:03:42.328550 [DEBUG] switch_core_state_machine.c:327 (sofia/internal/alice at 192.168.146.133) State Change CS_REPORTING -> CS_DESTROY
> 2014-08-20 05:03:42.328550 [DEBUG] switch_core_session.c:1021 Send signal sofia/internal/alice at 192.168.146.133 [BREAK]
> 2014-08-20 05:03:42.328550 [DEBUG] switch_core_session.c:1164 Session 18 (sofia/internal/alice at 192.168.146.133) Locked, Waiting on external entities
> 2014-08-20 05:03:42.328550 [NOTICE] switch_core_session.c:1182 Session 18 (sofia/internal/alice at 192.168.146.133) Ended
> 2014-08-20 05:03:42.328550 [NOTICE] switch_core_session.c:1184 Close Channel sofia/internal/alice at 192.168.146.133 [CS_DESTROY]
> 2014-08-20 05:03:42.328550 [DEBUG] switch_core_state_machine.c:428 (sofia/internal/alice at 192.168.146.133) Running State Change CS_DESTROY
> 2014-08-20 05:03:42.328550 [DEBUG] switch_core_state_machine.c:439 (sofia/internal/alice at 192.168.146.133) State DESTROY
> 2014-08-20 05:03:42.328550 [DEBUG] mod_sofia.c:341 sofia/internal/alice at 192.168.146.133 SOFIA DESTROY
> 2014-08-20 05:03:42.328550 [DEBUG] switch_core_state_machine.c:60 sofia/internal/alice at 192.168.146.133 Standard DESTROY
> 2014-08-20 05:03:42.328550 [DEBUG] switch_core_state_machine.c:439 (sofia/internal/alice at 192.168.146.133) State DESTROY going to sleep
>
>
> From: freeswitch-users-request at lists.freeswitch.org
> Subject: FreeSWITCH-users Digest, Vol 98, Issue 138
> To: freeswitch-users at lists.freeswitch.org
> Date: Wed, 20 Aug 2014 22:18:01 +0400
>
> Send FreeSWITCH-users mailing list submissions to
> freeswitch-users at lists.freeswitch.org
>
>
>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> or, via email, send a message with subject or body 'help' to
>
>
>
> freeswitch-users-request at lists.freeswitch.org
>
> You can reach the person managing the list at
> freeswitch-users-owner at lists.freeswitch.org
>
>
>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of FreeSWITCH-users digest..."
>
>
> --Forwarded Message Attachment--
> From: andretodd at verizon.net
> To: freeswitch-users at lists.freeswitch.org
> Date: Wed, 20 Aug 2014 13:35:01 -0400
> Subject: Re: [Freeswitch-users] high pdd
>
> Hi, I’m using the master. Should I try 1.4.7?
>
> I’ve done a dump after things started to go bad/ backed up.
>
> I see 8193 threads in _thread_cond_timedwait. Looks like its on line 81 of thread_cond.c res = WaitForSingleObject(cond->semaphore, timeout_ms);
>
> The value of timeout_ms is 2016850392.
>
> Not sure if this means anything.
>
> Thanks for the support guys.
>
> Andre
>
> From: freeswitch-users-bounces at lists.freeswitch.org [mailto:freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of Brian West
> Sent: Wednesday, August 20, 2014 11:57 AM
> To: FreeSWITCH Users Help
> Subject: Re: [Freeswitch-users] high pdd
>
> 1.2.X is EOL,
>
> 1.4.7 is the current release.
>
> We have releases and tags in git that no longer carry the 'stable' moniker starting with 1.4.
>
> On Sun, Aug 17, 2014 at 1:39 PM, Andre Demattia <andretodd at verizon.net> wrote:
> Thanks, I'm using the newest master and the last stable 1.2.23
> We are willing to pay to get this fixed.
> Andre
> From: Anthony Minessale
> Sent: 8/17/2014 12:30 PM
>
> To: Freeswitch-users
> Subject: Re: [Freeswitch-users] high pdd
> We dont have a lot of tools to troubleshoot windows. You should mention windows in your subject to have a better chance to get the attention of our windows users.
> You should consider installing debian 7 on the same hardware and perform similar tests to help determine if your issue is o/s specific or not.
> You also have not indicated the revision of FS. If you have not worked with latest master, you should be also to rule out improvements.
> On Aug 17, 2014 9:54 AM, "Andre Demattia" <andretodd at verizon.net> wrote:
> Yes that's off and I believe all the databases are off too. No authentication or registration is enabled. The sizes of the database are 0 until I call the shutdown command then its about 90k. I have the DBS in Ra drive too.
>
> Windows seems pretty good until the 3000 sessions per min mark. Then I just get long pdd and the threads get backed up then no more sessions can be created.
>
> Funny thing is I has 10 profiles and the same results. I also tried two consoles with the same results.
>
> FreeSWITCH is great.
>
> I'd be grateful for help. I've worked on this for 2 years and hate to give up.
>
> If any one from consulting at freeswitch.org is willing to help I'd appreciate that.
>
> Thanks again,
> Andre
> From: Anthony Minessale
> Sent: 8/17/2014 10:13 AM
> To: Freeswitch-users
> Subject: Re: [Freeswitch-users] high pdd
> Did you comment out manage-presence ? Also we have no real idea how well FS performs in windows under extreme load.
> On Aug 17, 2014 5:42 AM, "Andre Demattia" <andretodd at verizon.net> wrote:
> Thanks Ken, I'll try the consulting again.
> Andre
> From: Ken Rice
> Sent: 8/17/2014 1:19 AM
> To: FreeSWITCH Users Help
> Subject: Re: [Freeswitch-users] high pdd
> if the last post does not work contact consulting at freeswitch.org for pro help from one of the developers... thats about as far as the list will take you
> Ken
> Sent from my iPad
>
> On Aug 16, 2014, at 15:23, "Andre" <andretodd at verizon.net> wrote:
> Going with the idea it’s IO related I did a db_cache status. I just disabled limit in my code by removing it but limit should be HASH not a database however I stills how a database.
>
> Below is the results of the db cache status. I’m not real sure what its saying. I should have all registration and limit disabled and should not be using any sql database from my understanding.
>
> Anyone know what the results mean? I’ve only tested 2 calls on this status.
>
> [The entire original message is not included.]
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>
> [The entire original message is not included.]
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at 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 at 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 at freeswitch.org
>
> Twitter: @FreeSWITCH , @briankwest
> http://www.freeswitchbook.com
> http://www.freeswitchcookbook.com
> T:+19184209001 | F:+19184209002 | M:+1918424WEST (9378)
> iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype:briankwest
>
>
> --Forwarded Message Attachment--
> From: stuart.mills3 at btopenworld.com
> To: freeswitch-users at lists.freeswitch.org
> Date: Wed, 20 Aug 2014 19:17:34 +0100
> Subject: Re: [Freeswitch-users] Media after hang-up???
>
> Hi Mike,
>
> Thanks for the reply.
>
> I know for sure this isn’t FreeSWITCH causing the issue, I get the CDR posted at the right time and durations are correct, it’s almost as if the far end PBX hasn’t noticed the hang-up, even though the BYE does get sent.
>
> My carrier mentioned today (following a full trace from their end) that the PBX isn’t sending an ACK to the BYE, does that make any sense given the issue I am seeing? My main issue here is if it’s a PBX configuration issue, I am unable to look at and diagnose myself, so some sort of starting point would be really helpful .
>
> Cheers,
>
> Stuart
>
> From: Michael Jerris
> Sent: Wednesday, August 20, 2014 5:25 PM
> To: FreeSWITCH Users Help
> Subject: Re: [Freeswitch-users] Media after hang-up???
>
> I have never seen an issue like this, a pcap might tell you more, but i seriously doubt we are still sending media after the call hangs up. I would suggest taking a look at a pcap and the debug logs and seeing that the call is actually being hung up on the leg facing the pbx and we really stop sending media.
>
> Mike
>
> On Aug 19, 2014, at 8:19 PM, Stuart Mills <stuart.mills3 at btopenworld.com> wrote:
>
> Hi,
>
> I’m experiencing a strange issue calling a destination within the UK, whereby media seems to still be connected after hang up.
>
> I only know this as the destination is a PBX, supplied by Unify (formerly Siemens), and that PBX on occasions records a voicemail, when a message is taken and after the call is hung up, there is a continuous tone heard on the end of the recording. The call logs show the right duration and the carrier has also confirmed that the call ended as the logs suggest.
>
> So, I’m wondering if anyone else has come across the same sort of issue using FreeSWITCH? The end user has told me they never used to experience this issue using a different provider, and I can’t reproduce this issue at all using other types of PBX, all calls end as they should and voicemail recordings end when the call does.
>
> This issue doesn’t seem to be a FreeSWITCH one, just thought it worth an ask to the group.
>
> Cheers,
>
> Stuart
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at 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 at 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 at 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 at 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 at freeswitch.org
>
>
> Twitter: @FreeSWITCH , @briankwest
> http://www.freeswitchbook.com
> http://www.freeswitchcookbook.com
> T:+19184209001 | F:+19184209002 | M:+1918424WEST (9378)
> iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype:briankwest
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at 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 at 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 at freeswitch.org
>
>
> Twitter: @FreeSWITCH , @briankwest
> http://www.freeswitchbook.com
> http://www.freeswitchcookbook.com
> T:+19184209001 | F:+19184209002 | M:+1918424WEST (9378)
> iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype:briankwest
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at 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 at 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 at freeswitch.org
>
>
>
> Twitter: @FreeSWITCH , @briankwest
> http://www.freeswitchbook.com
> http://www.freeswitchcookbook.com
>
> T:+19184209001 | F:+19184209002 | M:+1918424WEST (9378)
> iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype:briankwest
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140821/fb8530a5/attachment-0001.html
Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users
mailing list