Subject: [sipcore] Happy Eyeballs for SIP

From: [email-masked] (Dale R. Worley)
Date: Mon, 12 Dec 2016 19:14:41 -0500

This is the start of getting the Happy Eyeballs for SIP work going in
the working group.

The authors (Olle Johansson, Gonzalo Salgueiro, Dale Worley) are working
with the following strategy (at this time):  The first tranche is the
case where (1) alternative addresses are provided by A and AAAA records
based on one host name, i.e., we are not considering multiple SRV
records, and (2) all of the targets use connection-oriented protocols.
This case is the closest to the Happy Eyeballs for HTTP work that has
already been done, though it has some additional requirements (in
particular, the fact that connections can be idle for a considerable
time, but at unpredictable times, the client wants to use the connection
in a soft-real-time way).

The current draft is named draft-worley-sip-he-connection-01.  (We'll be
revising the name.)

Our idea is to start with an exposition that is not too far beyond the
work for HTTP, so that the discussion remains manageable.  In later
stages, we will produce successive expansions until the entire SIP
operational space is covered.  The expansions can be done by any of
several methods:

- Produce successive RFCs, each of which incorporates the preceding RFC
  but extends it to additional operational space.  Thus, each RFC
  obsoletes and extends its predecessor, so that an implementer only has
  to read the current RFC of the sequence.  (This is the method that we
  prefer at present.)

- Produce successive drafts, each of which covers a larger operational
  space and progress the last one to an RFC.  This will slow the
  standardization of the earlier tranches of the work but reduce the
  overhead of formalizing the drafts as RFCs.

- Produce a series of RFCs, each of which updates the preceding RFCs.
  This seems like the least desirable strategy, as it requires an
  implementer to read several RFCs and collate their provisions.

Let the discussion begin, both on the work and on the plan for the work!

Dale

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 13 Dec 2016 11:45:22 +0000

RFC7984 => why not OPTIONS for testing without changing "status"
DNS SRV Records => not necessarily pointing to the same server's different IP Address families, could be multiple servers with each different address families => should be addressed by Happy-Eyeballs

Why only "connection oriented"? Fast /reliable/secure failover is another problem 

Please see inline for comments/questions.
 
Thanks,
Tolga

> -----Original Message-----
> From: sipcore [mailto:[email-masked]] On Behalf Of Dale R. Worley
> Sent: Monday, December 12, 2016 7:15 PM
> To: [email-masked]
> Subject: [sipcore] Happy Eyeballs for SIP
> 
> This is the start of getting the Happy Eyeballs for SIP work going in the
> working group.
> 
> with the following strategy (at this time):  The first tranche is the case where
> (1) alternative addresses are provided by A and AAAA records based on one
> host name, i.e., we are not considering multiple SRV records, and (2) all of
> the targets use connection-oriented protocols.
[TOLGA] 
i- Why only A/AAAA records? What about cases where a different SRV record is used for each supported address family? AFAIU this type of configuration is already mentioned in RFC7984. 
RFC3263 is a bit vague regarding what needs to be done if there are multiple SRV records:
   "If no NAPTR records are found, the client constructs SRV queries for
   those transport protocols it supports, and does a query for each."
Does this mean "for all transports for the selected -according to priority/weight- SRV Record" or "for all transport/SRV Record pairs".
I tend to think the former but RFC7984 seems to differ:
"For example, consider a server with DNS name example.com, with TCP
   transport specified.  The relevant SRV records for example.com are:

      _sip._tcp.example.com.  300 IN SRV 10 1 5060 sip-1.example.com.
      _sip._tcp.example.com.  300 IN SRV 20 1 5060 sip-2.example.com.

   The processing of [RFC2782] results in this ordered list of target
   domain names:

      sip-1.example.com
      sip-2.example.com"
Then it lists all addresses for both of the SRV Records. Granted, it mentions that addresses are not interleaved but nonetheless it assumes that a query is performed for both of the SRV Records. I am not sure what the right interpretation should be here but it is not well-defined to say the least. To me, it seems like RFC7984 should be updating RFC3263 normatively in this aspect as well -to promote the RFC7984 defined behavior-. And IMHO it would be up to the Happy-Eyeballs draft to define how addresses from multiple SRV Records should be used. Cases, where a dual-stack entity does not know whether IPv4/IPv6 is preferred and multiple SRV records are used for different address families on different servers should be covered as well.

ii- Why only for connection-oriented protocols? I think the generic problem happy-eyeballs addresses and what is targeted with draft-worley-sip-he-connection-01 are different. The former can be a building block for the latter but that shouldn't mean that it should be restricted by it IMHO. Is there any technical reason why happy-eyeballs is not applicable -by itself- for SIP over UDP?

> This case is the closest to the Happy Eyeballs for HTTP work that has already
> been done, though it has some additional requirements (in particular, the
> fact that connections can be idle for a considerable time, but at unpredictable
> times, the client wants to use the connection in a soft-real-time way).
> 
> Our idea is to start with an exposition that is not too far beyond the work for
> HTTP, so that the discussion remains manageable.  In later stages, we will
> produce successive expansions until the entire SIP operational space is
> covered.  The expansions can be done by any of several methods:
> 
[TOLGA] Please the second approach. It wouldn't significantly matter whether iterations of ideas/algorithms are captured in a series of RFCs/drafts in terms of adaptation. An RFC is supposed to be "complete" according to the best of our knowledge at a given time. So, I strongly would suggest to go with "multiple drafts" approach (Option-2).
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 13 Dec 2016 11:51:53 +0000

Please disregard everything before "Please see inline for comments/questions" :-)

Thanks,
Tolga

