Subject: [Sip] Progress draft-holmberg-sip-keep

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 19 Jun 2008 11:30:30 +0200

(As SIP WG cochair)

We have been asked by the author of 

http://www.ietf.org/internet-drafts/draft-holmberg-sip-keep-01.txt

Whether the SIP WG can progress this document.

Because this draft arose as a result of the discussion of outbound, and
indeed seems to reuse the requirements from outbound, and these
requirements never really got handled in the SIPPING WG, it has been
agreed with the SIPPING chairs that we will handle this entirely within
SIP.

Now in order to ask for charter milestones, and indeed when we finally
present this to IESG, we will be asked for the level of support in the
WG, which is also predicated on does this fix a real problem, or is it
just a corner case with limited application. So:

QUESTION 1 TO SIP WG: Are the use cases sufficiently important to
proceed with this draft? The document states:

   Chapter 3.5 of draft-ietf-sip-outbound-13 [I-D.ietf-sip-outbound]
   defines two keep-alive techniques.  Even though the keep-alive
   techniques are separated from the Outbound mechanism
   [I-D.ietf-sip-outbound], it is currently not possible to indicate
   support of the keep-alive techniques without also indicating support
   for the Outbound mechanism.

   The Outbound mechanism is enabled during the UA registration phase.
   However, there are use-cases where the UA does not register itself,
   but still needs to be able to make calls and maintain NAT bindings
   open during the duration of that call.  A typical example is
   emergency calls.  There are also cases where entities do not support
   the Outbound mechanism, but still want to be able to indicate support
   and use the keep-alive techniques defined in [I-D.ietf-sip-outbound].

At first sight this is not the most inspiring declaration of the need
for the document. Please respond indicating whether you consider this a
useful draft, and propose text that you think would be useful in this
section. Conversely, if you think this draft is not useful and the WG
has other more important things to work on first, please also respond.

QUESTION 2 TO SIP WG: Do we have a robust set of requirements for
proceeding with this work? The document currently lists:

   REQ 1: It MUST be possible for a UA to indicate support of the keep-
   alive techniques defined [I-D.ietf-sip-outbound] if the UA supports
   only the keep-alive part of [I-D.ietf-sip-outbound].

   REQ 2: It MUST be possible for an edge proxy to indicate support of
   the keep-alive techniques defined [I-D.ietf-sip-outbound] if the edge
   poxy supports only the keep-alive part of [I-D.ietf-sip-outbound].

It would be desirable to agree these at the outset, and not revisit them
if we continue with the work. So if you require clarification,
modification, or addition to these two requirements, then please also
response with your questions and proposals.

I suggest we would like responses by 30th June 2008 in order to allow
the author to revise the document before the deadlines. Please note that
we are looking to make this decision on the list within this deadline
based on responses received, not leave it until the Dublin meeting.

Regards

Keith
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 20 Jun 2008 13:19:35 -0400

My 2 cents: it is a useful draft.  Personally, I would like to have it available for two reasons not cited: PBX connections a la SIP trunks, and proxy-proxy connections.  Today I think a lot of people are using OPTIONS requests or proprietary means to perform such keep-alives when registration is not appropriate, but it has led to some interop issues and performance concerns in some cases.

Since the contentious issue of what form the keep-alives take have already been agreed on for outbound, this seems like a simple draft to get done. (famous last words, I know)

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> DRAGE, Keith (Keith)
> Sent: Thursday, June 19, 2008 5:31 AM
> To: [email-masked]
> Cc: Christer Holmberg
> Subject: [Sip] Progress draft-holmberg-sip-keep
>
> (As SIP WG cochair)
>

---

From: "Xavier Marjou" <[email-masked]>
Date: Mon, 23 Jun 2008 10:59:17 +0200

> proceed with this draft? The document states:

I agree this is a relevant use-case. If there's no other one, I think
we don't have to torture ourselves with too many use-cases, as it
would complicate the solution.
By the way, I like short & simple drafts like this one ;-)

> proceeding with this work? The document currently lists:

I would add one explicit requirement like: It MUST be possible for a
UA to negotiate a keep-alive mecanism outside a SIP registration.

Cheers,
Xavier

---

From: Aki Niemi <[email-masked]>
Date: Mon, 23 Jun 2008 15:56:55 +0300

> has other more important things to work on first, please also respond.

In theory, there is a small, but valid, reason for the draft to exists.
The draft could serve as a way to deploy outbound-aware proxies in front
of outbound-unaware registrars, using UDP transport. However, arguably
UDP is deployed and works through NAT today, which is why I find it
unlikely that anyone would deploy outbound keepalives in this way.

> response with your questions and proposals.

These requirements would make sense, but iff there was an actual need to
have this ability in the first place, as I described above. I don't
think such a need exists in practice.

(Note, this upgrade path only exists for UDP; for TCP registrars need to
be outbound-aware.)

Cheers,
Aki

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 23 Jun 2008 16:15:00 +0300

> proceed with this draft? The document states:
(...)
>    open during the duration of that call.

>    A typical example is emergency calls.

I don't get this one. You don't need to send keep-alive packets to make an 
outbound call (be it urgent or not).

>    There are also cases where entities do not support 

I don't get this either. If you don't support Outbound, why not use plain SIP 
OPTIONS, which works _today_?

-- 
Rémi Denis-Courmont

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 23 Jun 2008 15:21:16 +0200

Hi, 

>I don't get this one. You don't need to send keep-alive packets to make an outbound call (be it urgent or not).

I am not sure that is what I am saying. I am saying that you in these use-cases can't use outbound, with keep-alives, even if you support it.

>I don't get this either. If you don't support Outbound, why not use plain SIP OPTIONS, which works _today_?

An edge proxy does not know whether the UA is going to send OPTIONS, so it may use the short registration rerefresh mechanism. One of the purposes of the draft is for UAs to tell the edge proxy that it is willing to send keep-alives, so that the edge proxy doesn't need to use registration type of mechanisms.

