Just to make this as completely clear as possible, as this is the 4th or 5th thread on a similar issue. JSSIP IS KNOWN TO BE BROKEN AND DOES NOT RELIABLY WORK FOR ANYONE I HAVE SEEN POST ABOUT IT. Every single person i have mentioned this to has for whatever reason resisted changing to sip.js. Everyone has eventually switched to use sip.js and all of the issues they were reporting have disappeared once switching. Sip.js is a fork of jssip which fixed many of the issues found in jssip, and it is nearly api compatible, and they have a documented guide for how to switch. If anyone is having an issue with jssip, the first thing I am going to ask is if the same issue happens on sip.js. We are not going to spend any time trying to troubleshoot an issue with another piece of software that we have a long line of people acknowledging is fundamentally broken. Furthermore, the entire concept of sip in javascript is not particularly useful. We have spent the time to write an alternate endpoint, verto, which addresses many of the feature and fundamental design problems with the js sip support. We highly recommend using verto instead of sip to communicate with webrtc. Mike
On Jun 22, 2015, at 3:36 PM, Oleg Stolyar <olegstolyar@gmail.com> wrote:
Ah, got it. My bad.
On Mon, Jun 22, 2015 at 12:28 PM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>> wrote: 0 is not an attribute id, its a port.
On Jun 22, 2015, at 3:15 PM, Oleg Stolyar <olegstolyar@gmail.com <mailto:olegstolyar@gmail.com>> wrote:
Michael, so you are saying that 0 is not a valid attribute ID and FS is doing the right thing by not handling it, right?
If so, that's all I was asking! I'll try to fix it from the browser/JS end then.
On Mon, Jun 22, 2015 at 12:09 PM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>> wrote: It is absolutely manipulated by the library. Regardless, your issue is on the browser side, not the freeswitch side, you will need to figure out why it is sending that.
On Jun 22, 2015, at 2:50 PM, Oleg Stolyar <olegstolyar@gmail.com <mailto:olegstolyar@gmail.com>> wrote:
OK, thanks. Since this is not reproducible at will, the only way for me to try it with sip.js is to release sip.js into production. It's not really feasible just to test this one case.
From everything I could find, my understanding is that the m= line is created by Chrome and not manipulated by the library.
I think the question is this: Is 0 a valid value for an attribute ID. Unless it's explicitly forbidden by some RFP, I don't see why it wouldn't be. If it is, then shouldn't FS handle it?
On Mon, Jun 22, 2015 at 11:39 AM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>> wrote: it is manipulated by the js library.
On Jun 22, 2015, at 2:29 PM, Oleg Stolyar <olegstolyar@gmail.com <mailto:olegstolyar@gmail.com>> wrote:
Isn't SDP created by Chrome rather than the SIP JS library?
On Mon, Jun 22, 2015 at 11:25 AM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>> wrote: see if you get the same results with sip.js instead of jssip.
On Jun 22, 2015, at 2:20 PM, Oleg Stolyar <olegstolyar@gmail.com <mailto:olegstolyar@gmail.com>> wrote:
The client is sending this to Freeswitch.
On Mon, Jun 22, 2015 at 11:15 AM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>> wrote: is that the client sending that or freeswitch?
On Jun 22, 2015, at 2:09 PM, Oleg Stolyar <olegstolyar@gmail.com <mailto:olegstolyar@gmail.com>> wrote:
Thanks Brian, this makes a lot of sense. Snippets from SDP in these problem cases look like this: m=audio 0 RTP/SAVPF 111 103 104 9 0 8 106 105 13 126 c=IN IP4 10.198.149.58 a=rtcp:0 IN IP4 10.198.149.58
While good INVITES have this: m=audio 50937 RTP/SAVPF 111 103 104 9 0 8 106 105 13 126 c=IN IP4 10.198.149.35 a=rtcp:50937 IN IP4 10.198.149.35
Looks like it happens when the first parameter in m=audio is 0 even though there is a seemingly valid attribute 0 present. Should 0 be handled? If so, is this an FS bug?
On Mon, Jun 22, 2015 at 10:31 AM, Brian West <brian@freeswitch.org <mailto:brian@freeswitch.org>> wrote: See the logs with the offer and look at the codec parsing, without this its really hard to tell what is going on, it could be an issue in chrome. Do you ever see device or permission error?
On Mon, Jun 22, 2015 at 12:29 PM, Oleg Stolyar <olegstolyar@gmail.com <mailto:olegstolyar@gmail.com>> wrote: Hi guys,
I am calling FreeSWITCH from Chrome with WebRTC (JsSip). It works great but occasionally (much less than 1%) FreeSWITCH does this when trying to execute answer. I cannot reproduce it at will, so just collecting data from production logs. Is there some way I can find out what exactly makes FS unhappy?
EXECUTE sofia/leia_agent/anonymous@anonymous.invalid <mailto:sofia/leia_agent/anonymous@anonymous.invalid> answer() 2015-06-22 16:04:53.414528 [DEBUG] switch_core_session.c:912 Send signal sofia/leia_agent/anonymous@anonymous.invalid <mailto:sofia/leia_agent/anonymous@anonymous.invalid> [BREAK] 2015-06-22 16:04:53.414528 [NOTICE] switch_channel.c:3750 Hangup sofia/leia_agent/anonymous@anonymous.invalid <mailto:sofia/leia_agent/anonymous@anonymous.invalid> [CS_EXECUTE] [INCOMPATIBLE_DESTINATION] 2015-06-22 16:04:53.414528 [DEBUG] switch_channel.c:3242 Send signal sofia/leia_agent/anonymous@anonymous.invalid <mailto:sofia/leia_agent/anonymous@anonymous.invalid> [KILL]