> From: sipcore [mailto:[email-masked]] On Behalf Of Asveren,
> Tolga
> Sent: Tuesday, December 13, 2016 6:45 AM
> To: Dale R. Worley <[email-masked]>; [email-masked]
> Subject: Re: [sipcore] Happy Eyeballs for SIP
> 
> DNS SRV Records => not necessarily pointing to the same server's different
> IP Address families, could be multiple servers with each different address
> families => should be addressed by Happy-Eyeballs
> 
> > The authors (Olle Johansson, Gonzalo Salgueiro, Dale Worley) are
> > working with the following strategy (at this time):  The first tranche
> > is the case where
> > (1) alternative addresses are provided by A and AAAA records based on
> > one host name, i.e., we are not considering multiple SRV records, and
> > (2) all of the targets use connection-oriented protocols.
> [TOLGA]
> i- Why only A/AAAA records? What about cases where a different SRV record
> is used for each supported address family? AFAIU this type of configuration is
> already mentioned in RFC7984.
> Does this mean "for all transports for the selected -according to
> priority/weight- SRV Record" or "for all transport/SRV Record pairs".
> Then it lists all addresses for both of the SRV Records. Granted, it mentions
> that addresses are not interleaved but nonetheless it assumes that a query is
> performed for both of the SRV Records. I am not sure what the right
> interpretation should be here but it is not well-defined to say the least. To
> me, it seems like RFC7984 should be updating RFC3263 normatively in this
> aspect as well -to promote the RFC7984 defined behavior-. And IMHO it
> would be up to the Happy-Eyeballs draft to define how addresses from
> multiple SRV Records should be used. Cases, where a dual-stack entity does
> not know whether IPv4/IPv6 is preferred and multiple SRV records are used
> for different address families on different servers should be covered as well.
> 
> ii- Why only for connection-oriented protocols? I think the generic problem
> happy-eyeballs addresses and what is targeted with draft-worley-sip-he-
> connection-01 are different. The former can be a building block for the latter
> but that shouldn't mean that it should be restricted by it IMHO. Is there any
> technical reason why happy-eyeballs is not applicable -by itself- for SIP over
> UDP?
> 
> > time, but at unpredictable times, the client wants to use the connection in
> a soft-real-time way).
> >
> > The current draft is named draft-worley-sip-he-connection-01.  (We'll
> > be revising the name.)
> >
> [TOLGA] Please the second approach. It wouldn't significantly matter
> whether iterations of ideas/algorithms are captured in a series of RFCs/drafts
> in terms of adaptation. An RFC is supposed to be "complete" according to the
> best of our knowledge at a given time. So, I strongly would suggest to go with
> "multiple drafts" approach (Option-2).
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Dec 2016 10:53:43 -0500

>   implementer to read several RFCs and collate their provisions.

How long do you imagine this process will take?

ISTM that (2) is the most desirable, unless it takes a very long time. 
If it say more than a year between extensions then *maybe* (1) or (3) 
would make sense.

Also, if you need operational experience with an earlier phase befor 
moving on then one of the stages approaches will be justified.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 13 Dec 2016 12:21:11 -0500

"Asveren, Tolga" <[email-masked]> writes:
>> working with the following strategy (at this time):  The first
>> tranche is the case where (1) alternative addresses are provided by A
>> and AAAA records based on one host name, i.e., we are not considering
>> multiple SRV records, and (2) all of the targets use
>> connection-oriented protocols.
>
> i- Why only A/AAAA records? What about cases where a different SRV
> record is used for each supported address family? AFAIU this type of
> configuration is already mentioned in RFC7984. 

Indeed, that configuration is mentioned in 7984, and was inserted into
7984 because it is such a common configuration.  However, we decided to
not handle SRV in this tranche because a comprehensive approach to SRV
is complicated and nobody has yet proposed a solution that promises to
meet the desiderata, viz.:

- achieve the Happy Eyeballs effect, that is, traffic will be very
  rarely delayed by unreachability of one or more of the targets

- achieve the specified effect of SRV, that is, among the set of targets
  which are reachable, over the long run, the traffic will be
  distributed among them according to the specified priorities and
  weights in the SRV records

> priority/weight- SRV Record" or "for all transport/SRV Record pairs".

Well, since the priorities/weights are extracted from the SRV records,
the priorities/weights cannot affect how the SRV records are queried
for.  My interpretation is "for each transport that the client supports
and that is permitted by the URI scheme and the 'transport' option of
the URI (if any), the client constructs an SRV query for the URI scheme,
the transport and the target domain name".  Of course, if there are
multiple SRV records for a scheme/transport/domain name combination, the
single query will return all of them.  Thus, a query for

>       _sip._tcp.example.com.  300 IN SRV 20 1 5060 sip-2.example.com.

Once all the SRV records are obtained, the priority/weight processing is
applied to them.

Although it is not specified in RFC 2782 (SRV records), the standard
practice seems to be that all of the SRV records obtained for all of the
protocols are considered as a single set for priority/weight processing,
which generates an ordered list of the target domain names of the SRV
records.  (Of course, in this example, that is not relevant, since both
of the SRV records are for TCP, and so are obtained by one SRV query,
while the UDP SRV query obtains no records.)

> Then it lists all addresses for both of the SRV Records. Granted, it
> mentions that addresses are not interleaved but nonetheless it assumes
> that a query is performed for both of the SRV Records.

Actually, one query was done, for _sip._tcp.example.com, and it returned
both records.

> I am not sure
> what the right interpretation should be here but it is not
> well-defined to say the least. To me, it seems like RFC7984 should be
> updating RFC3263 normatively in this aspect as well -to promote the
> RFC7984 defined behavior-. And IMHO it would be up to the
> Happy-Eyeballs draft to define how addresses from multiple SRV Records
> should be used. Cases, where a dual-stack entity does not know whether
> IPv4/IPv6 is preferred and multiple SRV records are used for different
> address families on different servers should be covered as well.

Can you give an example where the procedures of RFC 2782 aren't
sufficient to resolve this problem?

> ii- Why only for connection-oriented protocols? I think the generic
> problem happy-eyeballs addresses and what is targeted with
> draft-worley-sip-he-connection-01 are different. The former can be a
> building block for the latter but that shouldn't mean that it should
> be restricted by it IMHO. Is there any technical reason why
> happy-eyeballs is not applicable -by itself- for SIP over UDP?

The *concept* of Happy Eyeballs can, should, and will be applied to UDP,
but the *details* are going to be considerably different from the
details for TCP.  For the first tranche, we are attempting to stay near
what has been done for HTTP, so we are limiting the scope to
connection-oriented protocols.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 14 Dec 2016 11:14:58 -0500