In addition, if OPTIONS is sent in-dialog it will be forwarded by the edge proxy towards the remote user, which is not needed.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 24 Jun 2008 08:15:12 +0100

Hadriel,

Concerning your "PBX connections a la SIP trunks" use case, I am not
convinced of this. ETSI TISPAN has specified two ways for an IPPBX to
connect to a service provider. One is the so-called subscription-based
approach, where the IPPBX registers with the SP and communicates via an
edge proxy. In this case, why not use SIP-outbound? The other is the
so-called peering-based approach, which is essentially the same as any
SIP "trunk", e.g., proxy-to-proxy, B2BUA-to-B2BUA, proxy-to-gateway.
SIP-outbound does not apply to these situations, and similarly the
keep-alive mechanism is not specified for this cases. The requirements
in SIP-keep do not cover these situations.

Basically I am not sold on the idea of a separate SIP-keep spec - I
don't think it would be the best use of WG time.

John

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hadriel Kaplan
> Sent: 20 June 2008 18:20
> To: DRAGE, Keith (Keith); [email-masked]
> Cc: Christer Holmberg
> Subject: Re: [Sip] Progress draft-holmberg-sip-keep
> 
> 
> My 2 cents: it is a useful draft.  Personally, I would like 
> to have it available for two reasons not cited: PBX 
> connections a la SIP trunks, and proxy-proxy connections.  
> Today I think a lot of people are using OPTIONS requests or 
> proprietary means to perform such keep-alives when 
> registration is not appropriate, but it has led to some 
> interop issues and performance concerns in some cases.
> 
> Since the contentious issue of what form the keep-alives take 
> have already been agreed on for outbound, this seems like a 
> simple draft to get done. (famous last words, I know)
> 
> -hadriel
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Jun 2008 09:19:54 +0200

Hi John,

SIP-keep CAN be used proxy-to-proxy, B2BUA-to-B2BUA etc. ANY entity (e.g. a proxy) can insert the keep parameter in its Via header, and if the next entity adds a "yes" value the "keep-alives" can be used between those entities.

Regards,

Christer

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 24. kesäkuuta 2008 10:15
To: Hadriel Kaplan; DRAGE, Keith (Keith); [email-masked]
Cc: Christer Holmberg
Subject: RE: [Sip] Progress draft-holmberg-sip-keep

Hadriel,

Concerning your "PBX connections a la SIP trunks" use case, I am not convinced of this. ETSI TISPAN has specified two ways for an IPPBX to connect to a service provider. One is the so-called subscription-based approach, where the IPPBX registers with the SP and communicates via an edge proxy. In this case, why not use SIP-outbound? The other is the so-called peering-based approach, which is essentially the same as any SIP "trunk", e.g., proxy-to-proxy, B2BUA-to-B2BUA, proxy-to-gateway.
SIP-outbound does not apply to these situations, and similarly the keep-alive mechanism is not specified for this cases. The requirements in SIP-keep do not cover these situations.

Basically I am not sold on the idea of a separate SIP-keep spec - I don't think it would be the best use of WG time.

John

> Hadriel Kaplan
> My 2 cents: it is a useful draft.  Personally, I would like to have it 
> available for two reasons not cited: PBX connections a la SIP trunks, 
> and proxy-proxy connections.
> proprietary means to perform such keep-alives when registration is not 
> appropriate, but it has led to some interop issues and performance 
> concerns in some cases.
> 
> Since the contentious issue of what form the keep-alives take have 
> already been agreed on for outbound, this seems like a simple draft to 
> get done. (famous last words, I know)
> 
> -hadriel
> 
> 
> Behalf Of
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 24 Jun 2008 11:05:03 +0100

Christer,

The majority of the specification talks about a UA as client and an edge proxy as server. The only hint that it might be applied in other situations is in section 8 "Overlap with connection reuse", but there is no normative language there. So the scope clearly seems to be between a UA and an edge proxy, and I don't see much value in that (i.e., might as well support sip-outbound).

If you wish to extend the scope so that it can operate between any two SIP entities, and in particular between two proxies, then that is a different matter. There may be valid use cases, but I can't recall whether these have been discussed. Will the same technical solution apply (e.g., in terms of which side is the client, which side chooses the timer value, what is the default timer value, etc.)?

I think Keith's questions related to the present draft (01) and I interpret the scope as UA to edge proxy only. If you wish to extend the scope, this would require a revised draft before making any decision on adopting as a work item.

John

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: 24 June 2008 08:20
> To: Elwell, John; Hadriel Kaplan; DRAGE, Keith (Keith); [email-masked]
> SIP-keep CAN be used proxy-to-proxy, B2BUA-to-B2BUA etc. ANY 
> entity (e.g. a proxy) can insert the keep parameter in its 
> Via header, and if the next entity adds a "yes" value the 
> "keep-alives" can be used between those entities.
> 
> Regards,
> 
> Christer
>  
> 
> Concerning your "PBX connections a la SIP trunks" use case, I 
> am not convinced of this. ETSI TISPAN has specified two ways 
> for an IPPBX to connect to a service provider. One is the 
> so-called subscription-based approach, where the IPPBX 
> registers with the SP and communicates via an edge proxy. In 
> this case, why not use SIP-outbound? The other is the 
> so-called peering-based approach, which is essentially the 
> same as any SIP "trunk", e.g., proxy-to-proxy, 
> B2BUA-to-B2BUA, proxy-to-gateway.
> SIP-outbound does not apply to these situations, and 
> similarly the keep-alive mechanism is not specified for this 
> cases. The requirements in SIP-keep do not cover these situations.
> 
> Basically I am not sold on the idea of a separate SIP-keep 
> spec - I don't think it would be the best use of WG time.
> 
> John
> 
> 
> to have it 
> registration is not

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Jun 2008 12:14:53 +0200

