Subject: Re: [dispatch] draft-procter-dispatch-outbound-discovery-01

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 15 Nov 2014 07:59:22 +0000

Greetings,

The majority of SIP deployments, measured in SIP end points, are attached to managed (operator) carrier networks, outbound-discovery cannot ignore that segment of the user community.

Please explain to me how the "open internet" use case is being ignored. 

Thank you,

Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Standards and Industry Alliances
[email-masked]
+1-609-903-3360

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
Sent: Friday, November 14, 2014 6:44 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [dispatch] draft-procter-dispatch-outbound-discovery-01

2014-11-15 0:34 GMT+01:00 Michael Hammer <[email-masked]>:
> Well, pretty much all networks have walls.

AFAIK I don't have to pay more for accessing a website in San
Francisco than in my city or country.

> BTW, did you read the IAB "stop bashing service providers" memo?

No, and I don't find it. Anyhow, maybe you mean "stop bashing
old-fashion telephony providers (those who still charge for items such
as call setup) and provide access to the network (Internet) in which
the real service providers are placed".

-- 
Iñaki Baz Castillo
<[email-masked]>

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 16 Nov 2014 21:07:11 +0100

I think discussion is way out of scope for this draft. Which type of organization that uses the outbound discovery
is not part of the document, it was only part of a comment.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 17 Nov 2014 01:43:40 +0100

> The majority of SIP deployments, measured in SIP end points, are attached to managed (operator) carrier networks, outbound-discovery cannot ignore that segment of the user community.

Hi, I've implemented both Outbound and GRUU in my environments (pure
Internet, no operators/PSTN) and used them for years. If a new
addition or feature (like the one being discussed in this thread)
comes to Outbound, and given that the "I" in IETF means "Internet"
(rather than "IP"), I hope that such a feature is designed with a
neutral vision in mind, rather than focusing it on no-Internet
networks/users/consumers.

It is just that. I'm sorry if I sounded rude.

> Please explain to me how the "open internet" use case is being ignored.

Well, when I read "To me that implies two separate network operators"
I don't think that pure Internet usage is being considered at all. I'd
be happy if I was wrong.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 17 Nov 2014 01:57:39 +0100

> is not part of the document, it was only part of a comment.

If I was a SIP provider around the entire world I would like to
provide my users with a common URI(s) so that, by means of the new
feature being discussed here, they connect transparently to the
Outbound proxy closest to them.

NAPTR usage in SIP takes the user's identity domain as input. This is,
sip:[email-masked] will query a DNS NAPTR for atlanta.com, and
retrieve a list of SRV records. Here there is no room for the provider
to select specific SRV records to provide Alice with, so indeed
another approach is required.

DHCP based solutions are "operator solutions" so I don't like them
(because they are not valid for pure Internet users in which the SIP
service is not provided by the Internet provider).

BTW, which is the aim of this feature? To auto-discover via DNS a list
of Outbound proxies for a given configuration domain? or to also
provide the "best" Outbound proxy given the geolocation of the user?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 17 Nov 2014 07:29:37 +0100

> provide the "best" Outbound proxy given the geolocation of the user?

So far geolocation has been out of the scope.

From my point of view, the goal is to be able to find a set of
SIP Outbound edge proxys based on the users configured
SIP domain or the configured outbound proxy name. By using
NAPTR + SRV the admin of the service can set up two or more
lists of servers that the user should use to find the edge proxys.
By having two or more lists the admin can avoid that the user
ends up in the same server using two protocols or the same
data center.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 17 Nov 2014 07:44:03 +0100

> I don't think that pure Internet usage is being considered at all. I'd

I think the word "operators" was significant here. The way I parsed Keith's
words was that the discovery of a set of outbound proxys may be depending
not only on the service network (the SIP domain) but also on the network
you are connected to. It was important input to me. We have an internet
with connected islands that have very broken networks. The work in TRAM
has been focusing a lot on solving this, and it has impact on WebRTC as
well. There's a draft now discussing whether to prioritize a TURN server
provided by the local network or one provided by the application.

We may end up in situations like this in regards to locating SIP outbound
servers as well. I think you overreacted this time Iñaki. It was good feedback
that at least forced me to rethink a bit.

We later came to the conclusion that the document Michael is working on
focuses on services provided by the entity that hosts the domain. If we want
and see a need to work on network-provided outbound proxys we can start 
writing another document.

/O

---

From: Michael Procter <[email-masked]>
Date: Mon, 17 Nov 2014 20:28:50 +0000

Hi Iñaki,

> provide the "best" Outbound proxy given the geolocation of the user?

The first - to auto-discover via DNS a list of outbound proxies
suitable for use when registering against a specific domain.

Geolocation is interesting, but isn't really my intended scope.  My
goal is only to define a simple way to make RFC5626 more commonly used
by removing the need for explicit configuration of the
outbound-proxy-set.

Best regards,

Michael