asterisk users - Jun 2020 - asterisk hints can be in multiple states; most sip NOTIFY dialogs only send one state

Asterisk can know that one of the attached phones is both "ringing"
and
"on the phone".

However the sip NOTIFY it sends out to interested parties can only 
communicate one state, for example with pidf+xml it can either send 
"Ringing" or "On the phone" and so it sends
"Ringing".

This makes the "busy lights" less than useful, if a call makes
multiple
phones ring you can't tell, looking at the busy lights, which ones are 
busy, and so less likely to answer.

In the chan_sip configuration there is an option "notifyringing":


        notifyringing

    *notifyringing* enables or disables notifications for the RINGING
    state when an extension is already INUSE. Only affects subscriptions
    using the *dialog-info* event package. Option can be configured in
    the general section only. It cannot be set per-peer.

As the doc says this only applies to dialog-info style NOTIFY, not the 
pidf+xml format my phones use.

Here is a patch that makes notifyringing work for pidf+xml.

Generalising it for other formats is left as an exercise for the reader.

Of course chan_sip is obsolete.  How might this be done for chan_pjsip?  
Parts of the code are similar, but the layering is vastly different.  
How could the ast_sip_presence_exten_state_to_str function in 
res/res_pjsip/presence_xml.c get at the pjsip configuration?

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20200610/24d08c9b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pidf+xml-notifyringing.patch
Type: text/x-patch
Size: 799 bytes
Desc: not available
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20200610/24d08c9b/attachment.bin>

On Wed, Jun 10, 2020 at 10:27 AM John Hughes <john at calva.com> wrote:
> Asterisk can know that one of the attached phones is both
"ringing" and
> "on the phone".
>
> However the sip NOTIFY it sends out to interested parties can only
> communicate one state, for example with pidf+xml it can either send
> "Ringing" or "On the phone" and so it sends
"Ringing".
>
> This makes the "busy lights" less than useful, if a call makes
multiple
> phones ring you can't tell, looking at the busy lights, which ones are
> busy, and so less likely to answer.
>
> In the chan_sip configuration there is an option "notifyringing":
>
> notifyringing
>
> *notifyringing* enables or disables notifications for the RINGING state
> when an extension is already INUSE. Only affects subscriptions using the
> *dialog-info* event package. Option can be configured in the general
> section only. It cannot be set per-peer.
>
> As the doc says this only applies to dialog-info style NOTIFY, not the
> pidf+xml format my phones use.
>
> Here is a patch that makes notifyringing work for pidf+xml.
>
> Generalising it for other formats is left as an exercise for the reader.
>
> Of course chan_sip is obsolete.  How might this be done for chan_pjsip?
> Parts of the code are similar, but the layering is vastly different.  How
> could the ast_sip_presence_exten_state_to_str function in
> res/res_pjsip/presence_xml.c get at the pjsip configuration?
>
You wouldn't be able to access such information from
ast_sip_presence_exten_state_to_str, that function is strictly for taking
in instructions/data and producing the output. The user of it would need to
pass in a value to turn on this new behavior. From that level the
ast_sip_exten_state_data structure can optionally have a subscription,
which itself has the endpoint that was used to establish the subscription.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20200610/aa5c13b6/attachment.html>

On 10/06/2020 15:40, Joshua C. Colp wrote:
>
> You wouldn't be able to access such information from 
> ast_sip_presence_exten_state_to_str, that function is strictly for 
> taking in instructions/data and producing the output. The user of it 
> would need to pass in a value to turn on this new behavior. From that 
> level the ast_sip_exten_state_data structure can optionally have a 
> subscription, which itself has the endpoint that was used to establish 
> the subscription.
Ok, I'll look at that when I get around to moving to chan_pjsip. I'm 
very slow at changing working configurations.  :)