14 Mar
2019
14 Mar
'19
1:47 p.m.
Hi there,
Well it's mostly rtpengine question but didn't know where should I send
it and probably the answer will be more or less useful for kamailio users.
By default if an offer has ICE candidates rtpengine leaves them
untouched and just inserts itself as an additional low priority
candidate and also rewrites c= line for the callee without ICE support.
Using ICE=force-relay rtpengine inserts itself as a "relay" candidate
what is great but doesn't touch c= line and callee without ICE have no
chance to send RTP to rtpengine.
Is it possible somehow to make a third behavior like force-relay +
rtpengine IP in c= param? It would allow any callee to send media to
rtpengine regardless of ICE support.
14 Mar
14 Mar
4:09 p.m.
On Thu, Mar 14, 2019 at 02:47:24PM +0200, Vitalii Aleksandrov wrote:
Well it's mostly rtpengine question but didn't
know where should I send it
and probably the answer will be more or less useful for kamailio users.
I get the feeling. You could open an issue in github, but
sipwise/rtpengine devs frequent here.
By default if an offer has ICE candidates rtpengine
leaves them untouched
and just inserts itself as an additional low priority candidate and also
rewrites c= line for the callee without ICE support. Using ICE=force-relay
rtpengine inserts itself as a "relay" candidate what is great but doesn't
touch c= line and callee without ICE have no chance to send RTP to
rtpengine.
Is it possible somehow to make a third behavior like force-relay + rtpengine
IP in c= param? It would allow any callee to send media to rtpengine
regardless of ICE support.
What is wrong with the default behavior? That adds ICE records and
rewrites SDP c=.
5:01 p.m.
On 14.03.19 17:09, Daniel Tryba wrote:
When a call goes through multiple proxies and every proxy inserts
itself
SDP becomes really huge. What I like in "force-relay" is that it removes
previously inserted "relay" candidates and inserts itself. Hope
rtpengine will still talk to those relay candidates on incoming leg if
"host" are not reachable. So I'm satisfied with "force-relay" when
call
to ICE supported phone, but when callee can't do ICE I'm in trouble.
On Thu, Mar 14, 2019 at 02:47:24PM +0200, Vitalii
Aleksandrov wrote:
It's not a bug. rtpengine works exactly as described in docs. Maybe a
feature request issue.
Well it's mostly rtpengine question but
didn't know where should I send it
and probably the answer will be more or less useful for kamailio users.
I get the
feeling. You could open an issue in github, but
sipwise/rtpengine devs frequent here.
By default if
an offer has ICE candidates rtpengine leaves them untouched
and just inserts itself as an additional low priority candidate and also
rewrites c= line for the callee without ICE support. Using ICE=force-relay
rtpengine inserts itself as a "relay" candidate what is great but doesn't
touch c= line and callee without ICE have no chance to send RTP to
rtpengine.
Is it possible somehow to make a third behavior like force-relay + rtpengine
IP in c= param? It would allow any callee to send media to rtpengine
regardless of ICE support.
What is wrong with the default behavior? That adds ICE
records and
rewrites SDP c=.
6:22 p.m.
On Thu, Mar 14, 2019 at 06:01:41PM +0200, Vitalii Aleksandrov wrote:
ICE is end to end. rtpengine does nothing with other ICE candidates
(AFAIK). So removing those other candidates defeats the purpose IMHO.
You might as well remove any ICE and simply rewrite DSP
What is wrong
with the default behavior? That adds ICE records and
rewrites SDP c=.
When a call goes through multiple proxies and every proxy inserts
itself SDP
becomes really huge. What I like in "force-relay" is that it removes
previously inserted "relay" candidates and inserts itself. Hope rtpengine
will still talk to those relay candidates on incoming leg if "host" are not
reachable. So I'm satisfied with "force-relay" when call to ICE supported
phone, but when callee can't do ICE I'm in trouble.
15 Mar
15 Mar
11:37 a.m.
On Thu, Mar 14, 2019 at 06:01:41PM +0200, Vitalii
Aleksandrov wrote:
ICE is end to end.
rtpengine does nothing with other ICE candidates
(AFAIK). So removing those other candidates defeats the purpose IMHO.
You might as well remove any ICE and simply rewrite DSP
Oh, it actually does. If
you use ICE=force, rtpengine removes all ICE
candidates and inserts its own and both call participant can't to talk
to each other directly but still can use ICE to establish media streams
to rtpengine. ICE=force-relay does another cool thing. Using it call
participants try to talk directly and if they can't (both behind NAT)
they can still use "relay" candidate inserted by rtpengine and exchange
media via it. I just need a mixed behavior like default + force-relay
and don't want to hack rtpengine sources and then maintain my patches
when need to update it.
What is
wrong with the default behavior? That adds ICE records and
rewrites SDP c=.
When a call goes through multiple proxies and every proxy inserts
itself SDP
becomes really huge. What I like in "force-relay" is that it removes
previously inserted "relay" candidates and inserts itself. Hope rtpengine
will still talk to those relay candidates on incoming leg if "host" are not
reachable. So I'm satisfied with "force-relay" when call to ICE supported
phone, but when callee can't do ICE I'm in trouble.
2:45 p.m.
On Fri, Mar 15, 2019 at 12:37:16PM +0200, Vitalii Aleksandrov wrote:
Oh, it actually does. If you use ICE=force, rtpengine
removes all ICE
candidates and inserts its own and both call participant can't to talk to
each other directly but still can use ICE to establish media streams to
rtpengine. ICE=force-relay does another cool thing. Using it call
participants try to talk directly and if they can't (both behind NAT) they
can still use "relay" candidate inserted by rtpengine and exchange media via
it. I just need a mixed behavior like default + force-relay and don't want
to hack rtpengine sources and then maintain my patches when need to update
it.
How is this any different than the default ICE setting (without rewriting
rtp)? rtpengine will add itself to ICE candidates (with a lower priority
than already present ICE). Allowing the rtpengine to be skipped entirely
if there is a better (higher priority) ICE candidate.
endpoint A with ICE support <-> rtpengine with ICE <-> endpoint B with ICE
Here RTP can go directly from A to B.
If any point doesn't support ICE, the rtpengine will be used (with ICE
for the endpoint that does support ICE) if rtpengine rewrites RTP for
legacy endpoints.
The problem of removing ICE is more apparent with more parties involved:
a <-> r1 <-> r2 <-> b
if a,r1 and r2 have ICE support but b doens't, do you want a to
communicate with r1 or r2? If you remove ICE with force-relay, it will
talk to r1, if you "do nothing", it may talk to r2 as ICE candidate.
2:49 p.m.
On 15/03/2019 06.37, Vitalii Aleksandrov wrote:
You can always submit a pull request as long as it doesn't break
existing functionality, e.g. by making it a new optional feature.
Cheers
On Thu, Mar 14, 2019 at 06:01:41PM +0200, Vitalii
Aleksandrov wrote:
ICE is end to end.
rtpengine does nothing with other ICE candidates
(AFAIK). So removing those other candidates defeats the purpose IMHO.
You might as well remove any ICE and simply rewrite DSP
Oh, it actually does. If
you use ICE=force, rtpengine removes all ICE
candidates and inserts its own and both call participant can't to talk
to each other directly but still can use ICE to establish media
streams to rtpengine. ICE=force-relay does another cool thing. Using
it call participants try to talk directly and if they can't (both
behind NAT) they can still use "relay" candidate inserted by rtpengine
and exchange media via it. I just need a mixed behavior like default +
force-relay and don't want to hack rtpengine sources and then maintain
my patches when need to update it.
What is
wrong with the default behavior? That adds ICE records and
rewrites SDP c=.
When a call goes through multiple proxies and every proxy inserts
itself SDP
becomes really huge. What I like in "force-relay" is that it removes
previously inserted "relay" candidates and inserts itself. Hope
rtpengine
will still talk to those relay candidates on incoming leg if "host"
are not
reachable. So I'm satisfied with "force-relay" when call to ICE
supported
phone, but when callee can't do ICE I'm in trouble.
1877
days inactive
1878
days old
6 comments
3 participants
participants (3)
-
Daniel Tryba -
Richard Fuchs -
Vitalii Aleksandrov