FreePBX/Asterisk res_hep_pjsip not sending packets to heplify-server when Asterisk extension is on WebRTC?

[pekkaar]

Hi All,

did anybody ever come across the situation that the HEPv3 Asterisk res module works perfectly fine for all SIP (PJSIP) endpoints (extensions and trunks) in FreePBX 16/Asterisk 18, but as soon as you configure an extension to be WebRTC (as per Asterisk guidelines), and the connection turns to WebSocket (actually secure WSS) from standard SIP, then the heplify-server (v1.59.4) database does not contain any info for that Asterisk -> WebRTC extension endpoint call segment anymore?

The WebRTC connection works perfectly, calls go back and forth with these extensions and the client logs the encapsulated SIP messages just fine. It is just that I see no trace info of these calls in the heplify-server DB, and by extension in Homer web app...

Many thanks for any insights!
Peter

[lmangani]

Hello @pekkaar res_hep_pjsip is part of Asterisk and we can't speak on its internals. You would have to dig into the code to see if its even capable to forwarding websocket packets. Based on your description, I assume nothing related to WSS legs is being sent to homer/heplify-server by the module, unless you can confirm otherwise, so you can focus on the source being the issue here.

For context, most of our users tend to terminate and monitor websockets on a proxy in front of B2BUAs rather than Asterisk.
Since the WSS legs are encrypted, there's not much one can do passively other than perhaps with rtcagent but it's virgin territory.

[pekkaar]

Hello @lmangani, many thanks for the response and insights!

I actually raised the same question at FreePBX/Asterisk community forum as well, exactly because of this res module being part of Asterisk. However looking at the source code it seems at least one of the original authors was @adubovikov so I hoped it is not that unknown.

Having the WSS legs encrypted appears to be no greater concern from an architecture perspective than a simple TLS SIP call leg? TLS SIP packets do make it to the heplify ecosystem just fine though... so again I thought this might still not be the root cause?

Terminating the websockets on a proxy just to be able to trace the encapsulated SIP messages feels a bit too complex? I assume that proxy would need its own HEP module plugging them into heplify-server? But I am happy to learn this concept, do you maybe have some known-good use cases documented on the web?

Thanks again,
Peter

[lmangani]

There's no such thing as a simple TLS SIP call leg since WSS/TLS is the transport. The messages you see in homer are most likely the B-Leg of those sessions? I assume you're using SIP over WSS and as such should see A/B session for each connection?

[pekkaar]

Yes, so for a call to a TLS extension I do see both A and B-legs in homer, but for a webrtc extension I only see the A-leg, and I don't see the B-leg. And yes, it is SIP in use in both cases.

[lmangani]

I'm afraid this confirms your concern with the Asterisk HEP module lacking proper hooks into the websocket handlers.

[pekkaar]

Oh, so there is no way this could be a config problem? Ouch, I wonder why nobody appears to have been requesting this functionality, or better yet offer a PR for it :)

[pekkaar]

Update, so bumping heplify-server loglvl to debug (logdbg to hep,loki) appears to show some SIP payloads arriving to decoder.go at least from between the webrtc extension and asterisk:

{"log":"2023/09/06 14:55:18.326568 decoder.go:163: DBG [hep] \u0026HEP{Version:2,Protocol:6,SrcIP:xxx.xxx.210.194,DstIP:10.0.22.52,SrcPort:16554,DstPort:8089,Tsec:1694012118,Tmsec:318000,ProtoType:1,NodeID:666,NodePW:,Payload:REGISTER sip:qaeu01pbx1.xxxxxx.com SIP/2.0\r\n","stream":"stderr","time":"2023-09-06T14:55:18.326662896Z"}

And its reponse

{"log":"2023/09/06 14:55:18.327124 decoder.go:163: DBG [hep] \u0026HEP{Version:2,Protocol:6,SrcIP:10.0.22.52,DstIP:xxx.xxx.210.194,SrcPort:8089,DstPort:16554,Tsec:1694012118,Tmsec:319002,ProtoType:1,NodeID:666,NodePW:,Payload:SIP/2.0 200 OK\r\n","stream":"stderr","time":"2023-09-06T14:55:18.327217107Z"}

However, I don't see the same for calls (INVITE). Weird, as 100 Trying and 180 Ringing from WebRTC->Asterisk arrives, but not the initial INVITE:

{"log":"2023/09/06 14:55:44.865904 decoder.go:163: DBG [hep] \u0026HEP{Version:2,Protocol:6,SrcIP:xxx.xxx.210.194,DstIP:10.0.22.52,SrcPort:16554,DstPort:8089,Tsec:1694012144,Tmsec:857000,ProtoType:1,NodeID:666,NodePW:,Payload:SIP/2.0 100 Trying\r\n","stream":"stderr","time":"2023-09-06T14:55:44.865982891Z"}

and

{"log":"2023/09/06 14:55:44.867935 decoder.go:163: DBG [hep] \u0026HEP{Version:2,Protocol:6,SrcIP:xxx.xxx.210.194,DstIP:10.0.22.52,SrcPort:16554,DstPort:8089,Tsec:1694012144,Tmsec:859000,ProtoType:1,NodeID:666,NodePW:,Payload:SIP/2.0 180 Ringing\r\n","stream":"stderr","time":"2023-09-06T14:55:44.868014131Z"}

Also, what is "Protocol:6" ? I don't think there is a table for that in heplify-data?