Hi, 

>The majority of the specification talks about a UA as client and an edge proxy as server. The only hint that it might be 
>applied in other situations is in section 8 "Overlap with connection reuse", but there is no normative language there. So 
>the scope clearly seems to be between a UA and an edge proxy, and I don't see much value in that (i.e., might as well 
>support sip-outbound).

Outbound can not always be used, as the draft says.

It is true that initially the primary scope is between the UA and the edge proxy. However, I am happy to add the proxy-to-proxy use-case, if people think that is something we should do.

>If you wish to extend the scope so that it can operate between any two SIP entities, and in particular between two 
>proxies, then that is a different matter. There may be valid use cases, but I can't recall whether these have been 
>discussed. Will the same technical solution apply (e.g., in terms of which side is the client, which side chooses the 
>timer value, what is the default timer value, etc.)?

At the moment I see no reason why the same technical solution wouldn't apply.

Regards,

Christer

I think Keith's questions related to the present draft (01) and I interpret the scope as UA to edge proxy only. If you 
wish to extend the scope, this would require a revised draft before making any decision on adopting as a work item.

John

> SIP-keep CAN be used proxy-to-proxy, B2BUA-to-B2BUA etc. ANY entity 
> (e.g. a proxy) can insert the keep parameter in its Via header, and if 
> the next entity adds a "yes" value the "keep-alives" can be used 
> between those entities.
> 
> Regards,
> 
> Christer
>  
> 
> approach, where the IPPBX registers with the SP and communicates via 
> an edge proxy. In this case, why not use SIP-outbound? The other is 
> the so-called peering-based approach, which is essentially the same as 
> any SIP "trunk", e.g., proxy-to-proxy, B2BUA-to-B2BUA, 
> proxy-to-gateway.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 24 Jun 2008 11:32:00 -0400

Hey John,
For the case where the IP-PBX registers into the SP, outbound can be used.  But it's the other case I was talking about: where the IP-PBX does NOT register into the SP, but it instead is a trunk.

-hadriel

> Sent: Tuesday, June 24, 2008 3:15 AM

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 24 Jun 2008 16:48:29 +0100

Hadriel,

That trunking case is no different from other trunking cases, e.g.,
proxy-to-proxy, and I have already suggested to Christer that he might
extend the scope of the draft to cover that. It would be good to have
some discussion on whether keep-alive on "trunking" interfaces would be
beneficial - I have an open mind on that at present.

John 

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 24 June 2008 16:32
> To: Elwell, John; DRAGE, Keith (Keith); [email-masked]
> Cc: Christer Holmberg
> For the case where the IP-PBX registers into the SP, outbound 
> can be used.  But it's the other case I was talking about: 
> where the IP-PBX does NOT register into the SP, but it 
> instead is a trunk.
> 
> -hadriel
> 
> 
> same as any

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 24 Jun 2008 12:11:21 -0400

Those cases are the ones I said would be useful in my original email far below.  I.e., when I said "two reasons not cited: PBX connections a la SIP trunks, and proxy-proxy connections."  They are not identical, in the sense that an IP-PBX can be a b2bua/UA/whatever, but also in the sense of their example use-case, for example an IP-PBX could be behind a NAT and thus want this keep-alive for more reasons than a proxy-proxy.

-hadriel

> Sent: Tuesday, June 24, 2008 11:48 AM

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 25 Jun 2008 00:05:29 +0200

Hi,

As I said before, I would be happy to extend the scope to also cover proxy-proxy. I have also received an off-line comment indicating that it would be useful. I don't think it would change the mechanism itself, so...

So, if we choose to move forward with the draft I would then update the scope etc it in the next version.

Does that sound ok?

Regards,

Christer 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: 24. kesäkuuta 2008 19:11
To: Elwell, John; DRAGE, Keith (Keith); [email-masked]
Cc: Christer Holmberg
Subject: RE: [Sip] Progress draft-holmberg-sip-keep

-hadriel

> some discussion on whether keep-alive on "trunking" interfaces would 
> be beneficial - I have an open mind on that at present.
>
> John
>
> > For the case where the IP-PBX registers into the SP, outbound can be 
> > used.  But it's the other case I was talking about:
> > where the IP-PBX does NOT register into the SP, but it instead is a 
> > trunk.
> >
> > -hadriel
> >
> >
> > > Concerning your "PBX connections a la SIP trunks" use case, I am 
> > > not convinced of this. ETSI TISPAN has specified two ways for
> > an IPPBX to
> > > edge proxy. In this case, why not use SIP-outbound? The other is 
> > > the so-called peering-based approach, which is essentially the
> > same as any
> > > Basically I am not sold on the idea of a separate SIP-keep spec - 
> > > I don't think it would be the best use of WG time.
> > >
> > > John
> > >
> > >
> > > > My 2 cents: it is a useful draft.  Personally, I would like to 
> > > > have it available for two reasons not cited: PBX connections a 
> > > > la SIP trunks, and proxy-proxy connections.
> > > > proprietary means to perform such keep-alives when registration 
> > > > is not appropriate, but it has led to some interop issues and 
> > > > performance concerns in some cases.
> > > >
> > > > > indeed seems to reuse the requirements from outbound, and 
> > > > > these requirements never really got handled in the SIPPING
> > WG, it has been
> > > > > [email-masked] for questions on
> > current sip
> > > > [email-masked] for questions on current sip

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 25 Jun 2008 11:10:39 +0200

Hi,
I see this also as useful to have the proxy-proxy behaviour covered.

BR

