[Home]

Summary:ASTERISK-24602: Unable to call WebRTC client via wss on chan_pjsip
Reporter:Oleg Kozlov (olkeep)Labels:
Date Opened:2014-12-09 21:32:00.000-0600Date Closed:2016-09-23 14:29:01
Priority:MajorRegression?
Status:Closed/CompleteComponents:pjproject/pjsip
Versions:13.0.0 Frequency of
Occurrence
Constant
Related
Issues:
is duplicated byASTERISK-25345 pjsip:0 : tsx0xb3fe5d1c ...Failed to send Request msg INVITE/cseq=28532 (tdta0xb6bb49c0)! err=171060 (Unsupported transport (PJSIP_EUNSUPTRANSPORT))
Environment:Centos 6.5 x86 pjproject 2.3 (https://github.com/asterisk/pjproject)Attachments:( 0) endpoint_config.txt
( 1) failing.log
( 2) inbound_debug_with_TLS_transport_on.txt
( 3) pjsip.transport.conf
( 4) registration_outbound_debugworks_fine.txt
( 5) working.log
Description:Calls to WebRTC client (sipml5) via WSS transport or chan_pjsip always fail.
Registration and calls from WebRTC client work without issues.

I believe that the issue is about Asterisk trying to use wrong transport (TLS instead of WSS) to SIP INVITE WebRTC clients.

Error summary:
1. TLS transport isn't configured in pjsip.conf:
bq. pjsip:0 <?>: tsx0xb740c914 ...Failed to send Request msg INVITE/cseq=5413 (tdta0xb740d3c8)! err=171060 (Unsupported transport (PJSIP_EUNSUPTRANSPORT))

2. TLS transport is configured for some other peers in pjsip.conf:
{quote}
<--- Transmitting SIP request (1741 bytes) to TLS:CLIENT_IP:62950 --->
INVITE sips:tempwss2@CLIENT_IP:62950;transport=wss;rtcweb-breaker=no SIP/2.0
...
pjsip:0 <?>: tlsc0x884bf24 TLS connect() error: Connection timed out
{quote}
Comments:By: Rusty Newton (rnewton) 2014-12-11 18:41:18.262-0600

Oleg can you provide an Asterisk log (gathered following these instructions:https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information) that shows the complete working and failing calls.

Be sure that SIP debug is enabled. What we want to see if is all the various logging channels such as VERBOSE and DEBUG integrated with the SIP trace.

By: Rusty Newton (rnewton) 2014-12-11 18:41:37.152-0600

Press Send Back or Enter Feedback when done. Thanks!

By: Oleg Kozlov (olkeep) 2014-12-15 11:19:14.415-0600

Hi, Rusty
I've uploaded two logs (verbose (5), debug (5), pjsip logger (host CLIENT_IP)):
1. working.log - WSS client registration and call from WebRTC client
2. failing.log - Call from Asterisk to WebRTC client

Thank you!

By: Marek Cervenka (cervajs) 2015-08-26 05:30:55.919-0500

any news about this problem?
i filled ASTERISK-25345 but it's duplicate to this

By: Joshua C. Colp (jcolp) 2015-08-26 05:34:05.940-0500

Any news/updates will be posted to this issue. As there have been no additional comments there is nothing else.

By: Marek Cervenka (cervajs) 2015-08-26 08:17:29.732-0500

this debug shows that TLS transport is chosen, but transport=wss is configured for endpoint

contact webrtc_cervenka/sips:webrtc_cervenka@1.1.1.1:58757;transport=wss;rtcweb-breaker=no

can i change somehow pjsip resolve transport?

[Aug 26 14:50:11] DEBUG[30213]: pjsip:0 <?>:     dlg0xb3f1d17c Module WebSocket Transport Module added as dialog usage, data=(nil                            )
[Aug 26 14:50:11] DEBUG[30213]: pjsip:0 <?>:     dlg0xb3f1d17c Module NAT added as dialog usage, data=(nil)
[Aug 26 14:50:11] DEBUG[30213]: pjsip:0 <?>:     inv0xb3f1d17c .Sending Request msg INVITE/cseq=32339 (tdta0xb3f3b8b8)
[Aug 26 14:50:11] DEBUG[30213]: pjsip:0 <?>:     dlg0xb3f1d17c ..Sending Request msg INVITE/cseq=32339 (tdta0xb3f3b8b8)
[Aug 26 14:50:11] DEBUG[30213]: pjsip:0 <?>:     tsx0xb3f3c924 ...Transaction created for Request msg INVITE/cseq=32338 (tdta0xb3                            f3b8b8)
[Aug 26 14:50:11] DEBUG[30213]: pjsip:0 <?>:     tsx0xb3f3c924 ..Sending Request msg INVITE/cseq=32338 (tdta0xb3f3b8b8) in state                             Null
[Aug 26 14:50:11] DEBUG[30213]: pjsip:0 <?>:     sip_resolve.c ...Target '1.1.1.1:58757' type=TLS resolved to '1.1.1.1:58757' type=TLS (TLS transport)
[Aug 26 14:50:11] WARNING[30213]: pjsip:0 <?>:   tsx0xb3f3c924 ...Failed to send Request msg INVITE/cseq=32338 (tdta0xb3f3b8b8)!                             err=171060 (Unsupported transport (PJSIP_EUNSUPTRANSPORT))


By: Martin Tomec (matesstar) 2015-09-02 04:38:27.593-0500

It seems to be bug in pjsip library. Acording to this patch:
https://trac.pjsip.org/repos/ticket/1319
"When sips scheme is used, TLS must be used even when transport=tcp is specified in the URI"
This in real means: when sips scheme is used, transport parameter is ignored.
I will try to submit patch to pjsip.

By: Marek Cervenka (cervajs) 2015-09-02 10:20:30.530-0500

after patching pjsip to ignore sips we moved to the next problem
call from webrtc_cervenka to webrtc_tomec
webrtc_tomec answered call but channel hangup
any ideas howto debug why hangup happened?

[Sep 2 11:25:28] DEBUG[28870] res_pjsip_session.c: Source of transaction state change is RX_MSG
[Sep 2 11:25:28] DEBUG[28870] res_pjsip_session.c: Received response
[Sep 2 11:25:28] DEBUG[28870] res_pjsip_session.c: Response is 200 OK
[Sep 2 11:25:28] DEBUG[28870] pjsip: inv0xb6c2acd4 ....Got SDP answer in Response msg 200/INVITE/cseq=5501 (rdata0xb6c679dc)
[Sep 2 11:25:28] DEBUG[28870] pjsip: inv0xb6c2acd4 ....SDP negotiation done, status=220046
[Sep 2 11:25:28] DEBUG[28870] pjsip: inv0xb6c2acd4 ....Received Response msg 200/INVITE/cseq=5501 (rdata0xb6c679dc), sending ACK
[Sep 2 11:25:28] DEBUG[28870] pjsip: endpoint ....Request msg ACK/cseq=5501 (tdta0xb6c0b188) created.
[Sep 2 11:25:28] DEBUG[28870] pjsip: dlg0xb6c2acd4 .....Sending Request msg ACK/cseq=5501 (tdta0xb6c0b188)
[Sep 2 11:25:28] DEBUG[28594] threadpool.c: Increasing threadpool stasis-core's size by 1
[Sep 2 11:25:28] DEBUG[28899][C-0000000f] channel.c: Hanging up channel 'PJSIP/webrtc_tomec-00000008'

By: Marek Cervenka (cervajs) 2015-09-02 12:22:27.527-0500

[Sep 2 11:25:28] DEBUG[28870] pjsip: inv0xb6c2acd4 ....SDP negotiation done, status=220046

the problem is
/** * @hideinitializer * Transport type is different in the remote answer. */
#define PJMEDIA_SDPNEG_EINVANSTP (PJMEDIA_ERRNO_START+46) /* 220046 */

By: Marek Cervenka (cervajs) 2015-09-03 06:21:27.286-0500

it looks like the problem is UDP/TLS/RTP/SAVPF vs RTP/SAVPF

sipml5 sending UDP/TLS/RTP/SAVPF, asterisk create sdp with RTP/SAVPF

https://tools.ietf.org/html/rfc5764#section-8  recommends UDP/TLS/RTP/SAVPF

By: Marek Cervenka (cervajs) 2015-09-03 09:20:53.875-0500

https://code.google.com/p/webrtc/issues/detail?id=2796
--cite--
As indicated in https://github.com/rtcweb-wg/jsep/issues/70, we should do: [UDP|TCP]/TLS/RTP/SAVPF in offers/answers we generate, but tolerate */RTP/* in offers/answers that come from the remote side. Also need to update SCTP drafts to do [UDP|TCP]/TLS/SCTP instead of DTLS/SCTP.
--cite--

we'll send patch to pjsip mailing list

By: Martin Tomec (matesstar) 2015-09-04 06:09:22.553-0500

Problem was, that WSS transport was not marked as "secure", so pjsip refused to use it with "sips" in uri (and used TLS instead)
Partial fix is in review: https://gerrit.asterisk.org/#/c/1181/
There is still problem in pjsip with UDP/TLS/RTP/SAVPF vs RTP/SAVPF...

By: Joshua C. Colp (jcolp) 2017-12-20 06:27:41.983-0600

Is this still a problem? WSS support has been changed and fixed, and is actively used now.

By: Richard Mudgett (rmudgett) 2018-03-16 12:27:48.323-0500

No response.

Closing as fixed as there have been other WebRTC fixes concerning WS vs WSS made since the partial fix that was directed explicitly toward this issue.