Hi,

On 07/05/2013 11:56 PM, Iwan Budi Kusnanto wrote:

I can see that SDES-SRTP is supported but DTLS-SRTP is not mentioned. Is it mean that there is no support for DTLS-SRTP? Any plan to support it?

It's planned (like ZRTP), just no specific time-line yet.

Andreas

Hi,

On 07/07/2013 11:19 AM, Raúl Alexis Betancor Santana wrote:

On Sat, Jul 06, 2013 at 10:01:28PM -0400, Nick Khamis wrote:

...

Can we run it behind nat? I've really been eyeing that and desparate to replace rtpproxy

Think twice ... trying to run something designed to avoid problems with NAT behing NAT? ... doesn't sound good at all ...

If it's behind a DNAT like on Amazon EC2, it could make sense.

Andreas

On 07/07/2013 04:01 AM, Nick Khamis wrote:

Can we run it behind nat? I've really been eyeing that and desparate to replace rtpproxy

Yes, check advertised address option.

Andreas

On 07/07/13 12:28, Juha Heinanen wrote:

why is it that ice relay candidate attributes are added only when rtpproxy_manage is called, i.e., why not also when rtpproxy_offer/rtpproxy_answer are called?

Shouldn't make a difference, they should behave the same. Otherwise please post log excerpts with details.

cheers

On 07/07/13 19:19, Nick Khamis wrote:

Last question from me. Does mediaproxy-ng have the media based accounting functionality that the original mediaproxy have? We currently have a problem where we are using RTPProxy along with CDRTool instead of the MediaProxy because of the lack for NAT support. This seems to be one of the reason for mediaproxy-ng? The problem we are having is that there are directives included in CDRTool such as

'%{SIP-Codecs}', '%{SIP-RPID}', '%{SIP-RPID-Header}', ''%{Rate}', \ '%{Price}', '%{Normalized}', '%{Billing-ID}', '%{MediaInfo}', '%{RTPStatistics}'

That are useless for RTPPProxy. More importantly RTPProxy does not support precise media based accounting which MediaProxy does. We really need this.

Despite its name, mediaproxy-ng is not supposed to be a replacement or enhancement to any other existing media/RTP proxy out there. So no, there's no support for any real accounting whatsoever.

cheers

On 07/08/13 01:52, Juha Heinanen wrote:

i haven't tried it yet. just read what readme says:

4.7. ice_candidate_priority_avp (string)

If specified and if value of the avp value is not 0, rtpproxy_manage function adds ICE relay candidate attributes to sdp stream(s) containing ICE candidate attributes.

This is from the regular rtpproxy module... not our code and has nothing to do with mediaproxy-ng, or any RTP proxy that runs behind it for that matter.

If you want to use mediaproxy-ng with its ICE features, you'll have to use it through the rtpproxy-ng module, which is currently available as patch here: https://github.com/sipwise/kamailio/blob/master/debian/patches/sipwise/rtpro...

cheers

Richard Fuchs writes:

If you want to use mediaproxy-ng with its ICE features, you'll have to use it through the rtpproxy-ng module, which is currently available as patch here: https://github.com/sipwise/kamailio/blob/master/debian/patches/sipwise/rtpro...

ok, i had missed that one. what is the reason that you have not committed rtpproxy-ng module to kamailio master branch?

-- juha

Richard Fuchs writes:

I've been meaning to commit it to a private branch for review/comments and eventual merging, but haven't gotten around to it yet.

if the module compiles and works for you, i don't see any reason for not committing it straight to master branch. that way the threshold for testing it would be much lower and the module would be ready to go when kamailio 4.1 is released.

-- juha

On 07/08/13 09:12, Juha Heinanen wrote:

i read readme of mediaproxy-ng module and don't find the rtpproxy module capability to tell priority of added ice attributes. also, i have hard time parsing this these sentences:

       + + - instructs the RTP proxy to discard any ICE attributes
         already present in the SDP body and then generate and insert
         new ICE data, leaving itself as the only ICE candidates.
         Without this flag, new ICE data will only be generated if no
         ICE was present in the SDP originally; otherwise the RTP proxy
         will only insert itself as an additional ICE candidate.

more specifically, what case "otherwise" describes?

Otherwise = no "+" flag given and ICE candidates already present.

There's no support for explicitly specifying the priority. In the case of mediaproxy-ng inserting itself as additional candidates, the priority will be chosen to be lower than anything already present.

