Re: [Asap] ASAP: Introduction & Way Forward

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

Hi Ram,
Thanks for your comments, please find my responses inline.


On 27/10/2020, 18:24, "Asap on behalf of Ram Mohan R (rmohanr)" <[e-mail] on behalf of rmohanr=[e-mail]> wrote:

    I just had a glance at some of the sections in the draft, did not read in depth though and here are some comments: 

    1) Section 3 3.  Reference Architecture defines SBC terminology, would it not be better to reference/re-use rfc5853 and / or rfc7092 terminology that already defines types of SBC/B2BUAs rather than creating new ones?
        Kaustubh: I don't think we introduce any new terminology here. "Edge Element" need not always be an SBC or a B2BUA, it could be a general purpose device that obtains the service provider capability set from the ITSP. A  
        Reference to RFC 5853/7092 could be added where we talk about SBCs/B2BUAs.

    2) In section 4

    >The enterprise network creates a well
    >formed HTTPS GET request to solicit the service provider capability set

     How often will this happen ? how will enterprise get updated config(if/when it changes on SP side) ?
 
     Kaustubh: Section 7 of the draft talks about this. 

    3)  >This workflow is based on HTTP version 1.1

     Is there a specific reason to restrict to HTTP 1.1 ?

     Kaustubh: The workflow described in this draft is based on HTTP 1.1 and as such ought to work with HTTP 2.0 as well. We will make the appropriate modifications to the text to convey this point.

    4)  In the section 9, 

     - 4.1)  would it be valuable to include SRV domain(for sip/sips service) in the peering capability response from ITSP ? for cases where enterprise edge SBC uses SRV lookup to resolve would be good to learn the SRV  of the SP domain via the peering config GET rather than requiring admin to configure/learn via other means.

     Kaustubh: We can add this in.

     - 4.2)  Also in section9 where you have included SRTP keying method (SDES / DTLS-SRTP) would it be useful to also include SRTP cipher suites the SP SBC side can allow to passthrough/support ?

   Kaustubh: We can add this in.

    5)  The current draft allows a way for enterprise SBC to learn SP side peering config, would there be a need/motivation for SP side also to learn enterprise side configs ? 
  
    Kaustubh: I don't see a situation wherein this would be needed.

    Regards,
    Ram

        From: Kaustubh Inamdar <[e-mail]>
        Date: Wednesday, 21 October 2020 at 23:05
        To: "[e-mail]" <[e-mail]>
        Cc: Murray Kucherawy <[e-mail]>, "Gonzalo Salgueiro (gsalguei)" <[e-mail]>
        Subject: Re: [Asap] ASAP: Introduction & Way Forward



        Apologies. I sent the previous email without the URL of the latest version of the draft:

        https://datatracker.ietf.org/doc/draft-kinamdar-dispatch-sip-auto-peer/

        Thanks,
        Kaustubh

        From: Kaustubh Inamdar <[e-mail]>
        Date: Wednesday, 21 October 2020 at 23:04
        To: "[e-mail]" <[e-mail]>
        Cc: Murray Kucherawy <[e-mail]>, "Gonzalo Salgueiro (gsalguei)" <[e-mail]>
        Subject: Re: [Asap] ASAP: Introduction & Way Forward



        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

    -- 
    Asap mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/asap