Automatic SIP trunking And Peering (ASAP) Working Group ======================================================= CHAIRS: Jean Mahoney Gonzalo Salgueiro IETF 110 AGENDA Monday, March 8, 2021 08:00 - 10:00 US Pacific Time Session III, Room 1 IETF 110 Info: https://www.ietf.org/how/meetings/110/ Meeting URL: https://gce.conf.meetecho.com/conference/?group=asap Etherpad: https://codimd.ietf.org/notes-ietf-110-asap ------------------------------------------------- 1. Note Well, Note Takers, Agenda Bashing, Draft status - (Chairs, 10 min) 2. Automatic Peering for SIP Trunks (Kaustubh Inamdar, Sreekanth Narayanan, 40 min) https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-peer 3. Wrapup and Next Steps (Chairs, 10 min) ------------------------------------------------- 1. Chair Items ~ Note well ~ Agenda bash ~ Status update; no real list activity, no adoption of new drafts ~ Gonzalo Salgueiro to act as Jabber scribe ~ Thanks to Marc Petit-Huguenin and Kaustubh Inamdar for taking notes 2. Automatic Peering for SIP Trunks (draft-kinamdar-dispatch-sip-auto-peer) ~ Draft authors provided overview, status and version history of current draft ~ Chairs took poll of who had read draft. Many people who responded had read it. Jean Mahoney: Poll (Raise of Hands) to adopt draft as WG item. Jon Peterson: This seems to be the only candidate for adoption. Jean Mahoney: Yes, that is the case unless there is there is a competing draft to consider. ~There was strong support in the meeting for adopting the draft. Kaustubh Inamdar: STIR is an important component of enterprise to service provider SIP trunking. However, there are facets of STIR yet to be finalised such as delegate certificates and Rich Call Data. Marc Petit-Huguenin: While STIR might have still have work to be done, draft can include STIR and can be extended as needed later. Kaustubh Inamdar: Agree with Marc. Will look at the best way to go about this. Jonathan Rosenberg: Supportive of moving forward the draft. There is some overlap with my current draft about SIP trunk HA. Happy to collaborate on that. Feedback on the “numRange” parameter to perhaps move it out of scope as it could be hard for service providers to provide this information. Gonzalo Salgueiro: Is the overlap problematic or complementary? Jonathan Rosenberg: Mostly complementary, just needs to be reconciled. Gonzalo Salgueiro: would be helpful to keep an eye on this draft, Jonathan. Jonathan Rosenberg: I’ll send comments on the list. Likely need to bring some additional parameters from my draft to this one. Kaustubh Inamdar: Agree that it would be difficult for service providers to track the number range for each enterprise registered to a service provider. However, was thinking along the lines of making it an optional parameter. Jonathan Rosenberg : Keep it simple. Can extend it later if needed. Cullen Jennings: There is a difference between large deployments and small PBXs. Draft probably not clear about when exactly does the numRange make sense and when they is it optional. Also, let’s not put stuff in here that isn’t needed. Jon Peterson: How automatable are telephone numbers? Even if you get a range of 50 numbers there is some manual intervention required. There could be use cases where this could make sense, however, this isn’t like DHCP. Jonathan Rosenberg: Problem is not that there are too many, this could be an issue for even a single number. Some degree of manual effort required. For the service providers, even if a single number is allocated to an enterprise, it likely would be difficult for them to implement software to provide even this single number in response to a HTTPS GET. Cullen Jennings: There is one thing that the ITSP SBC does know - which SIP request to route over which customer/enterprise SIP trunk, hence it would know all the numbers. Probably need to talk about this. Jonathan Rosenberg: Trunkgroup definitions could be used too. Cullen Jennings: The draft probably talks about a different use case for which the numRange would be helpful and this aspect needs discussion. Sreekanth Narayanan: We observed that sometimes the enterprise does not send the right phone number. 3. Wrap-Up and Next Steps ~ Chairs will confirm decision to adopt the draft on the mailing list.