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

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 9 Nov 2014 18:41:05 +0100

Hello,

I do think this work is important.

But I don't think the current proposal fits my requirement.

For me, it's important that the SIP outbound proxys used are in different networks. I need to be able to 
force a client to choose between two or more sets of proxys in different locations so they end up
with one server in one data center and another server somewhere else.

If I just have one SRV name, I don't see how I can make this happen. With two SRV names, it
can happen - but we can have a need for more. SIP outbounds says that we need a minimum
of two flows.

I think we may need a NAPTR solution that ends up with a set of SRV names that you pick
one each from. All SRV lists have their own failover rules that I as a manager of my service
set up and publish to make sure that UAs have connections to different networks/servers/
datacenters or planets.

I think this draft should be dispatched to sipcore and dealt with in that group.

/O

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 9 Nov 2014 17:50:03 +0000

I'd note that if I tried to apply your requirement to IMS, that would probably end up having to be two separate discovery actions, one for each network.

So basically what I think I am saying is that the solution for your problem depends on the relationship between the operator of the registrar and the operator(s) of each of the edge proxies. 

If you perform the edge proxy discovery directly with the registrar operator, then you need only one action. If the edge proxy discovery is supported by the edge proxy operators, then you need separate actions if there are two separate edge proxy operators.

Regards

Keith

> -----Original Message-----
> From: dispatch [mailto:[email-masked]] On Behalf 
> Of Olle E. Johansson
> Sent: 09 November 2014 17:41
> To: [email-masked]
> Subject: [dispatch] draft-procter-dispatch-outbound-discovery-01
> 
> Hello,
> 
> For me, it's important that the SIP outbound proxys used are 
> in different networks. I need to be able to force a client to 
> choose between two or more sets of proxys in different 
> locations so they end up with one server in one data center 
> and another server somewhere else.
> 
> If I just have one SRV name, I don't see how I can make this 
> happen. With two SRV names, it can happen - but we can have a 
> need for more. SIP outbounds says that we need a minimum of two flows.
> 
> I think we may need a NAPTR solution that ends up with a set 
> of SRV names that you pick one each from. All SRV lists have 
> their own failover rules that I as a manager of my service 
> set up and publish to make sure that UAs have connections to 
> different networks/servers/ datacenters or planets.
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

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

> So basically what I think I am saying is that the solution for your problem depends on the relationship between the operator of the registrar and the operator(s) of each of the edge proxies. 
Ok, this is similar to Turn discovery then. Did not think of that use case. So we may need to start
lookup from DHCP options - domain - and if that doesn't exist, the SIP domain.

But I fail to see how we can handle a case of two different operators of edge proxys - can you describe this a bit more?

> If you perform the edge proxy discovery directly with the registrar operator, then you need only one action. If the edge proxy discovery is supported by the edge proxy operators, then you need sepa…

Thanks for your feedback. Do you agree that we need to continue this work, and if so - should that happen in sipcore?

/O

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 10 Nov 2014 17:06:11 +0000

I understood it was your requirement for two separate networks

"For me, it's important that the SIP outbound proxys used are in different networks."

To me that implies two separate network operators. If that is not what you meant, can you explain more clearly.

Keith

> From: Olle E. Johansson [mailto:[email-masked]] 
> Sent: 10 November 2014 10:07
> To: DRAGE, Keith (Keith)
> Cc: Olle E Johansson; [email-masked]
> Subject: Re: [dispatch] draft-procter-dispatch-outbound-discovery-01
> 
> 
> > I'd note that if I tried to apply your requirement to IMS, 
> that would probably end up having to be two separate 
> discovery actions, one for each network.
> > 
> > So basically what I think I am saying is that the solution 
> for your problem depends on the relationship between the 
> operator of the registrar and the operator(s) of each of the 
> edge proxies. 
> Ok, this is similar to Turn discovery then. Did not think of 
> that use case. So we may need to start lookup from DHCP 
> options - domain - and if that doesn't exist, the SIP domain.
> 
> But I fail to see how we can handle a case of two different 
> operators of edge proxys - can you describe this a bit more?
> 
> > 
> > If you perform the edge proxy discovery directly with the 
> registrar operator, then you need only one action. If the 
> edge proxy discovery is supported by the edge proxy 
> operators, then you need separate actions if there are two 
> separate edge proxy operators.
> 
> Thanks for your feedback. Do you agree that we need to 
> continue this work, and if so - should that happen in sipcore?
> 
> /O
> 
> > 
> > 
> > Regards
> > 
> > Keith
> > 
> >> From: dispatch [mailto:[email-masked]] On 
> Behalf Of Olle 
> >> E. Johansson
> >> For me, it's important that the SIP outbound proxys used are in 
> >> different networks. I need to be able to force a client to choose 
> >> between two or more sets of proxys in different locations 
> so they end 
> >> up with one server in one data center and another server somewhere 
> >> else.
> >> 
> >> If I just have one SRV name, I don't see how I can make 
> this happen. 
> >> With two SRV names, it can happen - but we can have a need 
> for more. 
> >> SIP outbounds says that we need a minimum of two flows.
> >> 
> >> I think we may need a NAPTR solution that ends up with a 
> set of SRV 
> >> names that you pick one each from. All SRV lists have their own 
> >> failover rules that I as a manager of my service set up 
> and publish 
> >> to make sure that UAs have connections to different 
> networks/servers/ 
> >> datacenters or planets.
> >> 
> >> I think this draft should be dispatched to sipcore and 
> dealt with in 
> >> that group.
> >> 
> >> /O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 10 Nov 2014 18:44:04 +0100

