Module: sip-router Branch: master Commit: 75fde552f1c4cdea736baa72ff1aa36e527e0215 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=75fde552...
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Wed Jan 2 13:00:31 2013 +0200
modules/rtpproxy: rtpproxy_manage can now add ice relay candidates
- The feature is activated by defining ice_candidate_priority_avp module parameter.
---
modules/rtpproxy/README | 149 ++++++++++++++++++------------- modules/rtpproxy/doc/rtpproxy_admin.xml | 28 ++++++ modules/rtpproxy/rtpproxy.c | 139 ++++++++++++++++++++++++++++- 3 files changed, 250 insertions(+), 66 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=75fd...
Hi Juha,
is this commit taking the reply (media ip/port) from rtpproxy and makes ICE candidates out of it? If yes, that's nice indeed, like practically doing ICE without a turn server, right? What sip phones have you used for testing?
Thanks, Daniel
On 1/2/13 12:08 PM, Juha Heinanen wrote:
Module: sip-router Branch: master Commit: 75fde552f1c4cdea736baa72ff1aa36e527e0215 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=75fde552...
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Wed Jan 2 13:00:31 2013 +0200
modules/rtpproxy: rtpproxy_manage can now add ice relay candidates
- The feature is activated by defining ice_candidate_priority_avp module parameter.
modules/rtpproxy/README | 149 ++++++++++++++++++------------- modules/rtpproxy/doc/rtpproxy_admin.xml | 28 ++++++ modules/rtpproxy/rtpproxy.c | 139 ++++++++++++++++++++++++++++- 3 files changed, 250 insertions(+), 66 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=75fd...
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Daniel-Constantin Mierla writes:
is this commit taking the reply (media ip/port) from rtpproxy and makes ICE candidates out of it?
that is exactly what it tries to do.
If yes, that's nice indeed, like practically doing ICE without a turn server, right? What sip phones have you used for testing?
yes, because i had trouble with turn protocol due to its authentication scheme.
so far i have only tested the feature with baresip. it is likely that problems are discovered with more testing, but if the feature is not turned on, rtpproxy should keep on working as before.
-- juha
On Wednesday 02 January 2013, Juha Heinanen wrote:
Module: sip-router Branch: master Commit: 75fde552f1c4cdea736baa72ff1aa36e527e0215 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=75fde5 52f1c4cdea736baa72ff1aa36e527e0215
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Wed Jan 2 13:00:31 2013 +0200
modules/rtpproxy: rtpproxy_manage can now add ice relay candidates
- The feature is activated by defining ice_candidate_priority_avp module parameter.
This commit is introducing compiler warnings, can you please fix them?
This line: LM_DBG("inserting '%.*s'\n", at - buf, buf);
CC (gcc) [M rtpproxy.so] rtpproxy.o rtpproxy.c: In function 'insert_candidates': rtpproxy.c:1467: warning: field precision should have type 'int', but argument 7 has type 'long int' rtpproxy.c:1467: warning: field precision should have type 'int', but argument 5 has type 'long int' rtpproxy.c:1467: warning: field precision should have type 'int', but argument 6 has type 'long int' rtpproxy.c:1467: warning: field precision should have type 'int', but argument 4 has type 'long int' rtpproxy.c:1467: warning: field precision should have type 'int', but argument 4 has type 'long int'
Alex Hermann writes:
This commit is introducing compiler warnings, can you please fix them?
This line: LM_DBG("inserting '%.*s'\n", at - buf, buf);
fixed by removing the offending line (don't know how to tell '%.*' that length is long).
-- juha
On 1/7/13 9:02 PM, Juha Heinanen wrote:
Alex Hermann writes:
This commit is introducing compiler warnings, can you please fix them?
This line: LM_DBG("inserting '%.*s'\n", at - buf, buf);
fixed by removing the offending line (don't know how to tell '%.*' that length is long).
Just cast to int:
LM_DBG("inserting '%.*s'\n", (int)(at - buf), buf);
Cheers, Daniel
Hello Juha,
The relay candidate is added only for RTP stream, but not for RTCP stream. Example: received SDP: v=0. o=- 3569961501 3569961501 IN IP4 192.168.2.104. s=cpc_med. c=IN IP4 192.168.2.104. t=0 0. m=audio 53528 RTP/AVP 0 101. a=sendrecv. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ice-ufrag:3d6687c0. a=ice-pwd:165a6dbe. a=candidate:Hc0a80268 1 UDP 2130706431 192.168.2.104 53528 typ host. a=candidate:Hc0a80268 2 UDP 2130706430 192.168.2.104 49908 typ host.
sent SDP: v=0. o=- 3569961501 3569961501 IN IP4 192.168.2.2. s=cpc_med. c=IN IP4 192.168.2.2. t=0 0. m=audio 11070 RTP/AVP 0 101. a=sendrecv. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ice-ufrag:3d6687c0. a=ice-pwd:165a6dbe. a=candidate:Hc0a80268 1 UDP 2130706431 192.168.2.104 53528 typ host. a=candidate:19216822 1 UDP 16777215 192.168.2.2 11070 typ relay. a=candidate:Hc0a80268 2 UDP 2130706430 192.168.2.104 49908 typ host.
We should have an extra candidate: a=candidate:19216822 1 UDP 16777215 192.168.2.2 11071 typ relay.
rtpproxy will allocate an extra port for RTCP traffic (RTP port + 1).
Regards, Ovidiu Sas
Hello Juha,
The rtcp port was computed only if an rtcp attibute was present in the received SDP. Since rtpproxy daemon will always allocate an RTCP port = RTP port + 1, I simplified insert_candidates() signature and computed each port inside. See commit 2e58de7e16203c849cf1c445dfb33d304ffd3507.
Regards, Ovidiu Sas
Ovidiu Sas writes:
The rtcp port was computed only if an rtcp attibute was present in the received SDP.
yes, that is what i thought the outbound draft specified.
Since rtpproxy daemon will always allocate an RTCP port = RTP port + 1, I simplified insert_candidates() signature and computed each port inside. See commit 2e58de7e16203c849cf1c445dfb33d304ffd3507.
ok, fine with me.
-- juha