[OpenSIPS-Devel] [OpenSIPS/opensips] ff8994: SIP PN: Also match upstream Feature-Caps during PN...

[Liviu Chircu]

  Branch: refs/heads/feature/rfc-8599-sip-pn
  Home:   https://github.com/OpenSIPS/opensips
  Commit: ff8994efc68877fd0d2d3381e1a8fa628793b617
      https://github.com/OpenSIPS/opensips/commit/ff8994efc68877fd0d2d3381e1a8fa628793b617
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2020-05-06 (Wed, 06 May 2020)

  Changed paths:
    M lib/reg/pn.c

  Log Message:
  -----------
  SIP PN: Also match upstream Feature-Caps during PNS query


  Commit: 0c123df0e09ecc9b80af23e6aa9ae1bcfe43df86
      https://github.com/OpenSIPS/opensips/commit/0c123df0e09ecc9b80af23e6aa9ae1bcfe43df86
  Author: Liviu Chircu <liviu at opensips.org>
  Date:   2020-05-06 (Wed, 06 May 2020)

  Changed paths:
    M lib/reg/pn.c
    M lib/reg/pn.h
    M modules/mid_registrar/mid_registrar.c
    M modules/mid_registrar/mid_registrar.h
    M modules/mid_registrar/save.c
    M modules/registrar/reply.c

  Log Message:
  -----------
  SIP PN: Refine Feature-Caps hf building logic

The Feature-Caps content is not meant to be symmetrical for
upstream/downstream sides.  Some important ideas:

    * on downstream-forwarded REGISTER, we leak a _minimal_ amount of
      information.  For example, just that we support "apns" PNs and
      that the element MUST NOT send PNs anymore to it, e.g.:
         Feature-Caps: +sip.pns="apns"

    * on upstream-forwarded 200 OK which are not PN capability queries,
      we include _maximal_ amounts of information into the Feature-Caps,
      fully informing the UA of our supported parameters, e.g.:
         Feature-Caps: +sip.pns="apns";+sip.pnsreg="130";
                       +sip.pnspurr="3a0.94000.00001921"

Working for both registrar and mid-registrar...


Compare: https://github.com/OpenSIPS/opensips/compare/b5dea20467e7...0c123df0e09e