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

From: Michael Hammer <[email-masked]>
Date: Fri, 14 Mar 2003 14:12:20 -0500

Jon,

In a couple places you use the term "call path".  Could you clarify what 
you are referring to here?

I gathered from the original draft (that your draft critiques), that you 
are focusing on the SIP signaling only and not the media path taken?  Or is 
this a more general reference to the sequence of networks one must traverse 
to get to the endpoint or PSTN GW?

Also, I am curious about how tightly or loosely coupled the media path and 
signaling path are, given that it may not be just proxy or PSTN GW 
resources that may be congested, but the media path resources, in light of 
possible QoS usage.

I can appreciate that the target of the SIP INVITE can be diverted to an 
appropriate ETS-aware endpoint through (at the earliest recognition of a 
ETS priority header) possibly ETS-aware proxies.  But, does that ensure 
that an ETS media path finds ETS-aware networks that might set aside media 
resources and avoid ETS-unaware congested networks?

Also, has anyone given thought to how to route around countries that are 
antagonistic towards another country's perceived "emergency"?  I gather 
this is behind some of the anonymity requirements, but suspect this may 
come down to local policy implementation.  (Spare me the Internet does not 
recognize national boundaries rhetoric.)

Mike

At 06:02 AM 3/14/2003 -0500, Peterson, Jon wrote:

>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

_______________________________________________
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: Sat, 15 Mar 2003 16:29:19 -0500

> come down to local policy implementation.  (Spare me the Internet does 
> not recognize national boundaries rhetoric.)

It's your choice: you can use tel: and hope/test that the receiving 
gateway is ETS-capable. Or you can use sip:12345@your-favorite-ets-provider.

If you don't trust the SIP nodes along the way to not mess with the ETS 
indicator (Resource-Priority, in our draft), you need to stick it in an 
S/MIME body, but then lose the ability for proxies to help you out.

These are all operational choices, whose advisability will probably 
change as SIP elements become ETS-aware, may depend on how much you know 
about the network, etc.

The goal here, I think, is to make sure that any mechanism works as well 
as can be expected in most circumstances, does not interfere with normal 
SIP operation of the ETS-unaware and works better as more elements 
become ETS-aware. (I think the last sentence is pretty much true for any 
SIP extension that is optional-to-support.)

Henning