> To me that implies two separate network operators. If that is not what you meant, can you explain more clearly.
It could be two different BGP AS domains... But still my servers, just hosted in various places.
I may want two different IP routes used, so that all flows doesn't end up on the same fiber to
the same datacenter.

/O

---

From: Simon Perreault <[email-masked]>
Date: Mon, 10 Nov 2014 09:10:16 -1000

> I may want two different IP routes used, so that all flows doesn't end up

+1

I have interest in this use case too: one SIP operator, different
datacenters.

Simon

---

From: Michael Procter <[email-masked]>
Date: Tue, 11 Nov 2014 07:22:43 +0000

Hi Olle,

Sorry for the delay in responding.  Comments inline:

> can happen - but we can have a need for more. SIP outbounds says that we need a minimum

I don't know exactly what you mean here.  Do you mean two (or more)
targets for a particular SRV answer?  If so, that is exactly how the
draft currently operates.  If you mean that you want to perform two
(or more) SRV queries for different names, then that is indeed not
addressed by the current draft.

> set up and publish to make sure that UAs have connections to different networks/servers/

*If* we need a NAPTR-based solution, I would prefer it to resolve to a
set of URIs which can be used as the outbound-proxy-set, rather than a
set of SRV records.  We could define an RFC4848-based lookup to
simplify it, but I don't know if a NAPTR-based approach would get
implemented by UA vendors.

In the -00 version of my draft, there was a section listing a couple
of alternative approaches.  Section 5.1 in particular might be another
way to meet your use-case.  There are other variations that might be
considered too (e.g. return a 305 with a list of proxies?) but the
basic approach is to use SIP.  I removed this section as nobody
expressed any interest in anything other than the SRV-based approach!

In a later mail, you discuss the possibility of starting from DHCP
options.  That sounds like it wouldn't meet my use-cases, but might be
more appropriately addressed by the config-framework.

Regards,

Michael

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 11 Nov 2014 10:47:25 -0500

> From: "Olle E. Johansson" <[email-masked]>

+1

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 12 Nov 2014 09:04:15 +0100

> addressed by the current draft.
As stated in a separate thread, I want to make sure that UAs select from two
different SRV entries in order to be able to make sure a UA doesn't end up
with two flows to the same datacenter or the same server, just different ports.

> set of SRV records.  
The URIs will be resolved to SRV anyway, right. 

> We could define an RFC4848-based lookup to
We don't know if anything will be implemented by UA vendors and developers, we
can only try to push them forward. If the upside is good enough, I think
there will be requirements from customers to support this. 

It's either ONE naptr, that can be in the SIP domain, so we don't need
another configuration item. Or it can be two SRV names which means
we need to modify provisioning of the phones. There will be work
regardless of solution.

> expressed any interest in anything other than the SRV-based approach!
For me DNS-based control is the natural way to go, which is why I
focused on that... :-)

> more appropriately addressed by the config-framework.

II was just brainstorming based on Keiths feedback.  Using that kind
of discovery of outbound servers may be out of scope for this document.

/O

---

From: Michael Procter <[email-masked]>
Date: Fri, 14 Nov 2014 15:02:05 +0000

Hi Olle,

> The URIs will be resolved to SRV anyway, right.

I've been thinking about this approach a little more, and I am
starting to think you might be right!  To see what it would look like,
I have just written a short draft
(draft-procter-dispatch-outbound-unaptr-00), and it is shorter and
cleaner to specify.  The implementation doesn't look very hard either,
which is nice.  Let me know what you think.

As soon as the chairs agree to dispatch it to sipcore, we can continue
to pore over the details there and see which approach seems to be the
best fit.

Michael

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 15 Nov 2014 00:06:31 +0100

2014-11-10 18:06 GMT+01:00 DRAGE, Keith (Keith)
<[email-masked]>:
> To me that implies two separate network operators.

I'm sorry but, why should we assume "operators world" at all? May we
please assume "just pure Internet" instead of operators and their
"roaming business" relationship?

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

---

