Hi,
>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.
Isn't the second part ("be able to correct for this") of item 4 related
to 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 personally think that the definition of instance-id belongs to the
gruu spec.
But, I assume that has been discussed before, so...
>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.
To me the main problem is not that the keepalives are defined in
Outbound, but that it is currently not possible to negotiate the usage
of them without Outbound. But, the intention of the keep draft is to
solve that.
Regards,
Christer
>-----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
