Re: [SR-Users] RTPengine + kernel module long call RTP drops

[Richard Fuchs]

On 05/04/17 02:53 PM, Anthony Joseph Messina wrote:

On Wednesday, April 5, 2017 8:55:36 AM CDT Richard Fuchs wrote:

On 04/04/2017 09:33 PM, Anthony Joseph Messina wrote:

After more digging, I see (from the Asterisk perspective) that after a
certain amount of time, the "RTCP report" size gets smaller and this is
the point at which the audio from Asterisk back to the softphone is
dropped.  Again, this audio drop occurred around 19 minutes into the
call.

I'm not sure this means anything, but perhaps it can point someone more
knowledgeable in the right direction.

A good place to start is to inspect /proc/rtpengine/0/list and check the
packet and byte counters for the respective local ports. This way you
can check if incoming packets are actually arriving at rtpengine.

Thanks, Richard. I am amidst a call right now which shows it's kernelized.
The output from cat /proc/rtpengine/0/list shows nothing changing throughout
the call (after repeating the command).
That means your iptables rule isn't effective. Packets don't get 
delivered to the RTPENGINE iptables target. That doesn't explain audio 
stopping but that's the first thing you should fix.


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

Re: [SR-Users] rtpengine key file

[Richard Fuchs]

On 02/09/2017 05:05 AM, Kjeld Flarup wrote:

OK

The recipees I've found for rtpengne.conf, does not match 
/etc/rtpengine/rtpengine.sample.conf


Primarily the error is caused by not having [rtpengine] in 
/etc/rtpengine/rtpengine.conf


Looks like some change of file format.



Support for a real config file is a new feature. Previously only an 
/etc/defaults/ file was supported through the init.d script.


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

Re: [SR-Users] RTPEngine disable/enable crash kamailio

[Richard Fuchs]

On 02/06/2017 03:30 AM, Sergey Basov wrote:

Hi, All.

May be  it helps.

After patch
https://github.com/kamailio/kamailio/commit/8ca410cba540e8c8b0f711fb26c85823375480a9

when running kamailio with debug level=3
when I do disable rtpengine I got in log:
Feb  6 10:24:27 csbc-uat /usr/sbin/kamailio[10062]: DEBUG: mi_fifo
[mi_parser.c:245]: mi_parse_tree(): adding node <> ; val

Feb  6 10:24:27 csbc-uat /usr/sbin/kamailio[10062]: DEBUG: mi_fifo
[mi_parser.c:245]: mi_parse_tree(): adding node <> ; val <0>
Feb  6 10:24:27 csbc-uat /usr/sbin/kamailio[10062]: DEBUG: mi_fifo
[mi_parser.c:84]: mi_parse_node(): end of fifo input tree
Feb  6 10:24:27 csbc-uat /usr/sbin/kamailio[10062]: DEBUG: mi_fifo
[fifo_fnc.c:515]: mi_fifo_server(): done parsing the mi tree

And it disables correctly.

when I do enable of rtpengine I got:
Feb  6 10:24:30 csbc-uat /usr/sbin/kamailio[10062]: DEBUG: mi_fifo
[mi_parser.c:245]: mi_parse_tree(): adding node <> ; val

Feb  6 10:24:30 csbc-uat /usr/sbin/kamailio[10062]: DEBUG: mi_fifo
[mi_parser.c:245]: mi_parse_tree(): adding node <> ; val <1>
Feb  6 10:24:30 csbc-uat /usr/sbin/kamailio[10062]: DEBUG: mi_fifo
[mi_parser.c:84]: mi_parse_node(): end of fifo input tree
Feb  6 10:24:30 csbc-uat /usr/sbin/kamailio[10062]: DEBUG: mi_fifo
[fifo_fnc.c:515]: mi_fifo_server(): done parsing the mi tree

And command 'kamctl fifo nh_enable_rtpp udp:10.1.23.19:2223 1'
freezing, no kamailio crash, but I cannot wxecute any command with
kamctl...

If you need some more information or test - let me know.
Thanks for the detailed report. I've updated the commit, please try 
again with

https://github.com/kamailio/kamailio/commit/e78e9cd31e1cec79b936452a719dfca1b441ca8d

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

Re: [SR-Users] RTPEngine disable/enable crash kamailio

[Richard Fuchs]

On 02/02/2017 06:54 AM, Sergey Basov wrote:

Hello Daniel,

You can find backtrace in attaced file

Hi,

Can you please with the following patch
https://github.com/kamailio/kamailio/commit/8ca410cba540e8c8b0f711fb26c85823375480a9
from branch
https://github.com/kamailio/kamailio/tree/rfuchs/4.4-rtpengine-segfault-fix
applied?

Thanks

___
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

Re: [SR-Users] RTPEngine disable/enable crash kamailio

[Richard Fuchs]

On 02/02/2017 06:54 AM, Sergey Basov wrote:

Hello Daniel,

You can find backtrace in attaced file

Can you also share the output of "info locals" and "print *node" please

Thanks

___
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

Re: [SR-Users] rtpengine - Key file error

[Richard Fuchs]

On 25/01/17 06:44 PM, Serhat Guler wrote:

Hello,

I am trying to setup my Kamailio environment on a new Debian system. 
Everything went well, except I started facing a problem with the 
rtpengine. It did install it fine and I can view the program 
parameters via the help menu; however, when I run it with this command 
 "rtpengine --interface 192.168.0.66 --listen-ng=127.0.0.1:2 
 -m 3 -M 35000 -L 2" or any other 
commands, it gives an error as "CRIT: Fatal error: Bad command line: 
Key file does not have group 'rtpengine'".


Where is this key file it is complaining about ? I couldn't find 
anything neither in the doc nor anywhere else.
The key file is the config file. It defaults to 
/etc/rtpengine/rtpengine.conf


However, if no config file is explicitly specified, it ought to ignore 
errors trying to load from it. Does that file exist on your system? 
What's your glib (not glibc) version?


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

Re: [SR-Users] Why SDPOPS does not remove attributes in SDP

[Richard Fuchs]

On 17/06/16 03:46 AM, Dmitry wrote:

Hi all
I have the following code:

  if($T_reply_code=="200")
 {
 if(has_body("application/sdp"))
 {
xlog("L_INFO", "RTPENGINE received internal reply
$T_reply_code $rr SDP extra lines will be removed");

set_rtpengine_set("0");
rtpengine_manage();
 sdp_remove_line_by_prefix("a=rtcp");
 sdp_remove_line_by_prefix("a=ssrc");
 sdp_remove_line_by_prefix("a=ice");
 sdp_remove_line_by_prefix("a=candidate");

 xlog("L_INFO", "RTPENGINE received internal reply
$T_reply_code $rr SDP extra lines removed with SDPOPS");

 }

 }
When I look through traces  - I see that 200 ok(with SDP) has all these
attributes and they are not removed.

Why SDPOPS does not remove these attributes?


Probably because there's a problem rewriting parts of the SDP body more 
than once. But if you don't want ICE attributes in the output SDP, you 
can use the rtpengine flags ICE=remove. You can influence rtcp-mux 
attributes in the same way. See docs.


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

Re: [SR-Users] Dynamic advertised ip for rtpengine/rtpproxy

[Richard Fuchs]

On 06/01/2016 04:26 AM, Serge S. Yuriev wrote:

Hello,

Thanks a lot.
If I understand docs correctly there is no such thing for RTPEngine and
we should use app params?


Yes there is, you can give it as "media-address=..." inside the options 
string to the respective function calls.


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

Re: [SR-Users] Browser WebRTC transcoder

[Richard Fuchs]

On 05/19/2016 04:52 AM, Moacir Ferreira wrote:
...
> So the Grandstream offers a lot of codecs but will get a "Not Found"
> from Kamailio. Look in the other way:

That would be a SIP signalling (e.g. Kamailio config) problem. Perhaps a
missing registration.

> Here the Grandstream says "Media type not available". As I am not a real
> SIP guy, I got no clue why does not work!

This you can solve with rtpengine. The required codecs (PCM) are there,
you just need to break the encryption (RTP <> SRTP) and some other
features of WebRTC (ICE, BUNDLE, rtcp-mux, ...), all of which rtpengine
can do.

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

Re: [SR-Users] Browser WebRTC transcoder

[Richard Fuchs]

On 18/05/16 04:57 PM, Moacir Ferreira wrote:

Hey Daniel,

If you say so, you probably right... I did not try it because on the
sipwise  GitHub (https://github.com/sipwise/rtpengine) they mention:

/"Rtpengine does not (yet) support:/
//

  * /Repacketization or transcoding/


This refers to translating one audio codec into another (e.g. opus to 
PCM). Translating between RTP and SRTP (i.e. encrypting and decrypting) 
is supported.


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

Re: [SR-Users] question about RTPengine

[Richard Fuchs]

On 05/06/2016 07:36 AM, Dmitry wrote:
> hello
> 
> i read the documentation about RTPengine.
> and the documentation says that:
> 
>  If INVITE with SDP, when the tm module is loaded, mark transaction with
> internal flag FL_SDP_BODY to know that the 1xx and 2xx are for
> rtpengine_answer()
> 
> what does it mean?

This is taken from the rtpproxy module. For SDP negotiation, there are
two basic scenarios:

1) SDP "offer" in the INVITE and SDP "answer" in 1xx or 2xx,
or
2) No SDP in the INVITE, but SDP in 1xx or 2xx, which becomes the SDP
"offer," followed by the SDP "answer" in the ACK.

The flag is used for _manage() to be able to distinguish between these
two cases, in particular whether the SDP in 1xx or 2xx is an "offer" or
an "answer."

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

Re: [SR-Users] making rtpengine gives error on centos

[Richard Fuchs]

On 04/05/16 11:16 AM, Yasin CANER wrote:

Hello;
 i tried to make rtpengine.so deamon that gives error for
evthread_use_pthreads is implicit.


You need to have a recent libevent installed - libevent-devel or 
libevent2-devel. 
http://rpm.pbone.net/index.php3/stat/3/srodzaj/1/search/libevent2-devel 
might have builds if your distro doesn't provide it.


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

Re: [SR-Users] about rtpengine versions

[Richard Fuchs]

On 05/04/16 08:03 AM, Juha Heinanen wrote:

I noticed that 15 days ago there was rtpengine commit

https://github.com/sipwise/rtpengine/commit/aac8899b612dc8103b89f3f9c921f88af3501303

titled "Release new version 4.4.0.0+0~mr4.4.0.0", but I could not find
the corresponding branch or tag.

If someone wants to use that version, is 'git archive
aac8899b612dc8103b89f3f9c921f88af3501303' the only way to do so?


The version tag in the master branch is always one ahead of the latest 
release branch, to make sure that builds from master are seen as newer 
than release branches. The last release branch is 4.3.x, so master was 
updated to 4.4. It's not a real released version until 4.4.1 is branched.


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

Re: [SR-Users] RTP Engine multiplexing and De-multiplexing

[Richard Fuchs]

On 01/13/2016 04:26 AM, riko nir wrote:

Hello,

A call from a remote webrtc client is coming to (opensips+rtpengine).
The media streams from the webrtc client is multiplexed. Can I use
rtpengine to demultiplex the multiplexed streams and send it to other
end as de-multiplexed SRTP traffic . This is because, the other end
handle the srtp traffic only in demultiplxed manner.

Also, the streams from the remote end is a separate SRTP and SRTCP
traffic and the rtpengine has to add required ICE information to make
the streams to go in a single port and it has to multiplex the streams
and send it to webrtc client.

It is mentioned that rtpengine can support multiplex/demultiplex. So,
how can I configure rtpengine for this purpose from opensips?


Use the rtcp-mux-demux option in your offer/answer calls. This instructs 
rtpengine to break out of rtcp-mux.


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

Re: [SR-Users] Regarding rtpengine dtls handling and fetching crypto keys

[Richard Fuchs]

On 01/12/2016 04:09 AM, riko nir wrote:

Hi all,

I have a media server and it is able to handle SRTP, provided the crypto
key.

We are planning to give webrtc support to the media server. We are using
opensips+rtpengine for that.

For dtls, we are using rtpengine. The rtpengine just needs to do the
dtls handshake and it needs to fetch the crypto key and it should
provide the key to media server, so that the media server will be able
to handle the SRTP traffic.

We are bit struggling, how to get the crypto keys from rtpengine and
send it to opensips and opensips will send it to media server.

how this can be done? your suggestions will help us a lot.


The only place the crypto key appears is in the debug log output. It's 
printed there after the handshake completes. Other than that, this mode 
of operation is completely unsupported.


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

Re: [SR-Users] RTPPorxy -> RTPEngine migration issue

[Richard Fuchs]

On 09/01/16 07:28 PM, Arsen Hovhanissian wrote:


Hi everyone, i’ve been having this “not so problem” going on. So I have 
rtpengine installed on a server and use the default rtpproxy module on kamailio 
and it works beautifully. Having read the rtpengine modules description, I see 
that it is a drop in replacement of rtpproxy. So I keep trying to update the 
module names and function names but it keeps giving me this message when I 
start up kamailio.

ERROR: rtpengine [rtpengine.c:1622]: rtpp_test(): proxy responded with invalid 
response

Software versions:
Kamailio: 4.3.4
RTPEngine: 4.1.1

Any ideas on what it could be?


Can you post some relevant log lines from rtpengine please (best when 
running rtpengine with log-level 7).


Generally speaking, when using the old rtpproxy module, make sure you 
use the --listen-udp option to specify the listening port.


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

Re: [SR-Users] RTPPorxy -> RTPEngine migration issue

[Richard Fuchs]

On 10/01/16 12:48 AM, Arsen Hovhanissian wrote:

Hi Richard! Here’s the output at log level 7

[1452404737.610730] WARNING: Failed to properly parse UDP command line '11683_0 
d7:command4:pinge' from 10.0.0.10:54602, using fallback RE
[1452404737.619006] WARNING: Failed to properly parse UDP command line '11683_1 
d7:command4:pinge' from 10.0.0.10:59567, using fallback RE
[1452404737.621995] WARNING: Failed to properly parse UDP command line '11694_2 
d7:command4:pinge' from 10.0.0.10:57256, using fallback RE
[1452404737.623204] WARNING: Failed to properly parse UDP command line '11689_1 
d7:command4:pinge' from 10.0.0.10:52176, using fallback RE
[1452404737.629991] WARNING: Failed to properly parse UDP command line '11687_1 
d7:command4:pinge' from 10.0.0.10:55951, using fallback RE
[1452404737.630268] WARNING: Failed to properly parse UDP command line '11686_1 
d7:command4:pinge' from 10.0.0.10:51267, using fallback RE
[1452404737.630392] WARNING: Failed to properly parse UDP command line '11690_1 
d7:command4:pinge' from 10.0.0.10:55452, using fallback RE
[1452404737.634052] WARNING: Failed to properly parse UDP command line '11688_1 
d7:command4:pinge' from 10.0.0.10:49329, using fallback RE
[1452404737.635731] WARNING: Failed to properly parse UDP command line '11693_1 
d7:command4:pinge' from 10.0.0.10:43723, using fallback RE
[1452404737.636118] WARNING: Failed to properly parse UDP command line '11685_1 
d7:command4:pinge' from 10.0.0.10:55434, using fallback RE
[1452404737.636293] WARNING: Failed to properly parse UDP command line '11692_1 
d7:command4:pinge' from 10.0.0.10:34893, using fallback RE

Could it be that I am starting it up wrong?


Ah ok, so you want to replace the Kamailio module with rtpengine as 
well. Then you need to use the --listen-ng option instead. Stay on the 
same port and you should be good to go.


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

Re: [SR-Users] Too many packets in rtpengine UDP receive queue

[Richard Fuchs]

On 12/23/2015 09:08 AM, Zodiac wrote:

Thanks for your analysis. Actually my rtpengine daemon is running on a
Virtual Machine. So can there be solution to this problem?


Yes, run it on real hardware :)

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

