Re: [sipcore] Happy Eyeballs for SIP

["Asveren, Tolga" <[e-mail]>]

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

Thanks,
Tolga

> -----Original Message-----
> From: sipcore [mailto:[e-mail]] On Behalf Of Asveren,
> Tolga
> Sent: Tuesday, December 13, 2016 6:45 AM
> To: Dale R. Worley <[e-mail]>; [e-mail]
> Subject: Re: [sipcore] Happy Eyeballs for SIP
> 
> 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:[e-mail]] On Behalf Of Dale R.
> > Worley
> > Sent: Monday, December 12, 2016 7:15 PM
> > To: [e-mail]
> > Subject: [sipcore] Happy Eyeballs for SIP
> >
> > 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.
> [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).
> >
> > 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.
> [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).
> >
> > Let the discussion begin, both on the work and on the plan for the work!
> >
> > Dale
> >
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore