Subject: Re: [sipcore] Happy Eyeballs: Outbounde

From: [email-masked] (Dale R. Worley)
Date: Wed, 06 Jul 2016 17:54:12 -0400

Thanks for the information!  I've added your discussion to the rough
draft.

Roman Shpount <[email-masked]> writes:
> Few observations:
> [...]
> 3. For server, the most efficient way to keep the NAT hole open is to send
> OPTIONS or NOTIFY requests to the client. This is much more efficient then
> registrations with small timeouts.
>
> 4. Registration server which has an in-memory database for current
> registrations can be fairly efficient in reducing number of back-end DB
> updates due to registrations and subscriptions with small timeouts. It is
> not going to be stateless, but its state does not need to be replicated and
> would automatically recover on the stand-by server on the next registration
> or subscription request from the client.

I think what you are saying here is that if the server sends
OPTIONS/NOTIFY for keepalive, rather than making the client send
frequent re-REGISTERS, then the server doesn't need to record the timers
for the keepalives in persistent storage -- if the stand-by server is
activated, it simply sends keepalives to all registrations that are
recorded as having keepalive service.  In the long run, this requires no
more processing by the registration server and far less demand on the
persistent storage.

Is that correct?

> 5. One of the big problems with encrypted SIP traffic is that it gets
> modified by ALG. For a lot of hosted PBX providers avoiding the need to
> troubleshoot customer routers is a bigger incentive to deploy TLS then user
> privacy.

If I understand you correctly, hosted PBX providers favor TLS to stop
routers from modifying SIP messages.  But ALGs terminate TLS ... and
then modify the SIP messages.

Dale

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 6 Jul 2016 22:01:15 +0000

> then the server doesn't need to record the timers for the keepalives in
> persistent storage
I don't think using OPTIONS/NOTIFY v.s. REGISTER would change anything on this front. Roman probably refers more to the overall processing cost.

Thanks,
Tolga

> -----Original Message-----
> From: sipcore [mailto:[email-masked]] On Behalf Of Dale R. Worley
> Sent: Wednesday, July 06, 2016 5:54 PM
> To: Roman Shpount <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [sipcore] Happy Eyeballs: Outbounde
> 
> Thanks for the information!  I've added your discussion to the rough draft.
> 
> > 3. For server, the most efficient way to keep the NAT hole open is to
> > send OPTIONS or NOTIFY requests to the client. This is much more
> > efficient then registrations with small timeouts.
> >
> > registrations can be fairly efficient in reducing number of back-end
> > DB updates due to registrations and subscriptions with small timeouts.
> > It is not going to be stateless, but its state does not need to be
> > replicated and would automatically recover on the stand-by server on
> > the next registration or subscription request from the client.
> 
> I think what you are saying here is that if the server sends OPTIONS/NOTIFY
> for keepalive, rather than making the client send frequent re-REGISTERS,
> then the server doesn't need to record the timers for the keepalives in
> persistent storage -- if the stand-by server is activated, it simply sends
> keepalives to all registrations that are recorded as having keepalive service.
> In the long run, this requires no more processing by the registration server
> and far less demand on the persistent storage.
> 
> Is that correct?
> 
> > modified by ALG. For a lot of hosted PBX providers avoiding the need
> > to troubleshoot customer routers is a bigger incentive to deploy TLS
> > then user privacy.
> 
> If I understand you correctly, hosted PBX providers favor TLS to stop routers
> from modifying SIP messages.  But ALGs terminate TLS ... and then modify
> the SIP messages.
> 
> Dale
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 6 Jul 2016 18:17:44 -0400

>> registrations with small timeouts.