Re: [SR-Users] Too many packets in rtpengine UDP receive queue

[Richard Fuchs]

On 12/22/2015 10:21 AM, Zodiac wrote:

Hi friends:

I am running rtpengine daemon on a CentOS machine functionally. SIP
server is Kamailio. Vedio and audio calls are both OK with rtpengine.

But there is always prompts like following in rtpengine’s log:

Dec 22 19:57:52 localhost rtpengine[12679]:
[oaNEqGokmqgaXzj0xWyPeJDGPX7ln0gG port 30136] Too many packets in UDP
receive queue (more than 50), aborting loop. Dropped packets possible
Dec 22 19:57:52 localhost rtpengine[12679]:
[oaNEqGokmqgaXzj0xWyPeJDGPX7ln0gG port 30156] Too many packets in UDP
receive queue (more than 50), aborting loop. Dropped packets possible
Dec 22 19:57:52 localhost rtpengine[12679]:
[oaNEqGokmqgaXzj0xWyPeJDGPX7ln0gG port 30156] Too many packets in UDP
receive queue (more than 50), aborting loop. Dropped packets possible


So I am wondering whether this prompt is normal. Otherwise, what should
I do to prevent this to happen?


The usual cause for this is when the CPU is maxed out or when the 
machine can't keep up with the traffic in some other way (frequently 
happens in VMs). Another possibility is when signalling creates a 
forwarding loop within rtpengine, but that's usually detected and logged 
with an excplicit "loop detected" message.


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

Re: [SR-Users] why is rtpenengine-delete deleting the whole call?

[Richard Fuchs]

On 12/03/2015 06:38 PM, Juha Heinanen wrote:

i noticed one more things during testing of rfuchs/delete-branch, which
i don't quite understand.

the test call is parallel forked to two destinations and offer (using
via-branch=1) is issued for both.  thus the offers have the same params:

... "call-id": "138d9b5516741c30", "via-branch": "z9hG4bKe8998a18295855da", "received-from": [ "IP4", "192.98.102.10" 
], "from-tag": "b5b2ffd6a2205b13", "command": "offer" }

..."call-id": "138d9b5516741c30", "via-branch": "z9hG4bKe8998a18295855da", "received-from": [ "IP4", "192.98.102.10" ], 
"from-tag": "b5b2ffd6a2205b13", "command": "offer" }


That doesn't work. The point of the via-branch handling is to recognize 
that this is a forked call/offer and so the via-branch should be 
different in the two offers. Right now this only works if the call is 
forked in a second SIP proxy instance daisy-chained before the one doing 
the RTP proxy stuff, as Kamailio offers no mechanism to anticipate the 
next outgoing via-branch value. Fixing this is on our to-do list.



question: how it is possible the call works, i.e., rtpengine still has
the call even when it was already deleted?  does it remember that two
offers were made using same params and the call does not really get
deleted before it has received two deletes?


