28 May
2015
28 May
'15
6:02 p.m.
Hello list!
Have some difficulties with RTPengine:
My test scheme is: UA(WS) -> Kamailio (WS proxy) -> Kamailio (SIP REGISTRAR,
proxy) -> ASTERISK (media server) -> UA (SIP)
Kamailio (WS) use RTPengine.
Kamailio (WS proxy) - 4.2.3
Kamailio (SIP REGISTRAR, proxy) - 4.1.4
RTPengine - 3.3.0.0+0~mr3.8.0.0
I make a test call and have troubles in negotiation between UA(WS) ->
Kamailio (WS proxy):
UA(WS) -> INVITE -> Kamailio WS
......
rtpengine_manage("trust-address replace-origin replace-session-connection
ICE=force");
......
this INVITE consists in SDP section a=fingerprint:sha-256......
When Kamailio (WS) receives 200 OK, it is also handled by RTPengine
.......
rtpengine_manage("trust-address replace-origin replace-session-connection
ICE=force");
.......
but UA (WS) receives 200OK without fingerprint, and log an error:
Failed to set remote answer sdp: Called with SDP without DTLS fingerprint.
Currently spend a lot of time reading Kamailio/RTPengine
documentation/mail-list - but without success
If someone have some hints, I would appreciate any help.
--
View this message in context:
http://sip-router.1086192.n5.nabble.com/RTPengine-Kamailio-200-OK-without-D…
Sent from the Users mailing list archive at Nabble.com.
29 May
29 May
6:31 a.m.
You need send reply with Reverse rtp_manage functions. Now you sending with hte same
handling as request going to Kamailio. You use WS-UDP handling for inwite and WS-UDP
handling for reply. You must use WS-UDP to requests and UDP-WS to replyes
Четверг, 28 мая 2015, 9:02 -07:00 от Vasiliy Ganchev <vasiliy.ganchev(a)wildix.com>om>:
Hello list!
Have some difficulties with RTPengine:
My test scheme is: UA(WS) -> Kamailio (WS proxy) -> Kamailio (SIP REGISTRAR,
proxy) -> ASTERISK (media server) -> UA (SIP)
Kamailio (WS) use RTPengine.
Kamailio (WS proxy) - 4.2.3
Kamailio (SIP REGISTRAR, proxy) - 4.1.4
RTPengine - 3.3.0.0+0~mr3.8.0.0
I make a test call and have troubles in negotiation between UA(WS) ->
Kamailio (WS proxy):
UA(WS) -> INVITE -> Kamailio WS
......
rtpengine_manage("trust-address replace-origin replace-session-connection
ICE=force");
......
this INVITE consists in SDP section a=fingerprint:sha-256......
When Kamailio (WS) receives 200 OK, it is also handled by RTPengine
.......
rtpengine_manage("trust-address replace-origin replace-session-connection
ICE=force");
.......
but UA (WS) receives 200OK without fingerprint, and log an error:
Failed to set remote answer sdp: Called with SDP without DTLS fingerprint.
Currently spend a lot of time reading Kamailio/RTPengine
documentation/mail-list - but without success
If someone have some hints, I would appreciate any help.
--
View this message in context:
http://sip-router.1086192.n5.nabble.com/RTPengine-Kamailio-200-OK-without-D…
Sent from the Users mailing list archive at Nabble.com.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11:48 a.m.
Юрий, Thanks for your answer!
Sorry but I couldn't understand how to do "Reverse rtp_manage functions".
If
it is possible, extend your idea with some more example/explanation?
Maybe someone else can help suggest something, or do I need to give more
information?
Thanks in advance!
--
View this message in context:
http://sip-router.1086192.n5.nabble.com/RTPengine-Kamailio-200-OK-without-D…
Sent from the Users mailing list archive at Nabble.com.
2:19 p.m.
On 29/05/15 05:48 AM, Vasiliy Ganchev wrote:
Юрий, Thanks for your answer!
Sorry but I couldn't understand how to do "Reverse rtp_manage functions".
If
it is possible, extend your idea with some more example/explanation?
Maybe someone else can help suggest something, or do I need to give more
information?
A good way to start debugging this is to run rtpengine with log-level 7
and post the full log for such a call.
Cheers
5:16 p.m.
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>
Cheers
--
View this message in context:
http://sip-router.1086192.n5.nabble.com/RTPengine-Kamailio-200-OK-without-D…
Sent from the Users mailing list archive at Nabble.com.
5:34 p.m.
On 29/05/15 11:16 AM, Vasiliy Ganchev wrote:
On May 29, 2015; 3:19pm, Richard Fuchs wrote:
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
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>
2 Jun
2 Jun
12:35 p.m.
Richard Fuchs wrote
On 29/05/15 11:16 AM, Vasiliy Ganchev wrote:
On May 29, 2015; 3:19pm, Richard Fuchs wrote:
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 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>
sr-users@.sip-router
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.
Does this configuration has to work, or on the whole path has to be only one
profile RTP/AVPF or RTP/SAVPF?
Thanks in advance!
Cheers
--
View this message in context:
http://sip-router.1086192.n5.nabble.com/RTPengine-Kamailio-200-OK-without-D…
Sent from the Users mailing list archive at Nabble.com.
1:44 p.m.
On 02/06/15 06:35 AM, Vasiliy Ganchev wrote:
Richard Fuchs wrote
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
On 29/05/15 11:16 AM, Vasiliy Ganchev wrote:
On May 29, 2015; 3:19pm, Richard Fuchs wrote:
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 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>
sr-users@.sip-router
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.
5:05 p.m.
Richard Fuchs wrote
On 02/06/15 06:35 AM, Vasiliy Ganchev wrote:
Richard Fuchs wrote
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 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
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. sr-users@.sip-router
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-D…
Sent from the Users mailing list archive at Nabble.com.
3259
days inactive
3264
days old
8 comments
3 participants
participants (3)
-
Richard Fuchs -
Vasiliy Ganchev -
Юрий Горличенко