[email-masked] (Dale R. Worley) writes:
> records.

Thinking about the issue again, I believe that I am incorrect here.  In
the one implementation I know deeply, if two transports are queried for,
the SRV records are first sorted based on their transport, then by their
SRV priority.  Either UDP is placed before TCP or vice-versa, depending
on the message length, more or less based on section 18.1.1 of RFC 3261
-- short messages prefer UDP and long ones prefer TCP.

Dale

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 14 Dec 2016 17:11:01 +0000

Inline...

Thanks,
Tolga

> From: Dale R. Worley [mailto:[email-masked]]
> Sent: Tuesday, December 13, 2016 12:21 PM
> To: Asveren, Tolga <[email-masked]>
> Cc: [email-masked]
> not handle SRV in this tranche because a comprehensive approach to SRV is
> complicated and nobody has yet proposed a solution that promises to meet
> the desiderata, viz.:
> 
[TOLGA] I understand that "perfect outcome" may be hard to describe -let alone to achieve- especially considering various deployment models/expectations. OTOH, I would think that allowing some freedom in terms of ordering could be all what needs to be mentioned in the specification, e.g. 
Rather than:
One ought to use the SRV records according to their weight/priority where eventually only one of them is the winner and is resolved
This:
One may resolve all/a sub-set of available SRV records by also considering IP Address Family and IP Address Family can be also considered for the order of the queries 

I can provide text/edit the document if we can reach a conclusion/consensus on this point.
> Well, since the priorities/weights are extracted from the SRV records, the
> priorities/weights cannot affect how the SRV records are queried for.  My
> interpretation is "for each transport that the client supports and that is
> permitted by the URI scheme and the 'transport' option of the URI (if any),
> the client constructs an SRV query for the URI scheme, the transport and the
> target domain name".  Of course, if there are multiple SRV records for a
> scheme/transport/domain name combination, the single query will return all
> of them.  Thus, a query for sip/TCP/example.com would return the two SRV
> records you quoted:
> 
> Although it is not specified in RFC 2782 (SRV records), the standard practice
> seems to be that all of the SRV records obtained for all of the protocols are
> considered as a single set for priority/weight processing, which generates an
> ordered list of the target domain names of the SRV records.  (Of course, in
> this example, that is not relevant, since both of the SRV records are for TCP,
> and so are obtained by one SRV query, while the UDP SRV query obtains no
> records.)
> 
> Can you give an example where the procedures of RFC 2782 aren't sufficient
> to resolve this problem?
[TOLGA]  "Usage Rules" section of RFC2782 seem to imply:
i- A list is prepared by querying all SRV records. Queries are performed by the priority/weight based ordering.
ii- And then there is "freedom" in terms of selecting the server to actually use.

I think i- is where some improvement could be useful in the context of happy-eyeballs. The IP Address Family can be used as a third parameter -in addition to priority/weight- when ordering DNS queries. Granted, one may argue that all queries can be performed in parallel but still some clarification text in the specification could be a good idea to highlight this and prevent any confusion.
> The *concept* of Happy Eyeballs can, should, and will be applied to UDP, but
> the *details* are going to be considerably different from the details for TCP.
> For the first tranche, we are attempting to stay near what has been done for
> HTTP, so we are limiting the scope to connection-oriented protocols.
[TOLGA] I think one issue was regarding the "probing" for UDP. With TCP, connection establishment provides information about the quality of the connection toward the server. Why not using OPTIONS for UDP? It wouldn't change the "SIP state" and wouldn't cause any distraction to end users/devices.

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 15 Dec 2016 14:16:24 -0500

"Asveren, Tolga" <[email-masked]> writes:
>> However, we decided to

> [TOLGA] I understand that "perfect outcome" may be hard to describe
> -let alone to achieve- especially considering various deployment
> models/expectations. OTOH, I would think that allowing some freedom in
> terms of ordering could be all what needs to be mentioned in the
> specification, e.g. 

> One ought to use the SRV records according to their weight/priority
> where eventually only one of them is the winner and is resolved

I'm not sure that "only one of [the SRV records] ... is resolved" is
correct.  If there are two SRV records and, for the one with the lowest
priority value, the address(es) for the target name cannot be contacted,
the client is required to attempt to contact the address(es) for the
target name of the other SRV record.

> One may resolve all/a sub-set of available SRV records by also
> considering IP Address Family and IP Address Family can be also
> considered for the order of the queries 
>

I suspect that allowing the client unlimited authority to reorder the
target addresses based on IP address family will allow behaviors that we
do not want to allow.  In particular, if the SRV records give one IP
address family over the other family, and the client can contact both
addresses, we want the client to respect that declared priority.  (This
is a variation on the example in RFC 7984.)

> i- A list is prepared by querying all SRV records. Queries are
> performed by the priority/weight based ordering.

> ii- And then there is "freedom" in terms of selecting the server to

The freedom allowed by RFC 2782 is limited.  Actually, the only
variation allowed in the order of contacting the addresses is due to the
use of random numbers in selecting between records of the same priority.
(section "The format of the SRV RR" item "Weight")

> I think i- is where some improvement could be useful in the context of
> happy-eyeballs. The IP Address Family can be used as a third parameter
> -in addition to priority/weight- when ordering DNS queries. Granted,
> one may argue that all queries can be performed in parallel but still
> some clarification text in the specification could be a good idea to
> highlight this and prevent any confusion.

Remember that only one DNS query is needed to obtain *all* the SRV
records for a particular domain name and transport.

> [TOLGA] I think one issue was regarding the "probing" for UDP. With
> TCP, connection establishment provides information about the quality
> of the connection toward the server. Why not using OPTIONS for UDP? It
> wouldn't change the "SIP state" and wouldn't cause any distraction to
> end users/devices.

Yes, that would work.  But as I said, UDP is not included in this
tranche.

Dale

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 15 Dec 2016 19:58:03 +0000

Trying to summarize:

i- It is fine to target connection-oriented transport protocols first but I hope that does not imply that UDP never will be covered. I personally would favor a single RFC for all transports -initial versions of the draft can address/focus on connection-oriented ones- but could survive with multiple specifications as well.
ii- I feel stronger about the need to address SRV records rather than limiting the solution to A/AAAA. Granted, an entity can do stupid things with the freedom of ordering of queries by also considering IP Address Family but that is a given with any new degree of freedom. It is a direct consequence thereof. Providing use cases/warnings about possible issues could address this concern in a satisfactory way IMHO.

