Subject: RE: [Sipping] Comments on draft-peterson-sipping-ieprep-00

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 14 Mar 2003 06:02:10 -0500

Some notes inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: King, Kimberly S. [mailto:[email-masked]]
> Sent: Thursday, March 13, 2003 5:59 PM
> To: 'Peterson, Jon '; ''King, Kimberly S.' '
> Cc: [email-masked]' '; [email-masked]' '
> Subject: RE: [Sipping] Comments on draft-peterson-sipping-ieprep-00
> 
[snip]
> 
> Okay, the ideas I'm about to present represent my personal thoughts. 
> 
> Why should ETS need to justify the absence of congestion in the access
links
> or other parts of the network (thereby proving optional preferential
> treatment is justified) when the default system operates without respect
to
> transport congestion?  We are just trying to increase our odds with the
> default system.  Why not have transport congestion issues, where
> appropriate, handled independently?
> 

Well, I didn't mean to pick on transport congestion - I was just trying to
illustrate a case in which part of the network didn't support ETS and it had
deleterious effects. There are clearly other aspects of partial coverage
that are worthy of analysis (some of which I just talked about in another
mail).

[snip]
> 
> I agree with you that if gateways are the only issue then this could
affect
> the design.  However, are there not media or application servers that
might
> also provide such preferential access?  
> 

That's a good point, yes. I wouldn't ordinarily think application servers
are constrained resources, but media servers tend to have ports, just like
gateways. I suppose that an emergency call could constitute listening to
some sort of announcements or leaving a message, which could entail a media
server, but I hadn't really given the matter much thought. On initial
reflection, I imagine that it would be more difficult to enable media
servers to handle prioritization than it would be for gateways... or at
least, given how diverse media servers are, it would be difficult to
generalize this emergency behavior into useful guidelines.
_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Fri, 14 Mar 2003 12:48:07 -0500

> generalize this emergency behavior into useful guidelines.

We don't need to specify precisely what happens - again, "increased 
probability". For example, depending on the size of the server, one 
server may just have two queues (hi/lo priority), another may preempt 
some existing lower-priority session. This is within the scope of end 
system behavior, just as much as deciding precisely how (say) a UI 
renders the Priority header or rings.