4 Dec
2020
4 Dec
'20
5:14 p.m.
Actually Yuriy's..sorry...I see what you are saying.
So my question should be, this means I don't have a choice but to use the
ICE candidate between client and kamailio?
On Fri, Dec 4, 2020 at 9:11 AM Andrew Chen <achen(a)fuze.com> wrote:
So for Yuriy's comment:
I did issue ICE=force parameter but, as you can see my paste, it's still
sending RTP sequence packets to the ICE candidate, which is not what I want
to do.
Richard,
So our current setup is this:
SIP
client -> kamailio -> freeswitch
RTP
client -> freeswitch
What I want to accomplish is this:
SIP
client -> kamailio -> freeswitch
RTP (bypass ICE)
client -> rtpengine -> freeswitch
On Fri, Dec 4, 2020 at 3:34 AM Yuriy Gorlichenko <ovoshlook(a)gmail.com>
wrote:
--
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen(a)thinkingphones.com>fuze.com
--
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
Hello
2020-12-03T18:05:46.456106+00:00 ashmainkama51 kamailio[22147]:
a=candidate:2274611867 1 tcp 1518283007
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 9 typ host tcptype active generation
0 network-id 2 network-cost 10
is a local candidate sent in the offer from the client
ICE=force just says rtpengine: "when you will resend this offer to the
receiver, remove all candidates sent by sender and put yourself as the only
candidate"
But rtpengine still has to follow the ICE check for the received
candidates as in that case rtpengine is the receiver and it can't just not
check local candidates. That is why you facing this behaviour from the
rtpengine, which is totally correct.
In other terms
Sender -----------> rtpengine : rtpengine must follow ice procedure
and check availability of these local candidates to establish connection
between Sender and rtpengine
rtpengine ---------> Receiver: rtpengine pretends to be a Sender for
the ICE agent of the receiver. but in this term, RTPengine will be the only
candidate for this part of the call, so this part is establishing a
connection between rtpengine and Receiver
чт, 3 дек. 2020 г. в 23:40, Richard Fuchs <rfuchs(a)sipwise.com>om>:
--
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen(a)thinkingphones.com>fuze.com
On 03/12/2020 13.39, Andrew Chen wrote:
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi all,
I was wondering if someone can help me understand how the ICE
parameter works in the rtpengine module works.
So basically our client does an ICE candidate lookup and grabs a list
of them and applies it to the INVITE that gets sent to the Kamailio.
The list looks like this:
2020-12-03T18:05:46.456030+00:00 ashmainkama51 kamailio[22147]:
a=candidate:3373280875 1 udp 2122262783
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 59827 typ host generation 0
network-id 2 network-cost 10
2020-12-03T18:05:46.456057+00:00 ashmainkama51 kamailio[22147]:
a=candidate:3040609428 1 udp 2122197247
2001:8a0:78fc:7000:d979:bf75:dbc0:69f 59828 typ host generation 0
network-id 3 network-cost 10
2020-12-03T18:05:46.456081+00:00 ashmainkama51 kamailio[22147]:
a=candidate:1681997092 1 udp 2122129151 192.168.1.66 59829 typ host
generation 0 network-id 1 network-cost 10
2020-12-03T18:05:46.456106+00:00 ashmainkama51 kamailio[22147]:
a=candidate:2274611867 1 tcp 1518283007
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 9 typ host tcptype active
generation 0 network-id 2 network-cost 10
2020-12-03T18:05:46.456131+00:00 ashmainkama51 kamailio[22147]:
a=candidate:4223662180 1 tcp 1518217471
2001:8a0:78fc:7000:d979:bf75:dbc0:69f 9 typ host tcptype active
generation 0 network-id 3 network-cost 10
2020-12-03T18:05:46.456155+00:00 ashmainkama51 kamailio[22147]:
a=candidate:717406676 1 tcp 1518149375 192.168.1.66 9 typ host tcptype
active generation 0 network-id 1 network-cost 10
2020-12-03T18:05:46.456180+00:00 ashmainkama51 kamailio[22147]:
a=candidate:2130547417 1 udp 8199935 206.81.191.27 61165 typ relay
raddr 85.247.0.121 rport 53091 generation 0 network-id 1 network-cost
10
In the rtpengine_offer, I have this:
rtpengine_offer("ICE=force DTLS=passive replace-session-connection
replace-origin external internal");
What i am trying to do is to tell the freeswitch endpoint to use
rtpengine as ICE candidate and I see in the SDP this is happening:
a=candidate:6296910676 1 udp 659136 206.81.191.52 52766 typ host
generation 0
Btw..206.81.191.52 is a separate AWS instance running rtpengine binary.
On the rtpengine_answer, I tell the remote client side the same
thing..use rtpengine as your ICE candidate:
rtpengine_answer("ICE=force DTLS=passive replace-session-connection
replace-origin internal external");
and this is snippet from 200 OK:
a=candidate:6296910676 1 udp 659136 206.81.191.52 52766 typ host
generation 0
Question:
Why does the rtpengine logs still show that it's trying to use
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71 as RTP candidate in this
scenario?
Dec 3 18:05:47 ashmainrtpe42 rtpengine[8505]: DEBUG:
[ep1sbnkk9tikhg4kpmot]: Forward to sink endpoint:
2001:8a0:78fc:7000:e1d7:e93:3c50:ee71:59827 (RTP seq 25423 TS 0)
I thought ICE=force will handle such adjustments so that all rtp is
handled by the rtpengine to our client and bypass the STUN server?
Isn't that what's happening? Rtpengine receives media from one peer and
forwards it to one of the ICE candidates (presumably the primary one
that was negotiated) of the other peer. Or am I misunderstanding what
you posted?
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users