Over TCP you can use <CR><LF>. (And you don't need it very often.)

Over UDP why don't we use STUN?

In any case I see how this is a good substitute for frequent 
registration updates. The timing of both is determined by the server. 
This makes sense if the NAT is on the server end, and so its 
characteristics are known to the server.

But if the the NAT is at the client end and the client knows what is 
need is, then it may not be so good. Are we assuming that clients are 
dumb and won't know this stuff anyway, so a guess by the server is the 
best you are going to get.

	Thanks,
	Paul

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 6 Jul 2016 22:46:17 +0000

Inline...

Thanks,
Tolga

> From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Wednesday, July 06, 2016 6:18 PM
> To: [email-masked]
> In any case I see how this is a good substitute for frequent registration
> updates. The timing of both is determined by the server.
> This makes sense if the NAT is on the server end, and so its characteristics are
> known to the server.
> 
> But if the the NAT is at the client end and the client knows what is need is,
> then it may not be so good. Are we assuming that clients are dumb and won't
> know this stuff anyway, so a guess by the server is the best you are going to
> get.
[TOLGA] In general, it is not common to rely on the client to determine the refresh timing for NAT. It is either statically configured on the server side or server performs some sort of "probing" to determine a close-to-optimum refresh time. And agreed that CRLF/STUN-keepalive are the most preferred approaches, just there are still lots of deployments with no UE support for those though.
> >> DB updates due to registrations and subscriptions with small
> >> timeouts. It is not going to be stateless, but its state does not
> >> need to be replicated and would automatically recover on the stand-by
> >> server on the next registration or subscription request from the client.
> >
> > frequent re-REGISTERS, then the server doesn't need to record the
> > timers for the keepalives in persistent storage -- if the stand-by
> > server is activated, it simply sends keepalives to all registrations
> > that are recorded as having keepalive service.  In the long run, this
> > requires no more processing by the registration server and far less
> > demand on the persistent storage.
> >
> > Is that correct?
> >

---

From: Brett Tate <[email-masked]>
Date: Fri, 8 Jul 2016 08:55:43 -0400

> > then the server doesn't need to record the timers
> > for the keepalives in persistent storage
>
> I don't think using OPTIONS/NOTIFY v.s. REGISTER
> would change anything on this front. Roman probably
> refers more to the overall processing cost.

Because refreshing a registration typically involves updating persistent
information, performing authentication, et cetera, the impacts a REGISTER
can be significantly higher than that of OPTIONS.  This is the reason why
some vendors prefer receiving OPTIONS instead of REGISTER when sent
frequently as a workaround for NAT involvement.

Since OPTIONS is frequently used as a ping instead of the original
purpose, sipcore might want to standardize a mechanism to distinguish
between the two usages.  I don't recall why prior attempts such as
draft-jones-sip-options-ping failed.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 8 Jul 2016 12:14:13 -0400

> draft-jones-sip-options-ping failed.

I just looked back at my private archive. The discussions took place in 
May and July of 2010 on the sipcore list. (I haven't looked for these in 
the archives. These days I can get a URL into the archives from my copy 
of a message, but not with ones from that far back.)

I have attached a couple of messages as hooks into those discussions

Basically we could never agree on the groundrules for when using OPTIONS 
in the way proposed made sense.

	Thanks,
	Paul

Subject: Re: [sipcore] Revised draft-jones-sip-options-ping-02.txt
From: Paul Kyzivat <[email-masked]>
To: Victor Pascual <[email-masked]>
Date: Thu, 01 Jul 2010 12:23:30 -0400

Victor Pascual wrote:
> Would sip-ops be a better place for this?

I don't know - I don't follow that list.
If you think so, feel free to propose that publicly.

	Thanks,
	Paul

> https://www.ietf.org/mailman/listinfo/sip-ops
> 
> Sent from my iPad
> 
> On Jul 1, 2010, at 4:42 PM, Paul Kyzivat <[email-masked]> wrote:
> 
>> [as co-chair]
>>
>> Paul J,
>>
>> What are your intentions/expectations with respect to this draft?
>>
>> While it is written using normative language, I find nothing in it that is enhanced by being normative. So I would imagine if this is to go anywhere, it would be as a Informational document.
>>
>> At the moment I don't envision this rising to the level of becoming a milestone for this group.
>>
>> I have no problem with using this list for a modest amount of discussion about this draft - especially about its eventual outcome.
>>
>> 	Thanks,
>> 	Paul
>>
>> Paul E. Jones wrote:
>>> Folks,
>>> I just wanted to bring to your attention the fact that we've submitted a new
>>> revised version of the OPTIONS "ping" draft.  This document contains input
>>> from a number of folks who provided comments to me on various aspects of the
>>> draft.
>>> We had some discussion of moving this work to the SIP Overload Control (SOC)
>>> WG.  Given my current understanding of the scope of the SOC WG, I do not
>>> think that OPTIONS falls within the scope of their charter.  Further, this
>>> document was never produced for the purpose of providing an overload
>>> mechanism, either.
>>> I would like to have some further dialog on this document.  I've received
>>> some positive feedback from several people, as this has been seen as a
>>> useful first step in trying to define use of OPTIONS as a "ping" mechanism
>>> that is interoperable.  As I had mentioned before, there are several
>>> different variants of the same procedure in production networks and I think
>>> it's useful that we reach some agreement on how OPTIONS should be used as an
>>> application-level "ping", as RFC 3261 is a bit light on detail in this area.
>>> I know I might not have captured every comment, but that's because the
>>> discussions went in a variety of directions last time. :-)  So, my edits
>>> were primarily editorial or to add clarity to what was already written.
>>> Comments are most certainly welcome.
>>> Paul
>>>> From: [email-masked] [mailto:[email-masked]]
>>>> On Behalf Of [email-masked]
>>>> Sent: Thursday, July 01, 2010 12:30 AM
>>>> To: [email-masked]
>>>> Subject: I-D Action:draft-jones-sip-options-ping-02.txt
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>>
>>>> 	Title           : Using OPTIONS to Query for Operational Status in
>>>> the Session Initiation Protocol (SIP)
>>>> 	Author(s)       : V. Bhargava, et al.
>>>> 	Filename        : draft-jones-sip-options-ping-02.txt
>>>> 	Pages           : 8
>>>> 	Date            : 2010-06-30
>>>>
>>>> This document describes a procedure for using the Session Initiation
>>>> Protocol (SIP) OPTIONS method in order to allow one SIP entity to query
>>>> the operational status of another SIP entity.  Through discovery of the
>>>> status of a SIP entity, it is possible to expedite session establishment
>>>> or provide diagnostic information to network administrators.
>>>>
>>>> A URL for this Internet-Draft is:
>>>> http://www.ietf.org/internet-drafts/draft-jones-sip-options-ping-02.txt
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> Below is the data which will enable a MIME compliant mail reader
>>>> implementation to automatically retrieve the ASCII version of the
>>>> Internet-Draft.