It still works if the answer comes in before the delete-delay triggers 
actual deletion (which is the reason for delete-delay's existence). It's 
also necessary that both offers were made with the same parameters, e.g. 
not one with RTP and the second the SRTP (otherwise rtpengine could get 
confused).


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

Re: [SR-Users] why is rtpenengine-delete deleting the whole call?

[Richard Fuchs]

On 11/27/2015 07:41 PM, Juha Heinanen wrote:

Richard Fuchs writes:


To clarify: the extra-pv parameter simply replaces the via-branch value
with a custom string.


Got it and when standard via-branch value is taken into account that
would be enough for me at least for now.


I have a prospective fix in a separate branch:
https://github.com/sipwise/rtpengine/tree/rfuchs/delete-branch

Can you please test it to see if it works for your use case, then I'll 
merge into master.


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

Re: [SR-Users] why is rtpenengine-delete deleting the whole call?

[Richard Fuchs]

On 11/26/2015 09:21 PM, Juha Heinanen wrote:

Richard Fuchs writes:


question:  why does rtpengine not do what it is asked to do in 
rtpengine-delete, i,e. delete
the offer corresponding to "call-id": "f33a7e21c57edbf3", "via-branch":
"z9hG4bK79d6.d19587ffadd9f72bca61d9578eb12bd9.1"?


Because the via-branch isn't taken into account for the delete. I
thought I already explained that just recently?


Sorry about the confusion.  I thought that the previous one was about
via-branch extra value.

So via-branch will be taken in account in some future version of
rtpengine without a need to use extra value?


Correct.

To clarify: the extra-pv parameter simply replaces the via-branch value 
with a custom string.


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

Re: [SR-Users] why is rtpenengine-delete deleting the whole call?

[Richard Fuchs]

On 11/26/2015 07:39 PM, Juha Heinanen wrote:


question:  why does rtpengine not do what it is asked to do in 
rtpengine-delete, i,e. delete
the offer corresponding to "call-id": "f33a7e21c57edbf3", "via-branch":
"z9hG4bK79d6.d19587ffadd9f72bca61d9578eb12bd9.1"?


Because the via-branch isn't taken into account for the delete. I 
thought I already explained that just recently?


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

Re: [SR-Users] rtpengine via-branch=extra question

[Richard Fuchs]

On 11/22/2015 05:50 AM, Juha Heinanen wrote:

Richard Fuchs writes:


Yes, one of the two usual call timers. Off the top of my head I believe
the longer ("silenced") timer is the relevant one here.


Just for curiosity, I tried to find out from the sources, how long that
SILENT timer is, but didn't succeed.


It's configurable via CLI, the default is

if (silent_timeout <= 0)
silent_timeout = 3600;

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

Re: [SR-Users] rtpengine disabling offers of rtcp

[Richard Fuchs]

On 08/10/2015 05:45 AM, Daniel Tryba wrote:
 On Wednesday 05 August 2015 16:05:52 Daniel-Constantin Mierla wrote:
 maybe you can just removed with textops or sdpops functions plus
 msg_apply_changes().
 
 Somehow that doesn't work for me... The a=rtcp line remains 
 whatever/whereever 
 I try to use sdp_remove_line_by_prefix(a=rtcp) or 
 replace_body_all(^a=rtcp:*, ) the line is send to the callee.

You may have to call msg_apply_changes() before rewriting the SDP. But
are you actually certain that the a=rtcp line causes the problems?
Because that would be pretty weird.

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

Re: [SR-Users] RTPengine+Kamailio, 200 OK without DTLS fingerprint

[Richard Fuchs]

On 02/06/15 06:35 AM, Vasiliy Ganchev wrote:
 Richard Fuchs wrote
 On 29/05/15 11:16 AM, Vasiliy Ganchev wrote:
 On May 29, 2015; 3:19pm, Richard Fuchs wrote: 
 A good way to start debugging this is to run rtpengine with log-level 7 
 and post the full log for such a call. 
 Hi Richard! Thanks for answer!
 Call log written on WS_Kamailio, rtpengine with log-level 7 
 Call from UA_WS 272 calling to UA_SIP 271 attached. 
 200OK_without_DTLS_fingerprint_log_for_list.txt
 lt;http://sip-router.1086192.n5.nabble.com/file/n138286/200OK_without_DTLS_fingerprint_log_for_list.txtgt;
   

 Looks like you're making an RTP/SAVPF offer to a client that speaks
 RTP/AVPF only, and you're neglecting to instruct rtpengine to do any
 translation between the two. The solution is to include the RTP/AVPF
 flag in the offer.

 There's also a stray delete in there, which you may want to eliminate.
 It's harmless as it is, but it probably shouldn't be there.

 Cheers

 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 
 sr-users@.sip-router
 
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
 
 Hi Richard! 
 Thank you for your reply and suggested solution. You was right, in 200 OK
 was set RTP/AVPF (and in offer 
 RTP/SAVPF) and I did nothing with this mismatch.
 Now, playing around with flags for RTPengine, I have one questions for such
 case: 
 Browser send INVITE with RTP/SAVPF, RTPengine send forward to client with
 RTP/AVPF 
 When comes 200 OK with RTP/AVPF  RTPengine change it to RTP/SAVPF and
 forward to browser. In this case I got in browser log:
 
 setRemoteDescription() | error: +5ms Failed to set remote answer sdp: Offer
 and answer descriptions m-lines are not matching. Rejecting answer.

This is usually caused by broken SIP clients which don't properly reject
media streams. What usually happens is that the browser offers both
audio and video, but the other client only responds with audio. What the
client should do is to explicitly reject the video stream, instead of
just ignoring it and not including it in the reply at all. IOW, the
offer has two m= lines and thus the answer also should have two m=
lines, but it only has one, and this is not allowed by the RFC.

There might be a new option in rtpengine in the near future to fix these
kinds of broken SDP bodies, but right now there isn't.

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

Re: [SR-Users] RTPengine+Kamailio, 200 OK without DTLS fingerprint

[Richard Fuchs]

On 29/05/15 05:48 AM, Vasiliy Ganchev wrote:

Юрий, Thanks for your answer!
Sorry but I couldn't understand how to do Reverse rtp_manage functions. If
it is possible, extend your idea with some more example/explanation?

Maybe someone else can help suggest something, or do I need to give more
information?


A good way to start debugging this is to run rtpengine with log-level 7 
and post the full log for such a call.


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

Re: [SR-Users] RTPengine+Kamailio, 200 OK without DTLS fingerprint

[Richard Fuchs]

On 29/05/15 11:16 AM, Vasiliy Ganchev wrote:
 On May 29, 2015; 3:19pm, Richard Fuchs wrote: 
 A good way to start debugging this is to run rtpengine with log-level 7 
 and post the full log for such a call. 
 Hi Richard! Thanks for answer!
 Call log written on WS_Kamailio, rtpengine with log-level 7 
 Call from UA_WS 272 calling to UA_SIP 271 attached. 
 200OK_without_DTLS_fingerprint_log_for_list.txt
 http://sip-router.1086192.n5.nabble.com/file/n138286/200OK_without_DTLS_fingerprint_log_for_list.txt
   

Looks like you're making an RTP/SAVPF offer to a client that speaks
RTP/AVPF only, and you're neglecting to instruct rtpengine to do any
translation between the two. The solution is to include the RTP/AVPF
flag in the offer.

There's also a stray delete in there, which you may want to eliminate.
It's harmless as it is, but it probably shouldn't be there.

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

Re: [SR-Users] rtpproxy-ng and late SDP

[Richard Fuchs]

On 18/05/15 03:53 AM, Sebastian Damm wrote:

Hi Alex,

On Thu, May 14, 2015 at 5:47 AM, Alex Balashov
abalas...@evaristesys.com mailto:abalas...@evaristesys.com wrote:

According to the rtpengine module documentation for
rtpproxy_manage(), that's exactly what rtpproxy_manage() does:



http://kamailio.org/docs/modules/4.2.x/modules/rtpengine.html#rtpengine.f.rtpengine_manage

i.e.

- If INVITE with SDP, then do rtpengine_offer()
- If INVITE with SDP, when the tm module is loaded, mark transaction
with internal flag FL_SDP_BODY to know that the 1xx and 2xx are for
rtpengine_answer()
- If ACK with SDP, then do rtpengine_answer()
- If reply with SDP to INVITE having code 1xx and 2xx, then do
rtpengine_answer() if the request had SDP or tm is not loaded,
otherwise do rtpengine_offer()



What I'm missing there is how to handle an INVITE without SDP. Does that
mean, that if we haven't called rtpproxy_manage() on the INVITE, the 1xx
or 2xx reply will trigger an rtpproxy_offer instead of rtpproxy_answer?


That's what's supposed to happen, yes.

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

Re: [SR-Users] rtpengine, turn fallback

[Richard Fuchs]

On 06/05/15 01:30 AM, Isuru Wijesinghe wrote:

Hi All

I'm using rtpengine to in my implementation of webrtc.

In my client side browser I have used following code snippet to
configure stun/turn servers to identify ice candidates and turn fall back.

 
var pcConfig = {iceServers: [
 {'url': 'turn:52.6.57.126:3478?transport=tcp'}]
http://52.6.57.126:3478?transport=tcp'}]};
peerConn = new PeerConnection(pcConfig);
 
Am using rfc 5766 turn server
http://code.google.com/p/rfc5766-turn-server/

As long as stun is working my webrtc flow works fine.

I wanted to know how rtpengine support the turn fallback, is there any
configuration required in this case.


RTP over TCP isn't supported quite yet, but it's being worked on and 
will be available in the near future.


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

Re: [SR-Users] rtpengine and security

[Richard Fuchs]

On 21/04/15 10:40 PM, GG GG wrote:
 By port closed, I mean that ports are normally closed, but when
 rtpengine send the first rtp packets to the client, it opens a pinhole
 in the firewall, and the matching incoming packets from the client will
 make the connection established,related in iptables. I think symmetric
 nat permits that.

Yes, but rtpengine doesn't send any RTP or RTCP by itself. It only
forwards RTP and RTCP, and in order to forward it, it first must receive
it. If all ports are closed then nothing can ever be received and
nothing can ever be forwarded or sent.

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

Re: [SR-Users] rtpengine and security

[Richard Fuchs]

On 21/04/15 11:04 AM, GG GG wrote:
 Hello,
 
 what do you think about opening all RTP ports for rtpengine on Internet,
 is it a bad practice ?
 
 I wonder if it's possible to use rtpengine with all ports closed.

Not sure what you mean with ports closed. How would rtpengine, or any
other RTP proxy/client for that matter, receive any media traffic if the
ports are closed?

 Maybe someone could explain how rtpengine learn the source address when
 the SDP contains a local address.

For the first 2-3 seconds after the media session has been established,
it listens for incoming UDP packets and will learn the endpoint address
from the source address of the received packets. After 2-3 seconds this
learning stops and the endpoint is locked in place.

 If your rtpengine server is under attack, could rtpengine choose the
 wrong ip source for RTP ?

If the attacker is fast enough, yes. You can disable learning of
endpoint addresses using the asynchronous flag, but obviously this will
break NAT'd media. You can also use the strict-source flag to make
rtpengine drop packets received from a mismatched source address.

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

Re: [SR-Users] weight of rtpengine rtp proxy?

[Richard Fuchs]

On 08/04/15 04:19 AM, Juha Heinanen wrote:
 rtpengine readme tells in section 2:
 
   The balancing inside a set is done automatically by the module based on
   the weight of each RTP proxy from the set.
 
 i have not found in rtpengine_sock module parameter description, how is
 the weight of a rtp proxy is specified specified.
 
 it contains an example:
 
 modparam(rtpengine, rtpengine_sock,
   1 == udp:localhost:12221 udp:localhost:1)
 
 how can i tell what the weight of each of two proxies is?

The default weight is 1. If you wanted the second RTP proxy to be used
twice as often as the first one, you would specify

modparam(rtpengine, rtpengine_sock,
1 == udp:localhost:12221 udp:localhost:1=2)

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

Re: [SR-Users] rtpengine documentation error for forced rtpproxying?

[Richard Fuchs]

On 01/04/15 12:34 PM, Daniel Tryba wrote:
 On Wednesday 01 April 2015 18:08:28 Daniel Tryba wrote:
 rtpengine_manage(force);
 
 Whoops, I should read the whole thing.
 
 http://kamailio.org/docs/modules/4.2.x/modules/rtpengine.html#rtpengine.f.rtpengine_offer
 
 force - instructs the RTP proxy to ignore marks inserted by another RTP proxy 
 in transit to indicate that the session is already goes through another 
 proxy. 
 Allows creating a chain of proxies. 
 *Not supported and ignored by Sipwise rtpengine*

To clarify: rtpengine doesn't insert any marks and doesn't check for any
marks that might be present. IOW it behaves as if the force flag is
always enabled.

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

Re: [SR-Users] RTPEngine IPv4 to IPv6 bridging returning c=IN IP4 0.0.0.0 on answer?

[Richard Fuchs]

On 24/02/15 08:20 PM, Anthony Messina wrote:
 This is probably very likely a configuration issue on my part, but I wanted 
 to 
 check before reporting an RTPEngine bug...
 
 Thank you for any pointers or suggestions.
 
 This is a multi-homed server where
 
 em1: INTERNAL_IPv4  GLOBAL_IPv6
 em2: EXTERNAL_IPv4
 
 Note that below, the IPv6 address on my server is the same on priv and pub 
 and 
 is reachable from internal and external endpoints.  I have it set this 
 way 
 as I eventually want to use ICE and have it create the proper IPv4/IPv6 
 candidates regardless of the RTPEngine --interface.
 
 I'm running RTPEngine with the following:
 
 /usr/sbin/rtpengine
   --table=0
   --interface=pub/EXTERNAL_IPv4
   --interface=pub/GLOBAL_IPv6
   --interface=priv/INTERNAL_IPv4
   --interface=priv/GLOBAL_IPv6
   --listen-ng=127.0.0.1:12221
   --tos=184
   --log-level=7
   --pidfile=/run/rtpengine/rtpengine.test.pid
 
 I'm trying to bridge an IPv4-initated call to an IPv6 carrier. The call seems 
 to flow properly until the carrier's SDP is passed through RTPEngine on 
 answer.  The snippets are here, and I have attached the full log.
 
 [TdBe4MJa1DC4teIllJkqq6U-PAw9Zh4y] Received command 'answer' from 
 127.0.0.1:38786
 [TdBe4MJa1DC4teIllJkqq6U-PAw9Zh4y] Dump for 'answer' from 127.0.0.1:38786: { 
 sdp: v=0
 o=FreeSWITCH 1424799070 1424799071 IN IP6 CARRIER_IPv6
 s=FreeSWITCH
 c=IN IP6 CARRIER_IPv6
 t=0 0
 m=audio 24308 RTP/AVP 0 101
 a=rtpmap:0 PCMU/8000
 a=rtpmap:101 telephone-event/8000
 a=fmtp:101 0-16
 a=silenceSupp:off - - - -
 a=ptime:20
 a=rtcp:24309 IN IP6 CARRIER_IPv6
 
 
 The CARRIER_IPv6 gets converted as follows with 0.0.0.0 in place of what 
 should be the address of my RTPEngine instance.  Shouldn't it be returning 
 the 
 IPv4 address of my RTPEngine instance (either priv or pub as called from 
 Kamailio)?
 
 [TdBe4MJa1DC4teIllJkqq6U-PAw9Zh4y] Replying to 'answer' from 127.0.0.1:38786
 [TdBe4MJa1DC4teIllJkqq6U-PAw9Zh4y] Response dump for 'answer' to 
 127.0.0.1:38786: { sdp: v=0
 o=FreeSWITCH 1424799070 1424799071 IN IP4 0.0.0.0
 s=FreeSWITCH
 c=IN IP4 0.0.0.0
 t=0 0
 m=audio 38914 RTP/SAVP 0 101
 a=rtpmap:0 PCMU/8000
 a=rtpmap:101 telephone-event/8000
 a=fmtp:101 0-16
 a=silenceSupp:off - - - -
 a=ptime:20
 a=sendrecv
 a=rtcp:38915
 a=crypto:1 AES_CM_128_HMAC_SHA1_80 
 inline:Jby5IPt4WlNySLd66eK+Mcky8yJeUwp7dWH7W3aO

This was indeed an old bug which apparently nobody ever came across.
I've just fixed it in master.

https://github.com/sipwise/rtpengine/commit/956d07d42e106231aa4cae13d706b30e7833ae89

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

Re: [SR-Users] rtpproxy bridge ie ei behind NAT (like in aws EC2)

[Richard Fuchs]

On 16/02/15 12:39 PM, Muhammad Shahzad wrote:
 I haven't done something like that myself but i think if you use
 RTPEngine with media-address set correctly in offer and answer
 functions, you can easily achieve this. Simply check if request/reply is
 coming from FS or the end-user and adjust the media appropriately
 without even invoking auto-bridge etc.

Or perhaps with multiple interface specifications, binding to the same
local address but with different advertised addresses, as suggested in
the OP.

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

Re: [SR-Users] rtpproxy bridge ie ei behind NAT (like in aws EC2)

[Richard Fuchs]

On 16/02/15 01:00 PM, Virmantas Variakojis wrote:
 Hi,
 
 There pathch with -A can be found or it is allready implemented into
 specific rtpengine version?

Latest master from git. The command line syntax is a bit different from
rtpproxy, but the basic idea is the same.

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

Re: [SR-Users] rtpproxy bridge ie ei behind NAT (like in aws EC2)

[Richard Fuchs]

On 16/02/15 01:12 PM, Virmantas Variakojis wrote:
 Could you provide us a little example? For examlple i have kamailio with
 three interfaces: two interfaces (vlan's look at two different
 providers) and third interface looks at sip clients.

You would define two interfaces with different names, for example
--interface=public/10.0.1.15!54.86.X.X for outside media and
--interface=local/10.0.1.15 for local media. You would then use two
direction=... options in the offer to determine where A side and B side
are located, respectively. You can also call the interfaces external
and internal and use these flags instead, which mirrors rtpproxy's
behaviour.

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

Re: [SR-Users] rtpengine - Error when sending message. Error: Invalid argument

[Richard Fuchs]

On 14/02/15 08:13 AM, Amit Patkar wrote:
 Hi
 
 I am getting error with rtpengine.
 Running Kamailio 4.2.3
 
 I am trying to call from conventional SIP client to WebRTC client
 
 Google Chrome v38.0.2125.104
 Firefox v33.0
 
 Using sipML5 as WebRTC client
 
 root@rtcpbx:/home/avhan# /usr/sbin/rtpengine
 --interface=127.0.0.1\!192.168.2.161 --listen-ng=7722
 --pidfile=/var/run/ngcp-rtpengine-daemon.pid --tos=184 --table=42
 --foreground --log-level=7 --log-stderr

The problem is the --interface=127.0.0.1\!192.168.2.161 part. This binds
the UDP sockets for RTP to 127.0.0.1. You can't send to any other
address from such a socket.

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

Re: [SR-Users] Kamailio and rtpengine

[Richard Fuchs]

On 13/02/15 01:32 PM, Marc Soda wrote:
 How does Kamailio load balance traffic to rtpengine?  Is it load based,
 round robin, etc?  The module makes mention of this but I don't see how
 it works.  Also, it talks about weighting the proxies.  How is that
 accomplished?

This part of the module is virtually unmodified from the rtpproxy module
and I see that the documentation is lacking in this regard, so I'll go
by what the code tells me.

Load balancing is achieved by running a hash over the call-id and using
the hash value to determine which RTP proxy from the selected set to
use. The hash ensures that everything related to the same call ends up
on the same RTP proxy, which is a requirement for proper operation.

If weighting is used, then RTP proxies with a higher weight will
accordingly get a larger fraction of the calls. If two RTP proxies are
defined, the first with a weight of 1 (which is the default) and the
second with the weight of 2, then the second will get twice as many
calls as the first one.

Syntax for the config is like this:

modparam(rtpengine, rtpengine_sock,
udp:localhost:2223 udp:localhost:2224=2)

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

Re: [SR-Users] One Way RTP from destination SIP server using rtpengine

[Richard Fuchs]

On 07/02/15 07:24 AM, Muhammad Shahzad wrote:
 I think i have similar problem last week with rtpengine deployment which
 was about 1-2 weeks old. There was no audio although the logs say that
 STUN bindings are successful from both side (SAVPF - AVP). One symptom
 of the problem is this log message,
 
 --
 rtpengine[16455]: [kr8shv3uca0fnmg4ktd4 port 41198] SRTP output wanted,
 but no crypto suite was negotiated
 --
 
 As a last resort before filing an official bug, i decided to upgrade
 RTPEngine which seems to have solved the problem. Interestingly both
 rtpengine deployments (the one causing no audio and the upgraded one)
 have the same version numbers (i.e. the output of rtpengine -v), so i
 can't actually pinpoint which revision has this problem and which one
 has solved this problem. Anyhow, can you also try with latest RTPEngine
 from official git repo and see if that solves the problem. The git
 commit number of working RTPEngine is
 9a2da87f130ab3c1e21d9b593efec78a8eb7b3f3 (ah, i miss subversion which
 has more meaningful linear revision numbers ...).
 
 For RTPEngine developers, can you guys add git revision string as
 extended version for rtpengine -v output? It may be the same way as
 kamailio does, e.g.
 
 kamailio 4.2.2 (i386/linux) *6f7306*
 
 This will tremendously help in tracking bugs and their fixes.

It does, but it only works if the build environment has git available.
Otherwise it has to be left out.

tabasco:~/src/ngcp-git/rtpengine/daemon(master)# ./rtpengine -v
3.3.0.0+0~mr3.8.0.0 git-master-9a2da87

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

Re: [SR-Users] RTPEngine Intermittent One Way Audio Issue SRTP = RTP

[Richard Fuchs]

On 07/02/15 03:09 AM, Tim Chubb wrote:
 Hi,
 
  
 
 I am currently experiencing an intermittent one way audio issue, when
 using RTPEngine and proxying between srtp  and rtp.  There is no
 apparent pattern, I have managed to repeat the  on the 7^th , 23^rd ,
 and 63^rd calls to a test number, where upon connection only audio in
 the RTP = SRTP direction was working.  All other test calls worked as
 normal.  Digging through the RTPEngine log file the only abnormalities I
 can see are: Discarded invalid SRTP packet: authentication failed
 entries on the calls that had the one way audio issue. 

Your caller side uses an SRTP authentication tag and apparently
sometimes fails to calculate it correctly (or rtpengine does). You'd
have to a packet capture of the RTP traffic to see what exactly is going
on. Using the crypto tags found in the SDP, it's possible to verify the
authentication tags (I believe Wireshark does that automatically in some
cases).

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

Re: [SR-Users] Video Key-Frame Request using RTCP FIR or SIP INFO message

[Richard Fuchs]

On 02/01/15 09:17, Muhammad Shahzad wrote:
 Thanks for detailed reply and sharing the valuable information. You are
 right i should also post this on discuss-webrtc forum, will do after i
 get a fresh call trace, possibly tomorrow.
 
 Regarding your questions, yes the call establishes successfully at
 signalling level and audio stream works perfectly fine. I see DTLS
 certificates generated, sent, received, accepted etc. in RTPEngine logs.
 Both SIP and WebRTC clients successfully negotiate ICE and choose
 RTPEngine for media relay. However, the SIP client looses video after
 1-2 seconds of call establishment, the audio still works during the
 entire call. So, i am convinced that problem is entirely related to
 video as far as the call establishment is concerned.
 
 The WebRTC client is based on JSSIP but i am not aware of any config or
 method that may give us such control over media in response to this SIP
 INFO method. Any experienced JSSIP users / developers out there who may
 help on this?
 
 The SIP client is based on a commercial SIP SDK. Both WebRTC and SIP
 clients work perfectly fine as long as other end is same, i.e. SIP to
 SIP and WebRTC to WebRTC video calls work as expected under same network
 conditions. Each client has only one video codec enabled, which is VP8,
 without any trans-coding etc. involved in between.

To my (limited) knowledge, requests for key frames are sent as
AVPF-profile RTCP packets. Meanwhile, most regular SIP clients don't
speak AVPF but rather AVP only, and so don't support these requests for
key frames. Which results in the AVPF client never sending any key
frames because nobody requests any.

To allow interoperability, the translating agent (rtpengine) would need
to support and understand the video codec in use (VP8) at least to a
minimal extent and simulate AVPF key frame requests. Which it currently
doesn't.

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

Re: [SR-Users] Need help on WebRTC with Kamailio as proxy

[Richard Fuchs]

On 26/01/15 02:21 PM, Rahul MathuR wrote:

Hello,

I am totally struck at a point while implementing Kamailio as proxy for
WebRTC enabled UAC (Jssip). I am using Google's TURN server
(rfc5766-turn-server for ICE/STUN). I am able to get to the point where
the SIP server sends 183 session in progress to kamailio but after that
I can only see -
STUN: using this candidate
Successful STUN binding request from ..
SRTP output wanted, but no crypto suite was negotiated


This is fairly strange:


Jan 27 00:35:46 localhost rtpengine[5262]: [tsb1jrsqsadn33jjsi4f port 30794] 
Failed to set up SRTP after DTLS negotiation: no SRTP protection profile 
negotiated
Jan 27 00:35:46 localhost rtpengine[5262]: [tsb1jrsqsadn33jjsi4f port 30794] 
Failed to set up SRTP after DTLS negotiation: no SRTP protection profile 
negotiated


Are you running a very old OpenSSL version  by any chance?

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

Re: [SR-Users] RTPengine

[Richard Fuchs]

On 01/19/15 08:11, Kalala Alexander wrote:
 Is there a replacement of this flag /force/?

Rtpengine is always in force mode. It always tries to proxy the media
through itself when instructed to. If you need to prevent the media from
being proxies twice, you need to find some other way to detect this and
then not call the rtpengine_*() functions.

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

Re: [SR-Users] rtpengine stats

[Richard Fuchs]

On 12/22/14 10:33, Marc Soda wrote:
 Does anyone know how a can get stats from rtpengine?  I see the $rtpstat
 pseudo variable in Kamailio, but from the documentation it looks like
 that will only give me stats on a particular call.  I'm looking for
 overall stats like concurrent calls, bandwidth, etc...

Several ways...

If you have the TCP listener enabled, you can issue the status command
to get an output similar to what rtpproxy produces, one line with number
of calls and packet counters, followed by a list of all calls. You can
use telnet or netcat to connect and issue that command.

If you have the NG listener enabled, you can issue the list command,
which produces an encoded/parseable list of calls, but only up to
certain limit (contributed code - meant for debugging). You can use the
provided script utils/ng-client to do that.

Then there's a number of recently contributed patches, not yet merged
into master but available in git branch rfuchs/1und1-patches, one of
which provides a CLI and includes several status commands available
through utils/rtpengine-ctl.

Alex mentioned /proc/mediaproxy (or /proc/rtpengine in git master now)
which also gives a lot of details, but only applies to packet forwarding
done by the kernel module and doesn't include streams handled by the
userspace daemon only.

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

Re: [SR-Users] rtpengine returns 0.0.0.0 even with sendrecv in offer

[Richard Fuchs]

On 12/19/14 03:32, Juha Heinanen wrote:
 i got mozilla to generate sdp with sendrecv, but still rtpengine does
 not replace 0.0.0.0 address on o and c lines.  why?

Because 0.0.0.0 means steam is on hold and so should be left in place.

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

Re: [SR-Users] rtpengine returns 0.0.0.0 even with sendrecv in offer

[Richard Fuchs]

On 12/19/14 09:33, Juha Heinanen wrote:
 Richard Fuchs writes:
 
 On 12/19/14 03:32, Juha Heinanen wrote:
 i got mozilla to generate sdp with sendrecv, but still rtpengine does
 not replace 0.0.0.0 address on o and c lines.  why?

 Because 0.0.0.0 means steam is on hold and so should be left in place.
 
 what i understand from rfc3264 is that 0.0.0.0 address in initial invite
 does not mean that the call is on hold.  0.0.0.0 is used because webrtc
 client does not know its ip address:
 
RFC 2543 [10] specified that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0.  Its usage for putting
a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks
with connection oriented media.  However, it can be useful in an
initial offer when the offerer knows it wants to use a particular set
of media streams and formats, but doesn't know the addresses and
ports at the time of the offer.
 
 also, if the call would on hold, there would be sendonly attribute in
 the sdp, which is not the case in my example, which had sendrecv.

Yes I understand, but 1) the mechanism of using 0.0.0.0 to put a call on
hold must remain operational and intact for those clients which use it,
and 2) if the offering client sends 0.0.0.0 in the SDP, then the
rewritten SDP should also contain 0.0.0.0, no matter what the purpose
behind it is.

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

Re: [SR-Users] rtpengine returns 0.0.0.0 even with sendrecv in offer

[Richard Fuchs]

On 12/19/14 10:02, Juha Heinanen wrote:
 Richard Fuchs writes:
 
 Yes I understand, but 1) the mechanism of using 0.0.0.0 to put a call on
 hold must remain operational and intact for those clients which use it,
 and 2) if the offering client sends 0.0.0.0 in the SDP, then the
 rewritten SDP should also contain 0.0.0.0, no matter what the purpose
 behind it is.
 
 So with current implementation of rtpengine there is no hope if Firefox
 webrtc client needs rtpengine services?
 
 If so, would it be possible have a new flag that tells rtpengine to
 replace also 0.0.0.0 address if there is no sendonly attribute in sdp?