cheers

let me know if this is not the right forum to discuss mediaproxg-ng issues.

got so far that i tried to make the first test call.

offer produced to syslog:

Jul 9 15:31:50 siika /usr/sbin/sip-proxy[11043]: INFO: ===== making rtpproxy_offer(co1) Jul 9 15:31:50 siika mediaproxy-ng[8678]: Got valid command from 127.0.0.1:49613: offer - { "sdp": "v=0#015#012o=- 437955195 1958899385 IN IP4 188.67.173.24#015#012s=-#015#012c=IN IP4 188.67.173.24#015#012t=0 0#015#012a=tool:baresip 0.4.4#015#012m=audio 11864 RTP/AVP 96 97 98 9 8 0 101#015#012b=AS:125#015#012a=rtpmap:96 SILK/24000#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:9 G722/8000#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=ptime:20#015#012m=video 11790 RTP/AVP 96#015#012b=AS:875#015#012a=rtpmap:96 VP8/90000#015#012a=fmtp:96 max-fs=3600#015#012a=sendrecv#015#012a=label:2#015#012a=framerate:25#015#012a=rtcp-fb:* nack pli#015#012a=content:main#015#012", "replace": [ "session-connection", "origin" ], "call-id": "92cf0b20e6bb471f", "via-branch": "z9hG4bKfe15ff7064beea1e", "received-from": [ "IP4", "192.98.102.10" ], "from-tag": "b4088ca29783a8c3", "command": "offer" } Jul 9 15:31:50 siika mediaproxy-ng[8678]: [92cf0b20e6bb471f] Creating new call Jul 9 15:31:50 siika mediaproxy-ng[8678]: [92cf0b20e6bb471f - z9hG4bKfe15ff7064beea1e] Opened ports 50020..50021 for RTP Jul 9 15:31:50 siika mediaproxy-ng[8678]: [92cf0b20e6bb471f - z9hG4bKfe15ff7064beea1e] Opened ports 50022..50023 for RTP Jul 9 15:31:50 siika mediaproxy-ng[8678]: [92cf0b20e6bb471f - z9hG4bKfe15ff7064beea1e] Opened ports 50024..50025 for RTP Jul 9 15:31:50 siika mediaproxy-ng[8678]: [92cf0b20e6bb471f - z9hG4bKfe15ff7064beea1e] Opened ports 50026..50027 for RTP Jul 9 15:31:50 siika mediaproxy-ng[8678]: Returning to SIP proxy: d3:sdp1049:v=0#015#012o=- 437955195 1958899385 IN IP4 0.0.0.0#015#012s=-#015#012c=IN IP4 0.0.0.0#015#012t=0 0#015#012a=tool:baresip 0.4.4#015#012a=ice-lite#015#012m=audio 50020 RTP/AVP 96 97 98 9 8 0 101#015#012b=AS:125#015#012a=rtpmap:96 SILK/24000#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:9 G722/8000#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=ptime:20#015#012a=rtcp:50021#015#012a=ice-ufrag:zh7wWUuR#015#012a=ice-pwd:Jsf02iXReProwbGapBQKvHd4YkyT#015#012a=candidate:nIBozd1qJPXwc730 1 UDP 2130706432 0.0.0.0 50020 typ host#015#012a=candidate:nIBozd1qJPXwc730 2 UDP 2130706431 0.0.0.0 50021 typ host#015#012m=video 50024 RTP/AVP 96#015#012b=AS:875#015#012a=rtpmap:96 VP8/90000#015#012a=fmtp:96 max-fs=3600#015#012a=sendrecv#015#012a=label:2#015#012a=framerate:25#015#012a=rtcp-fb:* nack pli#015#012a=content:main#015#012a=rtcp:50025#015#012a=ice-ufrag:d3KUtZSv#015#012a=ice-pwd:iPkwCLT7Xzhma64FNfIJyeCLhkFI#015#012a=candidate:nIBozd1qJPXwc730 1 UDP 2130706432 0.0.0.0 50024 typ host#015#012a=candidate:nIBozd1qJPXwc730 2 UDP 2130706431 0.0.0.0 50025 typ host#015#0126:result2:oke

why are ip4 addresses 0.0.0.0? my mediaproxy-ng is running with these options and i did not pass ip address as param too offer:

