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
Isn't origin the o= line?
On 28 April 2014 22:43:00 GMT+04:00, Juha Heinanen jh@tutpro.com wrote:
Juha Heinanen writes:
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- 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
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
Richard Fuchs writes:
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?
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
On 04/28/14 15:08, Juha Heinanen wrote:
Richard Fuchs writes:
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?
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
Richard Fuchs writes:
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.
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
On 04/28/14 15:13, Juha Heinanen wrote:
Richard Fuchs writes:
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.
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 :)
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
On 28/04/14 03:28 PM, Juha Heinanen wrote:
Richard Fuchs writes:
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?
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
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
+1 On Apr 28, 2014 3:39 PM, "Juha Heinanen" jh@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 28/04/14 03:39 PM, Juha Heinanen 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.
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
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".
On 28/04/14 03:52 PM, Alex Balashov wrote:
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".
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
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@sipwise.com wrote:
On 28/04/14 03:52 PM, Alex Balashov wrote:
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".
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
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@sipwise.com wrote:
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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
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
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
On 04/29/14 13:02, Juha Heinanen wrote:
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).
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
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
On 04/29/14 13:30, 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.
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.
Fine with me. Should only take a couple of lines of code.
cheers
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))
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
On 04/30/14 00:45, Juha Heinanen wrote:
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.
ICE mandates that the a=rtcp attribute is present, even if the RTCP port is the default one.
cheers.
Richard Fuchs writes:
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.
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
On 05/01/14 06:52, Juha Heinanen wrote:
Richard Fuchs writes:
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.
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
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
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
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
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))
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Alex Balashov -
Alfred E. Heggestad -
Juha Heinanen -
Ovidiu Sas -
Richard Fuchs