Subject: Re: [sipcore] The predictive value of OPTIONS
From: Paul Kyzivat <[email-masked]>
To: Hadriel Kaplan <[email-masked]>
Cc: "Paul E. Jones" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 11 May 2010 20:39:42 -0400
List-Id: SIP Core Working Group <sipcore.ietf.org>

This is fragmenting into multiple issues that ought to be discussed 
separately. But I want to go home so I'm not splitting it up.

inline...

Hadriel Kaplan wrote:
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Paul Kyzivat
>> Sent: Tuesday, May 11, 2010 1:51 PM
>>
>>> For me it is.
>>> I do also have a need to actually learn what the next-hop's
>>> supported extensions are (and I do mean "box-level" ones),
>>> but that's not the main driver use-case for me at this instant in time.
>> Well, I would put that into somewhat the same bucket:
>> You are looking to predict which options will be supported for requests
>> you might send in the future.
>>
>> You seem to be making an assumption that extension support is uniquely
>> defined at the "box-level". I don't think its proper to assume that in
>> general, for a variety of reasons. For instance, a B2BUA may choose not
>> to admit to support for an extension in the context of a dialog unless
>> the "other leg" supports that extension.
>> This goes double for other "attributes" that may be reported by OPTIONS,
>> such as: event packages, mime types, media formats, even methods.
> 
> Yup, I know that quite well, and have made that argument before in IETF. :)
> 
> When I said "box-level", I meant capabilities *of* the B2BUA, at least with respect to me.  Not of any other "side", but of "my side".  In practice, there is a set of capabilities that could be indicated, and are.  Some of them would be quite useful, and really only apply on a per-hop basis anyway.  It's not everything, which makes it dangerous (and why I'm not suggesting doing it right now), but that's for a later time.
> 
>  
>> (For the latter, what is a B2BUA supposed to do if it understands some
>> method, but the other "side" doesn't?)
> 
> If it accepts the method on my "side", it accepts the method.  If the other side doesn't, then it will reject it when I send it.  Those two cases are not mutually inconsistent.  The B2BUA can make a routing decision which of many "sides" to send the request to, but it really does accept it and I really should send it to find out - as opposed to when it does not accept it on my side and there's no point ever sending it such a method.  

Lets use MESSAGE for discussion. You would report MESSAGE in an Accept 
header. Then later you receive MESSAGE, forward it to the "other side", 
and get back a 405, including a list of methods that are supported, not 
including MESSAGE. Do you pass that Accept on? Or alter it to indicate 
that you *do* support MESSAGE even though you are rejecting it with a 405?

There is no way to win here. You must be inconsistent at some point. So 
the result of the OPTIONS wrt Accept cannot be trusted to predict future 
behavior. The same is true for most of the other things reported in 
OPTIONS - its really hard to say much about how relevant they are for 
predicting future behavior.

To do better, I think it is necessary to either:
- specify in the query the context of the question, or
- return a complex document that describes what is supported under
   a variety of circumstances.

I doubt we want the latter (at least I don't).

Specifying the context for which you want an answer is also pretty 
difficult to do, given the number of different contexts that are 
possible. Maybe its possible to do a few interesting ones.

One is to send an OPTIONS to a URL and get an answer that pertains to 
*that* URL, while not necessarily pertaining to any other URL. AFAIK 
that is, more or less, what the current definition of OPTIONS does. You 
might choose to extrapolate the results for that URL to other URLs, but 
that may or may not produce correct results. Of course this is also 
limited, in that it only reports the results for OPTIONS. It has no way 
to customize the results for other methods. (For instance, some MIME 
types are likely to be acceptable only in the context of certain 
methods. Application/SDP may not be acceptable for MESSAGE.)

To get beyond the answer for one URL, we need a way to indicate we want 
an answer for a class of URLs, maybe all of them. Some seem to think 
that a URL with no user part is an indicator for this. I think that is 
probably a sensible meaning for some servers, but not all of them. IMO 
there is no good value you can pick to put in the user part of the R-URI 
to indicate this. But perhaps it could be indicated via some new header. 
If this is the desire, and single answers are desired, then some 
accuracy must be given up. Presumably the answer must be the union of 
the answers for all the URIs it applies to. So for any particular URI 
the answer might be less.

Also, there is the distinction between what might be available on a good 
day, vs. what the server is currently capable of, vs. what it is 
*willing* to do. Again, I don't see how any one answer is the right one 
for this. (E.g. the server is heavily loaded. It is capable of accepting 
*some* requests, but is only willing to accept requests from privileged 
callers. Or, it is in shutting-down mode. It has plenty of resources, 
but is only willing to accept in-dialog requests.)

Again, I think to get at this will require an indicator in the request 
of which sort of answer you want. Unless we can agree the answer is 
always and only about *capability*, and never about policy.

Bottom line here: I think there needs to be a selector, or selectors, 
for which kind of answer is desired.

>>> So for me, the main use-case for sending OPTIONS right now is to
>>> learn the capability of the next-hop to process messages.
>> You mean the dynamic, current "capacity" to process messages, not the
>> theoretical "ability" to do so when resources are available? Or do you
>> mean both?
> 
> Current.

Sorry - I botched my message that you are replying to. I wrote the 
above, then the list immediately below to replace that.

>> Do you mean:
>> - the theoretical "ability" to do so when resources are available,
>> - the "capacity" to do so given current load and resource availability,
>> - the "willingness" to do so, at this time, for this requestor?
> 
> If you mean "for this requestor" to mean for the same hop (as opposed to for the same source Contact URI), then I'd argue the second and third are effectively the same thing, in practice.  I believe that has even come up in the overload discussions a long time ago, and I think there was agreement they are effectively the same thing, logically.  Just because a next-hop tells me it can't do any more, but tells someone else something different, doesn't matter to my local processing of future requests to it.

I meant whatever the server would use as input to any policy decisions 
it might make. That might mean the sender of the message (top Via 
value), the originator of the request, whatever.

For instance, administrative shutdown would be a policy that determines 
willingness to handle requests. (At least until the listeners are 
stopped.) It might apply to certain links, which is what you are getting 
at. It might also apply to certain request originators, or to in-dialog 
vs. out-of-dialog requests, etc. It might also apply to certain R-URIs.

Policies to throttle load before overload occurs could also fall into 
this category of "willingness".

The specified expectation that an OPTIONS should return 486 if the 
device (a phone presumably) is on a call also falls into this "policy" 
category, since it could alternatively hang up the existing call or put 
it on hold to accept the new call.

I can see utility in getting theoretical capability as well: it would be 
nice to be able to determine which if any of your devices could support 
video, even if currently busy. I might then choose to wait till the 
video phone is free rather than calling now on the audio phone. (But of 
course this is better done with presence.)

But, if the majority of people can agree on a single context in which 
they want an answer, then perhaps we can simply have a single indicator 
that says we want that, rather than whatever it is that OPTIONS 
otherwise returns.

>> I expect that people have had one, or more, of the meanings I list above
>> in mind, perhaps without realizing that they are different. I'm willing
>> to bet not everyone will agree its the same one of the above. OPTIONS,
>> as currently defined, cannot provide all three answers. Nor will
>> tightening up the specs change that, though doing so might make it do a
>> better job of *one* of those.
> 
> In every case I have seen this used for in deployment, as far as I can tell they have actually meant the same thing.

To be fair, ACME has a particular perspective. SBCs talk to a certain 
class of equipment. I doubt you have need to interface directly to 
phones. But others do use OPTIONS to phones.

>> Then, lets talk about what range of things a given response applies to:
>>
>> Suppose I send OPTIONS to
>> - sip:198.51.100.101:5060
>> Does the response I get apply also to
>> - sip:198.51.100.101:5061,
>> - sip:[email-masked]:5060,
>> - sip:[email-masked]:5060,
>> - sips:[email-masked]:5061
>> - sip:example.com	(maps to 198.51.100.101)
>> - sip:pbx1.example.com	(also maps to 198.51.100.101)
> 
> YES.  If the responder understands the Header, then it's reporting a system-level capability. (luckily you forgot about anycasting ;)

I slipped some ringers in there for you. :-)

There is no guarantee that two ports for the same ip address are served 
by the same "server". They may be served by separate processes with 
independent resources. Statistically there is probably a good chance 
that 5060 and 5061 are served by the same server. But once you get past 
that, then what?

I didn't put in multi-homing situations, or IPv6/IPv6 cases, but they 
apply too. For all of these I can't see a good alternative to assuming 
they are distinct and asking on each, or *configuring* the cases when 
you *know* they are the same.

And I still disagree with assuming they are the same when the user part 
varies, unless we add something to the message to indicate that is what 
is desired. But even an indicator won't deal with the port issue, or 
with multihoming, since you can't know if the device speaks for the 
others. OR, the response could be altered to indicate all the different 
addresses is applies to.

>> But for a "phone" sip:198.51.100.101:5060 might just denote the "primary
>> line", while sip:[email-masked]:5060 may denote the "secondary line".
>> And then the answer for one might have little predictive value over
>> requests to the other. E.g. an OPTIONS to one might return 486 because
>> the phone is busy, while an OPTIONS to the other might return 200.
> 
> Hence the need/desire for a Header.
> 
>  
>> For a gateway, there may well be DSP resources required to establish a
>> call, and how much, or what type may depend on the codecs used in the
>> call. So an answer to OPTIONS won't be valuable in predicting if a
>> particular call can succeed.
> 
> That's OK.  A "box-wide" semantic is a superset.  If you can handle ANY more calls (from that previous hop), then "box-wide" you can handle more calls.  That doesn't mean you can't reject future calls due to unavailable resources such as DSPs.  If you can NOT handle any more "box-wide", for example due to CPU, then the number of DSP resources you have really doesn't matter.

That is a possible interpretation.

If some (expensive) codecs are disabled during peak load, should that be 
reflected in the response?

What if some destinations are currently unreachable? Should OPTIONS for 
a particular address reflect that? (E.g. only +1... calls are currently 
operational because the international trunk is down. Should OPTIONS to 
sip:+44... return 480 or 200?)

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 13 Jul 2016 15:10:01 -0400

> I have attached a couple of messages as hooks into those discussions

The messages with subject "Revised draft-jones-sip-options-ping-02.txt"
are (currently) indexed on
https://www.ietf.org/mail-archive/web/sipcore/current/thrd9.html The
messages with subjects "draft-jones-sip-options-ping-01" and "The
predictive value of OPTIONS" are indexed on
https://www.ietf.org/mail-archive/web/sipcore/current/thrd9.html
https://www.ietf.org/mail-archive/web/sipcore/current/thrd10.html

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 13 Jul 2016 15:16:27 -0400

> frequently as a workaround for NAT involvement.

Also, knowledge of the expirations of the registrations must be
maintained accurately, while a keepalive only has to be sent frequently
enough.  For instance, consider if the maximum keepalive interval is 60
secs, and the proxy sends an OPTIONS every 30 secs.  The proxy needs to
keep a database of keepalive timers.  But if it goes down, the standby
proxy doesn't need to know when each keepalive expires, it needs to send
an OPTIONS to every target within the next 30 secs.

Dale

---

From: Roman Shpount <[email-masked]>
Date: Wed, 13 Jul 2016 16:44:52 -0400

On Wed, Jul 6, 2016 at 5:54 PM, Dale R. Worley <[email-masked]> wrote:

> send

This is correct. Since OPTIONS/NOTIFY do not update the registration state
they typically require less resources then forcing the client to
re-register at the small interval. Registrations typically require
authentication and cause the shared storage update for the expiration time.
OPTIONS/NOTIFY sent from server require not of this.

> then modify the SIP messages.
One of the big problems with deploying SIP on customer premises are SIP ALG
implemented by the consumer routers. Such ALG are typically broken and
cause SIP call setup failures or call drops. If client equipment is using
SIP over TLS, SIP ALG in routers cannot affect the signaling and SIP
message pass the router unmolested. Because of this, SIP calls over TLS are
much more stable which results in big reduction of customer problems and
associated support calls. This reduction in support burden is a much bigger
incentive for service providers to deploy encryption for SIP then customer
privacy (which, in practice, is almost never their concern).
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 13 Jul 2016 16:47:12 -0400

On Wed, Jul 6, 2016 at 6:01 PM, Asveren, Tolga <[email-masked]>
wrote:

> I don't think using OPTIONS/NOTIFY v.s. REGISTER would change anything on
> this front. Roman probably refers more to the overall processing cost.
>
>
There is processing cost since OPTIONS/NOTIFY typically are not
authenticated. There is state storage cost, since registration state
typically needs to be stored in some sort of shared storage and recovered
in case of proxy failure. OPTIONS/NOTIFY can be send and processed based on
in-memory state and do not need to be recovered.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Jul 2016 20:53:52 +0000

Hi,

REGISTER requests used for keep-alive are not always authenticated, because they are not always forwarded to the registrar to begin with. They are terminated by an edge/outbound proxy.

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 13 July 2016 23:47
To: Asveren, Tolga <[email-masked]>
Cc: Dale R. Worley <[email-masked]>; [email-masked]
Subject: Re: [sipcore] Happy Eyeballs: Outbounde

There is processing cost since OPTIONS/NOTIFY typically are not authenticated. There is state storage cost, since registration state typically needs to be stored in some sort of shared storage and recovered in case of proxy failure. OPTIONS/NOTIFY can be send and processed based on in-memory state and do not need to be recovered.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 13 Jul 2016 17:00:36 -0400

On Wed, Jul 13, 2016 at 4:53 PM, Christer Holmberg <
[email-masked]> wrote:

>
> REGISTER requests used for keep-alive are not always authenticated,
> because they are not always forwarded to the registrar to begin with. They
> are terminated by an edge/outbound proxy.
>
>
>
When we implemented keep-alive using REGISTER we used an in memory DB in
the edge proxy to store registration and authentication information. We
used this DB to aggregate frequent REGISTER requests on the edge proxy into
a much less frequent requests to the Registration proxy. So, this is
implementable but a lot more work.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Jul 2016 21:05:04 +0000

Hi,

> When we implemented keep-alive using REGISTER we used an in memory DB in the edge proxy to store registration and authentication
> information. We used this DB to aggregate frequent REGISTER requests on the edge proxy into a much less frequent requests to the Registration proxy.

Correct.

> So, this is implementable but a lot more work.

Sure, and that's why we should hope that UAs implement STUN for keep-alive :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Jul 2016 17:44:46 -0400

On 7/13/16 4:53 PM, Christer Holmberg wrote:
> because they are not always forwarded to the registrar to begin with.
> They are terminated by an edge/outbound proxy.

I know this is done, but I have always thought it to be broken.

The response to REGISTER is supposed to include *all* contacts that have 
been registered, not just those that were offered in *this* REGISTER. 
Also, the expiration time is supposed to reflect what the registrar 
thinks it is.

If the request is short-circuited in a proxy, even a stateful proxy, the 
response likely won't have that property.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Jul 2016 22:31:06 +0000

Hi,

> The response to REGISTER is supposed to include *all* contacts that have been registered, not just those that were offered in *this* REGISTER. 

The edge proxy can store that information from the previous REGISTER response it received from the registrar, and include it in the REGISTER responses it triggers itself. It anyway needs to keep track of the registration, to make sure some REGISTER requests *are* forwarded towards the registrar (in order for the registration to not expire). 

> Also, the expiration time is supposed to reflect what the registrar thinks it is.
>
> If the request is short-circuited in a proxy, even a stateful proxy, the response likely won't have that property.

But it works :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Jul 2016 19:09:20 -0400

> The edge proxy can store that information from the previous REGISTER response it received from the registrar, and include it in the REGISTER responses it triggers itself. It anyway needs to keep tr…

That only works if the proxy is in the path for *all* REGISTER requests 
for that AoR. Otherwise there can be another contact, added by a UA 
through a different proxy. And then *this* UA won't get that info until 
the proxy decides to pass a request on to the registrar.

>> If the request is short-circuited in a proxy, even a stateful proxy, the response likely won't have that property.

For *some* definitions of "works". There are some things that won't 
work. You may judge that those don't matter, but somebody else may not.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Jul 2016 07:26:52 +0000

Hi,

>>> The response to REGISTER is supposed to include *all* contacts that
>>>have been registered, not just those that were offered in *this*
>>>REGISTER.
>>
>> The edge proxy can store that information from the previous REGISTER
>>response it received from the registrar, and include it in the REGISTER
>>responses it triggers itself. It anyway needs to keep track of the
>>registration, to make sure some REGISTER requests *are* forwarded
>>towards the registrar (in order for the registration to not expire).
>

Sure, but that is the case even if REGISTERs aren't used for keep-alives.

>>> If the request is short-circuited in a proxy, even a stateful proxy,
>>>the response likely won't have that property.
>>
>> But it works :)
>