Roland 

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von Christer Holmberg
> Gesendet: Mittwoch, 25. Juni 2008 00:05
> An: Hadriel Kaplan; Elwell, John; DRAGE, Keith (Keith); [email-masked]
> Betreff: Re: [Sip] Progress draft-holmberg-sip-keep
> 
> 
> Hi,
> 
> As I said before, I would be happy to extend the scope to 
> also cover proxy-proxy. I have also received an off-line 
> comment indicating that it would be useful. I don't think it 
> would change the mechanism itself, so...
> 
> So, if we choose to move forward with the draft I would then 
> update the scope etc it in the next version.
> 
> Does that sound ok?
> 
> Regards,
> 
> Christer 
> 
> Those cases are the ones I said would be useful in my 
> original email far below.  I.e., when I said "two reasons not 
> cited: PBX connections a la SIP trunks, and proxy-proxy 
> connections."  They are not identical, in the sense that an 
> IP-PBX can be a b2bua/UA/whatever, but also in the sense of 
> their example use-case, for example an IP-PBX could be behind 
> a NAT and thus want this keep-alive for more reasons than a 
> proxy-proxy.
> 
> -hadriel
> 
> instead is a 
> similarly the 
> registration

---

From: <[email-masked]>
Date: Wed, 25 Jun 2008 22:11:00 +0300

Hi,

I'm a bit sceptical about the need for keep-alives between proxies. It
is of course entirely possible that an enterprise PBX is connected to
(or peering with) a service provider proxy through a NAT and/or a
firewall. However, wouldn't such a NAT or firewall be under the
administration of either the enterprise itself or its ISP (who quite
often would be the SIP service provider), and the required port
forwardings or firewall rules could be set through administration. This
means that there would not be need for keepalive traffic to implicitely
keep the mapping/pinhole open.

Or are there really deployment cases where there are SIP PBXs behind
unadministrated NATs or firewalls?

Wouldn't we then need keepalives for SMTP as well, or how has the e-mail
infrastructure managed to solve this problem? 

Markus 

>Behalf Of ext Elwell, John
>Sent: 24 June, 2008 10:15
>same as any SIP "trunk", e.g., proxy-to-proxy, B2BUA-to-B2BUA, 
>proxy-to-gateway.
>SIP-outbound does not apply to these situations, and similarly 
>the keep-alive mechanism is not specified for this cases. The 
>requirements in SIP-keep do not cover these situations.
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 25 Jun 2008 15:33:34 -0400

Yes I am of that same opinion - that any real "IP-PBX" or whatever big enough NOT to be doing Registration, and to instead do static provisioning or DNS, would be given a static hole/DMZ address in their firewall/NAT.  But some of my customers have told me otherwise. (interestingly mostly in APAC region)
There's also some concern that while a static entry is there for inbound TCP connections, the PBX creates outbound ones to the service provider which are ephemeral port sources and need to live for very long durations (though why they can't just do TCP keepalive is beyond me, but I'm no expert).

But anyway, the big issue we've seen is that we need both the PBX and the service provider box to detect failure before an active call/request attempt is made; to trigger alternate route selection without waiting for transport failure, and as a method to detect liveness again and revert.  Today that's almost exclusively done with Options requests as far as I've seen, and lots of people don't seem to like that.

-hadriel

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, June 25, 2008 3:11 PM
> To: [email-masked]; Hadriel Kaplan; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use
> case
>
> Hi,
>

---

From: Jeroen van Bemmel <[email-masked]>
Date: Wed, 25 Jun 2008 21:57:24 +0200

Hadriel, Markus,

Instead of standardizing keep-alives between proxies, how about we 
define a "virtual UA" on each element (similar to the one described in 
RFC3261 section 16.7 point 6) to be used to provide this functionality? 
(using existing outbound functionality, perhaps both ways)

Regards,
Jeroen

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 25 Jun 2008 23:31:36 +0200

Hi,

Also, in some of the "proxy-to-proxy" cases it is not necessarily about the need for NAT keep-alive, but more about the need for a "heartbeat" function (I guess that is what Hadriel is also talking about). Today that functionality is sometimes implemented using SIP OPTIONS etc, which is a rather heavy and clumsy mechanism for that purpose.

Regards,

Christer

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: 25. kesäkuuta 2008 22:34
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: Christer Holmberg
Subject: RE: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case

Yes I am of that same opinion - that any real "IP-PBX" or whatever big enough NOT to be doing Registration, and to instead do static provisioning or DNS, would be given a static hole/DMZ address in their firewall/NAT.  But some of my customers have told me otherwise. (interestingly mostly in APAC region) There's also some concern that while a static entry is there for inbound TCP connections, the PBX creates outbound ones to the service provider which are ephemeral port sources and need to live for very long durations (though why they can't just do TCP keepalive is beyond me, but I'm no expert).

-hadriel

> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy 
> use case
>
> Hi,
>
> forwardings or firewall rules could be set through administration. 
> This means that there would not be need for keepalive traffic to 
> implicitely keep the mapping/pinhole open.
>
> Wouldn't we then need keepalives for SMTP as well, or how has the 
> e-mail infrastructure managed to solve this problem?
>
> Markus
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 25 Jun 2008 23:35:17 +0200

Hi,

So, you are proposing that each element should be a B2BUA, and both elements then register towards each other and use Outbound???

Regards,

Christer 

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: 25. kesäkuuta 2008 22:57
To: Hadriel Kaplan
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Christer Holmberg
Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case

Hadriel, Markus,

Instead of standardizing keep-alives between proxies, how about we define a "virtual UA" on each element (similar to the one described in
RFC3261 section 16.7 point 6) to be used to provide this functionality? 
(using existing outbound functionality, perhaps both ways)

Regards,
Jeroen

Hadriel Kaplan wrote:
> Yes I am of that same opinion - that any real "IP-PBX" or whatever big 
> enough NOT to be doing Registration, and to instead do static provisioning or DNS, would be given a static hole/DMZ address in their firewall/NAT.  But some of my customers have told me otherwise. (interestingly mostly in APAC region) There's also some concern that while a static entry is there for inbound TCP connections, the PBX creates outbound ones to the service provider which are ephemeral port sources and need to live for very long durations (though why they can't just do TCP keepalive is beyond me, but I'm no expert).
>
>> To: [email-masked]; Hadriel Kaplan; 
>> [email-masked]; [email-masked]
>> I'm a bit sceptical about the need for keep-alives between proxies. 
>> It is of course entirely possible that an enterprise PBX is connected 
>> to (or peering with) a service provider proxy through a NAT and/or a

