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_fing...;
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-DT... Sent from the Users mailing list archive at Nabble.com.