Sure.

And, I didn¹t mean to say this is the best way of doing things - I was
only explaining how many do use REGISTER for keep-olives.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Jul 2016 07:30:33 +0000

keep-alives, that is :)

On 14/07/16 10:26, "sipcore on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 14 Jul 2016 09:34:17 +0200

Even using OPTIONs for keepalives may generate problems considering a SIP implementation
that use OPTIONs for discovery.

In the case of Asterisk OPTIONs are answered blindly. But INVITEs are authenticated and
generated depending upon whether we have a configuration for that particular user.

This means that OPTIONs and INVITEs have different responses. If the UA use the
OPTIONs answer (including SDP) for discovery, the result is all wrong…

For keepalives - I would use what’s describe in section 4.4 of RFC 5626, regardless of
if I follow outbound or not. CRLF or STUN.

/O

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Jul 2016 07:43:04 +0000

>...
>
>
>For keepalives - I would use what¹s describe in section 4.4 of RFC 5626,
>regardless of

The negotiation and usage of those, without outbound, is described in RFC
6223.

https://tools.ietf.org/rfc/rfc6223.txt

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 14 Jul 2016 09:49:50 +0200

> On 14 Jul 2016, at 09:43, Christer Holmberg <[email-masked]> wrote:
> 
>> ...
>> 
>> 
>> For keepalives - I would use whatąs describe in section 4.4 of RFC 5626,
>> regardless of
Thank you for that reference, I forgot about that.