---

From: Jeroen van Bemmel <[email-masked]>
Date: Wed, 25 Jun 2008 23:55:48 +0200

No, not a B2BUA. Each element would have a virtual UA function "in 
parallel" to its regular function (e.g. being a proxy). And indeed, one 
way to implement this would be to keep either one (one way) or two 
(opposite ways) flows active between them.

Like so:

|-----------|                     |-----------|
|   Proxy     |                     |  Proxy     |
|-----------|                     |-----------|
|     UA      | <---------->|      UA     |
|-----------|                     |-----------|

Each "UA" would implement both a simple registrar and a UAC performing 
registration. It could also be setup asymmetrically, with the (smaller) 
IP-PBX doing a single registration towards the (bigger) Service provider 
network. Registration expiry would denote a loss of connectivity.

Regards,
Jeroen

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 26 Jun 2008 00:02:54 -0400

In the asymmetric case, if the registration is established with a long duration, and for some reason if IP-PBX crashes before the registration expires, then SP n/w will not know about it until the registration expires, or it tries to send a request to that PBX.
If the registration interval is short, then this becomes similar to using short registration intervals to keep nat bindings open.

Sanjay

>Behalf Of Jeroen van Bemmel
>Sent: Wednesday, June 25, 2008 5:56 PM
>To: Christer Holmberg
>Cc: [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]
>No, not a B2BUA. Each element would have a virtual UA function 
>"in parallel" to its regular function (e.g. being a proxy). 
>And indeed, one way to implement this would be to keep either 
>one (one way) or two (opposite ways) flows active between them.
>
>Like so:
>
>Each "UA" would implement both a simple registrar and a UAC 
>performing registration. It could also be setup 
>asymmetrically, with the (smaller) IP-PBX doing a single 
>registration towards the (bigger) Service provider network. 
>Registration expiry would denote a loss of connectivity.
>
>Regards,
>Jeroen
>
>
>Christer Holmberg wrote:
>> Hi,
>>
>> So, you are proposing that each element should be a B2BUA, 
>and both elements then register towards each other and use Outbound???
>>
>> Regards,
>>
>> Christer
>>
>> Cc: [email-masked]; [email-masked]; 
>> [email-masked]; [email-masked]; Christer Holmberg
>>> Yes I am of that same opinion - that any real "IP-PBX" or whatever 
>>> big enough NOT to be doing Registration, and to instead do 
>static provisioning or DNS, would be given a static hole/DMZ 
>address in their firewall/NAT.  But some of my customers have 
>told me otherwise. (interestingly mostly in APAC region) 
>There's also some concern that while a static entry is there 
>for inbound TCP connections, the PBX creates outbound ones to 
>the service provider which are ephemeral port sources and need 
>to live for very long durations (though why they can't just do 
>TCP keepalive is beyond me, but I'm no expert).
>>>
>>> But anyway, the big issue we've seen is that we need both 
>the PBX and the service provider box to detect failure before 
>an active call/request attempt is made; to trigger alternate 
>route selection without waiting for transport failure, and as 
>a method to detect liveness again and revert.  Today that's 
>almost exclusively done with Options requests as far as I've 
>seen, and lots of people don't seem to like that.
>>>
>>> -hadriel
>>>
>>>
>>>   
>>>     
>>>> It is of course entirely possible that an enterprise PBX is 
>>>> connected to (or peering with) a service provider proxy through a 
>>>> NAT and/or a firewall. However, wouldn't such a NAT or firewall be 
>>>> under the administration of either the enterprise itself 
>or its ISP 
>>>> (who quite often would be the SIP service provider), and the 
>>>> required port forwardings or firewall rules could be set 
>through administration.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 26 Jun 2008 01:56:37 -0400

Hey Jeroen,
I'm not sure I follow you.  The SIP Forum SIP-Connect profile, and now TISPAN, make use of a REGISTER for an IP-PBX to register a whole set of AoR's to be routed to.  For those devices that need that ability, it makes sense to use outbound of course, and its inherent keepalive, regardless of being behind a NAT or not.  And I don't think Christer's suggesting otherwise.

But for IP-PBX's or proxies which do not themselves represent an AoR target of requests, or do not represent one in the domain of the device they want to perform keepalive with, why would we want to make them add such registration logic?  What would be the gain over just simply sending OPTIONS at that point?

The beauty of a STUN or double-CRLF keepalive is, in my mind: it's trivial to construct, trivial to parse, very small and fixed size, can be separated or handled at a lower layer, explicit in its use, and does not get stopped by a SIP-layer overload control.  In short: it's a transport connection-layer keepalive, no more no less.  And indicating it in the Via keeps it a hop-link thing, backwards-compatible, little or no provisioning, and with no URI target addressing issues.

-hadriel

> Cc: Hadriel Kaplan; [email-masked]; [email-masked];
> > So, you are proposing that each element should be a B2BUA, and both
> elements then register towards each other and use Outbound???
> >
> > Regards,
> >
> > Christer
> >
> > Cc: [email-masked]; [email-masked]; drage@alcatel-
> lucent.com; [email-masked]; Christer Holmberg
> >> enough NOT to be doing Registration, and to instead do static
> provisioning or DNS, would be given a static hole/DMZ address in their
> firewall/NAT.  But some of my customers have told me otherwise.
> (interestingly mostly in APAC region) There's also some concern that while
> a static entry is there for inbound TCP connections, the PBX creates
> outbound ones to the service provider which are ephemeral port sources and
> need to live for very long durations (though why they can't just do TCP
> keepalive is beyond me, but I'm no expert).
> >>
> >> But anyway, the big issue we've seen is that we need both the PBX and
> the service provider box to detect failure before an active call/request
> attempt is made; to trigger alternate route selection without waiting for
> transport failure, and as a method to detect liveness again and revert.
> Today that's almost exclusively done with Options requests as far as I've

---

From: Jeroen van Bemmel <[email-masked]>
Date: Thu, 26 Jun 2008 08:49:38 +0200

Hadriel,

I did not intend to suggest to use the registration interval timer for 
keep-alive, of course all the regular flow keep-alive mechanisms of 
outbound could be used.

The benefit is that we would reuse the efforts put in outbound, instead 
of inventing yet another, only marginally different, mechanism for each 
specific case. From the sending element point of view, sending a 
REGISTER isn't very different from sending an OPTIONS; subsequent 
keep-alives can then become STUN or double CRLF, until the registration 
needs to be refreshed.

Using REGISTER instead of OPTIONS also provides the means to use the 
standard authentication mechanisms, besides reusing outbound (and 
there's a few other reusable things, like Path headers, but let's keep 
it simple for the moment)

Regards,
Jeroen

Hadriel Kaplan wrote:
>>> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use
>>>       
>> case
>>     
>>> Hadriel, Markus,
>>>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 26 Jun 2008 08:03:34 +0100

Jeroen,

Yes, this is effectively what you have when an IPPBX is required to register with a service provider. But in that case, there might also be a need to implement sip-outbound if there are unadministered NATs/firewalls in the way. Indeed, sip-outbound would operate between a virtual UA on the IPPBX side and a registrar on the service provider side.

What I am interested in gaining from this discussion is whether there are proxy-to-proxy cases where sip-outbound is not appropriate but keep-alive (or heartbeat) is needed.

John

> Sent: 25 June 2008 22:56
> Cc: Hadriel Kaplan; [email-masked]; Elwell, John; 
> performing 
> > Instead of standardizing keep-alives between proxies, how 
> about we define a "virtual UA" on each element (similar to 
> the one described in
> >> enough NOT to be doing Registration, and to instead do 
> the service provider which are ephemeral port sources and 
> need to live for very long durations (though why they can't 
> just do TCP keepalive is beyond me, but I'm no expert).
> >>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 26 Jun 2008 08:03:45 +0100

This is what sip-outbound is for.

John 

> From: Sanjay Sinha (sanjsinh) [mailto:[email-masked]] 
> Sent: 26 June 2008 05:03
> To: Jeroen van Bemmel; Christer Holmberg
> Cc: [email-masked]; [email-masked]; Elwell, John; 
> [email-masked]
> In the asymmetric case, if the registration is established 
> with a long duration, and for some reason if IP-PBX crashes 
> before the registration expires, then SP n/w will not know 
> about it until the registration expires, or it tries to send 
> a request to that PBX.
> If the registration interval is short, then this becomes 
> similar to using short registration intervals to keep nat 
> bindings open.
> 
> Sanjay
> 
> >> Subject: Re: [Sip] Progress draft-holmberg-sip-keep: 
> proxy-to-proxy 
> >> use case
> >>
> >> Hadriel, Markus,
> >>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 26 Jun 2008 09:06:16 +0200

Jeroen,

I don't understand what benefit it would be to establish outbound registrations between all SIP entities that want to use the keep-alive/heartbeat. Yes, we would "re-use an existing mechanism", but in my opinion it would really be an overkill,a hack - and anything but keep-it-simple...

Also, how would the proxies know which proxies it should establish registrations which?

Also, it wouldn't work in the use-case with UEs that don't register.

Regards,

Christer

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: 26. kesäkuuta 2008 9:50
To: Hadriel Kaplan
Cc: Christer Holmberg; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case

Hadriel,

I did not intend to suggest to use the registration interval timer for keep-alive, of course all the regular flow keep-alive mechanisms of outbound could be used.

The benefit is that we would reuse the efforts put in outbound, instead of inventing yet another, only marginally different, mechanism for each specific case. From the sending element point of view, sending a REGISTER isn't very different from sending an OPTIONS; subsequent keep-alives can then become STUN or double CRLF, until the registration needs to be refreshed.

Using REGISTER instead of OPTIONS also provides the means to use the standard authentication mechanisms, besides reusing outbound (and there's a few other reusable things, like Path headers, but let's keep it simple for the moment)

Regards,
Jeroen

Hadriel Kaplan wrote:
>> Cc: Hadriel Kaplan; [email-masked]; 
>> [email-masked]; [email-masked]; [email-masked]
>> parallel" to its regular function (e.g. being a proxy). And indeed, 
>> one way to implement this would be to keep either one (one way) or 
>> two (opposite ways) flows active between them.
>>
>> Like so:
>>
>> performing registration. It could also be setup asymmetrically, with 
>> the (smaller) IP-PBX doing a single registration towards the (bigger) 
>> Service provider network. Registration expiry would denote a loss of connectivity.
>>
>> Regards,
>> Jeroen
>>
>>
>> Christer Holmberg wrote:
>>     
>>> Hi,
>>>
>>> drage@alcatel-
>>>> big enough NOT to be doing Registration, and to instead do static
>>>>         
>> provisioning or DNS, would be given a static hole/DMZ address in 
>> their firewall/NAT.  But some of my customers have told me otherwise.
>> (interestingly mostly in APAC region) There's also some concern that 
>> while a static entry is there for inbound TCP connections, the PBX 
>> creates outbound ones to the service provider which are ephemeral 
>> port sources and need to live for very long durations (though why 
>> they can't just do TCP keepalive is beyond me, but I'm no expert).
>>     
>> the service provider box to detect failure before an active 
>> call/request attempt is made; to trigger alternate route selection 
>> without waiting for transport failure, and as a method to detect liveness again and revert.
>> Today that's almost exclusively done with Options requests as far as 
>> I've seen, and lots of people don't seem to like that.
>>     
>>>> -hadriel
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>>> under the administration of either the enterprise itself or its 
>>>>> ISP (who quite often would be the SIP service provider), and the 
>>>>> required port forwardings or firewall rules could be set through administration.
>>>>> Or are there really deployment cases where there are SIP PBXs 
>>>>> behind unadministrated NATs or firewalls?
>>>>>

---

From: Jeroen van Bemmel <[email-masked]>
Date: Thu, 26 Jun 2008 09:24:14 +0200

Christer,

The only solution I can think of that would give less processing, would 
be to simply open a TCP connection (or UDP flow with STUN) without 
sending any request. Less "overkill", but it would open up a bunch of 
security issues ( e.g. TCP connection resources being consumed by 
unauthorized elements, leading to DoS; all the concerns with STUNning 
before checking support, etc. ). So I don't see how sending at least one 
SIP request could be avoided. REGISTER is as good as any.

Which proxies to register with: that would of course have to be 
provisioned somehow, this is no different from having to provision which 
outbound proxy to use

UEs that don't register: the idea is to make all such UEs register, so 
there'd be no such case left

Regards,
Jeroen

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 26 Jun 2008 09:28:40 +0200

Hi, 

>The only solution I can think of that would give less processing, would be to simply open a TCP connection (or UDP flow 
>with STUN) without sending any request. Less "overkill", but it would open up a bunch of security issues ( e.g. TCP 
>connection resources being consumed by unauthorized elements, leading to DoS; all the concerns with STUNning before 
>checking support, etc. ). So I don't see how sending at least one SIP request could be avoided. REGISTER is as good as 
>any.
>
>Which proxies to register with: that would of course have to be provisioned somehow, this is no different from having to 
>provision which outbound proxy to use

There is a big difference. A UA will always send the requests via the outbound proxy, but a proxy can communicate with an unlimited number of other proxies. Those proxies are normally found (unless a service route exists) using DNS when the proxy receives a request to forward.

>UEs that don't register: the idea is to make all such UEs register, so there'd be no such case left

As said earlier, at least 3GPP has a requirement for non-register emergency calls.

Regards,

Christer

Christer Holmberg wrote:
> Cc: Christer Holmberg; [email-masked]; 
>>> the (smaller) IP-PBX doing a single registration towards the 
>>> (bigger) Service provider network. Registration expiry would denote a loss of connectivity.
>>>
>>> Regards,
>>> Jeroen
>>>
>>>
>>> Christer Holmberg wrote:
>>>     
>>>       
>>>> Hi,
>>>>
>>>>>> NAT and/or a firewall. However, wouldn't such a NAT or firewall 
>>>>>> be under the administration of either the enterprise itself or 
>>>>>> its ISP (who quite often would be the SIP service provider), and 
>>>>>> the required port forwardings or firewall rules could be set through administration.

---

From: Jeroen van Bemmel <[email-masked]>
Date: Thu, 26 Jun 2008 09:34:49 +0200

John,

The problem with "not appropriate" is that it's subjective and 
ambiguous. I think we understand "not strictly needed" (or "overkill" as 
some say), e.g. when there is no NAT device in between.

A case I can imagine where outbound wouldn't work, is if the proxies in 
question are connected indirectly (i.e. not hop-by-hop). Then the 
outbound keep-alive mechanism doesn't work, and you'd need some SIP 
request instead (or some elaborate scheme to pass on keep-alive 
information across multiple hops in some other way)

Regards,
Jeroen

Elwell, John wrote:
>> proxy-to-proxy use case
>> proxy-to-proxy use case
>>> RFC3261 section 16.7 point 6) to be used to provide this 
>>>       
>> functionality? 
>>     
>>>> Yes I am of that same opinion - that any real "IP-PBX" or 
>>>>         
>> whatever big 
>>     
>>>>> Subject: RE: [Sip] Progress draft-holmberg-sip-keep: 
>>>>>           
>> proxy-to-proxy 
>>     
>>>>> use case
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm a bit sceptical about the need for keep-alives 
>>>>>           
>> between proxies. 
>>     
>>>>> It is of course entirely possible that an enterprise PBX 
>>>>>           
>> is connected 
>>     
>>>>> to (or peering with) a service provider proxy through a 
>>>>>           
>> NAT and/or a 
>>     
>>>>> administration of either the enterprise itself or its ISP 
>>>>>           
>> (who quite 
>>     
>>>>> forwardings or firewall rules could be set through 
>>>>>           
>> administration. 
>>     
>>>>> Or are there really deployment cases where there are SIP 
>>>>>           
>> PBXs behind 
>>

---

From: Jeroen van Bemmel <[email-masked]>
Date: Thu, 26 Jun 2008 09:52:40 +0200

Christer,

We're mixing different cases here. The 3GPP non-register emergency call 
scenario is for an endpoint, I was talking about the proxy-to-proxy case 
(I believe the 3GPP case can be addressed using standard mechanisms 
available today, it's only about authorization policies and 
identification of what calls are emergency calls).

It doesn't make sense for a proxy to keep-alive connections with 
arbitrary other proxies. Either it has a limited set of peers (such as 
in case of an IP-PBX peering with a service provider), or it routes 
using DNS based on the domain in the request URI (or top Route header). 
For the latter case, the act of sending the INVITE itself will detect 
reachability.

So I suggest to limit the proxy-to-proxy use-case for keep-alive to 
proxies that route towards a limited set of next hops (instead of DNS on 
domain). According to RFC3261, such proxies would insert a Route header 
(with loose routing)

Regards,
Jeroen

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 26 Jun 2008 10:06:05 +0200

Hi, 

>We're mixing different cases here. The 3GPP non-register emergency call scenario is for an endpoint, I was talking about 
>the proxy-to-proxy case (I believe the 3GPP case can be addressed using standard mechanisms available today, it's only 
>about authorization policies and identification of what calls are emergency calls).
>
>It doesn't make sense for a proxy to keep-alive connections with arbitrary other proxies. Either it has a limited set of 
>peers (such as in case of an IP-PBX peering with a service provider), or it routes using DNS based on the domain in the 
>request URI (or top Route header). 
>For the latter case, the act of sending the INVITE itself will detect reachability.
>
>So I suggest to limit the proxy-to-proxy use-case for keep-alive to proxies that route towards a limited set of next hops 
>(instead of DNS on domain). According to RFC3261, such proxies would insert a Route header (with loose routing)

Ok. Thanks for the clarification.

So, if I understand you correctly you either:

1. Propose that proxy-to-proxy should not be part of the scope of the draft
2. Proxy-to-proxy could be part of the scope of the draft, but we would not necessarily use the same mechanism for UA-to-proxy and proxy-to-proxy.

Correct?

Regards,

Christer

Christer Holmberg wrote:
> Hi,
>
>   
>> The only solution I can think of that would give less processing, 
>> would be to simply open a TCP connection (or UDP flow with STUN) 
>> without sending any request. Less "overkill", but it would open up a 
>> bunch of security issues ( e.g. TCP connection resources being 
>> consumed by unauthorized elements, leading to DoS; all the concerns with STUNning before checking support, etc. ). So I don't see how sending at least one SIP request could be avoided. REGISTER is as good as any.
>>
>> provisioned somehow, this is no different from having to provision 
>> which outbound proxy to use
>>     
>
>> there's a few other reusable things, like Path headers, but let's 
>> keep it simple for the moment)
>>
>> Regards,
>> Jeroen
>>
>> Hadriel Kaplan wrote:
>>   
>>     
>>> Hey Jeroen,
>>>> performing registration. It could also be setup asymmetrically, 
>>>> with the (smaller) IP-PBX doing a single registration towards the
>>>>> proxy-to-proxy use
>>>>>> whatever big enough NOT to be doing Registration, and to instead 
>>>>>> do static
>>>>>>         
>>>>>>           
>>>>>>             
>>>> (interestingly mostly in APAC region) There's also some concern 
>>>> that while a static entry is there for inbound TCP connections, the 
>>>> PBX creates outbound ones to the service provider which are 
>>>> ephemeral port sources and need to live for very long durations 
>>>> (though why they can't just do TCP keepalive is beyond me, but I'm no expert).
>>>>     
>>>>       
>>>>         
>>>> Today that's almost exclusively done with Options requests as far 
>>>> as I've seen, and lots of people don't seem to like that.
>>>>     
>>>>       
>>>>         
>>>>>> -hadriel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>         
>>>>>>           
>>>>>>             
>>>>>>> connected to (or peering with) a service provider proxy through 
>>>>>>> a NAT and/or a firewall. However, wouldn't such a NAT or 
>>>>>>> firewall be under the administration of either the enterprise 
>>>>>>> itself or its ISP (who quite often would be the SIP service 
>>>>>>> provider), and the required port forwardings or firewall rules could be set through administration.
>>>>>>> Wouldn't we then need keepalives for SMTP as well, or how has 
>>>>>>> the e-mail infrastructure managed to solve this problem?
>>>>>>>
>>>>>>> Markus
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>             
>>>>>>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 26 Jun 2008 10:11:18 +0200

Hi,

Another thing.

As currently defined in the draft, when the "keep" parameter is used for non-registration calls (no matter whether it's UA-to-proxy or proxy-to-proxy) the duration is only for the lifetime of the call.

When the "keep" parameter is used for registration calls, the duration is for the lifetime of the registration (as for Outbound).

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 26. kesäkuuta 2008 11:06
To: Jeroen van Bemmel
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sip] Progress draft-holmberg-sip-keep: proxy-to-proxy use case

Hi, 

>scenario is for an endpoint, I was talking about the proxy-to-proxy 
>case (I believe the 3GPP case can be addressed using standard mechanisms available today, it's only about authorization policies and identification of what calls are emergency calls).
>
>in case of an IP-PBX peering with a service provider), or it routes using DNS based on the domain in the request URI (or top Route header).
>proxies that route towards a limited set of next hops (instead of DNS 
>on domain). According to RFC3261, such proxies would insert a Route 
>header (with loose routing)

1. Propose that proxy-to-proxy should not be part of the scope of the draft 2. Proxy-to-proxy could be part of the scope of the draft, but we would not necessarily use the same mechanism for UA-to-proxy and proxy-to-proxy.

Correct?

Regards,

Christer

This list is for NEW development of the core SIP Protocol Use [email-masked] for questions on current sip Use [email-masked] for new developments on the application of sip

---

From: "Kevin Johns" <[email-masked]>
Date: Mon, 30 Jun 2008 15:38:08 -0600

Q1: I agree that the emergency services use case is important. However,
I would like to see the statement that some devices do not support
outbound but want to use the keep alive mechanism be further clarified
(what devices this applies to and why they would not implement outbound
- I think this has already been discussed on the list).

Q2: Based on my comments to Q1, I would like to see the requirements
narrowed in scope to only be in the context of a dialog initiating
request outside of a registration. The reason being that outbound is the
approach defined by the WG for client to Edge Proxy NAT traversal and I
don't think there is a strong need for more tools which allow the
creation of another NAT traversal solution. This narrowing of scope
would still allow support by devices which would not implement outbound
and are not providing edge proxy functionality.

Regards,
Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
DRAGE, Keith (Keith)
Sent: Thursday, June 19, 2008 3:31 AM
To: [email-masked]
Cc: Christer Holmberg
Subject: [Sip] Progress draft-holmberg-sip-keep

(As SIP WG cochair)

Regards

Keith