Subject: Re: [Sipping] Event throttles

From: Aki Niemi <[email-masked]>
Date: Wed, 12 Apr 2006 13:15:41 +0300

Hi Dale,

ext Dale R. Worley wrote:
> This looks like a very useful addition, especially in limited-bandwidth
> environments.
> 
> The I-D could be improved by adding a few examples.  Also, why not add a
> "Working Code" section (as someone suggested a while back) describing
> the open-source implemention that you mention?

Sure I could do that, but I was afraid this would be sort of blatant
advertisement. After all, we're so used to talking in abstract terms,
like "a major deployment of SIP does X". ;)

FWIW, it's sofia-sip (http://sofia-sip.sf.net), in the nea module.

> As for Require/Supported/callerprefs:  In IMS/3GPP environments, there
> seems to be an architectural tendency to (in effect) subdivide the
> implementation of the UA for an AOR into a number of different
> "application servers" -- INVITEs will get routed to an actual user
> instrument, but NOTIFYs may get routed to a different subsystem entirely
> (and possibly NOTIFYs for different events get routed to different
> subsystems).  So it's best if an initial request manifests all the
> requirements that will be placed on the interaction, rather than "if the
> UA doesn't like answer it gets, it can terminate the dialog and try
> again".  (More on this concept later.)

Right, it seems to me there is pretty good support now for adding the
require/supported back in. So unless someone can point me to an
explanation of how such a thing is not useful or bad, I'll add the text
back in.

Thanks.

Cheers,
Aki

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

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 12 Apr 2006 10:20:00 -0400

On Wed, 2006-04-12 at 13:15 +0300, Aki Niemi wrote:
> > Also, why not add a
> advertisement.

A valid point.  OTOH, since the goal is to have at least two
interoperating implementations, your implementation won't be the only
one listed, which reduces that effect.

Dale