6 Jul
2013
6 Jul
'13
12:14 a.m.
Hi,
There've been a couple of questions regarding mediaproxy-ng as an
rtpproxy replacement on how to get it up and running with kamailio and
what it does compared to rtpproxy, mediaproxy and iptrtpproxy.
I hope, the README.md at
https://github.com/sipwise/mediaproxy-ng
answers these questions and makes it easy for you to use it.
Feedback highly appreciated,
Andreas
6 Jul
6 Jul
12:56 a.m.
Great!
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?
On Sat, Jul 6, 2013 at 4:14 AM, Andreas Granig <agranig(a)sipwise.com> wrote:
Hi,
There've been a couple of questions regarding mediaproxy-ng as an rtpproxy
replacement on how to get it up and running with kamailio and what it does
compared to rtpproxy, mediaproxy and iptrtpproxy.
I hope, the README.md at
https://github.com/sipwise/mediaproxy-ng
answers these questions and makes it easy for you to use it.
Feedback highly appreciated,
Andreas
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Iwan Budi Kusnanto
9:39 p.m.
Andreas Granig writes:
I hope, the README.md at
https://github.com/sipwise/mediaproxy-ng
answers these questions and makes it easy for you to use it.
great work. i'll give it a try as mediaproxy replacement.
-- juha
7 Jul
7 Jul
5:01 a.m.
Can we run it behind nat? I've really been eyeing that and desparate
to replace rtpproxy
On 7/5/13, Andreas Granig <agranig(a)sipwise.com> wrote:
Hi,
There've been a couple of questions regarding mediaproxy-ng as an
rtpproxy replacement on how to get it up and running with kamailio and
what it does compared to rtpproxy, mediaproxy and iptrtpproxy.
I hope, the README.md at
https://github.com/sipwise/mediaproxy-ng
answers these questions and makes it easy for you to use it.
Feedback highly appreciated,
Andreas
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
12:19 p.m.
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 ...
Best regards
12:53 p.m.
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:
If it's behind a DNAT like on Amazon EC2, it could make sense.
Andreas
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 ...
7:28 p.m.
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?
-- juha
10:22 p.m.
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
8 Jul
8 Jul
2:19 a.m.
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.
Last Question!!!
N.
9 Jul
9 Jul
8:39 p.m.
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
8 Jul
8 Jul
8:52 a.m.
Richard Fuchs writes:
On 07/07/13 12:28, 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.
-- juha
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.
3:03 p.m.
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/rtpr…
cheers
3:16 p.m.
On 7/8/13 2:03 PM, Richard Fuchs wrote:
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.
Juha, if not wrong, you added this parameter:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=75f…
Cheers,
Daniel
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/rtpr…
cheers
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
3:23 p.m.
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/rtpr…
ok, i had missed that one. what is the reason that you have not
committed rtpproxy-ng module to kamailio master branch?
-- juha
3:28 p.m.
On 07/08/13 08:23, Juha Heinanen wrote:
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.
cheerse
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/rtpr…
ok, i had missed that one. what is the reason that you have not
committed rtpproxy-ng module to kamailio master branch?
3:51 p.m.
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
4:12 p.m.
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?
-- juha
4:20 p.m.
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
9 Jul
9 Jul
2:44 p.m.
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?
-- juha
3:43 p.m.
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
4:14 p.m.
On 07/09/13 08:43, Juha Heinanen wrote:
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.
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.
cheers
11 Jul
11 Jul
8:04 p.m.
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
8:17 p.m.
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
14 Jul
14 Jul
3:59 p.m.
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4:05 p.m.
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/rtpr…
Or by checking out the branch rfuchs/rtpproxy-ng in the regular Kamailio
repository.
cheers
18 Jul
18 Jul
1:26 a.m.
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(a)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/rtpr…
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3:48 p.m.
Hi!
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.
Log events:
*[kamailio]*
...
ERROR: rtpproxy-ng [rtpproxy.c:1229]: unknown option `s'
...
ERROR: rtpproxy-ng [rtpproxy.c:1318]: proxy replied with error: Unknown
call-id
*[mediaproxy-ng]*
...
mediaproxy-ng[1507]: Got valid command from 127.0.0.1:57782: answer - {
"sdp": "v=0#015#012o=user2 0 0 IN IP4 10.61.24.86#015#012s=-#015#012c=IN
IP4 10.61.24.86#015#012t=0 0#015#012m=audio 5008 RTP/SAVPF 0 8
126#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:8
PCMA/8000#015#012a=rtpmap:126
telephone-event/8000#015#012a=direction:active#015#012", "ICE":
"remove",
"flags": [ "force", "trust-address", "symmetric"
], "replace": [ "origin",
"session-connection" ], "call-id": "5pl3eepicm9un6a3ir8e",
"via-branch":
"z9hG4bK6568.ba6f970a58580cf0ae892a1a7b5aa09d.0", "received-from": [
"IP4",
"127.0.0.1" ], "from-tag": "iqqqf0ucto",
"to-tag":
"19CE5B50-51E7D8F60001641A-788B8700", "command": "answer" }
mediaproxy-ng[1507]: Protocol error in packet from 127.0.0.1:57782: Unknown
call-id [d3:sdp202:v=0#015#012o=user2 0 0 IN IP4
10.61.24.86#015#012s=-#015#012c=IN IP4 10.61.24.86#015#012t=0
0#015#012m=audio 5008 RTP/SAVPF 0 8 126#015#012a=rtpmap:0
PCMU/8000#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:126
telephone-event/8000#015#012a=direction:active#015#0123:ICE6:remove5:flagsl5:force13:trust-address9:symmetrice7:replacel6:origin18:session-connectione7:call-id20:5pl3eepicm9un6a3ir8e10:via-branch46:z9hG4bK6568.ba6f970a58580cf0ae892a1a7b5aa09d.013:received-froml3:IP49:127.0.0.1e8:from-tag10:iqqqf0ucto6:to-tag34:19CE5B50-51E7D8F60001641A-788B87007:command6:answere]
mediaproxy-ng[1507]: Returning to SIP proxy:
d6:result5:error12:error-reason15:Unknown call-ide
regards,
/A
2013/7/14 Richard Fuchs <rfuchs(a)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/rtpr…
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4:13 p.m.
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
19 Jul
19 Jul
12:33 a.m.
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.
/Alexey
2013/7/18 Richard Fuchs <rfuchs(a)sipwise.com>
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
______________________________**_________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**users<http:/…
12:45 a.m.
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
9:46 p.m.
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.
regards,
Alexey
2013/7/19 Richard Fuchs <rfuchs(a)sipwise.com>
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.
10:35 p.m.
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
11:27 p.m.
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
23 Jul
23 Jul
10:59 p.m.
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(a)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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
14 Jul
14 Jul
4:05 p.m.
Alexey Rybalko writes:
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.
it is in rfuchs/rtpproxy-ng head of git.sip-router.org repo.
-- juha
9 Jul
9 Jul
8:31 p.m.
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
7 Jul
7 Jul
10:15 p.m.
when i built mediaproxy-ng, lintian complained:
I: ngcp-mediaproxy-ng-daemon: init.d-script-does-not-provide-itself
etc/init.d/ngcp-mediaproxy-ng-daemon
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?
-- juha
8 Jul
8 Jul
9:32 a.m.
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
4147
days inactive
4165
days old
40 comments
9 participants
participants (9)
-
Alexey Rybalko -
Andreas Granig -
Daniel-Constantin Mierla -
hiro -
Iwan Budi Kusnanto -
Juha Heinanen -
Nick Khamis -
Raúl Alexis Betancor Santana -
Richard Fuchs