[asterisk-bugs] [JIRA] (ASTERISK-29438) TURN Server never added to ICE candidate list.

Chris (JIRA) noreply at issues.asterisk.org
Fri May 21 06:30:17 CDT 2021


    [ https://issues.asterisk.org/jira/browse/ASTERISK-29438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=254976#comment-254976 ] 

Chris edited comment on ASTERISK-29438 at 5/21/21 6:29 AM:
-----------------------------------------------------------

We don't have control on the password generation, we'll see if we can escape it on our side somehow.
Unfortunately there is no formal list anywhere in the docs on what chars to escape. So it's kind of a wild guess.

Cleaner would be that all string-value configuration parsing is threatened the same way in Asterisk.
chan_sip accepts the double-quotes and removes them. 
The stun/turn settings don't remove the quotes.




was (Author: ccasterisk):
We don't have control on the password generation, we'll see if we can escape it on our side somehow.
Unfortunately there is no formal list anywhere in the docs on what chars to escape. So it's kind of a wild guess.

Cleaner would be that all string-value configuration parsing is threatened the same way in Asterisk.
chan_sip accept the double-quotes and removes them. 
The stun/turn settings don't remove the quotes.



> TURN Server never added to ICE candidate list.
> ----------------------------------------------
>
>                 Key: ASTERISK-29438
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29438
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: pjproject/pjsip, Resources/res_rtp_asterisk
>    Affects Versions: 16.17.0
>         Environment: Network topology requiring TURN
>  using PJSIP
>            Reporter: Chris
>            Assignee: Unassigned
>              Labels: webrtc
>         Attachments: no-turn-candidates.zip
>
>
> The configured TURN server is never added to the ICE candidate list offered via SIP/SDP
> The assumed reason is that, after receiving status 400 (Bad request) Asterisk stops sending request and shuts down the 
> According to the RFC, a status 400 does not necessary means the procedure has to stop.
> See: https://tools.ietf.org/id/draft-ietf-tram-stunbis-13.html#section.bid-down
> NOTE : The PCAP contains 4 requests,  these are for audio, video and their 2 RTCP counterparts.
> But each of those 4 are only tried once.



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list