<html><head><meta http-equiv="Content-Type" content="text/html charset=koi8-r"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Yes, it does not work with SPCE because of invalid Route.<div><br></div><div>Nikita Stashkov</div><div><br><div><div>12 апр. 2014 г., в 21:51, Andrew Pogrebennyk <<a href="mailto:apogrebennyk@sipwise.com">apogrebennyk@sipwise.com</a>> написал(а):</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">David,<br><br>it seems an ACK from the caller (sipml5) doesn't reach jitsi, so you<br>should trace where it gets lost and for this a SIP capture is a must.<br>What interests me most, is the Route set from sipml5. I've seen some<br>reports here and on sr-users mailing list where the sipml5 client would<br>insert an extra Route into ACK message, which is not allowed by RFC btw.<br>Probably a nasty client configuration issue that causes some request<br>spiraling. Check that the Route set of ACK message from sipml5 contains<br>the same set of URIs as Record-Route set in received in 200 OK, just in<br>reverse order.<br>If unsure, attach the SIP trace, kamailio-lb.log and kamailio-proxy.log<br>and send email to the list so we can figure it out.<br><br>BR,<br>Andrew<br><br>On 11/04/14 08:56, David Strejc wrote:<br><blockquote type="cite">Dear all,<br><br>does anyone have working connection between sipml5 and jitsi - since<br>jitsi is not supporting ICE and sipml5 have mandatory ICE I've setuped<br><a href="sip:provider">sip:provider</a> ce user preferences due this info I've received:<br><br>-----------------<br>So on the web interface, go to your subscriber used for Jitsi, click the<br>preferences button, and in the nat and media flow control section, set<br>use_rtpproxy to force with plain sdp, set the rtcp_feedback to force<br>AVP, and set the srtp option to force RTP.<br><br>For the subscriber you're using with sipml5, you do the opposite: set<br>use_rtpproxy to force with ice as only candidate, rtcp_feedback to<br>prefer AVPF, and srtp to prefer SRTP.<br><br>That should tell the system to properly transcode between plain sip<br>(RTP/AVP) and webrtc (RTP/SAVPF) profiles.<br>------------------<br><br>Now sipml5 doesn't complain in javascript console about ICE and SDP but<br>still when I call to jitsi client the sipml5 client says call connected<br>but jitsi says - connecting.<br><br>I know that this could be tricky and I think I can provide more info<br>about this particular problem, but I need help with where I should look<br>at now.<br><br>Many thanks to all for any suggestion.<br><br><br><br>David Strejc<br>t: +420734270131<br>e:<span class="Apple-converted-space"> </span><a href="mailto:david.strejc@gmail.com">david.strejc@gmail.com</a><span class="Apple-converted-space"> </span><<a href="mailto:david.strejc@gmail.com">mailto:david.strejc@gmail.com</a>><br></blockquote><br>_______________________________________________<br>Spce-user mailing list<br><a href="mailto:Spce-user@lists.sipwise.com">Spce-user@lists.sipwise.com</a><br><a href="http://lists.sipwise.com/listinfo/spce-user">http://lists.sipwise.com/listinfo/spce-user</a></div></blockquote></div><br></div></body></html>