Hi Francois,

>I'm saying a new draft on redundant registration is needed, 
>and we can leave outbound AS IS.
>
>I thought about this more.
>
>I think what it means, is NOT using "Supported: outbound", but using 
>the +sip.instance and reg-id in the REGISTER. Perhaps with a different
>"Support: redundant-registrations" or whatever.
>
>The reg-ids will distinguish the multiple registrations. The 
>+sip.instance will correlate them.

Funny, but your proposal reminds me about the email which
I sent to sip mailing list in Nov 2006:

http://www.ietf.org/mail-archive/web/sip/current/msg17495.html

What I proposed that time was essentially this:
----
Outbound draft has bundled together two different things
that actually are orthogonal, both as problems and as
solutions too. The only reason to keep them together in
one single spec is that in some environments it makes
sense to use them together, but the problem is that in
some other environments separation would be desirable.

Those two items could be described like this:

- A mechanism with which an UA would be able to maintain a
  persistent flow through a NAT/firewall towards an outbound 
  proxy, keep the flow alive and monitor its state. The
  mechanism would also define how the authoritative and edge 
  proxies would use the persistent flow and Path header for 
  forwarding incoming requests to the UA.

- A mechanism with which an UA instance would be able to achieve
  high availability towards its home domain, by maintaining
  multiple simultaneous registrations without the need to
  receive multiple forked copies of a single incoming request.
  This resiliency would enable the UA to protect its connectivity
  against edge proxy failures or access network connectivity 
  failures. This mechanism would introduce the reg-id parameter
  to Contact and allow the authoritative proxy to forward
  requests to the UA using the set of registered Contacts
  and corresponding Paths.
----

I proposed to split Outbound to two drafts along with those
lines:
a) flow keepalive draft
b) multiple registration draft

Interestingly enough I find the proposed flow keepalive draft
to highly correlate to the Outbound original requirements
(from Keith's recent email):

   1.  Must be able to detect that a UA supports these mechanisms.
   2.  Support UAs behind NATs.
   3.  Support TLS to a UA without a stable DNS name or IP address.
   4.  Detect failure of a connection and be able to correct for this.
   5.  Support many UAs simultaneously rebooting.
   6.  Support a NAT rebooting or resetting.
   7.  Minimize initial startup load on a proxy.
   8.  Support architectures with edge proxies.

On the other hand, the multiple reg draft does not have any direct
relation to these requirements, even if you could argue multiple
registrations would be needed to make the solution more robust
against NAT reboots (item 6). To me it really attacks SIP proxy
reboots or any network failures for multihomed UAs, something
_not_ within the original requirements of Outbound.

>I think what it means, is NOT using "Supported: outbound", but using 
>the +sip.instance and reg-id in the REGISTER. Perhaps with a different
>"Support: redundant-registrations" or whatever.
>
>The reg-ids will distinguish the multiple registrations. The 
>+sip.instance will correlate them.

The only real difference between our proposals is that you
suggest usage of +sip.instance and reg-id to be defined in
a rather similar way in two drafts: Outbound and a new one.
I was proposing to move all that stuff to another draft so
that implementations could implement support for keepalives
and multiple registration either separately or combined,
depending on the problems they try to solve.

P.S. Personally I believe all this discussion is just too late,
decisions have been taken years ago and most of the WG members
are probably too tired with this subject to do any work for it.

Regards,

Erkki

>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Francois Audet
>Sent: 08.October.2008 19:48
>To: Juha Heinanen
>Cc: [email protected]; Paul Kyzivat; Christer Holmberg; DRAGE,Keith 
>(Keith); Dean Willis
>Subject: Re: [Sip] Dual registration without Outbound
>
>No.
>
>I'm saying a new draft on redundant registration is needed, 
>and we can leave
>outbound AS IS.
>
>I thought about this more.
>
>I think what it means, is NOT using "Supported: outbound", but using 
>the +sip.instance and reg-id in the REGISTER. Perhaps with a different
>"Support: redundant-registrations" or whatever.
>
>The reg-ids will distinguish the multiple registrations. The 
>+sip.instance
>will correlate them.
>
>This will be in line with what we did with GRUU which also can use the
>+sip.instance.
>
>A new draft describing this should be fairly simple to do, and 
>we wouldn't
>derail the process, and it would be very much in line with 
>sip-outbound.
>
>Makes sense?
>
>> -----Original Message-----
>> From: Juha Heinanen [mailto:[EMAIL PROTECTED] 
>> Sent: Tuesday, October 07, 2008 23:54
>> To: Audet, Francois (SC100:3055)
>> Cc: DRAGE, Keith (Keith); Dean Willis; Paul Kyzivat; 
>> [email protected]; Christer Holmberg
>> Subject: Re: [Sip] Dual registration without Outbound
>> 
>> Francois Audet writes:
>> 
>>  > Rather, I think this should be a new draft, and it should 
>> be  > independent from outbound.
>> 
>> so do you now finally agree to base outbound drfat on two new 
>> drafts that are also independent of outbound: dialog 
>> connection re-use and keepalive?
>> 
>> -- juha
>> 
>_______________________________________________
>Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [EMAIL PROTECTED] for questions on current sip
>Use [EMAIL PROTECTED] for new developments on the application of sip
>
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to