Re: [Asap] ASAP: Introduction & Way Forward

["Kaustubh Inamdar (kinamdar)" <[e-mail]>]

Hi,
We have gone ahead and added two new parameters to the capability set, namely:


  1.  A parameter using which a service provider can specify the DID number range allocated to an enterprise.
  2.  A parameter encapsulating the URL of a .pem encoded file containing the certificate chain of the service provider – this is useful for SIP over TLS between enterprise and service provider networks.

Happy to hear any thoughts/comments on the draft.

Thanks,
Kaustubh

From: Asap <[e-mail]> on behalf of "Sreekanth Narayanan (sreenara)" <sreenara=[e-mail]>
Date: Monday, 21 September 2020 at 22:35
To: "[e-mail]" <[e-mail]>
Cc: Cullen Jennings <[e-mail]>
Subject: Re: [Asap] ASAP: Introduction & Way Forward

Hi All,

Of the four high-level items listed in the previous email, below are considerations for two of them, namely:

  1.  Modifications to the existing capability set
  2.  Inclusion of a STIR specific section.
From the perspective to modifications to the capability set, we suggest an addition - namely the DID Range allocated by an Internet Telephony Service Provider (ITSP) to the enterprise. This DID range may be continuous or disparate. This parameter is useful for an enterprise in configuring dial plans on edge elements such as SBCs. Additionally, most service providers require the calling number presented by an enterprise network for outgoing calls to fall within the allocated DID range.

From the perspective of STIR, a section specific to secure telephony identity could include the following:

a.  Parameter indicating whether the ITSP is STIR/SHAKEN compliant: This parameter could allow the enterprise to determine whether it needs to run a STIR Verification Service (VS) to cryptographically determine whether or not the identity presented by the caller is legitimate. While a STIR compliant provider would have a locally running VS to decode the PASSporT and provide an attestion level of A B or C, the enterprise might want to repeat the exercise and determine how to handle the call based on local policy.

b.  Parameter indicating whether the ITSP supports Rich Call Data (RCD) PASSporTs: Going forward, enterprise networks would be able to sign PASSporTS that contain Rich Call Data (RCD) before presenting the INVITE to their service providers. In such situations, it would be useful for the enterprise to determine whether the service provider supports RCD PASSporTs. Additionally, some of the constructs required to obtain delegate certificates could also be included in the capability set. For example, the directory URL of the ACME server and the scope of delegate certificates an enterprise is authorized to obtain.

Additionally, there could be other considerations for STIR that might warrant discussion:

  1.  STIR OOB CPS hostname/IP for enterprise VS to pull PASSporTs
  2.  In case of CPS federation between service providers, the IP/hostname of the CPS for PASSporT placement for outbound calls from the enterprise.
We would be happy to hear any thoughts you'll have on the above parameters as well as the existing parameters in the capability set. If we have overlooked or missed anything in the list, we would want to close those gaps.

Regards
Sreekanth

________________________________
From: Sreekanth Narayanan (sreenara)
Sent: Wednesday, August 26, 2020 6:02 PM
To: [e-mail] <[e-mail]>
Cc: Cullen Jennings <[e-mail]>
Subject: ASAP: Introduction & Way Forward

Hi All,

Thank you for subscribing to the ASAP mailing list. For the benefit of folks that are new to this effort, below is a summary

---
With the advent of SIP trunking, enterprise networks are increasing peering with their service providers over SIP in favour of traditional interconnection methods such as ISDN circuits and analog lines. However, due to the large number of extensions to baseline SIP & RTP and other minor considerations (formatting of the calling number, for example) administrators spend several time cycles in coming up with a configuration block that allows enterprise networks to effectively peer with their service providers over SIP. The following draft (https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-peer-03) defines a parameter set (and a corresponding data model), which when populated by a service provider and which when communicated to an enterprise network provides the administrator sufficient information to configure SIP trunking with the service provider.
---

In order to get the draft referenced above to be formally adopted by the ASAP working group, the authors believe it would be helpful to engage in a discussion about the following so as make the draft representative of the largest possible chunk of considerations that arise/may arise(as related work matures) when deploying SIP trunking with telephony service providers.


  1.  Modifications to the capability set.
  2.  Inclusion of a STIR specific section
  3.  Inclusion of a section for certificate management
  4.  Using WebFinger as a mechanism for service discovery.

We would like to ideally have a separate discussion thread for each of the items listed above. This mail serves as a starting point for those who are new to ASAP and would like to get familiar with the idea. A subsequent mail will cover detailed notes about each of the aforementioned points. In the meantime, we would be happy to address any thoughts or objections that you'll might have.


Regards
Sreekanth