We do need to update The Hitchhiker’s guide to SIP. The extended version :-)

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Jul 2016 11:03:26 -0400

> keep-alives, that is :)

I think I prefer keep-olives :-)

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 17 Jul 2016 21:10:47 -0400

Christer Holmberg <[email-masked]> writes:
> response it received from the registrar, and include it in the
> REGISTER responses it triggers itself. It anyway needs to keep track
> of the registration, to make sure some REGISTER requests *are*
> forwarded towards the registrar (in order for the registration to not
> expire). 

If the edge proxy has the information to provide correct responses to
the REGISTER request, then there's no problem.  Of course, that requires
that the edge proxy arranges to be updated by the registrar with
whatever changes it needs to know.

I do wonder whether it would be possible for the UA to send a REGISTER
with Max-Forwards: 0 as a keep-alive.  The edge proxy could then reply
with a 483 without needing to know any registration information, and
would be totally correct.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 17 Jul 2016 21:20:19 -0400

"Olle E. Johansson" <[email-masked]> writes:
> Even using OPTIONs for keepalives may generate problems considering a
> SIP implementation that use OPTIONs for discovery.
>
> In the case of Asterisk OPTIONs are answered blindly. But INVITEs are
> authenticated and generated depending upon whether we have a
> configuration for that particular user.
>
> This means that OPTIONs and INVITEs have different responses. If the
> UA use the OPTIONs answer (including SDP) for discovery, the result is
> all wrong...

