29 Apr
2014
29 Apr
'14
8:18 p.m.
On 04/29/14 13:02, Juha Heinanen wrote:
Richard Fuchs writes:
In that case, there needs to be a new flag (no-touchy-c-and-m or w/e, as
mentioned) to explicitly tell rtpengine not to change them.
I maintain that changing c= and m= by default is the only sensible thing
to do. Going through the RTP proxy is the best chance of establishing
RTP flow in absence of ICE support (or, as in this case, in the presence
of two ice-lite implementations on private primary networks). Leaving c=
and m= untouched may work if the endpoints happen to be able to talk to
each other, but it will break RTP if they can't.
cheers
But according to the SDPs, baresip only supports
(or at least in this
case, only advertises) ice-lite. An ice-lite host doesn't initiate any
connectivity checks. When both sides are ice-lite, no checks are
performed at all and the hosts would fall back to what's in c= and m=.
Which is exactly what you'd want.
The problem is the same as what we discussed yesterday, i.e., rtpengine
has changed c line ip and m line port to its own (to the ones of relay
candidate) and that is not what I want. I want them to stay as is so
that baresips would talk directly to each other if they can (and as they
can in this test).