3 Dec
2020
3 Dec
'20
7:39 p.m.
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?
Thanks.
--
Andy Chen
Sr. Telephony Lead Engineer
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.*
3 Dec
3 Dec
11:38 p.m.
On 03/12/2020 13.39, Andrew Chen wrote:
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
4 Dec
4 Dec
9:31 a.m.
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>:
On 03/12/2020 13.39, Andrew Chen wrote:
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
3:11 p.m.
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:
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
--
*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.*
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
3: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
3:17 p.m.
On 04/12/2020 09.11, Andrew Chen 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
I still don't understand. What does "bypass ICE" mean?
If you see rtpengine forwarding media packets as per the log you posted,
what makes you think that media is not going through rtpengine?
Cheers
3:24 p.m.
Hey Richard,
So it is true rtpengine is handling rtp between kamailio and receiver
(freeswitch). I'm trying to understand if there is a way to not
forward rtp to any of the ICE candidates in the original INVITE request
from the client side. In other words, have the client rtp forward directly
to the rtpengine and not any of the STUN servers (or ICE candidates). i
honestly thought putting ICE=force in the rtpengine_answer would help in
this case...but I don't see this part working.
On Fri, Dec 4, 2020 at 9:20 AM Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 04/12/2020 09.11, Andrew Chen 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.*
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
I still don't understand. What does "bypass ICE" mean?
If you see rtpengine forwarding media packets as per the log you posted,
what makes you think that media is not going through rtpengine?
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
3:33 p.m.
On 04/12/2020 09.24, Andrew Chen wrote:
Hey Richard,
So it is true rtpengine is handling rtp between kamailio and receiver
(freeswitch). I'm trying to understand if there is a way to not
forward rtp to any of the ICE candidates in the original INVITE
request from the client side. In other words, have the client rtp
forward directly to the rtpengine and not any of the STUN servers (or
ICE candidates). i honestly thought putting ICE=force in the
rtpengine_answer would help in this case...but I don't see this part
working.
But that is what's happening, isn't it? What other media would rtpengine
be sending to the client if not the media received from the other
client? So your A client is sending to rtpengine, and rtpengine is
forwarding that to B, while your B client is also sending to rtpengine,
which then forwards it to A. Where do you not see that working?
Cheers
3:40 p.m.
Hey Richard,
So that's what I thought too until I saw this in rtpengine logs for one of
my test calls:
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)
unless I misunderstood what this line means.
On Fri, Dec 4, 2020 at 9:34 AM Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 04/12/2020 09.24, Andrew Chen 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.*
Hey Richard,
So it is true rtpengine is handling rtp between kamailio and receiver
(freeswitch). I'm trying to understand if there is a way to not
forward rtp to any of the ICE candidates in the original INVITE
request from the client side. In other words, have the client rtp
forward directly to the rtpengine and not any of the STUN servers (or
ICE candidates). i honestly thought putting ICE=force in the
rtpengine_answer would help in this case...but I don't see this part
working.
But that is what's happening, isn't it? What other media would rtpengine
be sending to the client if not the media received from the other
client? So your A client is sending to rtpengine, and rtpengine is
forwarding that to B, while your B client is also sending to rtpengine,
which then forwards it to A. Where do you not see that working?
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
4:17 p.m.
On 04/12/2020 09.40, Andrew Chen wrote:
Hey Richard,
So that's what I thought too until I saw this in rtpengine logs for
one of my test calls:
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)
unless I misunderstood what this line means.
I think you did. It means rtpengine has received a media packet from one
side and has forwarded it to the other side. Of course it's one of the
ICE candidates from the SDP because that's where the peer said it wants
to receive the media from rtpengine.
Cheers
4:39 p.m.
So my next question would be:
My 200 OK back to the client should have rtpengine as the only ICE
candidate. Shouldn't it use that one instead?
On Fri, Dec 4, 2020 at 10:18 AM Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 04/12/2020 09.40, Andrew Chen 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.*
Hey Richard,
So that's what I thought too until I saw this in rtpengine logs for
one of my test calls:
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)
unless I misunderstood what this line means.
I think you did. It means rtpengine has received a media packet from one
side and has forwarded it to the other side. Of course it's one of the
ICE candidates from the SDP because that's where the peer said it wants
to receive the media from rtpengine.
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
5:31 p.m.
If that's the case then I don't know why this line doesn't show the ipv6
address of the client:
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)
On Fri, Dec 4, 2020 at 11:25 AM Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 04/12/2020 10.39, Andrew Chen 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.*
So my next question would be:
My 200 OK back to the client should have rtpengine as the only ICE
candidate. Shouldn't it use that one instead?
Yes it should. And it probably does.
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
5:37 p.m.
On 04/12/2020 11.31, Andrew Chen wrote:
If that's the case then I don't know why this
line doesn't show the
ipv6 address of the client:
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)
It doesn't?
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
What is this then?
Cheers
5:39 p.m.
oh...that's the IPv6 address of the STUN server, not the ipv6 of the
rtpengine instance.
On Fri, Dec 4, 2020 at 11:38 AM Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 04/12/2020 11.31, Andrew Chen 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.*
If that's the case then I don't know why
this line doesn't show the
ipv6 address of the client:
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)
It doesn't?
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
What is this then?
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
5:48 p.m.
On 04/12/2020 11.39, Andrew Chen wrote:
oh...that's the IPv6 address of the STUN server,
not the ipv6 of the
rtpengine instance.
Ok. From rtpengine's point of view, this is one of the client's IP
addresses. The ICE candidate in the SDP is the client telling rtpengine:
This is one of my own addresses (`typ host`) and I can receive media
here. It is also listed (by the client who has sent the SDP) as the
highest priority candidate, and this is why it's (presumably) negotiated
as the candidate to use. This is why rtpengine is sending media there.
Cheers
7:10 p.m.
So from a SIP point of view, the 200 OK should of sent the final
negotiation of SDP once the client ACK's it right?
On Fri, Dec 4, 2020 at 11:49 AM Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 04/12/2020 11.39, Andrew Chen 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.*
oh...that's the IPv6 address of the STUN
server, not the ipv6 of the
rtpengine instance.
Ok. From rtpengine's point of view, this is one of the client's IP
addresses. The ICE candidate in the SDP is the client telling rtpengine:
This is one of my own addresses (`typ host`) and I can receive media
here. It is also listed (by the client who has sent the SDP) as the
highest priority candidate, and this is why it's (presumably) negotiated
as the candidate to use. This is why rtpengine is sending media there.
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
7:29 p.m.
On 04/12/2020 13.10, Andrew Chen wrote:
So from a SIP point of view, the 200 OK should of sent
the final
negotiation of SDP once the client ACK's it right?
The requirement to send an updated offer once ICE has completed with the
final negotiated candidates existed in the original ICE RFC, but I
believe it has been removed in the newer ICE RFC (I'm not 100% sure
about that though). For rtpengine that requirement certainly doesn't
exist and it's happy to negotiate and conclude ICE without a final
updated offer. Also rtpengine itself cannot trigger such an updated
offer since it's not directly in the SIP path, so that would have to be
left up to the clients. So in short, a single offer/answer exchange is
enough to get ICE started and it can complete negotiation out of band
without further signalling.
Cheers
7:36 p.m.
Hmm..that's interesting. You would guess that the rtpengine binary process
shouldn't start connecting ICE candidates once the SIP part is fully
negotiated, which should trigger the rtpengine module on the Kamailio to
tell rtpengine binary.."ok..you can start associating now..."
On Fri, Dec 4, 2020 at 1:30 PM Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 04/12/2020 13.10, Andrew Chen 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.*
So from a SIP point of view, the 200 OK should of
sent the final
negotiation of SDP once the client ACK's it right?
The requirement to send an updated offer once ICE has completed with the
final negotiated candidates existed in the original ICE RFC, but I
believe it has been removed in the newer ICE RFC (I'm not 100% sure
about that though). For rtpengine that requirement certainly doesn't
exist and it's happy to negotiate and conclude ICE without a final
updated offer. Also rtpengine itself cannot trigger such an updated
offer since it's not directly in the SIP path, so that would have to be
left up to the clients. So in short, a single offer/answer exchange is
enough to get ICE started and it can complete negotiation out of band
without further signalling.
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
7:46 p.m.
On 04/12/2020 13.36, Andrew Chen wrote:
Hmm..that's interesting. You would guess that the
rtpengine binary
process shouldn't start connecting ICE candidates once the SIP part is
fully negotiated, which should trigger the rtpengine module on the
Kamailio to tell rtpengine binary.."ok..you can start associating now..."
Not really. Why would you think that? ICE and SIP are really largely
unrelated, and ICE processing starts as soon as possible so that media
can flow as soon as possible. Any delay in ICE processing leads to
delays in establishing the call or the media flows. (Trickle ICE exists
partly for that reason.) In particular early media would break if ICE
had to wait for SIP to finish.
Cheers
8:04 p.m.
Sure...I understand ICE has its own setup workflow than SIP but it's also
important that rtpengine uses the rtp path that's negotiated in the SIP or
else it can cause confusion (to those who don't understand ICE very well
like me).
On Fri, Dec 4, 2020 at 1:47 PM Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 04/12/2020 13.36, Andrew Chen 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.*
Hmm..that's interesting. You would guess
that the rtpengine binary
process shouldn't start connecting ICE candidates once the SIP part is
fully negotiated, which should trigger the rtpengine module on the
Kamailio to tell rtpengine binary.."ok..you can start associating now..."
Not really. Why would you think that? ICE and SIP are really largely
unrelated, and ICE processing starts as soon as possible so that media
can flow as soon as possible. Any delay in ICE processing leads to
delays in establishing the call or the media flows. (Trickle ICE exists
partly for that reason.) In particular early media would break if ICE
had to wait for SIP to finish.
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
8:17 p.m.
On 04/12/2020 14.04, Andrew Chen wrote:
Sure...I understand ICE has its own setup workflow
than SIP but it's
also important that rtpengine uses the rtp path that's negotiated in
the SIP or else it can cause confusion (to those who don't understand
ICE very well like me).
There is no RTP path negotiated through SIP. There is only a number of
possible paths, which are compiled from the list of candidates that each
side advertises. ICE then checks which paths work, and then finally
chooses the one with the highest priority.
The only way to have a single media path that is negotiated through SIP
is if you don't use ICE.
Cheers
8:24 p.m.
Ok..that's interesting to know. Thanks for your input Richard. This helps
a lot.
On Fri, Dec 4, 2020 at 2:18 PM Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 04/12/2020 14.04, Andrew Chen 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.*
Sure...I understand ICE has its own setup
workflow than SIP but it's
also important that rtpengine uses the rtp path that's negotiated in
the SIP or else it can cause confusion (to those who don't understand
ICE very well like me).
There is no RTP path negotiated through SIP. There is only a number of
possible paths, which are compiled from the list of candidates that each
side advertises. ICE then checks which paths work, and then finally
chooses the one with the highest priority.
The only way to have a single media path that is negotiated through SIP
is if you don't use ICE.
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
1236
days inactive
1237
days old
22 comments
3 participants
participants (3)
-
Andrew Chen -
Richard Fuchs -
Yuriy Gorlichenko