[asterisk-dev] Possible change to the AMI PJSIPShowRegistrationsInbound command

[Dan Jenkins]

On Tue, Dec 6, 2016 at 2:43 PM, George Joseph <gjoseph at digium.com> wrote:

> We just discovered that the PJSIPShowRegistrationsInbound command really
> only dumps all aors regardless of whether there's an inbound registration
> associated with it or not.  Fixing this would mean a change to what this
> command returns so I'm trying to get some feedback.  There are 2 solution
> alternatives...
>
> 1.  We could replace the current InboundRegistrationDetail event (which
> isn't even registered) with a ContactStatusDetail event.  Obviously this is
> a change for anyone who uses this command.
>
> 2.  We could send a ContactStatusDetail event along with the existing
> InboundRegistrationDetail event.  This would double the number of events
> sent and therefore increase the total data sent.
>
> Honestly I'm not sure how this command was ever useful to anybody so I'm
> leaning towards option 1 but we need feedback.
>
> This would be a change to 13, 14 and master.
>
>
> --
> George Joseph
> Digium, Inc. | Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>

I'd go with Option 1 - although it feels wrong breaking something
(regardless as to whether it was already broken) within a minor/patch
release.

In theory people should be reading release notes but I fall foul of not
reading release notes for breakages within a minor/patch update - because
in theory it shouldn't break anything... But we all know this does indeed
happen. I would argue the current behaviour is broken and so you are fixing
the broken behaviour - if people are relying on the data in this command
then they're relying on incorrect data anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20161206/64856cc5/attachment.html>