I don't see how it would make a difference. If Firefox sends 0.0.0.0 and
rtpengine replaces it with its own address, then the receiving client
can send media to rtpengine, but rtpengine would have nowhere to forward
it to. After the answer, ICE processing may commence and determine an IP
address, after which I expect Firefox to send an updated offer with the
address filled in. At this point, media should start to flow no matter what.

I'm not sure how much of a valid use-case this is, or if it'd be just a
Firefox-specific workaround, but my all means, give it a try and see if
it makes a difference.

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

Re: [SR-Users] rtpengine returns 0.0.0.0 even with sendrecv in offer

[Richard Fuchs]

On 12/19/14 11:39, Juha Heinanen wrote:
 Richard Fuchs writes:
 
 I don't see how it would make a difference. If Firefox sends 0.0.0.0 and
 rtpengine replaces it with its own address, then the receiving client
 can send media to rtpengine, but rtpengine would have nowhere to forward
 it to. After the answer, ICE processing may commence and determine an IP
 address, after which I expect Firefox to send an updated offer with the
 address filled in. At this point, media should start to flow no matter what.

 I'm not sure how much of a valid use-case this is, or if it'd be just a
 Firefox-specific workaround, but my all means, give it a try and see if
 it makes a difference.
 
 i found this on jssip mailing list:
 
   Just a side note; FF34 does offer the value '0.0.0.0' as the media
   connectiom address, and the value 9 as the media port. This way it
   announces the support for ICE Trickle. 
 
   Media servers not aware of this will take it as a 'hold' request and
   wont send media to the peer.

Oh dear, another IETF draft...

Well that certainly explains, thanks. Doesn't look like Firefox is quite
finished with it yet though, as ice-options=trickle isn't given.

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

Re: [SR-Users] Media trouble with kamailio/rtpengine

[Richard Fuchs]

On 12/19/14 10:47, Marc Soda wrote:
 I'm trying to use Kamailio and rtpengine as a webrtc gateway.  I'm not
 getting audio back to my browser.  From a packet capture I can see media
 from the browser to rtpengine, and then bi-directional RTP back and
 forth from my asterisk server, but rtpengine is not sending the media on
 to the browser, i.e.:
 
 browser - kamailio/rtpengine - asterisk
 
 This is the output from rtpengine:
 
 https://gist.github.com/marcantonio/bfe72644306b205cc7e1

You've caught the same thing as Juha did just earlier, Firefox is doing
something new called Trickle ICE, which at the moment breaks
communications with endpoints not supporting it (such as rtpengine).

The second call you posted seems fine. The error you're seeing is
because RTP was received before DTLS was established and so is expected.
You can try --dtls-passive as a possible fix. Media should start to flow
after DTLS gets established though, and according to the logs, media was
indeed seen in both directions. Try tcpdump to confirm.

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

Re: [SR-Users] webrtc clients support using rtpengine

[Richard Fuchs]

On 12/18/14 12:11, Andrey Utkin wrote:
 Hi!
 I need to establish calls between WebRTC and usual SIP clients
 (exactly, sipml/jssip and linphone-android).
 I used configs from https://github.com/caruizdiaz/kamailio-ws and
 latest git master HEAD of both kamailio and
 rtpengine. I got calls from webrtc to android working correctly (but only with
 Firefox browser), even with video. But in other directions i have some
 issues because of lack of RTP delivery or RTP timeouts.
 I have some logs to show you regarding this:
 https://gist.github.com/krieger-od/27c6f3e4924f5e21352e (works),
 https://gist.github.com/krieger-od/196bcfbd331d621427ef (doesn't
 work).
 I would really love to get some quick help from anyone. For direct
 manual fixing, I can give a couple of hundreds of bucks.
 
 Looking forward impatiently for reply from anyone having something to say.

Write error on RTP socket usually indicates an incorrect network setup,
for example trying to use a source address for IP packets which isn't
bound to any local network interface (especially if you're sitting
behind NAT), or local iptables rules rejecting outgoing IP packets, or
missing IP routes to the destination. Perhaps post your network setup
and the CLI arguments to rtpengine you're using.

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

Re: [SR-Users] webrtc clients support using rtpengine

[Richard Fuchs]