Thanks,
Tolga

> Sent: Thursday, December 15, 2016 2:16 PM
> >> not handle SRV in this tranche because a comprehensive approach to
> >> SRV is complicated and nobody has yet proposed a solution that
> >> promises to meet the desiderata, viz.:
> >>
> I'm not sure that "only one of [the SRV records] ... is resolved" is correct.  If
> there are two SRV records and, for the one with the lowest priority value,
> the address(es) for the target name cannot be contacted, the client is
> required to attempt to contact the address(es) for the target name of the
> other SRV record.
> 
> > This:
> 
> I suspect that allowing the client unlimited authority to reorder the target
> addresses based on IP address family will allow behaviors that we do not
> want to allow.  In particular, if the SRV records give one IP address family
> over the other family, and the client can contact both addresses, we want
> the client to respect that declared priority.  (This is a variation on the example
> in RFC 7984.)
> 
> >> > I am not sure
> >> > well-defined to say the least. To me, it seems like RFC7984 should
> >> > be updating RFC3263 normatively in this aspect as well -to promote
> >> > the
> >> > Happy-Eyeballs draft to define how addresses from multiple SRV
> >> > Records should be used. Cases, where a dual-stack entity does not
> >> > know whether
> >> > IPv4/IPv6 is preferred and multiple SRV records are used for
> >> > different address families on different servers should be covered as
> well.
> >>
> The freedom allowed by RFC 2782 is limited.  Actually, the only variation
> allowed in the order of contacting the addresses is due to the use of random
> numbers in selecting between records of the same priority.
> >> The *concept* of Happy Eyeballs can, should, and will be applied to
> >> UDP, but the *details* are going to be considerably different from the
> details for TCP.
> >> For the first tranche, we are attempting to stay near what has been
> >> done for HTTP, so we are limiting the scope to connection-oriented
> protocols.
> 
> Yes, that would work.  But as I said, UDP is not included in this tranche.
> 
> Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 16 Dec 2016 09:50:42 +0100

> On 15 Dec 2016, at 20:58, Asveren, Tolga <[email-masked]> wrote:
> 
> Trying to summarize:
> 
At the last SIPcore IETF meeting we decided to split up the work in chewable bits. Separating connection oriented from the
much more complex connectionless area was one decision in order to make progress fast in the Connection oriented space.

> ii- I feel stronger about the need to address SRV records rather than limiting the solution to A/AAAA. Granted, an entity can do stupid things with the freedom of ordering of queries by also consid…
If there is a problem, we need to work on it, but I would like to suggest that we limit the scope for each doc to get
it faster through the process.

We have a lot of related problems to cover, like selection of interfaces when we have multiple interfaces.

In regards to the current draft for connection-oriented SIP flows, I am not happy about copying a lot of text from the Happy Eyeballs RFC into this doc. 

Happy Eyeballs is a  large solution space and the important part of the RFC is the requirements - the solutions vary. 
Copying text from that RFC could mean we copy stuff that is out of scope and already old compared with today’s implementations and 
that we by accident limit the solution space for SIP, which would be unfortunate. The SIP solution for setting up a connection is in no 
way different from other protocols and thus I think we will be better off and have a smoother path to publication by just pointing to the Happy Eyeballs
RFC than starting to copy parts without us authors having current implementation experience.

Let’s keep the connection-oriented draft short and sweet and just get it to publication and then dive heads down into
UDP. That’s an area where no work has been done before (as far as I know) and we will propably end up producing an outbound-light
or something else. 

The implementation I work with currently send a simple OPTIONs without SDP to test both address
families and then select based on our preferences and responses. We do prefer IPv6 in this case, as IPv4 is hiding
behind an ugly carrier grade nat. As this is a mobile app, registration and calls happen within a short time and no 
flows are kept for long. Desktop phones have flows that goes on for a very long time and network properties may
change during that time, so we need more regular discovery.

/O

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 16 Dec 2016 13:43:28 +0000

Inline...

Thanks,
Tolga

> From: Olle E. Johansson [mailto:[email-masked]]
> Sent: Friday, December 16, 2016 3:51 AM
> Cc: Olle E Johansson <[email-masked]>; Dale R. Worley
> <[email-masked]>; [email-masked]
> > i- It is fine to target connection-oriented transport protocols first but I hope
> that does not imply that UDP never will be covered. I personally would favor
> a single RFC for all transports -initial versions of the draft can address/focus
> on connection-oriented ones- but could survive with multiple specifications
> as well.
> At the last SIPcore IETF meeting we decided to split up the work in chewable
> bits. Separating connection oriented from the much more complex
> connectionless area was one decision in order to make progress fast in the
> Connection oriented space.
[TOLGA] Understood. As said before though, this could be achieved with a single RFC/progressive versions of drafts as well IMHO. OTOH, I wouldn’t cry much over having multiple RFCs either.  So, I guess this means "consensus reached".
> 
> 
> > ii- I feel stronger about the need to address SRV records rather than
> limiting the solution to A/AAAA. Granted, an entity can do stupid things with
> the freedom of ordering of queries by also considering IP Address Family but
> that is a given with any new degree of freedom. It is a direct consequence
> thereof. Providing use cases/warnings about possible issues could address
> this concern in a satisfactory way IMHO.
> If there is a problem, we need to work on it, but I would like to suggest that
> we limit the scope for each doc to get it faster through the process.
> 
[TOLGA] I think covering SRV records is critical. They are used widely in practice; for various reasons and in different models. I don’t think burying our head into sand would make this issue disappear. We may take a "practical" approach though. I think 90% of utility could be achieved by addressing 10% of complexity. Some extra freedom on ordering/selection of queries would go a long way.
In general, I am also baffled why platform related issues, e.g. interface selection, is something to be defined in a SIP related RFC. Granted, a solution should be implementable but defining how to select the right interface, e.g. which system call for a particular OS, does not belong to this RFC. Specification can talk about the need packets taking the correct/intended path but how this is achieved on a given platform is an implementation issue IMHO. But then, maybe the former is already what you meant.
> 
> In regards to the current draft for connection-oriented SIP flows, I am not
> happy about copying a lot of text from the Happy Eyeballs RFC into this doc.
> 
> Copying text from that RFC could mean we copy stuff that is out of scope and
> already old compared with today’s implementations and that we by accident
> limit the solution space for SIP, which would be unfortunate. The SIP solution
> for setting up a connection is in no way different from other protocols and
> thus I think we will be better off and have a smoother path to publication by
> just pointing to the Happy Eyeballs RFC than starting to copy parts without us
> authors having current implementation experience.
> 
> Let’s keep the connection-oriented draft short and sweet and just get it to
> publication and then dive heads down into UDP. That’s an area where no
> work has been done before (as far as I know) and we will propably end up
> producing an outbound-light or something else.
[TOLGA] Maybe, I am not as optimistic as you though (especially when considering use of DTLS)
> 
> The implementation I work with currently send a simple OPTIONs without
> SDP to test both address families and then select based on our preferences
> and responses. We do prefer IPv6 in this case, as IPv4 is hiding behind an ugly
> carrier grade nat. As this is a mobile app, registration and calls happen within
> a short time and no flows are kept for long. Desktop phones have flows that
> goes on for a very long time and network properties may change during that
> time, so we need more regular discovery.
[TOLGA] Specification for UDP would mention about use of OPTIONS and maybe provide information about some use cases but the exact semantics of what/how is preferred shouldn’t be normatively defined.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 16 Dec 2016 14:48:50 +0100