If OPTIONS (don't forget the S!) has Max-Forwards: 0, then an edge proxy
will give a 483 response, which is completely correct.  I think you're
talking about the case where OPTIONS reaches a central proxy, but that
proxy would reject an INVITE from the same UA.

RFC 3261 section 11.2 seems to be aware that a proxy cannot handle
OPTIONS in exactly the same way as an INVITE:

   This use of OPTIONS has limitations due to the differences in proxy
   handling of OPTIONS and INVITE requests.  While a forked INVITE can
   result in multiple 200 (OK) responses being returned, a forked
   OPTIONS will only result in a single 200 (OK) response, since it is
   treated by proxies using the non-INVITE handling.  See Section 16.7
   for the normative details.

   If the response to an OPTIONS is generated by a proxy server, the
   proxy returns a 200 (OK), listing the capabilities of the server.
   The response does not contain a message body.

   Allow, Accept, Accept-Encoding, Accept-Language, and Supported header
   fields SHOULD be present in a 200 (OK) response to an OPTIONS
   request.  If the response is generated by a proxy, the Allow header
   field SHOULD be omitted as it is ambiguous since a proxy is method
   agnostic.  Contact header fields MAY be present in a 200 (OK)
   response and have the same semantics as in a 3xx response.  That is,
   they may list a set of alternative names and methods of reaching the
   user.  A Warning header field MAY be present.

Other than connectivity, in what way can an OPTIONS to a proxy be used
for discovery?

Christer Holmberg <[email-masked]> wrote:
> >For keepalives - I would use what's describe in section 4.4 of RFC
> >5626, regardless of if I follow outbound or not. CRLF or STUN.
> 

Thanks for mentioning that!  I wasn't aware of it.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 17 Jul 2016 21:37:37 -0400

Roman Shpount <[email-masked]> writes:
>> > 5. One of the big problems with encrypted SIP traffic is that it
>> > gets modified by ALG. For a lot of hosted PBX providers avoiding
>> > the need to troubleshoot customer routers is a bigger incentive to
>> > deploy TLS [than] user privacy.
>>

We'll have to remember this as a design point.

However this does mean that the UAs need to know the edge proxy's
certificate, so the ALG can't terminate TLS.

Dale

---

From: Roman Shpount <[email-masked]>
Date: Sun, 17 Jul 2016 22:21:50 -0400

> certificate, so the ALG can't terminate TLS.

UA do not need to know the edge proxy's certificate. This certificate can
be verified against the well known certificate authorities, similar to how
HTTPS web site certificates are verified. This works unless end user
specifically added ALG's certificate to the list of CAs on the UA, which is
typically not done.
_____________
Roman Shpount

---

From: James Cloos <[email-masked]>
Date: Mon, 18 Jul 2016 20:32:08 -0400

>>>>> "RS" == Roman Shpount <[email-masked]> writes:

RS> UA do not need to know the edge proxy's certificate. This certificate can
RS> be verified against the well known certificate authorities, similar to how
RS> HTTPS web site certificates are verified.

Most sip software I've looked at also supports not verifying the certs
at all.  If the only reason for using tls is to avoid mangling by the
edge routers, then at least in the short term (next few years, before
the edge router manufactures catch on) tls w/o auth would get the job
done.

Of course w/ auth is nicer, and letsencrypt makes that essentially free
(just the labor cost of setting it up).

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 19 Jul 2016 06:07:15 +0200

Consumer routers deploy SIP ALG to mainly fix the address/port in SDP to
enable media to traverse consumer the NAT, right? Are we saying consumer
endpoints are already doing ICE, so making those ALGs non-functional as a
result of doing SIP over TLS wouldn't be an issue?

thanks,
Muthu

On Wed, Jul 13, 2016 at 10:44 PM, Roman Shpount <[email-masked]> wrote:

> One of the big problems with deploying SIP on customer premises are SIP
> ALG implemented by the consumer routers. Such ALG are typically broken and

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 19 Jul 2016 11:46:59 -0400

> result of doing SIP over TLS wouldn't be an issue?

That's the idea:  The UA should use Outbound to keep a NAT binding, and
ICE to negotiate media ports.

Looking at the SIPit 31 summary (https://www.sipit.net/SIPit31_summary),
44% of endpoints support ICE, whereas only 28% support outbound.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Jul 2016 16:02:18 +0000

Hi,

Outbound is more than a mechanism for keeping NAT bindings open.

So, before saying "let's use outbound", what exactly are the properties/features that you need?

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: 19 July 2016 18:47
To: Muthu Arul Mozhi Perumal <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [sipcore] Happy Eyeballs: Outbounde

Muthu Arul Mozhi Perumal <[email-masked]> writes:
> Consumer routers deploy SIP ALG to mainly fix the address/port in SDP 
> to enable media to traverse consumer the NAT, right? Are we saying 
> consumer endpoints are already doing ICE, so making those ALGs 
> non-functional as a result of doing SIP over TLS wouldn't be an issue?

That's the idea:  The UA should use Outbound to keep a NAT binding, and ICE to negotiate media ports.

Dale

---

From: Roman Shpount <[email-masked]>
Date: Tue, 19 Jul 2016 14:35:55 -0400

> result of doing SIP over TLS wouldn't be an issue?
What I am saying is that most consumer routers include ALG code which is
broken. This code is supposed to update IP addresses in SIP Via and Contact
as well as in SDP. It is also supposed to setup packet forwarding between
public IP/port to the NATed IP/port. In reality, code in most of the
routers is so bad that the person who wrote it most likely needs to change
profession to avoid spreading future misery. Not doing anything to SIP on
the router in combination with ICE or server side NAT traversal works much
better then SIP ALG. There is almost never a reason to have SIP ALG enabled
unless you are using a very restrictive firewall.

For more information you can google "SIP ALG are evil" or read any of the
following:

https://support.onsip.com/hc/en-us/articles/204514014-NAT-and-Firewall-Traversal-Recommendation

http://support.phone.com/hc/en-us/articles/204162770-Do-I-Have-To-Change-My-Network-Settings-or-Hardware-

http://www.whichvoip.com/disable-sip-alg.htm

Look at the number of routers where SIP ALG needs to be disabled:
http://businesssupport.vonage.com/app/answers/detail/a_id/21546/~/network-equipment-compatibility

You can probably find a similar article for every hosted VoIP provider.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 19 Jul 2016 14:45:12 -0400

> properties/features that you need?

I have mentioned this in another thread but Happy Eyeballs do not need to
have anything to do with SIP Outbound. Main connection that I do see is
using SIP Outbound Keep-Alive messages to detect the working flow for SIP
messages when multiple local networks or multiple SIP Edge proxy addresses
are available.

I have also mentioned that this is not the only solution for Happy
Eyeballs, since figuring out rules for sending messages in the same SIP
transaction across multiple flows can serve as an alternative, and possibly
better, solution.

Obviously, if we restrict SIP to TLS only as the only acceptable protocol
for Happy Eyeballs, then SIP Outbound is the only standard solution which
attempts to describe how to make SIP work with TLS from end points behind
NAT. This, as I have mentioned before, have serious scalability and
fail-over issues for current deployments.

Regards,
_____________
Roman Shpount