From: Michael Hammer <[email-masked]>
Date: Fri, 14 Nov 2014 23:14:34 +0000

Ummm...

Why ignore the biggest users of the IETF specifications?

________________________________
Michael Hammer
Principal Engineer
[email-masked]
Mobile: +1 408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

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

> To me that implies two separate network operators.

I'm sorry but, why should we assume "operators world" at all? May we please assume "just pure Internet" instead of operators and their "roaming business" relationship?

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 15 Nov 2014 00:27:05 +0100

> Why ignore the biggest users of the IETF specifications?

Because unfortunately that (the telco/operators pollution and specs
like SIMPLE) are the reason why nobody in the Internet wants SIP stuff
at all, and instead of thinking in the real Internet usage we are
stuck into walled gardens and no-added-value "telephony" poor quality
audio calls.

And because IETF means "Internet Engineering Task Force" and AFAIK
"Internet != Walled Gardens".

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

---

From: Michael Hammer <[email-masked]>
Date: Fri, 14 Nov 2014 23:34:34 +0000

Well, pretty much all networks have walls.

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

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

> Why ignore the biggest users of the IETF specifications?

Because unfortunately that (the telco/operators pollution and specs like SIMPLE) are the reason why nobody in the Internet wants SIP stuff at all, and instead of thinking in the real Internet usage we are stuck into walled gardens and no-added-value "telephony" poor quality audio calls.

And because IETF means "Internet Engineering Task Force" and AFAIK "Internet != Walled Gardens".

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 15 Nov 2014 00:44:00 +0100

> 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]>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 15 Nov 2014 02:05:49 +0000

By all means use whatever terminology you like.

When the socialist revolution ultimately comes you may well end up being its president, but until then, some of us have to work on real world cost models, because ultimately, they pay our wages.

Regards

Keith 

> Sent: 14 November 2014 23:07
> To: DRAGE, Keith (Keith)
> Cc: Olle E. Johansson; [email-masked]
> I'm sorry but, why should we assume "operators world" at all? 
> May we please assume "just pure Internet" instead of 
> operators and their "roaming business" relationship?
> 
> 
> --
> Iñaki Baz Castillo
> <[email-masked]>
>

---

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

> which is nice.  Let me know what you think.
I think it's good.

In my view, the names in the first u-NAPTR lookup needs to be DNS names,
not SIP uris. These should be used for RFC 3263 lookup in order to
make it simple. By doing that, I can setup outbound proxys for TLS,
TCP and UDP and put them in the order I want. If there are
no NAPTR records, we go directly to SRV for that name.

Thank you for the acknowledgement, but please check the spelling
of my name :-)

Cheers,
/O

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 17 Nov 2014 13:27:00 -0500

> From: Michael Procter <[email-masked]>

> which is nice.  Let me know what you think.