> On 16 Dec 2016, at 14:43, Asveren, Tolga <[email-masked]> wrote:
> 
> Inline...
> 
> Thanks,
> Tolga
> 
> [TOLGA] Understood. As said before though, this could be achieved with a single RFC/progressive versions of drafts as well IMHO. OTOH, I wouldn’t cry much over having multiple RFCs either.  So, I guess this means "consensus reached”.
:-)

> [TOLGA] I think covering SRV records is critical. They are used widely in practice; for various reasons and in different models. I don’t think burying our head into sand would make this issue disap…
We already did that RFC - was there something wrong or missing in that?

> In general, I am also baffled why platform related issues, e.g. interface selection, is something to be defined in a SIP related RFC. Granted, a solution should be implementable but defining how to…
We need to figure out what part of this that is SIP-specific. But yes, every SIP developer seems to be hitting multiple interfaces, 
especially when moving to mobile platforms.

> [TOLGA] Maybe, I am not as optimistic as you though (especially when considering use of DTLS)
DTLS for SIP/UDP is not specified yet, so as of now that is out of scope.
But I do agree that it will be interesting.

> [TOLGA] Specification for UDP would mention about use of OPTIONS and maybe provide information about some use cases but the exact semantics of what/how is preferred shouldn’t be normatively defined.
We have to remember that OPTIONS may cause media-related issues as it is currently
specified. In my platform we know the behaviour of the other endpoints so it caused no
harm. We may need to specify PING. Or just sending an unknown method and getting
an error code - just to provoke a response. Sending HELLOOLLE sip:[email-masked]
will always generate an error, unless someone out there use the HELLOOLLE method…

/O

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 16 Dec 2016 17:27:57 -0500

> Yes, that would work.  But as I said, UDP is not included in this

Indeed, OPTIONS is relatively high-overhead but has the significant
benefit that it can be used with *any* transport to probe that
transport's connectivity.  So I expect OPTIONS to become a more
prominent technique in later tranches.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 16 Dec 2016 17:40:19 -0500

"Olle E. Johansson" <[email-masked]> writes:
> We have to remember that OPTIONS may cause media-related issues as it
> is currently specified. In my platform we know the behaviour of the
> other endpoints so it caused no harm. We may need to specify PING. Or
> just sending an unknown method and getting an error code - just to
> provoke a response. Sending HELLOOLLE sip:[email-masked] will always
> generate an error, unless someone out there use the HELLOOLLE
> method...

The advantage of OPTIONS with "Max-Forwards: 0" is that the first proxy
to receive it must return a response, either 2xx or 483.  (Or 486 if
it's a UA that's unwilling to accept a call at the moment!)  Without
Max-Forwards, the request passes transparently through proxies and only
when it reaches a UA is a response generated.

But it's not clear to me what "media-related issues" there are for
OPTIONS.  My understanding of RFC 3261 is that the UAC is required to
not change the state of the element that generates the response.  Or are
there slightly-out-of-spec elements that have behaviors that we need to
worry about?

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 17 Dec 2016 13:50:01 +0100

> On 16 Dec 2016, at 23:40, Dale R. Worley <[email-masked]> wrote:
> 

To do options right in a software Asterisk I would have to authenticate
because it’s only after authentication I can answer the same way as I
would answer if this was a proper Invite with SDP. So if anyone wants
to use OPTIONs for discovery as it was meant it would mean authentication
as well. Using Options as Ping has kind of taken this away so no one
really use Options for discovery any more since the answer differs
from an INVITE.

The question is can we base a new RFC on this misuse or do we
need to document the misuse and modify OPTIONs too?

/O

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sat, 17 Dec 2016 15:47:37 +0000

i- A single implementation does it certain way does not mean it is per specification/done the same way by all other entities/implementations. I am aware of many deployments using OPTIONS for ping/keepalive/probe with success and without any issues. IMHO, OPTIONS definitely should be mentioned as one of the alternatives.

ii- I don’t think "unknown method" should be part of the specification. That is too much of a hack IMHO.

Thanks,
Tolga