On 12/18/14 12:55, Andrey Utkin wrote:
 2014-12-18 19:30 GMT+02:00 Richard Fuchs rfu...@sipwise.com:
 Write error on RTP socket usually indicates an incorrect network setup,
 for example trying to use a source address for IP packets which isn't
 bound to any local network interface (especially if you're sitting
 behind NAT), or local iptables rules rejecting outgoing IP packets, or
 missing IP routes to the destination. Perhaps post your network setup
 and the CLI arguments to rtpengine you're using.
 
 I use VPS from DigitalOcean. Likely no NAT. Only one public IP, and
 one domain name used (whdd.org). Exactly the same situation was with
 Amazon VPS behind amazonish NAT.
 My configs are here: https://github.com/krieger-od/webrtc_kamailio_etc
 (only kamailio.cfg and modules.cfg are used, kamailio*.cfg are not).
 Also there you can check command line used to run rtpengine. To put it
 there, it is
 /home/krieger/rtpengine/daemon/rtpengine --interface=188.226.241.236
 --listen-ng=127.0.0.1:2 -m 3 -M 35000 --foreground
 --log-stderr

Amazon NAT is exactly why I've mentioned it, because on an Amazon
system, if you don't use the --interface option correctly
($INT_IP!$EXT_IP notation), you get exactly these kinds of write errors
that show in your log.

But these configs and this CLI line don't match the logs you posted
earlier. Is it also write errors you're getting with those?

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

Re: [SR-Users] webrtc clients support using rtpengine

[Richard Fuchs]

On 12/18/14 13:38, Andrey Utkin wrote:
 This works: call from sipml to linphone android:
 rtpengine: https://gist.github.com/krieger-od/bf8503fe7643c0571b58
 kamailio: https://gist.github.com/krieger-od/c119d64af6edcde3fc46
 ngrep: https://gist.github.com/krieger-od/cb5829be7a55a7acf9d3
 
 
 This doesn't work: few seconds after answer, there's no media from
 remote subscriber, then linphone android agent hangs up; sipml hangs
 pretending being in call.
 rtpengine: https://gist.github.com/krieger-od/9eb120199ec99d1adcb4
 kamailio: https://gist.github.com/krieger-od/26060c8d1d657458d9d2
 ngrep: https://gist.github.com/krieger-od/d677864fcab8c508adde

Couple of things to try here...

In the second case, Firefox kept sending answers (200 OK) for no good
reason. Check Firefox's debug log / JS console / whatever if there's any
error or warnings messages.

Try running rtpengine with the --dtls-passive switch, even though that
shouldn't make a difference after ICE went through (which it does).

Add rtcp-mux=demux to your rtpengine flags in your Kamailio config,
should be safe to use everywhere.

It's curious that Firefox was using RTP/SAVPF as protocol in one call
and UDP/TLS/RTP/SAVPF in another. I don't suspect that this would cause
a problem, but it's worth trying to specify the protocol not as
RTP/SAVPF but rather as transport-protocol=UDP/TLS/RTP/SAVPF. Note that
in the case of answers, you don't need to specify any protocol at all.

In the third case, the audio stream was setup as a=sendonly, explaining
the one-way audio. Probably caused by Firefox not being able to access
the playback device.