I assume that you intend (though you didn't write it) that the UA
should maintain one connection to one of the targets derived from the
URI in one of the NAPTR records, a second connection to one of the
targets derived from the URI in a *different* NAPTR record, etc.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 17 Nov 2014 13:34:56 -0500

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

> "roaming business" relationship?

It is a sign of a robust and highly usable protocol that it works well
in many different types of situation.  If a protocol works well only
in certain specific deployment situations, it is probably not a good
solution and will be vulnerable to future changes in Internet
configuration and operation.

In our case, we want the solution to work smoothly in a "globally
flat" Internet and in "walled garden" situations, as well as the
environment that is often encountered:  a large, "globally flat" part
of the Internet connected to various enterprise networks which are
isolated to varying degrees by firewalls/NATs, as well as connected to
tightly managed service provider networks.

Dale

---

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

Hi Olle,

> no NAPTR records, we go directly to SRV for that name.

The main advantage of getting URIs rather than DNS names is that the
URIs are directly usable in the outbound-proxy-set.  That is to say,
this draft simply becomes a way to determine the configuration of a UA
rather than an alternative way to resolve the first hop.  I agree that
using URIs means another stage in the lookup, but in my mind, the
separation of concerns is worth the extra lookup.  You will still have
complete flexibility to define TLS/TCP/UDP proxies in whatever order
you wish.

> Thank you for the acknowledgement, but please check the spelling

Many apologies!  I have updated my version so it is corrected in a later issue.

Best regards,

Michael

---

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

Hi Dale,

> targets derived from the URI in a *different* NAPTR record, etc.

Yes, that's right.  I wrote that:
   A UA may use as many of these as it supports in preference
   order as the outbound-proxy-set.

I didn't mention that the UA generally maintains a connection to each
target in the outbound-proxy-set as that part is already defined in
RFC5626.

Best regards,

Michael

---

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

> complete flexibility to define TLS/TCP/UDP proxies in whatever order
How do you provide that kind of flexibility for a URI?

Do you mean that we go from URI to NAPTR? 

(Let's assume that sips: is gone, extinct and never existed)

Maybe we're on to something :-)

/O

---

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

> Maybe we're on to something :-)

Yes.  RFC5626 says:

   The client needs to perform normal [RFC3263] SIP DNS resolution on
   the URI from the outbound-proxy-set to pick a transport.

But this is just restating the normal behaviour when you have a
pre-loaded route.  The outbound-proxy essentially becomes the top-most
route header and so you resolve the next hop in the usual RFC3263
manner.  This is spelt out in more detail in RFC5626 Section 4.2.1,
2nd para:

   For each outbound proxy URI in the set, the User Agent Client (UAC)
   SHOULD send a REGISTER request using this URI as the default outbound
   proxy. [...] Forming the route set for the request is
   outside the scope of this document, but typically results in sending
   the REGISTER such that the topmost Route header field contains a
   loose route to the outbound proxy URI.

Best regards,

Michael

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 18 Nov 2014 07:54:05 +0100

>   loose route to the outbound proxy URI.
THank you for the clarification - this looks good.

The only thing that bugs me is the difference in syntax between this NAPTR
and the RFC 3263 NAPTR that has an empty regex. I understand that that 
type is different and has to have a SRV record.

How do we handle the priorities of the NAPTR entry?

/O

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 18 Nov 2014 11:29:09 -0500

>    order as the outbound-proxy-set.

Ah, I overlooked that sentence.

> separation of concerns is worth the extra lookup.

This system also has the conceptual advantage that the multiplexing
regarding "multiple paths to edge proxies" is represented in a
different way than the usual SIP "multiple paths to equivalent
targets".  That is, we don't have to have a different semantic for DNS
SRV records in this situation than we normally have.

An advantage of having the process produce a list of URIs (rather than
just domain names) is that URIs can have port numbers and other
decorations (even user and password!).

Dale

---

From: Michael Procter <[email-masked]>
Date: Tue, 18 Nov 2014 17:23:18 +0000

> type is different and has to have a SRV record.

This is a consequence of using RFC4848 as the basis of the mechanism.
The data has to be in the REGEXP field as the REPLACEMENT field can
only contain valid domain names and I want to use URIs.  RFC4848
section 2.2 defines a minimal syntax for the REGEXP field to avoid UAs
needing to implement full regular expression support.

Whilst a NAPTR record has both REGEXP and REPLACEMENT fields, only one
can be used.  As RFC3403 states in the last paragraph of section 4.1
concerning the REPLACEMENT field:

   This field and the REGEXP field together make up the Substitution
   Expression in the DDDS Algorithm.  It is simply a historical
   optimization specifically for DNS compression that this field
   exists.  The fields are also mutually exclusive.  If a record is
   returned that has values for both fields then it is considered to
   be in error and SHOULD be either ignored or an error returned.

> How do we handle the priorities of the NAPTR entry?

The priority value is encoded in the NAPTR preference field.  I have
suggested that a UA uses the URIs to populate its outbound-proxy-set
in preference order.  If the UA supports only two members in the
o-p-s, it uses the first two (lowest preferences).  If it supports 4
(recommended in RFC5626), it uses the first four, again in preference
order.

Best regards,

Michael

---

From: Michael Procter <[email-masked]>
Date: Tue, 18 Nov 2014 17:23:23 +0000

> SRV records in this situation than we normally have.

That is true.  Once I took the time to think through the consequences
of Olle's suggestion, I came to the conclusion that it makes a lot of
sense to use this approach.  It avoids overloading SRV records as you
say, and by generating URIs, it maps more cleanly to the problem of
only providing the outbound-proxy-set.

> decorations (even user and password!).

Yes.  There are lots of fun things that we can do with this mechanism!

Best regards,

Michael

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 19 Nov 2014 17:33:46 +0000

> only providing the outbound-proxy-set.
I do agree. Let's get this dispatched!

> Yes.  There are lots of fun things that we can do with this mechanism!

Hrrmpf. I don't include "password in DNS" in my set of "fun things" ;-)

/O

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 20 Nov 2014 18:37:26 -0500

> (recommended in RFC5626), it uses the first four, again in preference

And conversely, we should specify that all the NAPTRs have the same
"order" field.  (Or perhaps fix the "order" field value?)  Given that
RFC 2915 is particularly strict that the resolver should consider only
NAPTRs with one "order" value:

   Order
      A 16-bit unsigned integer specifying the order in which the NAPTR
      records MUST be processed to ensure the correct ordering of
      rules.  Low numbers are processed before high numbers, and once a
      NAPTR is found whose rule "matches" the target, the client MUST
      NOT consider any NAPTRs with a higher value for order (except as
      noted below for the Flags field).

> Hrrmpf. I don't include "password in DNS" in my set of "fun things" ;-)

That's a point.

Dale