> From: sipcore [mailto:[email-masked]] On Behalf Of Olle E.
> Johansson
> Sent: Saturday, December 17, 2016 7:50 AM
> To: Dale R. Worley <[email-masked]>
> Cc: [email-masked]; Olle E Johansson <[email-masked]>
> > The advantage of OPTIONS with "Max-Forwards: 0" is that the first
> > proxy to receive it must return a response, either 2xx or 483.  (Or
> > 486 if it's a UA that's unwilling to accept a call at the moment!)
> > Without Max-Forwards, the request passes transparently through proxies
> > and only when it reaches a UA is a response generated.
> >
> > not change the state of the element that generates the response.  Or
> > are there slightly-out-of-spec elements that have behaviors that we
> > need to worry about?
> 
> because it’s only after authentication I can answer the same way as I would
> answer if this was a proper Invite with SDP. So if anyone wants to use
> OPTIONs for discovery as it was meant it would mean authentication as well.
> Using Options as Ping has kind of taken this away so no one really use
> Options for discovery any more since the answer differs from an INVITE.
> 
> The question is can we base a new RFC on this misuse or do we need to
> document the misuse and modify OPTIONs too?
> 
> /O

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 18 Dec 2016 09:50:04 +0000

> But I do agree that it will be interesting.
[TOLGA] Probably you are referring to "SIP+D2U" currently not being in the IANA Registry. I think it should. I will craft a draft for that. 
On another note, static configurations (e.g. both IPv4/IPv6 Addresses are provisioned for a target, by whatever means) and DHCP based learning of addresses for SIP Servers (RFC3361, RFC3319) should be considered. So,  I think SIP/UDP/DTLS is "allowed" afterall. And it is connection-oriented, therefore should be covered by happy-earballs IMHO.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 18 Dec 2016 11:57:35 +0100

> On 18 Dec 2016, at 10:50, Asveren, Tolga <[email-masked]> wrote:
> 

There is simply no standard for DTLS as a transport for SIP.
http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-transport

I agree it would be a good thing, but it requires more work than adding it to the NAPTR registry.
/O

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 18 Dec 2016 11:20:32 +0000

One correction for my previous message:
"SIP+D2U" => "SIPS+D2U"

And yes, there is yet another IANA Registry to be updated as you mentioned and some other work, mea culpa. 
There obviously will be a need to extend syntax for relevant SIP headers/parameters and semantics to use it as one of the valid protocols. OTOH, I don't think there would be thorny issues and it would be mostly replicating what has been done/said about other transport protocols.

Thanks,
Tolga

> Sent: Sunday, December 18, 2016 5:58 AM
> > [TOLGA] Probably you are referring to "SIP+D2U" currently not being in the
> IANA Registry. I think it should. I will craft a draft for that.
> > On another note, static configurations (e.g. both IPv4/IPv6 Addresses are
> provisioned for a target, by whatever means) and DHCP based learning of
> addresses for SIP Servers (RFC3361, RFC3319) should be considered. So,  I
> think SIP/UDP/DTLS is "allowed" afterall. And it is connection-oriented,
> therefore should be covered by happy-earballs IMHO.
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 18 Dec 2016 13:22:39 +0100

> On 18 Dec 2016, at 12:20, Asveren, Tolga <[email-masked]> wrote:
> 

Dale and I had a discussion about it at SIPit and it’s an interesting mix of connection-less and connection-oriented that needs
some documentation. But I do think it will help a lot of large-scale platforms.

/O

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sun, 18 Dec 2016 13:52:06 +0000

Yes, definitely useful in practice. I certainly am interested in working on the needed specification. Is there a reason why the work should not start as a parallel activity? 

Thanks,
Tolga

> Sent: Sunday, December 18, 2016 7:23 AM
> Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport
> 
> 
> > And yes, there is yet another IANA Registry to be updated as you
> mentioned and some other work, mea culpa.
> > There obviously will be a need to extend syntax for relevant SIP
> headers/parameters and semantics to use it as one of the valid protocols.
> OTOH, I don't think there would be thorny issues and it would be mostly
> replicating what has been done/said about other transport protocols.
> 
> Dale and I had a discussion about it at SIPit and it’s an interesting mix of
> connection-less and connection-oriented that needs some documentation.
> But I do think it will help a lot of large-scale platforms.
> 
> /O
> >
> > Thanks,
> > Tolga
> >
> >> provisioned for a target, by whatever means) and DHCP based learning
> >> of addresses for SIP Servers (RFC3361, RFC3319) should be considered.
> >> So,  I think SIP/UDP/DTLS is "allowed" afterall. And it is
> >> connection-oriented, therefore should be covered by happy-earballs
> IMHO.
> >>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 18 Dec 2016 16:57:54 +0100

> On 18 Dec 2016, at 14:52, Asveren, Tolga <[email-masked]> wrote:
> 
No, if there are people interested that’s fine. I suspect it has to start in dispatch, but the chairs can explain more.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 18 Dec 2016 11:45:58 -0500

> No, if there are people interested that’s fine. I suspect it has to start in dispatch, but the chairs can explain more.

I don't believe it must start in Dispatch. It clearly falls in scope of 
sipcore, even without the recent recharter. But I think it will need a 
new milestone.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 18 Dec 2016 20:40:20 -0500

"Olle E. Johansson" <[email-masked]> writes:
>> headers/parameters and semantics to use it as one of the valid
>> protocols. OTOH, I don't think there would be thorny issues and it
>> would be mostly replicating what has been done/said about other
>> transport protocols.
>
> Dale and I had a discussion about it at SIPit and it's an interesting
> mix of connection-less and connection-oriented that needs

Though I remember discussions with Roman Shpount that DTLS has some
serious deficiencies for really large-scale systems.  It seems like a
design adjustment might be needed for DTLS to be really usable for SIP
signaling.  There was a discussion on Sipcore back in March.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 18 Dec 2016 21:59:21 -0500

"Olle E. Johansson" <[email-masked]> writes:
> because it's only after authentication I can answer the same way as I

I don't see what the problem is, even if OPTIONS demands authentication.
If the client sends OPTIONS and receives back a 401 or 407 response,
then clearly the communication path is working.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 18 Dec 2016 22:06:01 -0500

"Asveren, Tolga" <[email-masked]> writes:
> i- A single implementation does it certain way does not mean it is per
> specification/done the same way by all other
> entities/implementations. I am aware of many deployments using OPTIONS
> for ping/keepalive/probe with success and without any issues. IMHO,
> OPTIONS definitely should be mentioned as one of the alternatives.

The use of OPTIONS is listed in section 5 of
draft-worley-sip-he-connection-01.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 18 Dec 2016 22:13:44 -0500

