Richard Fuchs wrote > On 02/06/15 06:35 AM, Vasiliy Ganchev wrote: >> Richard Fuchs wrote >>> On 29/05/15 11:16 AM, Vasiliy Ganchev wrote: >>>> On May 29, 2015; 3:19pm, Richard Fuchs wrote: >>>>> A good way to start debugging this is to run rtpengine with log-level >>>>> 7 >>>>> and post the full log for such a call. >>>> Hi Richard! Thanks for answer! >>>> Call log written on WS_Kamailio, rtpengine with log-level 7 >>>> Call from UA_WS 272 calling to UA_SIP 271 attached. >>>> 200OK_without_DTLS_fingerprint_log_for_list.txt >>>> <http://sip-router.1086192.n5.nabble.com/file/n138286/200OK_without_DTLS_fingerprint_log_for_list.txt> >>>> >>> >>> Looks like you're making an RTP/SAVPF offer to a client that speaks >>> RTP/AVPF only, and you're neglecting to instruct rtpengine to do any >>> translation between the two. The solution is to include the "RTP/AVPF" >>> flag in the offer. >>> >>> There's also a stray "delete" in there, which you may want to eliminate. >>> It's harmless as it is, but it probably shouldn't be there. >>> >>> Cheers >>> >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> >>> sr-users@.sip-router >> >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> Hi Richard! >> Thank you for your reply and suggested solution. You was right, in 200 OK >> was set RTP/AVPF (and in offer >> RTP/SAVPF) and I did nothing with this mismatch. >> Now, playing around with flags for RTPengine, I have one questions for >> such >> case: >> Browser send INVITE with RTP/SAVPF, RTPengine send forward to client with >> RTP/AVPF >> When comes 200 OK with RTP/AVPF RTPengine change it to RTP/SAVPF and >> forward to browser. In this case I got in browser log: >> >> setRemoteDescription() | error: +5ms Failed to set remote answer sdp: >> Offer >> and answer descriptions m-lines are not matching. Rejecting answer. > > This is usually caused by broken SIP clients which don't properly reject > media streams. What usually happens is that the browser offers both > audio and video, but the other client only responds with audio. What the > client should do is to explicitly reject the video stream, instead of > just ignoring it and not including it in the reply at all. IOW, the > offer has two m= lines and thus the answer also should have two m= > lines, but it only has one, and this is not allowed by the RFC. > > There might be a new option in rtpengine in the near future to fix these > kinds of broken SDP bodies, but right now there isn't. > > Cheers > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@.sip-router > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users You are right again. In my INVITE sent 2 lines m= one fore audio and another one for video. In 200OK was only one m=audio... that causes such error. I switched off m=video... in INVITE from browser, and it became working. Currently there is no more questions for this issue. Richard, thank you, again, for answers end your priceless help! Cheers! -- View this message in context: http://sip-router.1086192.n5.nabble.com/RTPengine-Kamailio-200-OK-without-DTLS-fingerprint-tp138240p138368.html Sent from the Users mailing list archive at Nabble.com. _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
