[SR-Users] RTPengine+Kamailio, 200 OK without DTLS fingerprint

[Vasiliy Ganchev]

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 at .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 at .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.