"Asveren, Tolga" <[email-masked]> writes:
> On another note, static configurations (e.g. both IPv4/IPv6 Addresses
> are provisioned for a target, by whatever means) and DHCP based
> learning of addresses for SIP Servers (RFC3361, RFC3319) should be
> considered. So,  I think SIP/UDP/DTLS is "allowed" afterall. And it is

At least in regard to RFC 3361/3319, the data carried by DHCP are the
addresses or domain names of SIP servers.  As such, each is used as an
*input* to the RFC 3263 process.  The two RFCs contain this identical
paragraph, giving an ordering in how they are to be processed:

   The option MAY contain multiple domain names, but these SHOULD refer
   to different NAPTR records, rather than different A records.  The
   client MUST try the records in the order listed, applying the
   mechanism described in Section 4.1 of RFC 3263 [3] for each.  The
   client only resolves the subsequent domain names if attempts to
   contact the first one failed or yielded no common transport protocols
   between client and server or denote a domain administratively
   prohibited by client policy.

So it looks like these provide an even higher-level ordering of all the
possible targets.  And I suppose that the entire set should be subject
to Happy Eyeballs processing, rather than each result of 3263 being
processed seperately.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 18 Dec 2016 22:24:17 -0500

> would be mostly replicating what has been done/said about other

The question of SIP over DTLS has been discussed before and the idea has
been controversial.  See, at least, draft-jennings-sip-dtls, with a
discussion starting at
http://www.ietf.org/mail-archive/web/sip/current/msg11114.html.

The major argument put in favor of SIP/DTLS is that a server can easily
handle a million clients or more.  But Roman Shpount has mentioned a
number of shortcomings of DTLS in that environment.

My personal feeling is that we'll need to devise a "DTLS Lite" that
alleviates the shortcomings of DTLS for that particular environment.
After that, the purists may still not like it, but there will be enough
practical deployment of SIP-over-DTLS-Lite to overcome their objections.

Dale

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 19 Dec 2016 06:49:10 +0000

I will try to prepare an initial draft.

And meanwhile, it would be great if the chairs can decide whether re-chartering is needed. I think this work is "in-scope" as far as its content but obviously is not in the list of current goals.

Thanks,
Tolga

> From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Sunday, December 18, 2016 11:46 AM
> To: [email-masked]
> >> Yes, definitely useful in practice. I certainly am interested in working on
> the needed specification. Is there a reason why the work should not start as
> a parallel activity?
> > No, if there are people interested that’s fine. I suspect it has to start in
> dispatch, but the chairs can explain more.
> 
> I don't believe it must start in Dispatch. It clearly falls in scope of sipcore,
> even without the recent recharter. But I think it will need a new milestone.
> 
> 	Thanks,
> 	Paul
> 
> > /O
> >>
> >> Thanks,
> >> Tolga
> >>
> >>> OTOH, I don't think there would be thorny issues and it would be
> >>> mostly replicating what has been done/said about other transport
> protocols.
> >>>
> >>> Dale and I had a discussion about it at SIPit and it’s an
> >>> interesting mix of connection-less and connection-oriented that needs
> some documentation.
> >>>>> provisioned for a target, by whatever means) and DHCP based
> considered.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 19 Dec 2016 08:26:50 +0000

