[SR-Users] question regarding rtpengine and ICE candidate selection

Andrew Chen achen at fuze.com
Fri Dec 4 15:11:02 CET 2020


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 at 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 at sipwise.com>:
>
>> 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 at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Andy Chen
Sr. Telephony Lead Engineer
415 516 5535 (M)
achen@ <achen at 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.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201204/595e1f96/attachment.htm>


More information about the sr-users mailing list