Change type of transport?

Asterisk Asterisk Support
1

My CLI says:

 -- Added contact 'sip:7c2skbrc@192.168.1.8:36792;transport=ws' to AOR '100' with expiration of 600 seconds
    -- Removed contact 'sip:rfj6eopj@192.168.1.8:36622;transport=ws' from AOR '100' due to remove_existing
  == Contact 100/sip:rfj6eopj@192.168.1.8:36622;transport=ws has been deleted
    -- Contact 100/sip:oplv9iot@192.168.1.8:36710;transport=ws is now Reachable.  RTT: 18.413 msec

But all the certificates are installed and placed on right places (and the transport has set to use wss). Any tips on that?

2

The transport parameter in a URI for secure Websocket is still “ws”[1]. Is there some other problem you are experiencing? The log shows a registration came in, it displaced an existing one, and the new one is reachable.

[1] https://tools.ietf.org/html/rfc7118#page-6

3

Hi Jcolp.

This happens when I refresh the web page (should it happen?).

I thought that was my problem, but I can not make calls. When I try, the webphone drops automatically. In the Chrome log, something like “Unable to acquire media” appears, but in the CLI it only appears that the SIPDOMAIN variable has been set for my DNS.

4

Each time you refresh the page it’s a new established connection to the server. The connection doesn’t stick around. That’s expected. That’s not your problem.

You’d need to provide a SIP trace (pjsip set logger on) of a call attempt. If it’s not really reaching Asterisk and the problem is browser side, then you’ll need to dig in there. Welcome to the world of WebRTC - it doesn’t work 100% of the time and when it doesn’t you can spend a ton of time in the browser trying to figure out why.

5

I’ve enabled the PJSIP Logging, it should appear on CLI?

6

If traffic is received, yes.

8

That is incomplete. It doesn’t show from the start of a call attempt to the end.

9

Oh, sorry. Look at the complete log
Log from asterisk

10

It appears to be trying to call “PJSIP/101” and nothing is registered. Since nothing is registered, it can’t call it.

11

But the two webphones are online and apparently registered once they can connect.
Now they can dial each other (I changed the extension setting), but when one of the parties answers, it drops.

12

Then you need to provide a new log.

13

I apologize for the confusion, this was already the log of this new error. I’m really sorry, I forgot to specify

14

The log doesn’t show that. It shows a call attempt to a device that resulted in nothing being dialed, and then later 101 registering.

15

I realized that too … is there any specific log that can provide this information?

16

No, what you’ve provided should show such a thing.

17

Wow, that’s a really big problem… :’(
think there’s something I can do?

18

Try to trace it down further? If there doesn’t appear to be a call as you’ve stated in Asterisk (just a call attempt that failed to call anything), not much I can add…

19

I will search about the network!

20

@jcolp I noticed this on log:

[2018-07-06 13:37:10] ERROR[22458][C-00000025]: res_rtp_asterisk.c:2557 __rtp_recvfrom: DTLS failure occurred on RTP instance '0x7f7bb8089ce0' due to reason 'certificate verify failed', terminating
[2018-07-06 13:37:10] WARNING[22458][C-00000025]: res_rtp_asterisk.c:5310 ast_rtp_read: RTP Read error: Unspecified.  Hanging up.

It says something to you?

21

Yes, that would be because WebRTC hasn’t been properly configured in Asterisk. There are examples on the wiki.