Subject: [RAI] Fwd: Re: Option-tag registration

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 04 May 2010 13:22:56 +0300

Folks,

I asked the following question a couple of weeks ago (see email below):

"Getting a few examples of option tags people would
like to register using the simpler registration method that has been
proposed would help focus this discussion."

Spending our limited cycles creating a process without having examples
of extensions that may use that process does not sound like the right
thing to do. Can people interested in this provide examples?

Thanks,

Gonzalo

-------- Original Message --------
Subject: Re: [RAI] Option-tag registration
Date: Tue, 20 Apr 2010 20:27:22 +0200
From: Gonzalo Camarillo <[email-masked]>
To: Hadriel Kaplan <[email-masked]>
CC: Dean Willis <[email-masked]>, Christer Holmberg
<[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>

Hi,

related to the INFO analogy, the design of the INFO events framework has
involved a great deal of mailing list discussion. There has been a
significant amount of energy spent on it. Surprisingly, not many people
have shown interest (so far at least) in registering new INFO packages
(this has been explicitly asked a couple of times during our
face-to-face meetings) now that the framework is (mostly) done. So, when
talking about option tags, let's make sure we have concrete rather than
abstract discussions. Getting a few examples of option tags people would
like to register using the simpler registration method that has been
proposed would help focus this discussion.

I fully agree we need to spend our (limited amount of) energy on
relevant issues. Having a sense of how relevant this issue is in
practice would be useful, IMHO.

Thanks,

Gonzalo

On 15/04/2010 2:10 AM, Hadriel Kaplan wrote:
> 
> 
>> -----Original Message-----
>> From: Dean Willis [mailto:[email-masked]]
>> Sent: Wednesday, April 14, 2010 6:33 PM
>>
>> ------- Original message -------
>>> From: Christer Holmberg <[email-masked]>
>>> Cc: [email-masked], [email-masked]
>>> Sent: 11.4.'10,  15:37
>>>
>>> The situation is very similar to the one we have with INFO, which we are
>>> now trying to solve with the Info Events mechanism.
>>>
>> And making INFO usages FCFS would have helped how?
> 
> We wouldn't have done info-events, we would have just done "info-dtmf" option-tag.  It would have been quick, easy, and simple.  And if someone else had needed INFO to carry their "events", they could have defined "info-foobar".
> 
> Sure it would have made more option-tag names instead of event names, and it would have been a specific solution to a specific problem, but incrementalism for specific needs is sometimes a better solution than a new framework.  It's often simpler, more interoperable, faster to market, and more widely adopted. 
> 
> Cases in point: Diversion vs. Hist-Info, sdp-cap-neg vs. best-effort-srtp et al, KPML vs. anything else.
> 
>  
>> The problem is that the extensibility model of "anything that can be
>> negotiated with an option-tag" is just too broad. When we have tightly
>> specced well-scoped extension models like Events (or like INFO is
>> becoming)
>> we can be liberal in what extensions we register. But letting just anybody
>> turn the protocol inside out is NOT a recipe for interop.
> 
> INFO didn't _really_ have those problems.  Not in practice.
> 
> -hadriel
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 5 May 2010 19:00:15 -0400

Good question.

So I'll list the first 10 proprietary extensions that I can remember or quickly find, all of which people *already use* today, and might or might not have been candidates had we had this thing all along. (some using proprietary option-tags, some not using an option-tag):

1) An extension for doing a specific SIP keep-alive mechanism.  Typically this is done between a UA and its next-hop proxy or registrar, to keep NAT pinholes open.  This was implemented before sip-outbound.  One example is a vendor that uses a proprietary SIP message for the keep-alive.

2) An extension for having the UA "fix" its SIP-layer addressing info, based on the public IP:port the server it's talking to sees (ie., the public one of the NAT).  The UA Registers through a proxy/registrar, and based on the Register response's Via received=/port= params, the UA modifies future Contact URIs and other header fields it sends, to be the public IP that proxy/registrar next-hop saw.  This was implemented before sip-outbound, and caused major interop issues because there was no option-tag.

3) An extension for not indicating presence by a Registration, but by a Publish using a different presence document format than IETF uses (with different info).

4) An extensions for supporting additional Register digest-challenge mechanisms, as well as clarified semantics for specific responses to REGISTER.

5) An extension for supporting a single Subscribe for multiple separate target presence info, and support for getting the info for those multiple identities in one Notify response. (using multi-part MIME)

6) An option-tag which indicates the client actually supports serial forking using q-values as per RFC-3261.

7) An option-tag which indicates support for compliance with a specific RFC (which did not itself have an option-tag).

8) An extension for notifying the UA in the Register response, that its version info is out of date and it needs to retrieve a new one.

9) An extension for notifying the UA that one of its registered bindings have been removed, without needing a Subscribe for reg-event to do so. (I guess you could argue the Register creates an implicit subscription, but I think that vendor sends the Notify out-of-dialog)

10) An extension for out-of-dialog Notify.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Gonzalo Camarillo
> Sent: Tuesday, May 04, 2010 6:23 AM
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 May 2010 06:31:26 -0600

Thanks - I think theses examples help sort out what to do. 

Cullen

PS - what list should this be on? I think rai is likely the wrong one. Seems like it should be on sipcore to me...

>> thing to do. Can people interested in this provide examples?

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 12 May 2010 08:52:24 -0500

I agree with Cullen on this one...

> PS - what list should this be on? I think rai is likely the wrong one. 
> Seems like it should be on sipcore to me...

Thanks,

Spencer

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 May 2010 22:03:10 -0400

+1  I agree as well. It's a sipcore issue. Lets fix it now. 

Too many of these issues are just festering out there like bad wounds
waiting to get infected.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Spencer Dawkins
Sent: Wednesday, May 12, 2010 9:52 AM
To: Cullen Jennings; Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [RAI] Fwd: Re: Option-tag registration

Thanks,

Spencer