> Sent: Sunday, December 18, 2016 8:40 PM
> To: Olle E. Johansson <[email-masked]>
> Cc: Asveren, Tolga <[email-masked]>; [email-masked]
> > mix of connection-less and connection-oriented that needs some
> > documentation. But I do think it will help a lot of large-scale platforms.
> 
> serious deficiencies for really large-scale systems.  It seems like a design
> adjustment might be needed for DTLS to be really usable for SIP signaling.
> There was a discussion on Sipcore back in March.
[TOLGA] IITC, discussions were around how to provide fast failover when DTLS is used without requiring per-transaction state synchronization. Actually, we (you, Roman and I had some off-line discussions regarding this. A single-RTT failover indeed may require some changes but that is for an improvement on failover timing rather than to address a generic deficiency in DTLS (and changes do not necessarily need to be in DTLS itself IMHO).

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Dec 2016 13:11:01 -0500

On Mon, Dec 19, 2016 at 3:26 AM, Asveren, Tolga <[email-masked]>
wrote:

> design
> [TOLGA] IITC, discussions were around how to provide fast failover when
> DTLS is used without requiring per-transaction state synchronization.
> Actually, we (you, Roman and I had some off-line discussions regarding
> this. A single-RTT failover indeed may require some changes but that is for
> an improvement on failover timing rather than to address a generic
> deficiency in DTLS (and changes do not necessarily need to be in DTLS
> itself IMHO).
>
>
The question we need to answer is what makes SIP-over-DTLS better then
SIP-over-TLS. For all practical purposes SIP-over-DTLS combines downsides
of SIP-over-TLS (connection oriented, cannot fail-over without extensive
state sharing) with downsides of SIP-over-UDP (unreliable, cannot be used
to transport large messages). Unless you can come up with a compelling
reason why SIP-over-DTLS will perform better then SIP-over-TLS, there is no
reason to define it.

This being said, defining a new UDP based secure transport for SIP is
something that would be a good idea, but this protocol needs to be designed
to preserve the useful qualities of SIP-over-UDP while adding security.
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 19 Dec 2016 18:18:41 +0000

I think SIP/UDP/DTLS may be enhanced to have “easy switchover without sharing per-transaction state information”, and just with some -relatively straightforward- SIP side enhancements rather than specifying a new transport/modifying DTLS (and I don’t think the same would be possible for SIP/TLS/TCP). It would take quite some work to perfect the mechanism but to me it looks like worth to spend the effort.

Thanks,
Tolga

The question we need to answer is what makes SIP-over-DTLS better then SIP-over-TLS. For all practical purposes SIP-over-DTLS combines downsides of SIP-over-TLS (connection oriented, cannot fail-over without extensive state sharing) with downsides of SIP-over-UDP (unreliable, cannot be used to transport large messages). Unless you can come up with a compelling reason why SIP-over-DTLS will perform better then SIP-over-TLS, there is no reason to define it.

This being said, defining a new UDP based secure transport for SIP is something that would be a good idea, but this protocol needs to be designed to preserve the useful qualities of SIP-over-UDP while adding security.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Dec 2016 13:29:24 -0500

Do you think it would be possible to implement "easy switch-over" with
SIP/DTLS without significant changes to DTLS only by changing things on SIP
side? Can you share what you have in mind, even if it is still at the idea
stage?

I thought it was possible to implement a secure UDP based protocol by
changing DTLS and using SIP sequence numbers or other SIP headers, such as
Call ID and via branch value, transformed through a hash function, to
replace DTLS sequence number for message key generation. I am not sure how
to do the same thing by changing SIP and keeping DTLS the same.

Regards,
_____________
Roman Shpount

On Mon, Dec 19, 2016 at 1:18 PM, Asveren, Tolga <[email-masked]>
wrote:

> I think SIP/UDP/DTLS may be enhanced to have “easy switchover without
> sharing per-transaction state information”, and just with some -relatively
> straightforward- SIP side enhancements rather than specifying a new
> transport/modifying DTLS (and I don’t think the same would be possible for
> SIP/TLS/TCP). It would take quite some work to perfect the mechanism but to
> me it looks like worth to spend the effort.
>
>
>
> Thanks,
>
> Tolga
>
>
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 19 Dec 2016 19:07:45 +0000

Yes, and I think it should stay.
Thanks,
Tolga

> Sent: Sunday, December 18, 2016 10:06 PM
> Cc: [email-masked]; [email-masked]
> > specification/done the same way by all other entities/implementations.
> > I am aware of many deployments using OPTIONS for ping/keepalive/probe
> > with success and without any issues. IMHO, OPTIONS definitely should
> > be mentioned as one of the alternatives.
> 
> The use of OPTIONS is listed in section 5 of draft-worley-sip-he-connection-
> 01.
> 
> Dale

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 19 Dec 2016 19:14:35 +0000

It *could* be possible -but the ideas need to be vetted by a security guru- and I wouldn’t bet my life on the success of it at this stage.

There are various scenarios to cover, below is the high-level concept for server side failover:
i- Active Server sends a shared-key/nonce to UE after it completes registration, e.g. as part of 200(REGISTER).
ii- Active Server synchronizes shared-key/nonce with the Standby Server
iii- UE detects that Active Server is down and sends a message (maybe a new STUN usage) with (DTLS epoch, DTLS sequence_no, MAC[shared secret, some message content, nonce]) to Standby Server
iv- Standby Server uses the received epoch/sequence_no to initialize DTLS state for a new instance. This would require a change in the DTLS API/local stack if it is not already supported but no changes from on-the-wire protocol perspective.
v- Standby Server sends a message for ack (mayube a new STUN usage).

*If* something along these lines works, there wouldn’t be a need to establish a “new” DTLS session between UE/Standby Server. There wouldn’t be a need to change the on-the-wire DTLS protocol/define a new protocol (both tall orders in terms of making their way to practical use/deployment widely IMHO) .

Thanks,
Tolga

From: Roman Shpount [mailto:[email-masked]]
Sent: Monday, December 19, 2016 1:29 PM
To: Asveren, Tolga <[email-masked]>
Cc: Dale R. Worley <[email-masked]>; Olle E. Johansson <[email-masked]>; [email-masked]
Subject: Re: [sipcore] Happy Eyeballs for SIP - DTLS as a SIP transport

Do you think it would be possible to implement "easy switch-over" with SIP/DTLS without significant changes to DTLS only by changing things on SIP side? Can you share what you have in mind, even if it is still at the idea stage?

I thought it was possible to implement a secure UDP based protocol by changing DTLS and using SIP sequence numbers or other SIP headers, such as Call ID and via branch value, transformed through a hash function, to replace DTLS sequence number for message key generation. I am not sure how to do the same thing by changing SIP and keeping DTLS the same.

Regards,
_____________
Roman Shpount

On Mon, Dec 19, 2016 at 1:18 PM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
I think SIP/UDP/DTLS may be enhanced to have “easy switchover without sharing per-transaction state information”, and just with some -relatively straightforward- SIP side enhancements rather than specifying a new transport/modifying DTLS (and I don’t think the same would be possible for SIP/TLS/TCP). It would take quite some work to perfect the mechanism but to me it looks like worth to spend the effort.

Thanks,
Tolga

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Dec 2016 12:37:35 -0600

[as chair]

Paul is right -- this is a core protocol change that would have been in 
scope even prior to the rechartering. I'm going to send out an email 
shortly that talks about some potential milestones for our new charter; 
and, given that there seems to be some interest in this area, it should 
be part of that discussion.

/a

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 20 Dec 2016 16:16:23 -0500

"Olle E. Johansson" <[email-masked]> writes:
> In regards to the current draft for connection-oriented SIP flows, I
> am not happy about copying a lot of text from the Happy Eyeballs RFC
> into this doc.
>
> Happy Eyeballs is a large solution space and the important part of the
> RFC is the requirements - the solutions vary.  Copying text from that
> RFC could mean we copy stuff that is out of scope and already old
> compared with today's implementations and that we by accident limit
> the solution space for SIP, which would be unfortunate. The SIP
> solution for setting up a connection is in no way different from other
> protocols and thus I think we will be better off and have a smoother
> path to publication by just pointing to the Happy Eyeballs RFC than
> starting to copy parts without us authors having current
> implementation experience.

Ultimately, what goes into this draft/RFC is the working group's
decision.  But in the mean time, we can check that we've got a correct
understanding of this tranche of the problem, so that decision becomes
essentially editorial rather than technical:

- Have we got the separation of requirements and solutions right?  The
  requirements (on SIP devices) should be stated with MUST.  Solution
  advice should be stated with SHOULD or even non-normative language.

- Have we got up-to-date recommendations for the solutions?  Most of the
  current language is copied from RFC 6555.  Are there known improvements
  on that of wide applicability?

- Are the recommendations that are relevant for SIP but not for HTTP,
  and thus are new relative to RFC 6555, properly done?  (This is
  section 5 in draft-worley-sip-he-connection-01.)

So far, we haven't had much discussion of the technical content.

Dale