No audio on exactly same Opensips 3.0 Instances on AWS

173 views
Skip to first unread message

M B

unread,
Mar 21, 2022, 12:09:48 PM3/21/22
to rtpengine
Hello all.

After setting up rtpengine on staging and testing thoroughly for a few days, it seems that I can't get audio on WebRTC -> MicroSIP calls. Everything is the same (clearly not). There's one difference in the logs (level 6):

Working instance:
Mar 21 15:46:28 ip-172-31-38-9 rtpengine[8393]: ERR: [e698c13b-6d07-4d37-55e9-e75184a60330 port 11038]: [core] SRTP output wanted, but no crypto suite was negotiated
Mar 21 15:46:28 ip-172-31-38-9 rtpengine[8393]: INFO: [e698c13b-6d07-4d37-55e9-e75184a60330 port 11051]: [ice] ICE negotiated: peer for component 1 is MyIP:52491
Mar 21 15:46:28 ip-172-31-38-9 rtpengine[8393]: INFO: [e698c13b-6d07-4d37-55e9-e75184a60330 port 11051]: [ice] ICE negotiated: local interface 172.31.38.9
Mar 21 15:46:28 ip-172-31-38-9 rtpengine[8393]: INFO: [e698c13b-6d07-4d37-55e9-e75184a60330 port 11051]: [ice] ICE negotiated: peer for component 2 is MyIP:52492

No-audio instance:
Mar 21 15:51:34 ip-172-31-27-223 rtpengine[18890]: ERR: [6ecf435c-2d30-d9c1-42fc-e77ed712ba9d port 11054]: [core] SRTP output wanted, but no crypto suite was negotiated
Mar 21 15:51:34 ip-172-31-27-223 rtpengine[18890]: INFO: [6ecf435c-2d30-d9c1-42fc-e77ed712ba9d port 11067]: [ice] ICE negotiated: local interface 172.31.27.223
Mar 21 15:51:34 ip-172-31-27-223 rtpengine[18890]: INFO: [6ecf435c-2d30-d9c1-42fc-e77ed712ba9d port 11067]: [ice] ICE negotiated: peer for component 2 is MyIP:62407

It seems that " [ice] ICE negotiated: peer for component 1" is NOT happening in the no-audio instance.

Can someone please enlighten me what I have done wrong? :(

Thanks.

Richard Fuchs

unread,
Mar 21, 2022, 1:24:08 PM3/21/22
to rtpe...@googlegroups.com
That may or may not mean anything. Depending on which version you're
running, this message is only printed if the new peer address is
different from the previously known or assumed peer address. This was
only recently improved so that a log message is printed either way (and
indicating whether the peer address has changed or not).
> Can someone please enlighten me what I have done wrong? :(

Impossible to say with only this little information. Seeing the
odd-numbered port from the log perhaps something to do with RTCP-mux?
But this is just a wild guess. Knowing the exact version you're running
would be a good starting point, and I would also suggest to enable debug
logging and then perhaps share what your signalling (to rtpengine) looks
like. After all this is why debug logging exists - to debug things.

Cheers

M B

unread,
Mar 22, 2022, 12:38:31 AM3/22/22
to rtpengine
Hi again.

Thanks a lot for taking the time to respond. Apologies for the incompleteness. It does seem to be related to RTCP-mux (I am using the Late SDP Opensips config: https://opensips.org/pub/docs/tutorials/websockets/opensips-late.cfg). The rtpengine version is:
Version: 10.1.1.10-2~bpo10+1

Attached is the debug log file. Sorry pastebin doesn't work where I'm located.

Thanks for your help.
No-Audio-MUX.txt

M B

unread,
Mar 23, 2022, 9:01:32 AM3/23/22
to rtpengine
Hi there.

Just wondering if you needed any more information or if I misunderstood something.

Thanks again for the help.

M B

unread,
Mar 25, 2022, 1:21:02 AM3/25/22
to rtpengine
For some unknown reason, I am getting audio now after having started rtpproxy (in addition to rtpengine).
Reply all
Reply to author
Forward
0 new messages