$ ps ax | egrep media 8678 ? Sl 10:19 /usr/sbin/mediaproxy-ng --ip=192.98.102.10 --listen-ng=127.0.0.1:25060 --timeout=60 --silent-timeout=3600 --pidfile=/var/run/mediaproxy-ng.pid --tos=184 --port-min=50000 --port-max=60000 --no-fallback --table=0

i would thus expect to see ip4 192.98.102.10 in the sdp returned to sip proxy.

what did i do wrong?

-- juha

Richard Fuchs writes:

There was a bug in using the "received from" address. We always have the "trust address" flag set, so we never noticed it. This is now fixed in git master.

thanks. it now worked fine without "r" flag.

regarding "r" flag, if sip ua is behind nat, how can ip address in sdp be "trusted", because source address of rtp packets does not match the one in sdp?

-- juha

Hi!

Question regarding Kamalio rtpproxy-ng module for mediaproxy-ng daemon.* *

* On Tue, Apr 2, 2013 at 7:05 PM, Richard Fuchs <rfuchs at sipwise.com> wrote:

*>The newest version supports a new control protocol, which is facilitated

through a new Kamailio module rtpproxy-ng. For now, this module is a drop-in replacement for the old rtpproxy module and supports the same stuff, plus some ICE options. It's not included in the regular Kamailio git tree yet, but soon will be. In the meantime, the module is available from our github Kamailio tree.

Regarding the mediaproxy-ng documentation special features can't be invoked without usage of 'ng' protocol provided by rptmediaproxy-ng. Unfortunately there is no info about rtpproxy-ng module itself. Haven't found it at Sipwise GitHub site.

regards, Alexey

2013/7/11 Richard Fuchs rfuchs@sipwise.com

On 07/11/13 13:04, Juha Heinanen wrote:

...

regarding "r" flag, if sip ua is behind nat, how can ip address in sdp be "trusted", because source address of rtp packets does not match the one in sdp?

Mediaproxy-ng pays attention to the source address of incoming packets and adjusts the forwarding address of the other stream direction accordingly (but only in the initial stage of a call to limit abuse).

cheers

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hi!

Richard, Juha,

thanks for the hint. Have fetched and rendered the module documentation. Now playing with translation between SRTP and RTP through mediaproxy: not trivial to focus on proper routes inside configuration file. I'm new to the Kamailio/OpenSER. Hope for the success J

best regards, Alexey

2013/7/14 Richard Fuchs rfuchs@sipwise.com

On 07/14/13 08:59, Alexey Rybalko wrote:

...

Regarding the mediaproxy-ng documentation special features can't be invoked without usage of 'ng' protocol provided by rptmediaproxy-ng. Unfortunately there is no info about rtpproxy-ng module itself. Haven't found it at Sipwise GitHub site.

You can get it either as a patch file here:

https://github.com/sipwise/kamailio/blob/master/debian/patches/sipwise/rtpro...

Or by checking out the branch rfuchs/rtpproxy-ng in the regular Kamailio repository.

cheers

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hi,

On 07/18/13 08:48, Alexey Rybalko wrote:

Just suggest someone already tried mediaproxy-ng with conversion RTP/SRTP. Few examples of options' usage would be very appreciated! May authors bring them into the tutorial?

E.g. caller invokes RTP/SAVPF profile (SIP over WS), but calle supports RTP/AVP only. During the simple tests I've put /rtpproxy_offer("spFRWOCII1-")/ into the INVITE route. However it doesn't work as was expected: mediaproxy offers the same SDP for callee. SIP 488 (Not Acceptable) as a result for caller.

Your usage is correct, but it doesn't seem to match the log lines you posted (those are for an "answer", not an "offer"). Where exactly did you get the module from? Did you perhaps grab an older version, one that doesn't have the 's' flag implemented yet?

cheers

On 07/18/13 17:33, Alexey Rybalko wrote:

Richard,

to be frank, I tried Sipwise's distribution of Kamailio (NGCP 2.8). Thanks for configured distro image as well :) Spending some time with tracing the config file brought the call stack: ROUTE_INVITE ->...->ROUTE_BRANCH_ACC_RTP. However I've added "sp" flags into rtpproxy_offer function among other flags into ROUTE_BRANCH_ACC_RTP.

