[asterisk-bugs] [JIRA] (ASTERISK-24106) WebSockets Automatically decides what driver it will use

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-24106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan updated ASTERISK-24106:
-----------------------------------

    Status: Open  (was: Triage)

> WebSockets Automatically decides what driver it will use 
> ---------------------------------------------------------
>
>                 Key: ASTERISK-24106
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24106
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_http_websocket, Resources/res_pjsip_transport_websocket
>    Affects Versions: 12.4.0
>            Reporter: Andrew Nagy
>            Severity: Minor
>
> When using WebSockets in Asterisk 12, Asterisk itself randomly decided what driver will manage the websockets protocol if both chan_sip and pjsip are loaded at the same time. This means it's a random draw for a system as to what driver is actually being used.
> It would be nice to be able to use both, either through a different url (as opposed to just ws) or through a flag or another option.
> Right now I have to check the CLI to see is module "res_pjsip_transport_websocket" is loaded and is running, if it's not running then I blindly assume that chan_sip is in control of the websocket port.
> This was discussed at length in #asterisk-dev so I am attaching the log here:
> {code}
> tm1000: file: one last question about webrtc I swear, just trying to figure out a good way to determine if pjsip or chan_sip is controlling the websocket. The best way I can think of is to run: module show like res_pjsip_transport_websocket, and see if the use count is above 0 and status is Running
> [09:31am] file: that should work
> [09:32am] tm1000: k
> [09:32am] • file ponders
> [09:32am] file: we could make the pjsip one use a different URL, actually
> [09:36am] mjordan: file: if it were configurable on the transport, that would be a "good thing"
> [09:37am] tm1000: mjordan: I strongly agree
> [09:37am] tm1000: however I wasnt going to push anything since 12 is feature locked
> [09:38am] tm1000: file: different url, different something, but the guessing is kind of painful to be honest
> [09:38am] file: it should be... possible
> [09:38am] mjordan: well.... (a) it doesn't mean it should be done. (b) interoperability concerns are still problematic. Running chan_sip + chan_pjsip together is sort of what we were trying to ensure with this, and this feels like a bug (that is, you can't split apart the two on websockets easily)
> [09:39am] mjordan: s/it should be done/it shouldn't be done
> [09:39am] tm1000: mjordan: Yeah its confusing in my land since I run both at the same time and I have to guess through the CLI which device to write out (think auto creating webrtc devices)
> [09:47am] tm1000: mjordan: because really if I have both chan_sip and pjsip enabled and I go and create a webrtc device on pjsip it wont work and how am I suppose to know that? (as an end user) if chan sip is taking control 
> [09:48am] mjordan: rationalization!
> [09:48am] file: sleepy
> [09:48am] mjordan: tm1000: mind opening an issue for it?
> [09:54am] tm1000: mjordan: sure how would I word it? like how I put it above?
> [09:54am] mjordan: yup
> {code}



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