[mod_amqp] binding_key parameter works only for commands with weird behaviour

[jpVm5jYYRE1VIKL]

Previously noticed inside discussion at #59 Look like parameter "binding_key" works only for commands and does not work for producers and logging nodes. Beside this it is not possible to setup queue name for binding because it is not implemented. For commands node FS just create random titled queue and bind to it using "binding_key" routing key. it is also not possible to set type of binded queue. by default command queue have a parameter "auto delete" which not always good but at least it is possible to live with it in case if it have more predictable queue names.

[mjerris]

happy to review pull requests to address this

[cdosoftei]

This issue touches on a couple of different aspects of mod_amqp.

(1) binding_key only works for commands, i.e. does not work for producers and logging.

That is by design, the commands portion is, primarily, an AMQP consumer whereas the producer and logging portions are AMQP producers. Therefore, the binding key concept would be applicable to commands but not to the others; however, the latter employ the counterpart concept: routing keys. They are constructed dynamically, as follows:

Logging: <hostname>.<entity_id_or_NULL>.<log_level>.<source_file>

e.g.

Exchange:    TAP.Logging
Routing Key: localhost.c044bae6-b685-49b7-a689-4e64e1e1313b.INFO.switch_rtp_c
Payload:     {
                "file":"switch_rtp.c",
            "function":"switch_rtp_add_crypto_key",
            "line":4190,
            "level":"INFO",
            "timestamp":"2019-10-22 17:56:24.800192",
            "timestamp_epoch":1.571767e+09,
            "content":" Activating audio Secure RTP RECV\n"
            }

Producer: FreeSWITCH.<hostname>.<event>..[entity_id]

e.g.

Exchange:    TAP.Events
Routing Key: FreeSWITCH.localhost.CHANNEL_CREATE..04e1eb30-6541-4ecd-9ad6-8a2c3793ff6b
Payload:     {
                "Event-Name":"CHANNEL_CREATE",
                "Core-UUID":"ece06276-910b-477f-8b96-9eae47aaeb57",
                "FreeSWITCH-Hostname":"localhost",
                "FreeSWITCH-Switchname":"localhost",
                "FreeSWITCH-IPv4":"10.0.0.101",
                "FreeSWITCH-IPv6":"::1",
                "Event-Date-Local":"2019-10-22 17:56:25",
                "Event-Date-GMT":"Tue, 22 Oct 2019 17:56:25 GMT",
                "Event-Date-Timestamp":"1571766985820205",
                /* ... more properties ... */
                "variable_RFC2822_DATE":"Tue, 22 Oct 2019 17:56:21 +0000",
                "variable_dialed_extension":"1000",
                "variable_loopback_app":"voicemail",
                "variable_loopback_app_arg":"default 10.0.0.101 1000",
                "variable_other_loopback_leg_uuid":"9989d984-6238-4a76-8eaf-726e26d687be",
                "variable_other_loopback_from_uuid":"c044bae6-b685-49b7-a689-4e64e1e1313b",
                "variable_loopback_leg":"B"
             }

Consumers of the event and log producers can create application specific queues, binding them against the designated exchanges with binding keys observing the above routing patterns, likely using * and # wildcards.

(2) It is not possible to configure the commands queue name.

This is in fact possible but is not documented (at least not in Confluence); the queue-name parameter is readily available, e.g.

    <param name="queue-name" value="fs.commands" />

(3) It is not possible to configure the command queue properties.

Indeed, the queue properties are hardcoded; attributes such as passivity, durability, exclusivity and auto-deleting could be exposed via the module configuration. I'll prepare a PR to address this aspect though I would appreciate any feedback.

--

Please advise if the above response is satisfactory; I believe the first two items can be addressed by extending the existing documentation.

[jpVm5jYYRE1VIKL]

Thanks for your help. Absolutely satisfactory response.

[crienzo]

I think we're all set now- PRs have been merged. Please re-open if this is not correct.