Last but not least, try a different browser, either a newer version of
Firefox (it's up to v34 I see), or Chrome.

As for the call teardown, it's Kamailio's responsibility (through the
config) to let rtpengine know that the call has been terminated, for
example when handling the BYE method. Otherwise you'll see timeouts in
rtpengine. Even though the BYE should still be relayed to the other SIP
end, causing the call to be hung up there.

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

Re: [SR-Users] SIP Fragments

[Richard Fuchs]

On 12/17/14 21:14, Alex Balashov wrote:
 And yeah, WebRTC is morbidly obese. I think your best bet is to use TCP. 

... or try to fix your networking.

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

Re: [SR-Users] How to Fix the RTP Engine SDP Rewriting direction.

[Richard Fuchs]

On 12/16/14 10:04, Mahmoud Ramadan Ali wrote:
 Hi Dears,
 I'm working on integrating the rtpengine to work with Kamailio as RTP
 proxy and i have successfully configured the rtpengine in multi home
 mode to proxy the media and rewrite the SDP message whenever it passes
 trough the Kamailio internal interface to the external interface and
 vice versa using this command.
 
 root@debian:/usr/local/etc/kamailio# rtpengine
 --interface=Kamailio-Internal/192.168.100.1 http://192.168.100.1
 --interface=Kamailio-External/192.168.50.1 http://192.168.50.1
 --listen-ng=127.0.0.1:2 http://127.0.0.1:2
 --pidfile=/var/run/ngcp-rtpengine-daemon.pid
 
 Also i have configured the i and e flags in the route[NATMANAGE] to
 take care of the SDP rewriting direction the same way it worked before
 with my rtpproxy module configuration.
 
 But the issue now is that whenever i make a call from the external to
 the internal the rtpengine can NOT detect the right direction as colored
 in red below so my question now is : How to set the direction of the
 rtpengine to designate that the interface 192.168.50.1 is the external
 and 192.168.100.1 is the internal ?
 
 Dec 16 09:28:09 debian rtpengine[4714]: Got valid command from
 127.0.0.1:50639 http://127.0.0.1:50639: offer - { sdp:
 v=0#015#012o=- 13063213690566395 1 IN IP4 192.168.50.2#015#012s=X-Lite
 release 4.7.1 stamp 74247#015#012c=IN IP4 192.168.50.2#015#012t=0
 0#015#012m=audio 56078 RTP/AVP 125 100 0 9 8 101#015#012a=rtpmap:125
 opus/48000/2#015#012a=fmtp:125 useinbandfec=1#015#012a=rtpmap:100
 speex/16000#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101
 0-15#015#012a=sendrecv#015#012, direction: [ internal, external
 ], flags: [ asymmetric, trust-address, symmetric ], replace: [
 session-connection, orig ...

If you want to use the i and e flags, you must name your logical
interfaces internal and external respectively, as in:

./rtpengine ... --interface=internal/192.168.100.1
--interface=external/192.168.50.1 ...

Alternatively if you wish to retain and use the more free-form interface
names, you must use the direction=... option in your calls to
rtpengine_*(), but you'd need a more recent version of the rtpengine
module for this to work.

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

Re: [SR-Users] rtpengine use of udp

[Richard Fuchs]

On 05/12/14 04:38 AM, Juha Heinanen wrote:

what has been the motivation that rtpengine control protocol is using
udp instead of tcp or ssl?

we have noticed that reply to delete containing stats is too large for a
single udp packet over ethernet and causes udp fragmentation and
fragmentation needed requests.


Because that's what the original rtpproxy module used, and it seemed to 
work.


If it were to use TCP and if the stats reply is too large for a single 
packet, the reply would still be sent in multiple packets. Not 
fragmented, but TCP segments. Nothing gained unless you have packet loss.


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

Re: [SR-Users] rtpengine and sdes

[Richard Fuchs]

On 11/19/2014 01:35 AM, Daniel-Constantin Mierla wrote:
 Hello,
 
 I saw that rtpengine docs still advertise support for SDES SRTP and I
 was wondering if anyone was (is still) using it for
 decryption/encryption of this type of SRTP, mainly in scenarios like
 SRTP from a classic sip phone (e.g., snom) to another SIP endpoint
 wihtout srtp support.
 
 As I cc-ed Richard, another question is about the plans for the future,
 if at this moment is properly working/maintained, will it be kept for
 the future or the plan is to deprecate/remove/don't invest any effort in
 its maintenance?

Hi,

SDES is still fully supported and any SRTP offers generated include both
SDES and DTLS attributes for the time being. There are no plans to
remove support for SDES, and the only thing we may have to address the
SDES/DTLS dualism in the future is an option to select one over the
other when generating offers (e.g. do DTLS-only offers).

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

Re: [SR-Users] rtpengine UDP/TLS/RTP/SAVP = RTP/AVP re-INVITE

[Richard Fuchs]

On 11/18/2014 08:29 PM, Juha Heinanen wrote:
 Richard,
 
 Enclosed find syslog that includes rtgpengine log at level 7 and also
 pcap of the call.  I made re-invite from baresip to sems once I saw this
 in syslog:
 
 Nov 19 03:22:14 rautu rtpengine[29718]: [5315d797a9a5e7ce port 50761] 
 DTLS-SRTP successfully negotiated
 
 I didn't include the to this message due to the pcap.

Looking at your logs, I think what happened is that you've included the
trust-address flag in the original answer, but haven't included it in
the answer to the re-invite. This means that in the second answer,
rtpengine erroneously saw a different endpoint than before (using the
source address of the SIP packet), in response to this it also opened a
new endpoint on its own side, which was then sent to the DTLS-SRTP
client. This client then saw the new endpoint and correctly started a
new DTLS connection, meanwhile rtpengine was still using the old keys
and (I'm guessing) neither expected nor processed the new DTLS
handshake, thus en/decrypted SRTP using the old keys, resulting in
mangled RTP packets.

So the short-term fix would be to include trust-address to avoid
switching endpoints. As for DTLS restarts in rtpengine, this is
something that I was just working on and DTLS restarts on changed
endpoints should be working soon.

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

Re: [SR-Users] rtpengine UDP/TLS/RTP/SAVP = RTP/AVP re-INVITE

[Richard Fuchs]

On 11/17/2014 08:03 PM, Juha Heinanen wrote:
 when i make call from UDP/TLS/RTP/SAVP baresip to RTP/AVP sems,
 rtpengine gets called on initial invite/200 ok like this and audio works
 fine:
 
 Nov 18 02:46:06 rautu /usr/bin/sip-proxy[926]: INFO: = 
 rtpengine_offer(ICE=force replace-session-connection replace-origin 
 via-branch=1 RTP/AVP trust-address)
 
 Nov 18 02:46:06 rautu /usr/bin/sip-proxy[878]: INFO: = 
 rtpengine_answer(ICE=force via-branch=2 trust-address)
 
 however, when baresip makes re-invite, rtpengine gets called using the
 same offer/answer flags, but sems clears the call.  on syslog, i see
 this:
 
 Nov 18 02:46:59 rautu /usr/bin/sip-proxy[919]: INFO: Routing in-dialog INVITE 
 sip:127.0.0.1:5090;transport=udp from sip:j...@test.tutpro.com
 Nov 18 02:46:59 rautu /usr/bin/sip-proxy[879]: INFO: = 
 rtpengine_answer(ICE=force via-branch=2 replace-session-connection 
 replace-origin)
 Nov 18 02:46:59 rautu rtpengine[29718]: [abd2bcf75f71af57 port 50444] SRTP 
 output wanted, but no crypto suite was negotiated
 Nov 18 02:46:59 rautu /usr/bin/sip-proxy[919]: INFO: Routing in-dialog ACK 
 sip:127.0.0.1:5090;transport=udp from sip:j...@test.tutpro.com
 Nov 18 02:46:59 rautu rtpengine[29718]: [abd2bcf75f71af57 port 50462] 
 Discarded invalid SRTP packet: authentication failed
 Nov 18 02:46:59 rautu sems[20439]: [#b7193b70] [receive, AmRtpAudio.cpp:212] 
 ERROR:  decode() returned -4
 Nov 18 02:46:59 rautu /usr/bin/sip-proxy[878]: INFO: = rtpengine_delete()
 Nov 18 02:46:59 rautu /usr/bin/sip-proxy[878]: INFO: Routing in-dialog BYE 
 sip:jh-0x9a95b00@192.98.102.30:5066;transport=tcp from 
 sip:j...@as.test.tutpro.com to sip:192.98.102.30:46718;transport=TCP 
 based on gruu
 Nov 18 02:46:59 rautu rtpengine[29718]: [abd2bcf75f71af57 port 50463] Error 
 parsing RTCP header: invalid packet type
 
 and on baresip console this:
 
 dtls_srtp: --- DTLS-SRTP complete (audio/RTCP) 
 Profile=AES_CM_128_HMAC_SHA1_80
 dtls_srtp: incoming DTLS connect from 192.98.102.30:50524
 dtls_srtp: verified sha-1 fingerprint OK
 dtls_srtp: --- DTLS-SRTP complete (audio/RTP) Profile=AES_CM_128_HMAC_SHA1_80
 srtp: recv: failed to decrypt RTCP-packet (Unknown error 217)
 srtp: recv: failed to decrypt RTCP-packet (Unknown error 217)
 srtp: recv: failed to decrypt RTP-packet (Unknown error 217)
 srtp: recv: failed to decrypt RTP-packet (Unknown error 217)
 srtp: recv: failed to decrypt RTP-packet (Unknown error 217)
 srtp: recv: failed to decrypt RTP-packet (Unknown error 217)
 sip:j...@as.test.tutpro.com: session closed: Connection reset by peer
 
 could it be that at some point during the re-invite, sems gets srtp audio
 and therefore clears the call?  if so, is it a bug in rtpengine?

Can you post the complete log from rtpengine for such a call and perhaps
also make a pcap of the media packets? It's kinda hard to follow what
exactly is going on with just what you posted.

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

Re: [SR-Users] rtpengine flags UDP/TLS/RTP/SAVP and UDP/TLS/RTP/SAVPF

[Richard Fuchs]

On 11/17/2014 08:14 AM, Juha Heinanen wrote:
 Juha Heinanen writes:
 
 rtpengine source code, however, seems to know also these DTLS ones:

 daemon/call.c:   .name   = UDP/TLS/RTP/SAVP,
 daemon/call.c:   .name   = UDP/TLS/RTP/SAVPF,

 can they be used in rtpengine_offer/answer calls even when they are
 missing from README?
 
 i made a test where invite has
 
   m=audio 50152 UDP/TLS/RTP/SAVP 96 97 8 0 101
 
 and i call rtpengine_offer on it like this:
 
   rtpengine_offer(ICE=force replace-session-connection replace-origin 
 via-branch=1 RTP/AVP trust-address)
 
 and on 200 OK from callee which has
 
   m=audio 50162 RTP/AVP 96 97 8 0 101
 
 i call rtpengine_answer like this:
 
   rtpengine_answer(ICE=force UDP/TLS/RTP/SAVP via-branch=2 trust-address)
 
 rtpengine complains about it:
 
   Nov 17 15:07:32 rautu rtpengine[29718]: Unknown flag encountered: 
 'UDP/TLS/RTP/SAVP'
 
 but still it has converted m line of the 200 OK to caller to this:
 
   m=audio 50180 UDP/TLS/RTP/SAVP 96 97 8 0 101
 
 and audio works fine between the RTP/AVP UA (sems) and UDP/TLS/RTP/SAVP
 UA (baresip).
 
 why the unknown flag message?

Because it's an unknown flag. :)

You only need to specify the transport protocol in an answer if you want
to change it from whatever the offering client sent (for whatever
reason). If you don't specify the protocol in the answer (and you
essentially did that as your flag wasn't understood and ignored), it
will reply with the same protocol that the offering client used, which
is normally what you want.

The command flags RTP/AVP etc are translated into the key
transport-protocol=$X within the control protocol. If you wish to
force usage of one of the UDP/TLS/... protocol, you should be able to do
so by spelling it out in your command. I believe this is not documented,
but should work.

FTR, RFC 5764 states that UDP/TLS/... must be used when DTLS-SRTP is
used, only WebRTC doesn't seem to honour that and omits this prefix,
possibly because SDES exists (or used to exist) as an alternative to
DTLS-SRTP within WebRTC. Which actually makes me wonder if WebRTC
clients actually understand the UDP/TLS/... protocols...

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

Re: [SR-Users] rtpengine does not send RTP packets out

[Richard Fuchs]

On 11/01/14 15:39, Juan Perez wrote:
 Hi, I have kamilio-4.2 and rtpengine running on the same machine.
 I have this scenario:
 
 softphone -- Kamailio with Rtpengine -- Asterisk
 The softphone initiates the call, it is sent to the Asterisk. I can see
 the SDPs being re-written with the new IP/Ports provided by rtpengine:
 
 Invite from Kamailio to Asterisk
 200 Ok from Kamailio to Softphone
 
 However,  I take a signaling/media capture on the server where the
 kamailio/rtpengine are running and see the RTP coming from both
 endpoints (softphone and asterisk) to the correct ports but there is no
 packets coming out from the proxy to either direction.
 
 I see these 2 lines on the rtpengine log and make me think that
 something prevents the rtpengine to stream out to the 2 endpoints:
 
 Nov  1 18:59:26 ip-10-0-2-68 rtpengine[27764]:
 [0866b358-dc9c-1232-1399-3767db69b8dd port 35038] Write error on RTP socket

Seeing as you're using the direction options, can you double check
that the local IP addresses that you've configured at the command line
are actually addresses bound to local interfaces on the machine?

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

Re: [SR-Users] rtpengine does not send RTP packets out

[Richard Fuchs]

On 11/03/14 09:17, Juan Perez wrote:
 thank you Richard, yes the IP is local to the machine:
 
 ./rtpengine --interface=pub/PUBLIC_IP --interface=priv/10.0.2.68
 --listen-ng=127.0.0.1:7722--timeout=30 --port-min=35000 --port-max=65000
 --log-level=7 --log-facility=daemon
 
 The PUBLIC_IP is a NAT that the machine has, it is a virtual machine
 (Amazon), so it is not configured on any interface in that machine.

There's your problem. If the address isn't configured on the machine,
rtpengine cannot use it as source address when sending packets out. If
RTP packets must be sent with one address as source, but another address
must appear in SDP bodies, use this format:

--interface=pub/RTP SOURCE ADDRESS!SDP ADDRESS

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

Re: [SR-Users] Installing rtpengine on CentOS 6.5

[Richard Fuchs]

On 10/31/14 15:27, Juan Perez wrote:
 
 Using Kamailio 4.2, CentOS 6.5, as per the documentation here:
 https://github.com/sipwise/rtpengine
 
 Running make will compile the binary, which will be called rtpengine.
 
 When trying to install rtpengine I got the following error when building
 daemon
 
 [root@ip-10-0-2-68 daemon]# make
 Usage: awk [POSIX or GNU style options] -f progfile [--] file ...
 Usage: awk [POSIX or GNU style options] [--] 'program' file ...

Looks like your awk doesn't understand the -e option. I've just
committed a patch to remove it, which should fix this:

https://github.com/sipwise/rtpengine/commit/24608361d61b67b162b9dc33b08e00b24a2e81e4

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

Re: [SR-Users] Installing rtpengine on CentOS 6.5

[Richard Fuchs]

On 10/31/14 17:31, Juan Perez wrote:
 Thank you, but after removing the -e now I get this error:
 
 [root@ip-10-0-2-68 daemon]# make
 Makefile:88: .depend: No such file or directory
 make: *** No rule to make target `aux.c', needed by `.depend'.  Stop.
 [root@ip-10-0-2-68 daemon]#

Are you sure you have a complete source tree? Is aux.c present? Are you
using GNU make?

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

Re: [SR-Users] (no subject)

[Richard Fuchs]

On 10/29/14 10:08, Yuriy Gorlichenko wrote:
 Hello. I use kamailio with last rtpengine and 
 I have 5-7 Seconds voice delay. This happened only for  from webphone.
 But it is not client issue as i see. Wireshark at client side shows that
 RTP starts as soon I pick up call. So rtp leaves rtpengine and goes to
 the destination with delay... I use WSS and think that problem at
 handshake. 
 
 There are some statisticcs after call finished (as example). You may see
 that one of streams created after 5 seconds delay.

The difference in the times you posted is the delay between the offer
and the answer, e.g. between INVITE and 200 OK. This is normal if you're
slow to pick up the call. As for audio delay, some clients/browsers
(Firefox especially I believe) are slow with starting or responding to
the DTLS handshake. Since the SRTP encryption keys are negotiated during
the DTLS handshake, no SRTP can be sent until after this has been
completed. You can see this in the log. If you run a packet dump, what
you will normally see is that rtpengine starts the DTLS handshake right
away, but the browser doesn't respond until several seconds after. I'm
not sure why they do this.

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

Re: [SR-Users] rtpproxy_manage fails to rewrite SDP

[Richard Fuchs]

On 10/28/14 09:18, Igor Potjevlesch wrote:
 Hello,
 
  
 
 I have seen that the problem can occur due to the kernel limitation.
 
 So, I have changed the local_port range to be sure that they include the
 port range of RTPProxy.
 
  
 
 But, I still not explain this limitation. Because, even with the kernel
 limitation, they should be have sufficient number of ports to allocate.
 
  
 
 Any idea? Thanks.

It could be that the maximum number of file descriptors allowed for the
process has been reached. You can try executing ulimit -n 6 before
starting the RTP proxy daemon. Just a guess. In any case, the daemon
should log an error if it fails to open or allocate a port. If it
doesn't, you can try hooking into the running process with strace to see
what's going on.

HTH
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

Re: [SR-Users] Kamailio for ARM with rtpproxy-ng

[Richard Fuchs]

On 10/27/14 06:57, Marino Mileti wrote:
 Richard Fuchs wrote
 Interesting. I'm not sure why this is required for this value, but hey,
 if it works... Let me know if you run into any more trouble.
 
 Bad news..the __attribute__((packed)) modification allows only the kernel to
 fixup the alignment trap but it still exist and i don't know if this can be
 a problem during calls.. 
 
 Do you have some suggest in order to fix this issue?

Unfortunately my understanding of ARM alignment restrictions is very
limited, in fact so limited that I don't understand why this particular
instruction even is a problem to begin with. My only suggestions would
be to either declare the entire struct as packed, or try adding some gcc
flags to the makefile (-munaligned-access or -mno-unaligned-access,
apparently it depends on what kind of kernel you're running), recompile
the entire source and see if that fixes anything. Other than that, I'm
at a loss.

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

Re: [SR-Users] Kamailio for ARM with rtpproxy-ng

[Richard Fuchs]

On 10/23/14 11:32, Marino Mileti wrote:
 Version is 3.3.0.0 mr3.5.0.0
 
 I've seen that the problem is during the ping-pong test when the value of
 bencode_item is assigned
 
 The error is on __bencode_dictionary_init, and the istruction is :
 dict-value=0
 
 I've read ARM documentation and it says to add __attribute__((packed)) to
 value definition inside bencode_item struct. In my case i've done:
 
 long long int value __attribute__((packed));
 
 I've tried and it works. I don't know if this is the right solution.
 What do you think about it?

Interesting. I'm not sure why this is required for this value, but hey,
if it works... Let me know if you run into any more trouble.

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

Re: [SR-Users] rtpengine not working with append_branch

[Richard Fuchs]

On 10/23/14 12:17, Yuriy Gorlichenko wrote:
 What you mean under full set of flags? At reply I use mirror (+/-)
 flags off course. More, it work without branches fine ( i select only
 one endpoint). I have issue only with branches.

I mean that instead of using rtpproxy_manage(co) you should use
rtpproxy_manage(co-sp).

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

Re: [SR-Users] rtpengine not working with append_branch

[Richard Fuchs]

On 10/23/14 15:06, Yuriy Gorlichenko wrote:
 Still have same error...
 Now rtpproxy_manage(co-sp) for classic call. At log I see that
 rtpproxy wirked gine. For each step it generate write body, but t_Relay
 still send strange compinated packet to UDP with SDP for WS... 

Do you mean that the outgoing packet contains two SDP bodies? This has
been discussed and solved in this thread:
http://lists.sip-router.org/pipermail/sr-dev/2014-July/024507.html

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

Re: [SR-Users] how to always use rtpproxy-ng in kamailio

[Richard Fuchs]

On 10/05/14 07:15, andrew wrote:
 Hi,
 
 I have one question about kamailio. 
 
 rtpproxy-ng is installed with kamailio. When client A initiates one call
 to client B, SDP in invite/200ok are rewritten, where ice candidates for
 rtpproxy-ng are added. Sometimes rtp packets are relayed through
 rtpproxy-ng, but in some cases rtp packets pass through route created by
 ICE algorithm.
 
 How to set kamailio, then rtpproxy-ng is always used?

Add either ICE=force or ICE=remove to your list of options ('+' or '-'
if you're using the older one-character options), depending on whether
your clients expect to see ICE attributes or not.

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

Re: [SR-Users] rtpproxy_offer and fix_nated_sdp in one route

[Richard Fuchs]

On 09/24/14 09:16, Sebastian Damm wrote:
 Hi,
 
 I switched from rtpproxy module to the rtpproxy-ng module lately, and
 noticed a strange behavior. In my branch route to the device, I have two
 statements:
 
 fix_nated_sdp(1);
 rtpproxy_offer();
 
 The first command appends a line with direction:active to the SDP. The
 second one puts the RTP proxy in the stream. This worked all well with
 the old rtpproxy module. But with the new rtpproxy-ng module, I get an
 empty line after the SDP body, just before the direction:active line
 in the SDP, which makes the packet invalid.
 
 I tried changing the order of both statements, but without any
 difference. What I saw is, that the old module just sent some basic
 parameters to the rtpproxy and got only IP and port back. The new module
 sends the complete SDP to the rtpengine and gets back the fixed SDP.
 
 Has anyone ever seen this? Is there a way to fix it?

This is caused by rewriting the SDP body twice. The rtpproxy module only
rewrites small parts of the SDP, while rtpproxy-ng substitutes the
entire SDP body, which is why you run into conflicts when there's
another function touching the SDP body. Calling msg_apply_changes()
between the two calls fixes that, but may have side effects. I would
suggest the same as Juha did.

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

Re: [SR-Users] R: Re: RTPPROXY BRANCH

[Richard Fuchs]

On 09/25/14 10:22, Frank Carmickle wrote:
 
 On Sep 25, 2014, at 10:09 AM, Marino Mileti marino.mil...@alice.it
 mailto:marino.mil...@alice.it wrote:
 
 Because I've more than 1 client behind NAT (1,2,3 mobile phones) and I would 
 like to reach all of them in parallel mode. I can't use for all of them same 
 ports because all mobile clients have early media (the receive video media 
 before they answer)

 I don't understand.  Are you saying that you have clients that when they
 receive an invite sent video with 183?  How do you want to composite the
 video to show to the caller?  It is not RFC3261 compliant to change IP
 and port from 183 to 200.  Of course you can reinvite after the 200.
  Most B2BUAs require you to ignore early media and generate something
 locally to send to the caller or just send them 180.
 
 Maybe if you explain your use case someone can help you.

That's also what I'm confused about. The calling client only offers one
endpoint, so without RTP proxy in between, all receiving clients would
be offered the same IP and port, just as they do now with an RTP proxy.
In either case, the offering client would receive multiple early media
streams from different endpoints. I'm not sure what difference the RTP
proxy should make.

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

Re: [SR-Users] R: Re: RTPPROXY BRANCH

[Richard Fuchs]

On 09/29/14 13:03, Richard Fuchs wrote:
 On 09/25/14 10:22, Frank Carmickle wrote:

 On Sep 25, 2014, at 10:09 AM, Marino Mileti marino.mil...@alice.it
 mailto:marino.mil...@alice.it wrote:

 Because I've more than 1 client behind NAT (1,2,3 mobile phones) and I 
 would like to reach all of them in parallel mode. I can't use for all of 
 them same ports because all mobile clients have early media (the receive 
 video media before they answer)

 I don't understand.  Are you saying that you have clients that when they
 receive an invite sent video with 183?  How do you want to composite the
 video to show to the caller?  It is not RFC3261 compliant to change IP
 and port from 183 to 200.  Of course you can reinvite after the 200.
  Most B2BUAs require you to ignore early media and generate something
 locally to send to the caller or just send them 180.

 Maybe if you explain your use case someone can help you.
 
 That's also what I'm confused about. The calling client only offers one
 endpoint, so without RTP proxy in between, all receiving clients would
 be offered the same IP and port, just as they do now with an RTP proxy.
 In either case, the offering client would receive multiple early media
 streams from different endpoints. I'm not sure what difference the RTP
 proxy should make.

Sorry, I see this has already been discussed. Your email client seems to
break reply threads. Ignore this email.

___
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

Re: [SR-Users] R: Re: R: Re: RTPPROXY BRANCH

[Richard Fuchs]

On 09/25/14 10:41, Marino Mileti wrote:
 
 No no. The video will be sent by the caller user to all the callees.  
 
 I'l try to explain better. My scenario is:
 
 - A make a call to a group... B  C are group member...so Kamailio is
 able to call them in parallel using alias..
 
 - B  C receive the INVITEs  replies with two separate 183 with SDP (in
 SDP they specified where they are able to receive audiovideo)
 
 - A receives two 183... starts to send its RTP video stream to B  C
 (early media)
 
 - Once B or C answers the call the other leg is cancelled..
 
 Everything is working fine but if B  C are behind NAT rtpproxy is
 activated  and during INVITE for B C  rtprpoxy doesn't generate a
 couple of new ports for each of them but it uses always the same ports.
 So the only fastest client (B or C) get the video.
 
 I don't want to change IP between 183  200, i would like only that
 rtpptoxy sends INVITE for B  C with differents port.
 Is it possible to implement this scenario or there's some turnarund?

This may work with rtpengine, as it will open new ports for answers come
from different endpoints. But the final two-way association for the
actual call may still end up broken, as it has no way of knowing which
client ends up receiving the call (unless they do a final re-invite).

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

Re: [SR-Users] rtpengine with rejected re-invites to new RTP ports

[Richard Fuchs]

On 09/25/14 12:05, Jeff Pyle wrote:
 Hello,
 
 Given the following scenario with Kamailio and rtpengine in the middle:
 
 -  call establishes with G.711 RTP
 -  b-leg re-invites to T.38, indicating a different port number then he
 is using for G.711
 -  a-leg refuses the re-invite with a 488
 -  call continues using G.711 on original port numbers as if re-invite
 never happened
 
 Will Kamailio and rtpengine handle it?
 
 Today I have a functional configuration with rtpproxy on another SIP
 proxy.  It handles every scenario I have tried except this one.
  rtpproxy sees the new ports in the re-invite and adjusts its session
 accordingly.  If the re-invite is rejected, the old media ports are no
 longer valid through rtpproxy, and the call fails.
 
 Is there an approach I can take with Kamailio and rtpengine to allow
 this scenario to succeed?

This may or may not work with rtpengine. If it does work, it's simply a
lucky side effect, as this is entirely unsupported and I've never tested
it myself. Now if you had a final re-invite back to G.711, then that
would and should most definitely work.

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

Re: [SR-Users] rtpproxy extra_id_pv

[Richard Fuchs]

On 09/26/14 16:57, Marino Mileti wrote:
 Hello,
 
 On Friday 26 September 2014 16:44:44 Marino Mileti wrote:
 Hi guys,
 I've seen that setting the parameter extra_id_pv, every branch should 
 be a different callid..
 How can i set this parameter? I've tried with :
 modparam(rtpproxy, extra_id_pv, $avp(extra_id))

 but in the INVITE message the callid is still the same for all 
 branches. Any suggest?
 
 Did you assign a value to $avp(extra) in the script, before calling any of
 the rtpproxy functions?
 
 Did you use the 'b' parameter in the call to rtpproxy_*() functions?
 --
 Alex Hermann
 
 Yes, i've assigned a value in the script, just to try I've assigned $rU and
 on the log of rtpengine I can see the value of via-branch valorized
 correctly. I've also used the 'd' parameter in rtpproxy_manage() function.
 
 I've also checked on the source code of rtpengine and the part regarding the
 parse  get of via-branch value is commented...I'm using the master branch
 of rtpengine.
 
 This is the piece of code of call_interfaces.c where the via-branch
 parameter is commented:
 //bencode_dictionary_get_str(input, via-branch, viabranch);

The via-branch is currently unused in rtpengine, even though it does
appear in the control messages. From-tag and to-tag are sufficient to
identify a unique dialogue within a call.

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

Re: [SR-Users] R: Re: R: Re: RTPPROXY BRANCH

[Richard Fuchs]

On 09/29/14 13:19, Frank Carmickle wrote:
 
 On Sep 29, 2014, at 1:14 PM, Richard Fuchs rfu...@sipwise.com wrote:

 This may work with rtpengine, as it will open new ports for answers come
 from different endpoints. But the final two-way association for the
 actual call may still end up broken, as it has no way of knowing which
 client ends up receiving the call (unless they do a final re-invite).
 
 But it should see the 200.  Shouldn't that be enough?

Unfortunately it doesn't see SIP codes, it only sees SDP bodies and some
particular details from the SIP message. 200 OK would be translated to
an answer, but not every answer is from a 200 OK, so you can't use
that to break other associations. Perhaps this would be a nice addition
to have in the future.

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

Re: [SR-Users] R: Re: R: Re: RTPPROXY BRANCH

[Richard Fuchs]

On 09/29/14 13:29, Frank Carmickle wrote:
 
 On Sep 29, 2014, at 1:24 PM, Richard Fuchs rfu...@sipwise.com wrote:
 
 On 09/29/14 13:19, Frank Carmickle wrote:

 On Sep 29, 2014, at 1:14 PM, Richard Fuchs rfu...@sipwise.com wrote:

 This may work with rtpengine, as it will open new ports for answers come
 from different endpoints. But the final two-way association for the
 actual call may still end up broken, as it has no way of knowing which
 client ends up receiving the call (unless they do a final re-invite).

 But it should see the 200.  Shouldn't that be enough?

 Unfortunately it doesn't see SIP codes, it only sees SDP bodies and some
 particular details from the SIP message. 200 OK would be translated to
 an answer, but not every answer is from a 200 OK, so you can't use
 that to break other associations. Perhaps this would be a nice addition
 to have in the future.
 
 I will argue that the only thing that is an answer is a 200.  A progress, 
 early media or pre_answer is a 183.  Yes both 183s and 200s need to set up 
 media but as you know there could be many 183s and only one 200.
 
 If the UA sends an sdp with both the 183 and the 200 would this work 
 correctly?

That might just work, as the last answer rtpengine sees determines the
association with the offer.

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

Re: [SR-Users] rtpproxy extra_id_pv

[Richard Fuchs]

On 09/29/14 14:08, Marino Mileti wrote:
 But with from-tag and To-tag it's possible to instruct rtpengine to generate
 new couple of ports for each branch of a call? In the source code of
 rtpengine it seems that it check only the callid parameter

Yes it will. The call-id is only a vague umbrella under which the
from/to tags are collected. All media parameters, ports etc are
associated with the tags, and a single call can contain any number of
different from/to tags, all with their own separate parameters.

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

Re: [SR-Users] rtpproxy extra_id_pv

[Richard Fuchs]

On 09/29/14 14:29, Marino Mileti wrote:
 Wow! Do you have an example of how to do that? How I have to modify my
 kamailio.conf in order to instructs rtpproxy to user from-tag  to-tag in
 this way?

You don't have to do anything, tags are already included in all the
messages.

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

Re: [SR-Users] R: Re: R: Re: RTPPROXY BRANCH

[Richard Fuchs]

On 09/29/14 14:23, Marino Mileti wrote:
 The problem isn't on 183s but on the multiple INVITE that Kamailio sends to
 clients behind rtpengine. Rtpengine open new ports for answer but on INVITE
 the rtpengine ports are the same...This happens because for all these
 clients the callid is still the same..so for rtpengine there's no
 difference...for this reason I can see early media only on one of the
 receivers

I still don't understand what difference an RTP proxy is supposed to
make for the invite. Your offering client only opens one endpoint and
sends that out. Without RTP proxy, all receiving clients see the same
endpoint and they will all send their early media to that same endpoint.
With RTP proxy, the same thing happens. What's the difference?

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

Re: [SR-Users] R: Re: R: Re: RTPPROXY BRANCH

[Richard Fuchs]

On 09/29/14 14:51, Marino Mileti wrote:
 Without rtpproxy:
 
 - A offers port a1,a2 (audio video) in INVITE to B,C (in case of no natted
 client so no needs of rtpproxy)
 - B offers port b1,b2 (183)
 - C offers port c1,c2 (182).
 - A starts to send  audio/video RTP to B on port b1,b2
 - A starts to send audio/video RTP to C on port c1,c2
 
 With rtpproxy:
 
 - A offers port a1,a2 (audio video) in INVITE to Kamailio
 - Kamailio contact rtpproxy because BC are natted clients
 - rtpproxy check callid and offer offers port k1,k2
 - Kamailio sends INVITE to B offering k1,k2
 - Kamailio sends INVITE to C offering k1,k2
 - B offers port b1,b2 (183)
 - C offers port c1,c2 (182)
 - Kamailio sends 183 to A (for B leg) offering p1,p2
 - Kamailio sends 183 to A (for B leg) offering p3,p4
 - A starts to stream on p1,p2,p3,p4 but only one receiver can see the video
 (B or C depends who will be the first:))
 
 I don't know if it depends on that B  C receives same ports; i don't know
 if rtpproxy is able to duplicate stream received from A to all receiver

If A sends two streams, there is no need for duplication. A sending to
p1 should be forwarded to B (b1) and A sending to p3 should be forwarded
to C (c1). Both should be able to receive media sent by A. I believe
that's what rtpengine does (but I haven't tested it). The reverse
direction might be more confusing, but a final 200 OK with SDP should
fix that.

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

Re: [SR-Users] rtpengine upgrade fails

[Richard Fuchs]

On 08/21/14 03:09, Juha Heinanen wrote:

 Now I made another dist-upgrade upgrading rtpengine from
 3.3.0.0+0~mr3.4.1.0 to 3.3.0.0+0~mr3.5.0. Indeed dist-upgrade tries to
 setup daemon after the kernel module was removed but before new kernel
 module was installed.
...
 Setting up ngcp-rtpengine-daemon (3.3.0.0+0~mr3.5.0.0) ...
 Restarting RTP/media proxy: ngcp-rtpengine-daemonFATAL: Module xt_MEDIAPROXY 
 not found.
 iptables: No chain/target/match by that name.
 ip6tables: No chain/target/match by that name.
 FAILED TO CREATE KERNEL TABLE 0, KERNEL FORWARDING DISABLED
 invoke-rc.d: initscript ngcp-rtpengine-daemon, action restart failed.
 dpkg: error processing ngcp-rtpengine-daemon (--configure):
  subprocess installed post-installation script returned error exit status 255

Just as a follow-up, do you have the NO_FALLBACK option set in the config?

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

Re: [SR-Users] How do I translate rtpproxy bridge mode config to mediaproxy-ng/rtpengine?

[Richard Fuchs]

On 08/25/14 19:25, Alex Villací­s Lasso wrote:
 I have a rtpproxy configuration that spawns several rtpproxy instances,
 using bridge mode. An example is shown below:
 
 /usr/bin/rtpproxy -p /var/run/rtpproxy.pid-7723 -u rtpproxy -s
 udp:127.0.0.1 7723 192.168.2.18/127.0.0.1 -m 1 -M 2
 
 Here, rtpproxy bridges between 192.168.2.18 and 127.0.0.1 .
 
 Now I want to migrate to rtpengine with the rtpproxy-ng module in
 kamailio. However, I do not find an equivalent to bridge mode in the
 rtpengine command-line parameters. I see the --ip=IP parameter, but the
 source code expects a single IP address, and cannot be specified more
 than once. The closest I see is the --advertised-ip=IP parameter, but I
 am not sure that it will do what I need.

Just a quick note to you and anyone else who has asked for this: With
the latest version of rtpengine (git master), bridging between multiple
local interfaces is fully supported.

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

Re: [SR-Users] OT: RTCP logging

[Richard Fuchs]

On 09/04/14 12:01, Daniel Tryba wrote:
 On Thursday 04 September 2014 15:22:52 Daniel-Constantin Mierla wrote:
 - http://kamailio.org/docs/modules/stable/modules/rtpproxy.html#idp1673992

 rtpengine (former rtpproxy-ng) should have it as well, I guess.
 
 Found this before posting, but I could not make any sense of it, $rtpstat 
 with 
 the old rtpproxy module contains:
 60 A B A+B 0
 
 Source didn't explain anything (to me). But now looking at the rtpproxy-ng 
 version (4.1.5), it appears to contain what I want to know:
 Input: %lli bytes, %lli packets, %lli errors; Output: %lli bytes, %lli 
 packets, %lli errors

Note that these stats are from the RTP proxy's point of view and not
extracted from RTCP packets sent by the RTP endpoints.

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

Re: [SR-Users] How do I translate rtpproxy bridge mode config to mediaproxy-ng/rtpengine?

[Richard Fuchs]

On 08/26/14 20:58, Alex Balashov wrote:
 On 08/26/2014 08:56 PM, Paul Belanger wrote:
 
 I'd agree 'drop-in' replacement is not correct. I ran into the same
 issues as you. Current there is no bridge-mode in rtpengine, I point
 you to an open issue about it [1].
 
 I think the idea behind the formulation of drop-in replacement is that
 the module interface functions are compatible with the standard
 'rtpproxy' module, so no config changes are required to make it work.
 
 It doesn't mean that all the old features exist. It means that they are
 stubbed out in such a manner as to not invalidate the existing config.
 
 Even then, that's not entirely true, given the 'rtpengine' nomenclature
 change recently.

Correct, the drop-in replacement wording was related to the older
module rtpproxy-ng. The newer rtpengine module isn't 100% compatible any
more, so the docs should probably be changed.

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

Re: [SR-Users] How do I translate rtpproxy bridge mode config to mediaproxy-ng/rtpengine?

[Richard Fuchs]

On 08/25/14 19:25, Alex Villací­s Lasso wrote:
 I have a rtpproxy configuration that spawns several rtpproxy instances,
 using bridge mode. An example is shown below:
 
 /usr/bin/rtpproxy -p /var/run/rtpproxy.pid-7723 -u rtpproxy -s
 udp:127.0.0.1 7723 192.168.2.18/127.0.0.1 -m 1 -M 2
 
 Here, rtpproxy bridges between 192.168.2.18 and 127.0.0.1 .
 
 Now I want to migrate to rtpengine with the rtpproxy-ng module in
 kamailio. However, I do not find an equivalent to bridge mode in the
 rtpengine command-line parameters. I see the --ip=IP parameter, but the
 source code expects a single IP address, and cannot be specified more
 than once. The closest I see is the --advertised-ip=IP parameter, but I
 am not sure that it will do what I need.

Depending on your network setup, you should be able to allow your
private IP networks to communicate with the public address of the media
proxy by adding a network route in the right place(s). Another possible
solution could be to use the media-address= option. Certain iptables
rules (assuming you're on Linux) such as SNAT might also be helpful, or
a combination of several of these mechanisms.

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

Re: [SR-Users] rtpengine symmetric RTP behavior

[Richard Fuchs]

On 08/11/14 17:04, Narsay, Deep wrote:
 Hello Andreas,
 
 Yes, that's what I had thought, but 
 
 I am actually seeing it using two different UDP ports towards Freeswitch
 (send=40036 and recv=40042) 
 
 and two more ports towards SIP Client (send=40038, and recv=40040).
 
 I am wondering if there is any setting (or flag at compilation time)
 that will make it symmetric.

It shouldn't do that, unless it gets confused about which party talks to
whom, assuming there's more than two parties involved. The symmetric
and asymmetric flags actually have a different purpose (with
symmetric being the default).

If you experience asymmetric RTP coming from rtpengine, please post the
full rtpengine log from one such call, together with details about the
RTP flows you're seeing.

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

Re: [SR-Users] Does rtpengine properly handle FQDN in SDP Origin?

[Richard Fuchs]

On 08/19/14 14:53, Anthony Messina wrote:
 I've begun playing with rtpengine (git e0957d1) a little and in my testing:
 CSipSimple - Kamailio/rtpengine - Asterisk 12/13
 
 I see the following error when parsing SDP from the Asterisk side, possibly 
 related to the use of the FQDN in the Origin:
 
 Got valid command from 127.0.0.1:44407: answer - {
 sdp: v=0
 o=- 3617462201 3617462204 IN IP4 hostname.example.com
 s=Asterisk
 snip
 
 Error parsing SDP at offset 5: Error parsing o= line
 Protocol error in packet from 127.0.0.1:44407: Failed to parse SDP 
 [d3:sdp353:v=0
 o=- 3617462201 3617462204 IN IP4 hostname.example.com
 s=Asterisk
 snip
 
 It was brought up here, 
 https://issues.asterisk.org/jira/browse/ASTERISK-23994 
 and it appears that a FQDN should be supported in the SDP Origin.  Is this 
 the 
 case, or might it be something else?

You're quite correct, this was an oversight. Fixed in
https://github.com/sipwise/rtpengine/commit/50f2bfbc4dc7f73a1fa215e1c80e89ccc1887d85

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

Re: [SR-Users] [rtpengine] continuous 'Successful STUN binding request from' messages

[Richard Fuchs]

On 05/08/14 11:01 AM, Paul Belanger wrote:

I was hoping somebody could confirm the following is a _normal_ log
file for rtpengine.  Specifically I am curious of the 'Successful STUN
binding request from' messages are continuously logged.


Chrome seems to be doing this during normal operation. I have no idea 
why though, perhaps some sort of keep-alive. You should be able to 
confirm successful STUN communication with Wireshark.


I did notice that you're responding to an RTP/SAVPF offer with an 
RTP/SAVP answer. That might be the source of your issue.


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

Re: [SR-Users] [rtpengine] DTLS error: 1 (message digest is null)

[Richard Fuchs]

On 04/08/14 01:10 PM, Paul Belanger wrote:

Greetings,

I'm having some trouble getting dtls-srtp working with kamailio 4.1
(mediaproxy-ng) and rtpengine (master).

I believe I finally have my branch logic setup properly in kamailio,
however when the calls get placed into rtpengine, it appears DTLS is
not initialized properly. Attached is my debug log file.


From the little I can find online about this error, it may be a problem 
with your OpenSSL version. I'm running 1.0.1h and I haven't seen this yet.


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

Re: [SR-Users] Kamailio with rtpproxy-ng and mediaproxy-ng: Error rewriting SDP

[Richard Fuchs]

On 24/07/14 09:27 AM, Olli Heiskanen wrote:


That's odd... I pulled a new version from git master 4 days ago, and
copied the compiled rtpengine to /usr/sbin, which is running. (although
might help verifying the version if command rtpengine --version gave
actual output instead of 'undefined') :)

Any chance my environment might cause something like this? For example I
can't use kernel packet forwarding as I'm running these on a virtual
server. I don't think this problem has anything to do with the kernel
module but maybe something environment related (virtual server, nat,
having Asterisk on the side, etc...), or maybe the way I've written my
config?


I can't imagine what. The selection of active/passive is pretty 
straightforward and doesn't depend on much of anything. The 
offer/answer/delete commands as reproduced in full in the log are all 
the input that rtpengine gets, and with the same input it should always 
produce the same result.


The only thing to consider is that in your pasted log, the offer 
command is truncated in the SDP and so some of the flags are missing. I 
don't think they would make a lot of difference though, and I tried a 
few different variations and still couldn't reproduce it.


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

Re: [SR-Users] Kamailio with rtpproxy-ng and mediaproxy-ng: Error rewriting SDP

[Richard Fuchs]

On 07/23/14 05:03, Olli Heiskanen wrote:
 
 Hi,
 
 Thanks very much for this, that solved the double-m-line issue. Now I'm
 calling rtpengine_offer in a branch route.
 
 One issue still remains; the call still gets connected to the called
 zoiper client, but it gets hung up right away. I traced this to be
 caused by a BYE message from Kamailio, which I think may be caused by
 the fact that the SDP returning to the chrome/websocket caller contains
 RTP/AVP profile, which it doesn't support. What I don't know is why this
 happens. 
...
 I suspect there is a 200 OK message going from Kamailio to the ws client
 that has the RTP/AVP profile, as the Jssip library gets an error
 stating: Failed to set remote answer sdp: Failed to push down transport
 description: Answerer must use either active or passive value for setup
 attribute.
 
 Any idea on what's going wrong here? 

Yes, I see there's an a=setup:actpass in the answer, which shouldn't be
there. Could you post the entire log for the whole call (just the
rtpengine part) so I can see why it's putting that there?

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

Re: [SR-Users] Kamailio with rtpproxy-ng and mediaproxy-ng: Error rewriting SDP

[Richard Fuchs]

On 20/07/14 01:15 PM, Olli Heiskanen wrote:

Hi,

...

There may be something off in my Asterisk configs since it's Asterisk
that responds 488, but see how Kamailio responds, SDP contains 2 similar
m= lines. Is there something I might be doing wrong in configuring
rtpengine? The INVITE going to the called client has nice clean rtp with
RTP/AVP profile.


This looks a lot like the issue discussed here:

http://lists.sip-router.org/pipermail/sr-dev/2014-July/024507.html

The solution was:

http://lists.sip-router.org/pipermail/sr-dev/2014-July/024519.html

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

Re: [SR-Users] rtpengine upgrade fails

[Richard Fuchs]

On 07/16/14 03:21, Juha Heinanen wrote:
 i build debian packages for rtpengine branch 3.3.0.0+0~mr3.4.1.0.  after
 that i did 'apt-get dist-upgrade' and it failed like this:
 
 Setting up ngcp-rtpengine-daemon (3.3.0.0+0~mr3.4.1.0) ...
 Installing new version of config file /etc/init.d/ngcp-rtpengine-daemon ...
 Restarting RTP/media proxy: ngcp-rtpengine-daemonFATAL: Module xt_MEDIAPROXY 
 not found.
 iptables: No chain/target/match by that name.
 ip6tables: No chain/target/match by that name.
 FAILED TO CREATE KERNEL TABLE 0, KERNEL FORWARDING DISABLED
 invoke-rc.d: initscript ngcp-rtpengine-daemon, action restart failed.
 dpkg: error processing ngcp-rtpengine-daemon (--configure):
  subprocess installed post-installation script returned error exit status 255
 
 however, if i now run 'apt-get install ngcp-rtpengine-daemon', setting up
 ngcp-rtpengine-daemon succeeds and also packages that depended on it
 get installed fine:
 
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 ngcp-rtpengine-daemon is already the newest version.
 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
 2 not fully installed or removed.
 After this operation, 0 B of additional disk space will be used.
 Do you want to continue [Y/n]? 
 Setting up ngcp-rtpengine-daemon (3.3.0.0+0~mr3.4.1.0) ...
 Restarting RTP/media proxy: ngcp-rtpengine-daemon.
 Starting RTP/media proxy: ngcp-rtpengine-daemon already running.
 Setting up ngcp-rtpengine (3.3.0.0+0~mr3.4.1.0) ...
 
 any ideas why setting up ngcp-rtpengine-daemon fails with dist-upgrade?

Hard to tell without further information. Perhaps dist-upgrade tried to
upgrade the daemon after the kernel module was removed but before the
new module was installed? Did you install the kernel module through
dkms? Do you have the metapackage installed? You can check the dpkg.log
and dkms log files for more info.

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

Re: [SR-Users] Kamamilio ignores RTP engine returned string

[Richard Fuchs]

On 07/16/14 17:25, Yuriy Gorlichenko wrote:
 Hello Rtpengine (rtpproxy-ng module) works fine with kamailio till today.
 
 Without any changes at kamailio or rtpengine kamailio ignores changed by
 rtpengine SDP content.
 
 To check this I use sdp_get() and after tying to call I print avp from
 this function and returned sdp body by rtpengine != this content

I don't know if this answers your question, but you may not see the
changes to the SDP body within Kamailio until you call
msg_apply_changes() or actually send the message back 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

Re: [SR-Users] Problem with installing rtpengine

[Richard Fuchs]

On 07/10/14 20:25, Muhammad Shahzad wrote:
 Hi,
 
 I am trying to upgrade from mediaproxy-ng to rtpengine trunk version.
 The compilation steps go well and i have deb packages created. However
 when i try to install them (on same machine where they compiled), i get
 this error for every deb package,
 
  ngcp-rtpengine-daemon pre-depends on ngcp-system-tools
 *  ngcp-system-tools is not installed.*
 
 I can't find this ngcp-system-tools package anywhere, neither on source
 nor in built deb packages. So, i am stuck.

Execute debian/flavors/no_ngcp to fix it up for non-NGCP systems.

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

Re: [SR-Users] No sound between chrome and firefox

[Richard Fuchs]

On 07/07/14 06:40 PM, Yuriy Gorlichenko wrote:

Hello. I have Kamailio 4.1.3+rtpengine_rtpproxy-ng as module for rtpengine.

Kamailio installed as frontend (registration, auth, proxy ) of
asterisksk servers.

WEBRTC users registred at kamailio and asterisk works as media server.

When I try to call from Jssip from Firefox to chrome to way audio is fine.
When I call from chrome - I see rtp packets only from firefox. Not from
chrome.

At kamailio log when I call from chrome log the same as whe i try to
call from firefox (I can not see anithing wrong)


It would help to have the complete log messages from rtpengine. Make 
sure you have a very recent version of Firefox, it used to have certain 
WebRTC implementation problems.


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