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

[Richard Fuchs]

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