| 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-0600 | Date Closed: | 2016-09-23 14:29:01 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | pjproject/pjsip | ||
| Versions: | 13.0.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| 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. | ||||