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

Fri Dec 4 15:14:32 CET 2020

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 at 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 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
>
>

-- 
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/7f76453e/attachment.htm>