28 Apr
2014
28 Apr
'14
11:40 p.m.
while doing rtpengine tests, i noticed that it replaces c line ip
address without being asked for.
-- juha
Apr 28 21:27:06 siika /usr/sbin/sip-proxy[15139]: INFO: =====
rtpengine_offer(ICE=force_relay via-branch=1 trust-address)
Apr 28 21:27:06 siika rtpengine[13711]: Got valid command from 127.0.0.1:59497: offer - {
"sdp": "v=0#015#012o=- 2010440216 969631828 IN IP4
192.168.43.146#015#012s=-#015#012c=IN IP4 192.168.43.146#015#012t=0
0#015#012a=tool:baresip
0.4.10#015#012a=ice-lite#015#012a=ice-ufrag:K7tL#015#012a=ice-pwd:Dl0YogJckXGNkrM36zfOVW#015#012m=audio
10082 RTP/AVP 96 97 98 8 0 101#015#012b=AS:125#015#012a=rtpmap:96
opus/48000/2#015#012a=fmtp:96 stereo=1;sprop-stereo=1#015#012a=rtpmap:97
speex/16000#015#012a=fmtp:97 mode="7";vbr=off;cng=on#015#012a=rtpmap:98
speex/8000#015#012a=fmtp:98 mode="7";vbr=off;cng=on#015#012a=rtpmap:8
PCMA/8000#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:101
telephone-event/8000#015#012a=fmtp:101
0-15#015#012a=sendrecv#015#012a=label:1#015#012a=rtcp-rsize#015#012a=ssrc:1679331760
cname:sip:test@test.tutpro.com#015#012a=ptime:20#015#012a=candidate:c062661e 1 UDP
2113932031 192.98.102.30 10082 typ host#015#012a=candidate:c062661e 2 UDP 2113932030
192.98.102.30 10083 typ host#015#012a=candidate:c0a82b92 1 UDP 2113932031 192.168.43.146
10082 typ host#015#012a=candidate:c0a82b92 2 UDP 2113932030 192.168.43.146 10083 typ
host#015#012a=candidate:c062671e 1 UDP 2113932031 192.98.103.30 10082 typ
host#015#012a=candidate:c062671e 2 UDP 2113932030 192.98.103.30 10083 typ
host#015#012a=candidate:63c01c46 1 UDP 2113932031 2002:c062:661e::1 10082 typ
host#015#012a=candidate:63c01c46 2 UDP 2113932030 2002:c062:661e::1 10083 typ
host#015#012a=candidate:1e6662c0 1 UDP 2113932031 ::192.98.102.30 10082 typ
host#015#012a=candidate:1e6662c0 2 UDP 2113932030 ::192.98.102.30 10083 typ
host#015#012", "ICE": "force_relay", "flags": [
"trust-address" ], "call-id": "462bf6747eb5df7a",
"via-branch": "z9hG4bK94d314320dc25092", "received-from": [
"IP4", "192.98.102.30" ], "from-tag":
"f8419c09a23200e0", "command": "offer" }
Apr 28 21:27:06 siika rtpengine[13711]: [462bf6747eb5df7a] Creating new call
Apr 28 21:27:06 siika rtpengine[13711]: [462bf6747eb5df7a] enabling passthrough mode
Apr 28 21:27:06 siika rtpengine[13711]: [462bf6747eb5df7a] Opened ports 50076..50077 for
media relay
Apr 28 21:27:06 siika rtpengine[13711]: [462bf6747eb5df7a] Opened ports 50078..50079 for
media relay
Apr 28 21:27:06 siika rtpengine[13711]: [462bf6747eb5df7a] Returning to SIP proxy:
d3:sdp1459:v=0#015#012o=- 2010440216 969631828 IN IP4
192.168.43.146#015#012s=-#015#012c=IN IP4 192.98.102.30#015#012t=0 0#015#012a=tool:baresip
0.4.10#015#012a=ice-lite#015#012a=ice-ufrag:K7tL#015#012a=ice-pwd:Dl0YogJckXGNkrM36zfOVW#015#012m=audio
50076 RTP/AVP 96 97 98 8 0 101#015#012b=AS:125#015#012a=rtpmap:96
opus/48000/2#015#012a=fmtp:96 stereo=1;sprop-stereo=1#015#012a=rtpmap:97
speex/16000#015#012a=fmtp:97 mode="7";vbr=off;cng=on#015#012a=rtpmap:98
speex/8000#015#012a=fmtp:98 mode="7";vbr=off;cng=on#015#012a=rtpmap:8
PCMA/8000#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:101
telephone-event/8000#015#012a=fmtp:101
0-15#015#012a=label:1#015#012a=rtcp-rsize#015#012a=ssrc:1679331760
cname:sip:test@test.tutpro.com#015#012a=ptime:20#015#012a=candidate:c062661e 1 UDP
2113932031 192.98.102.30 10082 typ host#015#012a=candidate:c062661e 2 UDP 2113932030
192.98.102.30 10083 typ host#015#012a=candidate:c0a82b92 1 UDP 2113932031 192.168.43.146
10082 typ host#015#012a=candidate:c0a82b92 2 UDP 2113932030 192.168.43.146 10083 typ
host#015#012a=candidate:c062671e 1 UDP 2113932031 192.98.103.30 10082 typ
host#015#012a=candidate:c062671e 2 UDP 2113932030 192.98.103.30 10083 typ
host#015#012a=candidate:63c01c46 1 UDP 2113932031 2002:c062:661e::1 10082 typ
host#015#012a=candidate:63c01c46 2 UDP 2113932030 2002:c062:661e::1 10083 typ
host#015#012a=candidate:1e6662c0 1 UDP 2113932031 ::192.98.102.30 10082 typ
host#015#012a=candidate:1e6662c0 2 UDP 2113932030 ::192.98.102.30 10083 typ
host#015#012a=sendrecv#015#012a=rtcp:50077#015#012a=candidate:WHSppLRUqzptTceE 1 UDP
16777216 192.98.102.30 50076 typ relay#015#012a=candidate:WHSppLRUqzptTceE 2 UDP 16777215
192.98.102.30 50077 typ relay#015#0126:result2:oke
11:44 p.m.
Isn't origin the o= line?
On 28 April 2014 22:43:00 GMT+04:00, Juha Heinanen <jh(a)tutpro.com> wrote:
Juha Heinanen writes:
--
Sent from my mobile, and thus lacking in the refinement one might expect from a fully
fledged keyboard.
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0671
Web: http://www.evaristesys.com/, http://www.alexbalashov.com
while doing rtpengine tests, i noticed that it
replaces c line ip
address without being asked for.
sorry about wrong subject. the above text is correct.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 
11:54 p.m.
On 04/28/14 14:40, Juha Heinanen wrote:
while doing rtpengine tests, i noticed that it
replaces c line ip
address without being asked for.
c= line address is always replaced by default. The
"replace-session-connection" option is only relevant if there are two c=
lines, one in the session scope and one in the media scope. Without the
option, only the media-scope c= line is modified. This corresponds to
the old "c" flag.
cheers
12:08 a.m.
Richard Fuchs writes:
easy. when ice capable sip ua registers, it has +sip.ice feature tag in
contact uri. caller's ice support can be detected using sdp_with_ice()
function that i introduced today.
-- juha
why? when
both parties use ice, i don't see any reason to touch c line.
How would the proxy know ahead of time that both parties actually
support ICE?
12:09 a.m.
On 04/28/14 15:08, Juha Heinanen wrote:
Richard Fuchs writes:
easy. when ice capable sip ua registers, it has +sip.ice feature tag in
contact uri. caller's ice support can be detected using sdp_with_ice()
function that i introduced today.
Sorry, I meant the RTP proxy, not the SIP proxy.
cheers
why?
when both parties use ice, i don't see any reason to touch c line.
How would the proxy know ahead of time that both parties actually
support ICE?
12:13 a.m.
Richard Fuchs writes:
Sorry, I meant the RTP proxy, not the SIP proxy.
rtp proxy does not need to know anything. it just does what it is
explicitly asked for by sip proxy.
-- juha
How would the proxy know ahead of time that both
parties actually
support ICE?
easy. when ice capable sip ua registers, it has +sip.ice feature tag in
contact uri. caller's ice support can be detected using sdp_with_ice()
function that i introduced today.
12:15 a.m.
On 04/28/14 15:13, Juha Heinanen wrote:
Richard Fuchs writes:
Sorry, I meant the RTP proxy, not the SIP proxy.
rtp proxy does not need to know anything. it just does what it is
explicitly asked for by sip proxy.
Yes, and it is asked to proxy RTP traffic, which requires modifying c=
and m= lines :)
How would the proxy know ahead of time that both
parties actually
support ICE?
easy. when ice capable sip ua registers, it has +sip.ice feature tag in
contact uri. caller's ice support can be detected using sdp_with_ice()
function that i introduced today.
12:17 a.m.
On 04/28/2014 03:15 PM, Richard Fuchs wrote:
Yes, and it is asked to proxy RTP traffic, which
requires modifying c=
and m= lines :)
You can introduce a new rtpengine function to offer "moral support" for
an ICE media exchange. :-)
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
12:34 a.m.
On 28/04/14 03:28 PM, Juha Heinanen wrote:
Richard Fuchs writes:
It probably is, but like I said before, the RTP proxy cannot know that
both parties support ICE ahead of time.
Counter-question: if both parties support ICE, then what difference does
it make if c= and m= are modified?
cheers
Yes, and it is asked to proxy RTP traffic, which
requires modifying c=
and m= lines :)
when both parties support ice, why is adding a=candidate lines not
enough?
12:39 a.m.
Richard Fuchs writes:
Counter-question: if both parties support ICE, then
what difference does
it make if c= and m= are modified?
i don't think it makes a difference, but is useless, since rtp proxy has
no way to figure out, which candidates will be chosen by the parties and
thus which addresses to put on c and m lines.
my point is that rtpengine should only do what it is asked to do. if it
is not asked to modify c and m lines, it should leave them alone.
-- juha
12:42 a.m.
+1
On Apr 28, 2014 3:39 PM, "Juha Heinanen" <jh(a)tutpro.com> wrote:
Richard Fuchs writes:
Counter-question: if both parties support ICE,
then what difference does
it make if c= and m= are modified?
i don't think it makes a difference, but is useless, since rtp proxy has
no way to figure out, which candidates will be chosen by the parties and
thus which addresses to put on c and m lines.
my point is that rtpengine should only do what it is asked to do. if it
is not asked to modify c and m lines, it should leave them alone.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
12:48 a.m.
On 28/04/14 03:39 PM, Juha Heinanen wrote:
Richard Fuchs writes:
And I disagree, since I don't know of any sensible use case where it
would make sense not to modify m= and c=. If ICE isn't supported, then
the default should be to go through the RTP proxy. If it is supported,
then it makes no difference either way, AFAIK.
If ICE isn't supported and you don't want the traffic to go through the
RTP proxy, you can just not call _offer()/_answer().
cheers
Counter-question: if both parties support ICE,
then what difference does
it make if c= and m= are modified?
i don't think it makes a difference, but is useless, since rtp proxy has
no way to figure out, which candidates will be chosen by the parties and
thus which addresses to put on c and m lines.
my point is that rtpengine should only do what it is asked to do. if it
is not asked to modify c and m lines, it should leave them alone.
12:52 a.m.
On 04/28/2014 03:48 PM, Richard Fuchs wrote:
If ICE isn't supported and you don't want the
traffic to go through the
RTP proxy, you can just not call _offer()/_answer().
It seems to me the disagreement here is about how much "management" the
_offer/_answer() functions should "wrap".
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
1:17 a.m.
On 28/04/14 03:52 PM, Alex Balashov wrote:
On 04/28/2014 03:48 PM, Richard Fuchs wrote:
Hmmm no not really... I just think that since rtpengine itself cannot
know whether or not ICE is supported, it shouldn't assume that it is,
with the result in the opposite case being that it effectively does nothing.
I'm not opposed to an explicit "no-touchy-m-and-c" flag, but the default
behaviour should be that rtpengine should try to do what it's designed
to do, which is to proxy RTP packets. Especially since in the case that
this is supposed to address (ICE is supported) it doesn't seem to make a
difference anyway.
cheers
If ICE isn't supported and you don't want
the traffic to go through the
RTP proxy, you can just not call _offer()/_answer().
It seems to me the disagreement here is about how much "management" the
_offer/_answer() functions should "wrap".
1:21 a.m.
I can't remember all the details, but after an ICE negotiation, during
the UPDATE that confirms the negotiated parameters, the c line
shouldn't be touched (if touched, it breakes the ICE negotiation).
Maybe the new rtpproxyengine handles this by default ...
Regards,
Ovidiu Sas
On Mon, Apr 28, 2014 at 4:17 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 28/04/14 03:52 PM, Alex Balashov wrote:
--
VoIP Embedded, Inc.
http://www.voipembedded.com
On 04/28/2014 03:48 PM, Richard Fuchs wrote:
Hmmm no not really... I just think that since rtpengine itself cannot know
whether or not ICE is supported, it shouldn't assume that it is, with the
result in the opposite case being that it effectively does nothing.
I'm not opposed to an explicit "no-touchy-m-and-c" flag, but the default
behaviour should be that rtpengine should try to do what it's designed to
do, which is to proxy RTP packets. Especially since in the case that this is
supposed to address (ICE is supported) it doesn't seem to make a difference
anyway.
cheers
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev If ICE isn't supported and you don't want
the traffic to go through the
RTP proxy, you can just not call _offer()/_answer().
It seems to me the disagreement here is about how much "management" the
_offer/_answer() functions should "wrap".
1:41 a.m.
On 28/04/14 04:21 PM, Ovidiu Sas wrote:
I can't remember all the details, but after an ICE
negotiation, during
the UPDATE that confirms the negotiated parameters, the c line
shouldn't be touched (if touched, it breakes the ICE negotiation).
Maybe the new rtpproxyengine handles this by default ...
I wasn't aware of this, is there an RFC which specifies this? All the
ICE negotiations I've seen so far were done entirely outside of
signalling (apart from the initial offers and answers). I believe
rtpproxy would also be guilty of this then, as it also always modifies
m= and c=.
cheers
1:57 a.m.
It's in the ICE spec. I can't remember all the details.
Try to make a call between two ICE clients that are using UPDATE to
confirm the negotiated stream (I think with prflx candidates).
Regards,
Ovidiu Sas
On Mon, Apr 28, 2014 at 4:41 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 28/04/14 04:21 PM, Ovidiu Sas wrote:
--
VoIP Embedded, Inc.
http://www.voipembedded.com
I can't remember all the details, but after an ICE negotiation, during
the UPDATE that confirms the negotiated parameters, the c line
shouldn't be touched (if touched, it breakes the ICE negotiation).
Maybe the new rtpproxyengine handles this by default ...
I wasn't aware of this, is there an RFC which specifies this? All the ICE
negotiations I've seen so far were done entirely outside of signalling
(apart from the initial offers and answers). I believe rtpproxy would also
be guilty of this then, as it also always modifies m= and c=.
cheers
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
9:35 p.m.
New subject: ICE=force_relay tests between two baresips
i made some ICE=force_relay tests between two baresip sip uas running on
the same host. the result was that they decided to use relay candidates
even when direct connection would have been possible.
the question is why? is it a bug in baresip's ice implementation or is
it a result of the fact that rtpengine changed ip address on c line and
port on m line (which, in opinion, it should not have done), or is the
priority of relay candidates wrong (i.e., smaller value means higher
priority)?
sdps are shown below. any hints would be appreciated. i'll cc also to
baresip list.
-- juha
----------- invite sdp to sip proxy from caller
v=0.
o=- 1831289157 1375419182 IN IP4 192.168.43.146.
s=-.
c=IN IP4 192.168.43.146.
t=0 0.
a=tool:baresip 0.4.10.
a=ice-lite.
a=ice-ufrag:EIQC.
a=ice-pwd:DNXuahNdPEKC53rtVnweqq.
m=audio 10518 RTP/AVP 96 97 98 8 0 101.
b=AS:125.
a=rtpmap:96 opus/48000/2.
a=fmtp:96 stereo=1;sprop-stereo=1.
a=rtpmap:97 speex/16000.
a=fmtp:97 mode="7";vbr=off;cng=on.
a=rtpmap:98 speex/8000.
a=fmtp:98 mode="7";vbr=off;cng=on.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=sendrecv.
a=label:1.
a=rtcp-rsize.
a=ssrc:2581598159 cname:sip:test@test.tutpro.com.
a=ptime:20.
a=candidate:c062661e 1 UDP 2113932031 192.98.102.30 10518 typ host.
a=candidate:c062661e 2 UDP 2113932030 192.98.102.30 10519 typ host.
a=candidate:c0a82b92 1 UDP 2113932031 192.168.43.146 10518 typ host.
a=candidate:c0a82b92 2 UDP 2113932030 192.168.43.146 10519 typ host.
a=candidate:c062671e 1 UDP 2113932031 192.98.103.30 10518 typ host.
a=candidate:c062671e 2 UDP 2113932030 192.98.103.30 10519 typ host.
a=candidate:63c01c46 1 UDP 2113932031 2002:c062:661e::1 10518 typ host.
a=candidate:63c01c46 2 UDP 2113932030 2002:c062:661e::1 10519 typ host.
a=candidate:1e6662c0 1 UDP 2113932031 ::192.98.102.30 10518 typ host.
a=candidate:1e6662c0 2 UDP 2113932030 ::192.98.102.30 10519 typ host.
----------- invite sdp from sip proxy callee
v=0.
o=- 1831289157 1375419182 IN IP4 192.98.102.30.
s=-.
c=IN IP4 192.98.102.30.
t=0 0.
a=tool:baresip 0.4.10.
a=ice-lite.
a=ice-ufrag:EIQC.
a=ice-pwd:DNXuahNdPEKC53rtVnweqq.
m=audio 50012 RTP/AVP 96 97 98 8 0 101.
b=AS:125.
a=rtpmap:96 opus/48000/2.
a=fmtp:96 stereo=1;sprop-stereo=1.
a=rtpmap:97 speex/16000.
a=fmtp:97 mode="7";vbr=off;cng=on.
a=rtpmap:98 speex/8000.
a=fmtp:98 mode="7";vbr=off;cng=on.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=label:1.
a=rtcp-rsize.
a=ssrc:2581598159 cname:sip:test@test.tutpro.com.
a=ptime:20.
a=candidate:c062661e 1 UDP 2113932031 192.98.102.30 10518 typ host.
a=candidate:c062661e 2 UDP 2113932030 192.98.102.30 10519 typ host.
a=candidate:c0a82b92 1 UDP 2113932031 192.168.43.146 10518 typ host.
a=candidate:c0a82b92 2 UDP 2113932030 192.168.43.146 10519 typ host.
a=candidate:c062671e 1 UDP 2113932031 192.98.103.30 10518 typ host.
a=candidate:c062671e 2 UDP 2113932030 192.98.103.30 10519 typ host.
a=candidate:63c01c46 1 UDP 2113932031 2002:c062:661e::1 10518 typ host.
a=candidate:63c01c46 2 UDP 2113932030 2002:c062:661e::1 10519 typ host.
a=candidate:1e6662c0 1 UDP 2113932031 ::192.98.102.30 10518 typ host.
a=candidate:1e6662c0 2 UDP 2113932030 ::192.98.102.30 10519 typ host.
a=sendrecv.
a=rtcp:50013.
a=candidate:bTYPlIJSc0vw3WjT 1 UDP 16777216 192.98.102.30 50012 typ relay.
a=candidate:bTYPlIJSc0vw3WjT 2 UDP 16777215 192.98.102.30 50013 typ relay.
----------- 200 ok sdp from callee to sip proxy
v=0.
o=- 2323140971 266432672 IN IP4 192.168.43.146.
s=-.
c=IN IP4 192.168.43.146.
t=0 0.
a=tool:baresip 0.4.10.
a=ice-lite.
a=ice-ufrag:cxB9.
a=ice-pwd:mLyJkKOP8xHg3Yv9R0BClp.
m=audio 10332 RTP/AVP 96 97 98 8 0 101.
b=AS:125.
a=rtpmap:96 opus/48000/2.
a=fmtp:96 stereo=1;sprop-stereo=1.
a=rtpmap:97 speex/16000.
a=fmtp:97 mode="7";vbr=off;cng=on.
a=rtpmap:98 speex/8000.
a=fmtp:98 mode="7";vbr=off;cng=on.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=sendrecv.
a=label:1.
a=rtcp-rsize.
a=ssrc:2733287141 cname:sip:jh@test.tutpro.com.
a=ptime:20.
a=candidate:c062661e 1 UDP 2113932031 192.98.102.30 10332 typ host.
a=candidate:c062661e 2 UDP 2113932030 192.98.102.30 10333 typ host.
a=candidate:c0a82b92 1 UDP 2113932031 192.168.43.146 10332 typ host.
a=candidate:c0a82b92 2 UDP 2113932030 192.168.43.146 10333 typ host.
a=candidate:c062671e 1 UDP 2113932031 192.98.103.30 10332 typ host.
a=candidate:c062671e 2 UDP 2113932030 192.98.103.30 10333 typ host.
a=candidate:63c01c46 1 UDP 2113932031 2002:c062:661e::1 10332 typ host.
a=candidate:63c01c46 2 UDP 2113932030 2002:c062:661e::1 10333 typ host.
a=candidate:1e6662c0 1 UDP 2113932031 ::192.98.102.30 10332 typ host.
a=candidate:1e6662c0 2 UDP 2113932030 ::192.98.102.30 10333 typ host.
----------- 200 ok sdp from sip proxy to caller
v=0.
o=- 2323140971 266432672 IN IP4 192.98.102.30.
s=-.
c=IN IP4 192.98.102.30.
t=0 0.
a=tool:baresip 0.4.10.
a=ice-lite.
a=ice-ufrag:cxB9.
a=ice-pwd:mLyJkKOP8xHg3Yv9R0BClp.
m=audio 50014 RTP/AVP 96 97 98 8 0 101.
b=AS:125.
a=rtpmap:96 opus/48000/2.
a=fmtp:96 stereo=1;sprop-stereo=1.
a=rtpmap:97 speex/16000.
a=fmtp:97 mode="7";vbr=off;cng=on.
a=rtpmap:98 speex/8000.
a=fmtp:98 mode="7";vbr=off;cng=on.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=label:1.
a=rtcp-rsize.
a=ssrc:2733287141 cname:sip:jh@test.tutpro.com.
a=ptime:20.
a=candidate:c062661e 1 UDP 2113932031 192.98.102.30 10332 typ host.
a=candidate:c062661e 2 UDP 2113932030 192.98.102.30 10333 typ host.
a=candidate:c0a82b92 1 UDP 2113932031 192.168.43.146 10332 typ host.
a=candidate:c0a82b92 2 UDP 2113932030 192.168.43.146 10333 typ host.
a=candidate:c062671e 1 UDP 2113932031 192.98.103.30 10332 typ host.
a=candidate:c062671e 2 UDP 2113932030 192.98.103.30 10333 typ host.
a=candidate:63c01c46 1 UDP 2113932031 2002:c062:661e::1 10332 typ host.
a=candidate:63c01c46 2 UDP 2113932030 2002:c062:661e::1 10333 typ host.
a=candidate:1e6662c0 1 UDP 2113932031 ::192.98.102.30 10332 typ host.
a=candidate:1e6662c0 2 UDP 2113932030 ::192.98.102.30 10333 typ host.
a=sendrecv.
a=rtcp:50015.
a=candidate:bTYPlIJSc0vw3WjT 1 UDP 16777216 192.98.102.30 50014 typ relay.
----------------------------
during call baresip reports that relay ip/port is in use:
RTP debug:
Encode: seq=6904 ssrc=0x99e00fcf
----- RTCP Session: -----
cname=sip:test@test.tutpro.com SSRC=0x99e00fcf/2581598159 rx=48000Hz
member 0xa2eaa6e5: lost=0 Jitter=19.6ms RTT=0.7ms
IP=192.98.102.30:50014 psent=512 rcvd=736
TX: packets=737, octets=179009
9:53 p.m.
New subject: ICE=force_relay tests between two baresips
On 04/29/14 12:35, Juha Heinanen wrote:
i made some ICE=force_relay tests between two baresip
sip uas running on
the same host. the result was that they decided to use relay candidates
even when direct connection would have been possible.
the question is why? is it a bug in baresip's ice implementation or is
it a result of the fact that rtpengine changed ip address on c line and
port on m line (which, in opinion, it should not have done), or is the
priority of relay candidates wrong (i.e., smaller value means higher
priority)?
Higher priority numbers have higher priority, with relay candidates
having the lowest type preference number, thus lowest priority. Baresip
seems to give different host candidates the same priority though. This
is invalid according to the RFC.
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.
cheers
10:02 p.m.
New subject: ICE=force_relay tests between two baresips
Richard Fuchs writes:
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).
-- Juha
10:18 p.m.
New subject: ICE=force_relay tests between two baresips
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).
10:30 p.m.
New subject: ICE=force_relay tests between two baresips
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.
ok, how about making ICE=force_relay to imply "leave c and m lines as is?
this should not break anything, because ICE=force_relay is a new
flag value and its purpose is just to add relay candidates to ice
capable session setup.
-- juha
10:35 p.m.
New subject: ICE=force_relay tests between two baresips
On 04/29/14 13:30, Juha Heinanen wrote:
Richard Fuchs writes:
Fine with me. Should only take a couple of lines of code.
cheers
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.
ok, how about making ICE=force_relay to imply "leave c and m lines as is?
this should not break anything, because ICE=force_relay is a new
flag value and its purpose is just to add relay candidates to ice
capable session setup.
30 Apr
30 Apr
12:50 a.m.
New subject: ICE=force_relay tests between two baresips
Richard Fuchs writes:
Fine with me. Should only take a couple of lines of
code.
i edited daemon/sdp.c (diff enclosed) and after that o, c, and m lines
were left as is when ICE=force_relay was present. also two baresips now
talked directly for rtp, but still used rtpengine for rtpc.
perhaps than can be explained by the fact that there was no
a=rtcp:<port> or a=rtcp-mux attribute in sdp from caller baresip:
v=0.
o=- 3026288523 667456406 IN IP4 192.168.43.146.
s=-.
c=IN IP4 192.168.43.146.
t=0 0.
a=tool:baresip 0.4.10.
a=ice-lite.
a=ice-ufrag:fjww.
a=ice-pwd:FjnvBvq6JcJqCuaQ1shfb5.
m=audio 10788 RTP/AVP 96 97 98 8 0 101.
b=AS:125.
a=rtpmap:96 opus/48000/2.
a=fmtp:96 stereo=1;sprop-stereo=1.
a=rtpmap:97 speex/16000.
a=fmtp:97 mode="7";vbr=off;cng=on.
a=rtpmap:98 speex/8000.
a=fmtp:98 mode="7";vbr=off;cng=on.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=sendrecv.
a=label:1.
a=rtcp-rsize.
a=ssrc:2097792405 cname:sip:test@test.tutpro.com.
a=ptime:20.
a=candidate:c062661e 1 UDP 2113932031 192.98.102.30 10788 typ host.
a=candidate:c062661e 2 UDP 2113932030 192.98.102.30 10789 typ host.
a=candidate:c0a82b92 1 UDP 2113932031 192.168.43.146 10788 typ host.
a=candidate:c0a82b92 2 UDP 2113932030 192.168.43.146 10789 typ host.
a=candidate:c062671e 1 UDP 2113932031 192.98.103.30 10788 typ host.
a=candidate:c062671e 2 UDP 2113932030 192.98.103.30 10789 typ host.
a=candidate:63c01c46 1 UDP 2113932031 2002:c062:661e::1 10788 typ host.
a=candidate:63c01c46 2 UDP 2113932030 2002:c062:661e::1 10789 typ host.
a=candidate:1e6662c0 1 UDP 2113932031 ::192.98.102.30 10788 typ host.
a=candidate:1e6662c0 2 UDP 2113932030 ::192.98.102.30 10789 typ host.
but rtpengine went and added a=rtcp:50009 to sdp of the invite:
v=0.
o=- 3026288523 667456406 IN IP4 192.168.43.146.
s=-.
c=IN IP4 192.168.43.146.
t=0 0.
a=tool:baresip 0.4.10.
a=ice-lite.
a=ice-ufrag:fjww.
a=ice-pwd:FjnvBvq6JcJqCuaQ1shfb5.
m=audio 10788 RTP/AVP 96 97 98 8 0 101.
b=AS:125.
a=rtpmap:96 opus/48000/2.
a=fmtp:96 stereo=1;sprop-stereo=1.
a=rtpmap:97 speex/16000.
a=fmtp:97 mode="7";vbr=off;cng=on.
a=rtpmap:98 speex/8000.
a=fmtp:98 mode="7";vbr=off;cng=on.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=label:1.
a=rtcp-rsize.
a=ssrc:2097792405 cname:sip:test@test.tutpro.com.
a=ptime:20.
a=candidate:c062661e 1 UDP 2113932031 192.98.102.30 10788 typ host.
a=candidate:c062661e 2 UDP 2113932030 192.98.102.30 10789 typ host.
a=candidate:c0a82b92 1 UDP 2113932031 192.168.43.146 10788 typ host.
a=candidate:c0a82b92 2 UDP 2113932030 192.168.43.146 10789 typ host.
a=candidate:c062671e 1 UDP 2113932031 192.98.103.30 10788 typ host.
a=candidate:c062671e 2 UDP 2113932030 192.98.103.30 10789 typ host.
a=candidate:63c01c46 1 UDP 2113932031 2002:c062:661e::1 10788 typ host.
a=candidate:63c01c46 2 UDP 2113932030 2002:c062:661e::1 10789 typ host.
a=candidate:1e6662c0 1 UDP 2113932031 ::192.98.102.30 10788 typ host.
a=candidate:1e6662c0 2 UDP 2113932030 ::192.98.102.30 10789 typ host.
a=sendrecv.
a=rtcp:50009.
a=candidate:vWmFu3vQHsxxmORV 1 UDP 16777216 192.98.102.30 50008 typ relay.
a=candidate:vWmFu3vQHsxxmORV 2 UDP 16777215 192.98.102.30 50009 typ relay.
it thus looks like that when ICE=force_relay is given, also adding of
a=rtcp:<port> need to be prevented.
-- juha
*** sdp.c Mon Apr 28 17:46:41 2014
--- /usr/src/opensipg/trunk/src/rtpengine/daemon/sdp.c Tue Apr 29 22:15:26 2014
***************
*** 1670,1680 ****
}
}
! if (session->origin.parsed && flags->replace_origin) {
if (replace_network_address(chop, &session->origin.address, ps, flags))
goto error;
}
! if (session->connection.parsed && sess_conn) {
if (replace_network_address(chop, &session->connection.address, ps, flags))
goto error;
}
--- 1670,1682 ----
}
}
! if (session->origin.parsed && flags->replace_origin &&
! !flags->ice_force_relay) {
if (replace_network_address(chop, &session->origin.address, ps, flags))
goto error;
}
! if (session->connection.parsed && sess_conn &&
! !flags->ice_force_relay) {
if (replace_network_address(chop, &session->connection.address, ps, flags))
goto error;
}
***************
*** 1703,1718 ****
goto error;
ps = j->data;
! if (replace_media_port(chop, sdp_media, ps))
! goto error;
! if (replace_consecutive_port_count(chop, sdp_media, ps, j))
! goto error;
! if (replace_transport_protocol(chop, sdp_media, call_media))
! goto error;
!
! if (sdp_media->connection.parsed) {
! if (replace_network_address(chop, &sdp_media->connection.address, ps,
flags))
! goto error;
}
if (process_media_attributes(chop, sdp_media, flags, call_media))
--- 1705,1722 ----
goto error;
ps = j->data;
! if (!flags->ice_force_relay) {
! if (replace_media_port(chop, sdp_media, ps))
! goto error;
! if (replace_consecutive_port_count(chop, sdp_media, ps, j))
! goto error;
! if (replace_transport_protocol(chop, sdp_media, call_media))
! goto error;
!
! if (sdp_media->connection.parsed) {
! if (replace_network_address(chop, &sdp_media->connection.address, ps,
flags))
! goto error;
! }
}
if (process_media_attributes(chop, sdp_media, flags, call_media))
9:45 a.m.
New subject: ICE=force_relay tests between two baresips
Juha Heinanen writes:
it thus looks like that when ICE=force_relay is given,
also adding of
a=rtcp:<port> need to be prevented.
if a=rtcp:<port> did not exist in incoming sdp, there is no need for
rtpengine to add it, because then, by default, rtcp port is one larger
than rtp port.
if a=rtcp:<port> did exist in incoming sdp, then rtpengine needs to
change <port> value, if it changed m line port value.
so this issue is not really related to ICE=force_relay except that when
ICE=force_relay exists in incoming sdp, then m line port is not changed.
-- juha
6:33 p.m.
New subject: ICE=force_relay tests between two baresips
On 04/30/14 00:45, Juha Heinanen wrote:
Juha Heinanen writes:
ICE mandates that the a=rtcp attribute is present, even if the RTCP port
is the default one.
cheers.
it thus looks like that when ICE=force_relay is
given, also adding of
a=rtcp:<port> need to be prevented.
if a=rtcp:<port> did not exist in incoming sdp, there is no need for
rtpengine to add it, because then, by default, rtcp port is one larger
than rtp port.
1 May
1 May
3:52 p.m.
New subject: ICE=force_relay tests between two baresips
Richard Fuchs writes:
I did check ice rfc 5245 and didn't find such requirement. Word "rtcp"
does not exist in the rfc and its ice sdp example does not include rtcp
attribute:
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 192.0.2.3
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998
Where did you find the requirement? Is it in some other rfc?
-- Juha
if
a=rtcp:<port> did not exist in incoming sdp, there is no need for
rtpengine to add it, because then, by default, rtcp port is one larger
than rtp port.
ICE mandates that the a=rtcp attribute is present, even if the RTCP port
is the default one.
4:05 p.m.
New subject: ICE=force_relay tests between two baresips
On 05/01/14 06:52, Juha Heinanen wrote:
Richard Fuchs writes:
I did check ice rfc 5245 and didn't find such requirement. Word "rtcp"
does not exist in the rfc and its ice sdp example does not include rtcp
attribute:
Section 4.3, 6th paragraph:
The default candidates are added to the SDP as the default
destination for media. For streams based on RTP, this is done by
placing the IP address and port of the RTP candidate into the c and m
lines, respectively. If the agent is utilizing RTCP, it MUST encode
the RTCP candidate using the a=rtcp attribute as defined in RFC 3605
[RFC3605]. If RTCP is not in use, the agent MUST signal that using
b=RS:0 and b=RR:0 as defined in RFC 3556 [RFC3556].
The sample SDP doesn't include it because it has RTCP disabled.
cheers
if
a=rtcp:<port> did not exist in incoming sdp, there is no need for
rtpengine to add it, because then, by default, rtcp port is one larger
than rtp port.
ICE mandates that the a=rtcp attribute is present, even if the RTCP port
is the default one.
4:23 p.m.
New subject: ICE=force_relay tests between two baresips
Richard Fuchs writes:
Section 4.3, 6th paragraph:
The default candidates are added to the SDP as the default
destination for media. For streams based on RTP, this is done by
placing the IP address and port of the RTP candidate into the c and m
lines, respectively. If the agent is utilizing RTCP, it MUST encode
the RTCP candidate using the a=rtcp attribute as defined in RFC 3605
[RFC3605]. If RTCP is not in use, the agent MUST signal that using
b=RS:0 and b=RR:0 as defined in RFC 3556 [RFC3556].
The sample SDP doesn't include it because it has RTCP disabled.
ok thanks. i'll try to get it fixed in baresip and see how to prevent
rtpengine updating a=rtcp:<port> when ICE=force_relay is present.
-- juha
7:11 p.m.
New subject: [Re-devel] ICE=force_relay tests between two baresips
On 04/29/2014 06:35 PM, Juha Heinanen wrote:
i made some ICE=force_relay tests between two baresip
sip uas running on
the same host. the result was that they decided to use relay candidates
even when direct connection would have been possible.
the question is why? is it a bug in baresip's ice implementation or is
it a result of the fact that rtpengine changed ip address on c line and
port on m line (which, in opinion, it should not have done), or is the
priority of relay candidates wrong (i.e., smaller value means higher
priority)?
sdps are shown below. any hints would be appreciated. i'll cc also to
baresip list.
<snip>
----------- 200 ok sdp from sip proxy to caller
v=0.
o=- 2323140971 266432672 IN IP4 192.98.102.30.
s=-.
c=IN IP4 192.98.102.30.
t=0 0.
a=tool:baresip 0.4.10.
a=ice-lite.
a=ice-ufrag:cxB9.
a=ice-pwd:mLyJkKOP8xHg3Yv9R0BClp.
m=audio 50014 RTP/AVP 96 97 98 8 0 101.
b=AS:125.
a=rtpmap:96 opus/48000/2.
a=fmtp:96 stereo=1;sprop-stereo=1.
a=rtpmap:97 speex/16000.
a=fmtp:97 mode="7";vbr=off;cng=on.
a=rtpmap:98 speex/8000.
a=fmtp:98 mode="7";vbr=off;cng=on.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=label:1.
a=rtcp-rsize.
a=ssrc:2733287141 cname:sip:jh@test.tutpro.com.
a=ptime:20.
a=candidate:c062661e 1 UDP 2113932031 192.98.102.30 10332 typ host.
a=candidate:c062661e 2 UDP 2113932030 192.98.102.30 10333 typ host.
a=candidate:c0a82b92 1 UDP 2113932031 192.168.43.146 10332 typ host.
a=candidate:c0a82b92 2 UDP 2113932030 192.168.43.146 10333 typ host.
a=candidate:c062671e 1 UDP 2113932031 192.98.103.30 10332 typ host.
a=candidate:c062671e 2 UDP 2113932030 192.98.103.30 10333 typ host.
a=candidate:63c01c46 1 UDP 2113932031 2002:c062:661e::1 10332 typ host.
a=candidate:63c01c46 2 UDP 2113932030 2002:c062:661e::1 10333 typ host.
a=candidate:1e6662c0 1 UDP 2113932031 ::192.98.102.30 10332 typ host.
a=candidate:1e6662c0 2 UDP 2113932030 ::192.98.102.30 10333 typ host.
a=sendrecv.
a=rtcp:50015.
a=candidate:bTYPlIJSc0vw3WjT 1 UDP 16777216 192.98.102.30 50014 typ relay.
^^^^^
it looks like Component 2 (RTCP) is missing here ...?
you can try to run baresip in verbose debug mode (-v) and also
set "ice_debug" to "yes" in the config file.
/alfred
7:17 p.m.
New subject: [Re-devel] ICE=force_relay tests between two baresips
Alfred E. Heggestad writes:
it looks like Component 2 (RTCP) is missing here ...?
you can try to run baresip in verbose debug mode (-v) and also
set "ice_debug" to "yes" in the config file.
it turned out baresip does not include a=rtcp line if ice_mode lite is
chosen.
-- juha
8:39 p.m.
enclosed diff on rtpengine/daemon/sdp.c leaves attributes of original
sdp untouched if ICE=force_relay flag is set. i tested it with sdps
generated by baresip, jssip, and pjsip.
this diff complements earlier commit that added ICE=force_relay flag,
which is not really useful if original sdp attributes are not left as
is.
-- juha
*** /usr/src/orig/rtpengine/daemon/sdp.c Mon Apr 28 17:46:41 2014
--- sdp.c Thu May 1 17:49:06 2014
***************
*** 1399,1404 ****
--- 1399,1406 ----
case ATTR_RTCP:
case ATTR_RTCP_MUX:
+ if (flags->ice_force_relay)
+ break;
case ATTR_INACTIVE:
case ATTR_SENDONLY:
case ATTR_RECVONLY:
***************
*** 1670,1680 ****
}
}
! if (session->origin.parsed && flags->replace_origin) {
if (replace_network_address(chop, &session->origin.address, ps, flags))
goto error;
}
! if (session->connection.parsed && sess_conn) {
if (replace_network_address(chop, &session->connection.address, ps, flags))
goto error;
}
--- 1672,1684 ----
}
}
! if (session->origin.parsed && flags->replace_origin &&
! !flags->ice_force_relay) {
if (replace_network_address(chop, &session->origin.address, ps, flags))
goto error;
}
! if (session->connection.parsed && sess_conn &&
! !flags->ice_force_relay) {
if (replace_network_address(chop, &session->connection.address, ps, flags))
goto error;
}
***************
*** 1703,1718 ****
goto error;
ps = j->data;
! if (replace_media_port(chop, sdp_media, ps))
! goto error;
! if (replace_consecutive_port_count(chop, sdp_media, ps, j))
! goto error;
! if (replace_transport_protocol(chop, sdp_media, call_media))
! goto error;
!
! if (sdp_media->connection.parsed) {
! if (replace_network_address(chop, &sdp_media->connection.address, ps,
flags))
! goto error;
}
if (process_media_attributes(chop, sdp_media, flags, call_media))
--- 1707,1724 ----
goto error;
ps = j->data;
! if (!flags->ice_force_relay) {
! if (replace_media_port(chop, sdp_media, ps))
! goto error;
! if (replace_consecutive_port_count(chop, sdp_media, ps, j))
! goto error;
! if (replace_transport_protocol(chop, sdp_media, call_media))
! goto error;
!
! if (sdp_media->connection.parsed) {
! if (replace_network_address(chop, &sdp_media->connection.address, ps,
flags))
! goto error;
! }
}
if (process_media_attributes(chop, sdp_media, flags, call_media))
***************
*** 1749,1755 ****
chopper_append_c(chop, "\r\na=rtcp-mux\r\n");
ps_rtcp = NULL;
}
! else if (ps_rtcp) {
chopper_append_c(chop, "a=rtcp:");
chopper_append_printf(chop, "%hu", ps_rtcp->sfd->fd.localport);
if (!MEDIA_ISSET(call_media, RTCP_MUX))
--- 1755,1761 ----
chopper_append_c(chop, "\r\na=rtcp-mux\r\n");
ps_rtcp = NULL;
}
! else if (ps_rtcp && !flags->ice_force_relay) {
chopper_append_c(chop, "a=rtcp:");
chopper_append_printf(chop, "%hu", ps_rtcp->sfd->fd.localport);
if (!MEDIA_ISSET(call_media, RTCP_MUX))
2 May
2 May
12:01 a.m.
Applied, thanks.
On 05/01/14 11:39, Juha Heinanen wrote:
enclosed diff on rtpengine/daemon/sdp.c leaves
attributes of original
sdp untouched if ICE=force_relay flag is set. i tested it with sdps
generated by baresip, jssip, and pjsip.
this diff complements earlier commit that added ICE=force_relay flag,
which is not really useful if original sdp attributes are not left as
is.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
3658
days inactive
3661
days old
37 comments
5 participants
participants (5)
-
Alex Balashov -
Alfred E. Heggestad -
Juha Heinanen -
Ovidiu Sas -
Richard Fuchs