That was the shortest way to figure out how mediaproxy works with media translation feature J Other reason for using the prepared distro is that I'm completely new to the Kamailio scripting and there are no other live examples for mediaproxy-ng usage.

Regarding "s" flag..Hm...Just haven't thought that version of rtpproxy-ng might be out of date... Seems that I need to compile module from your Git branch.

Yep, that is exactly the reason, NGCP 2.8 didn't support this. It's a very new feature and release 3.0 will support it, which is in the process of being put together.

cheers

On 07/19/13 14:46, Alexey Rybalko wrote:

Good! When NGCP 3.0 will be available for the community?

Have we any chance to evaluate media profile conversion(SDP) prior that event using base Kamailio? There a several patches from Sipwise for Kamailio core and some other modules as well (e.g. nathelper).The only examples for new mediaproxy might be found inside SPCE (NGCP), but it's config doesn't work without patching the Kamailio sources.

You don't have to patch it if you check out the rtpproxy-ng branch from the Kamailio git repo (or the Sipwise Kamailio repo for that matter), but you're still gonna have to compile the sources yourself. At this point, there's no way around that. NGCP 3.0 is on the horizon, but not quite there yet as there's still some issues that need to be worked out.

cheers

I've been trying to make srtp->srtp work with kamailio, rtpproxy and two symbian phones. rtpproxy does not receive any rtp/sdp packets. I'm still trying to debug what makes it fail. Without tls and srtp everything works, with either results are varied. Before I waste more time: Should kamailio+rtpproxy work out of the box with NATted TLS+SRTP clients? mediaproxy-ng is only needed for *conversion* between srtp and rtp?

On 7/19/13, Alexey Rybalko alexey.rybalko@gmail.com wrote:

Today I compiled and installed your branch from Kamailio repository. Another hope for kickstart was to swap Kamailio inside NGCP: in order to use already working config straight from then authors J But it was figured out that a lot of symbols and funcs are out of place (despite that all necessary modules are compiled). Then I found missing patches at Sipwise repo. But haven't been sure they are needed for the purpose or not.

p.s. Sorry if I'm annoying. Despite a hot set of projects for "WebRTC to SIP" convergence (almost) none of them are stable or working as expected. E.g. Asterisk doesn't (yet) officially support VP8 for B2BUA. And I don't want to involve Asterisk here as well.

regards, /A

2013/7/19 Richard Fuchs rfuchs@sipwise.com

...

On 07/19/13 14:46, Alexey Rybalko wrote:

...

Good! When NGCP 3.0 will be available for the community?

Have we any chance to evaluate media profile conversion(SDP) prior that event using base Kamailio? There a several patches from Sipwise for Kamailio core and some other modules as well (e.g. nathelper).The only examples for new mediaproxy might be found inside SPCE (NGCP), but it's config doesn't work without patching the Kamailio sources.

You don't have to patch it if you check out the rtpproxy-ng branch from the Kamailio git repo (or the Sipwise Kamailio repo for that matter), but you're still gonna have to compile the sources yourself. At this point, there's no way around that. NGCP 3.0 is on the horizon, but not quite there yet as there's still some issues that need to be worked out.

cheers

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

On 07/09/13 07:44, Juha Heinanen wrote:

i got so far that my sip proxy started ok and was able to connect to mediaproxy-ng. i see in syslog these kind of messages:

Jul 9 14:40:11 siika /usr/sbin/sip-proxy[10499]: INFO: rtpproxy-ng [rtpproxy.c:1410]: rtpp_test(): rtp proxy udp:127.0.0.1:25060 found, support for it enabled Jul 9 14:40:11 siika mediaproxy-ng[8678]: Got valid command from 127.0.0.1:39880: ping - { "command": "ping" } Jul 9 14:40:11 siika mediaproxy-ng[8678]: Returning to SIP proxy: d6:result4:ponge

those kind of syslog message are useful in testing phase, but a mediaroxy-ng debug level option (info, warn, error) would be useful for production. is that in the works?

No, but it would be fairly trivial to implement. On the other hand, syslog messages can be filtered on the syslogd side of things, so I'm not sure this is really necessary.

cheers

Juha Heinanen writes:

why is daemon binary called mediaproxy-ng instead of ngcp-mediaproxy-ng-daemon? i think it is common debian practice that daemon and init script both have the same name?

another option is to keep binary name mediaproxy-ng and add --name=mediaproxy-ng param to dh_installinit.

-- juha