Add incoming_call to webhook_to_call: for inbound calls

[casm]

In working with ha-sip and automations, it occurred to me that if it was possible to define a webhook for incoming_call, this would add a lot of flexibility to automations.

As it stands, incoming_call relies on a template to be evaluated (which is fine; I'm not suggesting that the template be removed), but being able to give it its own webhook would be very useful since it could be directly referenced as a triggering event.

[arnonym]

I'm not sure what you would win with that, except saving one condition in the automation. On the other hand you would need more config options for special webhooks.

For the record. This is about removing the condition and have a special webhook only called for incoming calls:

alias: "SIP: Incoming calls"
description: ""
mode: single
triggers:
  - webhook_id: sip_call_webhook_id
    allowed_methods:
      - POST
      - PUT
    local_only: true
    trigger: webhook
conditions:
  - condition: template
    value_template: |
      {{ trigger.json.event == "incoming_call" }}
actions:
  something

[casm]

The main goal would be to add granularity in terms of both monitoring and acting on call progress with webhooks.

If my reading of the logs is correct, the global webhook is fired every time an inbound call comes in. The next webhook to fire is call_established when the call is answered. This is fine, but because there's no explicit inbound_call webhook, there isn't a good way (using webhooks) to differentiate between an unanswered and an answered call - it appears to have to be done in conjuction with a template.

FWIW, I did try defining an incoming_call webhook under webhook_to_call:, but it never seems to fire. The docs seem to indicate that it should be possible to define it for an incoming or outgoing call, so not sure why that's the case.

[arnonym]

Where did you try to define the incoming_call on webhook_to_call? I could not find any mention of this option in the docs. The webhook defined in the global config is the only webhook being called for incoming calls.

I'm not sure if I understand the 2nd paragraph correctly. The global webhook (from the add-on config) is called for every event on all calls. Additionally you can define granular webhooks for calls that are in progress. And you're right, if you're using the global webhook you need a condition if you're only interested in certain events. But you can also create multiple automations on the same webhook with different conditions.

Is it only about the condition? Do you think it's hard to understand? Sorry, I'm still not sure what you're trying to achieve.

[casm]

Where did you try to define the incoming_call on webhook_to_call? I could not find any mention of this option in the docs. The webhook defined in the global config is the only webhook being called for incoming calls.

Apologies for the delay in replying; my memory's a bit fuzzy as a result. IIRC, it was defined under webhook_to_call: in sip-1-incoming.yaml.

I'm not sure if I understand the 2nd paragraph correctly. The global webhook (from the add-on config) is called for every event on all calls. Additionally you can define granular webhooks for calls that are in progress. And you're right, if you're using the global webhook you need a condition if you're only interested in certain events. But you can also create multiple automations on the same webhook with different conditions.

Both of these are true, but I was running into problems with trying to run automations that were specifically tied to an incoming call event. Basically, no matter what logic I applied to the automation, the webhook I defined for the incoming call never fired.

My recollection is that I had defined a webhook (incoming_call: ha-sip-incoming_call) in under webhook_to_call: in sip-1-incoming.yaml. The webhook never fired, but the documentation at https://github.com/arnonym/ha-plugins?tab=readme-ov-file#web-hooks indicates that there is an incoming_call webhook to handle this. That one didn't fire, either.

Is it only about the condition? Do you think it's hard to understand? Sorry, I'm still not sure what you're trying to achieve.

The main goal is to have a webhook that uniquely represents an unanswered incoming call which would allow automations, etc. to act on that specific call state.

It's possible that I'm misunderstanding something, but it feels like there's a bit of a gap in how the current configuration handles call progress; adding the incoming_call webhook would cover that gap and help to streamline interactions between ha-sip and automations, etc.

Apologies if this isn't making sense - I swear that I'm not trying to be obtuse about it :)