Subject: [dispatch] draft-rosenberg-dispatch-cloudsip-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 5 Mar 2021 17:17:02 +0000

I wanted to call attention to this draft:
https://www.ietf.org/archive/id/draft-rosenberg-dispatch-cloudsip-00.txt

Basically, the draft proposes some new mechanisms to facilitate building SIP-based systems which can avoid call drops in the face of complete failures of B2BUAs which hold call state, and to do so in ways that are amenable to cloud deployment (namely, elastically autoscaling clusters of a large number of b2buas).

Feedback is welcome, and we're especially interested in finding folks that would be willing to prototype it with us.

Thx,
Jonathan R.

--
Jonathan Rosenberg, Ph.D.
mailto:[email-masked]
http://www.jdrosen.net/

________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential information of Five9 and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Five9 and/or its affiliated entities.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Mar 2021 10:01:52 -0500

Hi Jonathan!

> Feedback is welcome, and we're especially interested in finding folks that would be willing to prototype it with us.

A thought from a quick first read:

Couldn't you use DNS to identify the existence and address of the cloud 
source server? Then this all becomes part of resolving the next hop when 
first setting up the call, and doesn't require special configuration of 
the calling server.

	Thanks,
	Paul

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 9 Mar 2021 14:35:52 +0000

Thanks Paul for the comments!

To be clear - are you suggesting we don't need the protocol to push from the source to the sync? Or rather, that we can utilize discovery to allowing the calling server to find the config server, eliminating the need for the initial configuration of a URL?

I thought about adding some kind of auto-discovery, but in all cases there needs to be initial configuration in the calling server, when the SIP trunk is created between the calling server and the cluster itself. There will already be a bunch of config in that. Whether you add a DNS name for the cloud SIP trunk, or an HTTPS URI, seemed half a dozen on one hand, 6 on the other.

Thx,
Jonathan R.

-----Original Message-----
From: dispatch <[email-masked]> On Behalf Of Paul Kyzivat
Sent: Monday, March 8, 2021 10:02 AM
To: [email-masked]
Subject: Re: [dispatch] draft-rosenberg-dispatch-cloudsip-00.txt

Hi Jonathan!

Couldn't you use DNS to identify the existence and address of the cloud source server? Then this all becomes part of resolving the next hop when first setting up the call, and doesn't require special configuration of the calling server.

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 9 Mar 2021 14:10:54 -0500

> To be clear - are you suggesting we don't need the protocol to push from the source to the sync? Or rather, that we can utilize discovery to allowing the calling server to find the config server, e…

The latter.

> I thought about adding some kind of auto-discovery, but in all cases there needs to be initial configuration in the calling server, when the SIP trunk is created between the calling server and the…

Why must there be any preconfiguration in the calling server? Can't it 
discover it all by resolving the url to the next hop? Or is the route to 
the next hop being injected by the calling server, so *that* must be 
configured into it?

	Thanks,
	Paul