Applicationurl shouldn't randomly generate port 5060 or 5061
See original GitHub issueI noticed a little error.
Port 5060 and 5061 aren’t allowed by new browser versions due to the natslip attack (https://chromestatus.com/feature/5064283639513088). Port 5060 was randomly created for me in the launchSettings.json
file which made me have issues accessing my API from the browser. I had to change the applicationUrl
port manually.
if I can be shown the line where the port generation is done in the dotnet SDK, I would also appreciate it. Thanks
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:12 (7 by maintainers)
Top Results From Across the Web
Applicationurl shouldn't randomly generate port 5060 or 5061
I noticed a little error. Port 5060 and 5061 aren't allowed by new browser versions due to the natslip attack ...
Read more >Legacy SIP and PJSIP port usage - Configuration
I would still like to use 5060/5061 with IP based ACLs for providers and use a random port for remote phone clients. The...
Read more >Port Utilization in CVP [Cisco Unified Contact Center ...
This port must be different from the default SIP port which is 5060/5061 (see aforementioned row). SIP endpoints. Random. Bi-directional. Listen ...
Read more >Introduction to SIP
Port 5060 is commonly used for non-encrypted signaling traffic, whereas port 5061 is typically used for traffic encrypted with Transport Layer Security (TLS)....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
cc @phenning and @vijayrkn this may also impact Visual Studio scenarios
All the port generation is done in a template engine generator on creation via the following, not from either of the host. One of the issues here though is that even though it would be fixed in the template engine generator, we would not have that fix available until VS was updated with that dependency. I don’t believe there is anything for us to do in VS/VSMac other than consume updated template engine binaries.
It would be nice if the port generator supported a passable exclusion range as a parameters, so that if there are additional ports in the future that need to be excluded, fixes could be made in the templates until an engine update can be made/inserted.