Subject: RE: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t xt

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Fri, 14 Apr 2006 19:10:43 +0200

Paul,

In your example you indicate that Provider-B behaved in a compliant manner.
Fine.

However if Provider-A does not trust the early media sent by Provider-B is
will certainly not let it through there is nothing IETF can do about this
(regardless of the outcome of this P-header).

My advice to Provider-B here is to "gain trust with Provider-A" so that it
can actually make its services work properly for its customers of
Provider-B. I don't think that Provider-B will be able to impose whatsoever
by saying that it complies with RFC xxx.

sébastien

-----Message d'origine-----
De : Paul Kyzivat [mailto:[email-masked]] 
Envoyé : vendredi 14 avril 2006 16:41
À : Ejzak, Richard P (Richard)
Cc : Cullen Jennings; Jon Peterson; Gonzalo Camarillo; Mary Barnes; sipping;
Aki Niemi
Objet : Re: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t xt

Richard,

A few added words added to the draft here and there will adequately deal
with most of the issues here.

But the fundamental issue is whether blocking early media by default, and
without the awareness of *both* UAs, is valid or is in fact a violation of
sip. IMO it is a violation.

In the cases you cite as examples where early media is not possible:

> There are plenty of examples in existing RFCs where an answerer is not 
> able to send media immediately upon sending an answer.
> Preconditions come to mind. 
> Receipt of a black hole address is another. 

the two UAs are complicit and aware of what is going on, and so are able to
adapt their behavior to the circumstances.

In the case of preconditions, if they are used in the offer but the answerer
doesn't understand, then the offerer knows the answerer doesn't understand
and is expected to make things work appropriately.

In the case of a black hole address, again it is obvious to both that there
will be no successful delivery of media to the black hole.

Another example you didn't mention is if the offer contains a=sendonly or
a=inactive. Again both parties then know the score based on public
standards. Even then the offerer is supposed to recognize if the answer
indicates a lack of understanding, and should deal with it.

What draft-ejzak-sipping-p-em-auth-00 proposes doesn't have these
properties. Notably, the UAs is never informed that early media will not
work. Consider the following use case:

- UA-A is registered with AOR-A at Provider-A, which uses
   draft-ejzak-sipping-p-em-auth-00 to manage early media

- UA-B is registered with AOR-B at Provider-B, which does *not*
   use draft-ejzak-sipping-p-em-auth-00. (Provider-B
   permits early media.)

- There is no trust relationship between Providers A & B.
   Calls are forwarded between them using basic RFC 3263
   procedures. But Provider-A will not accept a P-Early-Media
   header from Provider-B. (And Provider-B wouldn't know to
   provide one anyway.)

- Provider-B provides a call screening feature. Incoming calls
   to AOR-B go to a server (AS-B) that uses early media (Gateway
   Model) to prompt for and receive a password. If the proper
   password is provided, the call is forked to the registered UA-B
   where it rings and may be answered. If the incorrect password,
   or no response, is provided, the call is rejected by the server.

- UA-A sends an INVITE to AOR-B. Then AS-B tries to
   send a password prompt in the media stream to UA-A and read
   the response. But Provider-A has blocked the media stream, so
   no response arrives. Eventually AS-B terminates the call,
   so UA-A fails in its attempt to call AOR-B.

(Note that the feature could be provided using either the Gateway Model or
the Application Server model. I here assume the Gateway Model because it
doesn't require support for any extensions, except possibly PRACK.)

In this case, Provider-B behaved in a standards compliant way, and yet the
result was bad because Provider-A did something non-standard. And neither
user has a clue why this failed, and neither had any real option for how to
fix it.

If AS-B knew that early media was not supported, it could adjust its
behavior - perhaps just returning a 403 Forbidden response. Then UA-A would
at least know something was amiss. One thing that comes to mind is for
Provider-A to insert a P-Early-Media header into the request as well as the
response. But this would violate the rules of P-headers because it changes
behavior and so depends on the recipient understanding the P-header.

Two possible solutions come to mind for me:

1) stop trying to be so picky. Just allow early media all the time.
    If you are concerned about fraud, charge for the early media.

2) explicitly indicate in the offer that early media isn't supported,
    e.g. using a=inactive. Also indicate support for the Application
    Server model of early media. Gateways and application servers that
    need early media and are allowed to use it can then negotiate an
    early-session to do it.

Some other odds and ends of comments inline. I've snipped the old text down
to just what is relevant.

	Paul

Ejzak, Richard P (Richard) wrote:

>>There may be some potential overlap with RFC 3959. It provides an 
>>explicit way to signal an intent to exchange early media. This draft 
>>doesn't explain what if any impact it has on that mechanism.
>>
>>That mechanism can result in two offer/answer exchanges going on in 
>>parallel, and negotiating different media streams. Those negotiated 
>>using early-session are *intended* for early media. One would hope 
>>that P-Early-Media would not apply to those.
> 
> P-Early-Media was never intended to apply to "early-session" media.  I
will clarify this.

Thanks.

>>- ICE depends on being able to send packets that are for all intents a 
>>form of early media.
> 
> Messages used for ICE, such as STUN, can be gated separately from RTP
flows in networks needing to support NATs.

It would be good to indicate that the gating is intended to be sensitive to
the content type, rather than applying to everything to/from the port.

>>- using the "gateway" model, early media cannot be distinguished from 
>>"regular" (late?) media that outruns the signaling that the call has 
>>been answered. So blocking "early" media can also block some "regular"
>>media.
> 
> It is appropriate to include text to warn of this possibility.

OK. But I'm not convinced it is sufficient to warn that one is planning to
violate the specs.

>>>As a side comment, the draft also doesn't explain what would happen 
>>>in a scenario where early media is not allowed, indicated by
>>>"P-Early-Media:
>>>inactive", and is therefore gated off; yet the UAC doesn't support 
>>>the proposed extension. How does it handle getting silence while 
>>>expecting early media?
> 
> According to RFC 3960, a UAC has to be able to deal with either the
presence or absence of early media, regardless of the value of the header,
so I don't see what the issue might be.

My scenario above deals with a related case in more detail. It covers the
case where the callee doesn't support the extension.

Its a little different when the caller doesn't support it. Of course the
caller can never know for sure if the callee expected it to get early media.
So in some sense it doesn't have to deal with this case.

>>- It isn't clear about state model - how the use of this new header 
>>interacts with offer/answer. Is this a new piece of dialog-usage state 
>>that remains until changed? Is it permissible to change the state in a 
>>response that doesn't contain an offer or answer?
> 
> The answer to both questions was intended to be "yes".  I'll make sure
it's clear.

Thanks.

>>- It doesn't discuss the relationship of this header to cases where 
>>there is more than one early dialog. (As a result of forking.)
> 
> It is intended to apply independently to each dialog.

It is relatively obvious that this is intended, but it wouldn't hurt to
mention forking and discuss the implications on all parties.

>>- It doesn't discuss its impact on reINVITE. One might presume that 
>>this header is meaningless once the call is answered, but that isn't 
>>discussed.
> 
> It is intended to apply only to the early dialog.

It would be helpful to mention this then talking about the processing of
INVITE messages and responses - that the procedures only apply to an
*initial* (dialog forming) INVITE.

>>- It doesn't discuss its interaction with UPDATE, which may happen 
>>before the call is answered, and which may have an additional offer or 
>>answer. For instance the UAS for the INVITE may send an UPDATE with a 
>>new offer. There might be need to change early media authorization at 
>>this time.
> 
> It was intended that if early media authorization changes at the same 
> time as an offer/answer exchange in an UPDATE transaction, that the 
> UAS would send a separate provisional response with the early media 
> header to indicate the change.  If you are proposing to add the header 
> to the UPDATE request, that would be a reasonable thing to do.

Either way can work. Allowing the header in UPDATE and responses to UPDATE
would save a message exchange. Either way it would be useful to mention the
case and how it is to be handled.

>>- It assumes that authorization for early media is all-or-nothing if 
>>there are multiple media streams. If you believe early media needs to 
>>be authorized, then it seems likely that the policy might vary from 
>>stream to stream. Using 3pcc and B2BUAs it is even possible that two 
>>media streams in one offer or answer may originate at different UAs.
> 
> It would be quite easy to allow multiple direction parameters to apply 
> in order to separate media lines, as you seem to propose.  This would 
> also be a reasonable thing to do.

This would change the syntax quite a bit, and its not clear how you would
correlate values to particular media lines. Seems like a bit of a hack.

Making such a change would not eliminate my primary objection to the overall
concept. (It would be more a case of perfuming the pig.) So I'm not sure
such a change would be an improvement.

>>- NIT: there are no provisions in the header syntax for future 
>>extensibility.
> 
> OK.

Having already encountered multiple P-headers without provisions for
extensibility, and where it has later proved to have been a mistake, I am
going to keep raising this issue for every P-header. It is really cheap
allow generic-param on every header.

	Paul

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Apr 2006 14:26:41 -0400

> by saying that it complies with RFC xxx.

The "trust" here seems to be tied to the billing model. Apparently the 
assumption here is that early media is permitted for certain network 
provided features, but not for UA-UA communication. As a result, "trust" 
could only ever by present between entities that have a business 
relationship for purposes of billing for telephony services.

That only seems to work for an analog of the existing walled garden.

SIP is designed to permit calls between parties that have no business 
relationship other than both being connected to the internet.

If I want to call someone with a sip address on the internet, am I going 
to be prevented from making a successful call if the callee, or the 
callee's provider, doesn't have a business relationship with *my* provider?

It seems like the proposal here will abet a strategy that is sip-based 
but is in fact only interoperates with other sip nodes when it suits the 
operator's purposes.

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Tue, 18 Apr 2006 10:58:49 +0300

Inline.

> relationship for purposes of billing for telephony services.

I think so too. When I read the draft, my impression was that the main
motivation for the extension is to enable inter-provider ability to stop
toll-fraud using early media. If early media doesn't cost per-minute,
but real media does, then UAs could simply use early media for the
session and never complete the dialog.

Having said that, any per-minute charging triggered by SIP messages is
just a bad idea; this concept of transitive trust IMHO is generally a
bad idea and just unfortunately leaked into the Internet from the PSTN
once it was connected. ;)

> but is in fact only interoperates with other sip nodes when it suits the

This is discussion of business models, not protocols. RFC 3960 and RFC
3959 already mention this issue, and propose this in the security
considerations:

   On the other hand, some application servers (e.g., Interactive Voice
   Response systems) use bidirectional early media to obtain information
   from the callers (e.g., the PIN code of a calling card).  So, we do
   not recommend that operators disallow bidirectional early media.
   Instead, operators should consider a remedy of charging early media
   exchanges that last too long, or stopping them at the media level
   (according to the operator's policy).

I think the draft in question addresses the issue at the very end of the
passage. I gather that the intent is that this "operator's policy" be
shared among a set of consenting providers, and made explicit. Given
that the model already exists in 3959/3960, I don't think the draft
significantly alters the behavior of such nodes; if anything, it makes
the implicit policy explicit.

But I agree it does sound like walled gardens or cartels, and I really
doubt whether such operators would allow calls to my domain, a home of a
whopping 3 SIP users (one of them a bot ;). But this is why it's a 'P'
header, and that's why applicability statements are made.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Apr 2006 09:12:39 -0400

It seems to me that if we are willing to find this draft acceptable then 
we should also just come out and state formally that any UA sending 
early media via the gateway model should assume that it probably won't 
be received unless it is aware of the policies in effect on the entire 
path to the peer. Maybe that is the actual state of affairs, but I hope not.

Note that I am *not* opposed to service providers charging for their 
services. If the stated purpose of this header was to determine whether 
to charge for early media then I would have no problem. Nor would I have 
a problem with a mechanism by which a UA could ask to have early media 
blocked in cases where it would otherwise be charged for it.

	Paul

---

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 18 Apr 2006 09:44:23 -0400

> path to the peer. Maybe that is the actual state of affairs, but I hope not.

You're probably right in all your points, but ... I just don't see why
it matters.  I tend to think of early media as a weird hack, really.
The more I think about it, the less it makes sense to me.  That's a
purely emotional argument, I know.  But from a more intellectual point
of view, if you're really going to interchange media, why aren't you
"establishing" a dialog, that's the point of dialogs.  If you just want
to tell the caller that he's 437th in line, we've already got a "Call
Progress" response for carrying such small bits of info.  I envision
that 99.9% of all early media will be "Your call is very important to
us...".

So I guess my position is that it is not a *significant*
interoperability problem if early media doesn't generally work when you
call somebody on the Foo-Network.

I don't claim that's a persuasive argument; there's probably a good
explanation for why I'm wrong.  But I haven't seen that explanation in
this conversation yet, and I think that explanation is the core point of
the issue, and that explanation really needs to be put on the table.

Dale

---

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 18 Apr 2006 10:09:40 -0400

After reading the following exchange, I'm a bit better informed.

I've reorganized the following passages to simplify my comments.

> > header, and that's why applicability statements are made.

This does seem to be a fairly strong argument in favor of the proposed
header -- what the header regulates is behavior that seems to be
admitted by the RFCs.

> > once it was connected. ;)

It does seem that the per-minute billing model is a poor fit to the
realities of the network.  But for the time being, that's the only
billing model there is, and we are likely to have to cope with it.  (We
could also reform the English spelling system before using English verbs
as method names...)

(Ironically, one reason per-minute is so popular is that it minimizes
the amount of trust that the customer has to put into the carrier, since
the user can time the call himself and check the bill.  "Economically
rational" congestion-based charging leaves the customer taking the
carrier's word for it.)

In this context, it's rather odd that the carrier would permit any
significant information transfer in early media, such as PIN entry, as
someone mentioned.  Effectively, the carrier is giving a particular IVA
user a discounted rate, as a certain fraction of the information
transfer is not charged.  And not only is that carrier sacrificing, it
is also sacrificing a fraction of what the interconnecting carriers
would otherwise be billing for.

I agree that transitive trust is a difficult thing to implement, but it
seems to be necessary in economic systems.  Think of the amazing web of
transitive trust that you invoke when you write a check.  How would you
establish an individual trust relationship with every network that
carries your packets?

> path to the peer. Maybe that is the actual state of affairs, but I hope not.

I've previously mentioned this.

> blocked in cases where it would otherwise be charged for it.

What would such a mechanism look like?  If it was no more complicated
than the current proposal, and achieved the business goals of the
current proposal, and was philosophically better, we could adopt it as a
replacement.

Dale

---

From: David R Oran <[email-masked]>
Date: Tue, 18 Apr 2006 10:42:29 -0400

On Apr 18, 2006, at 9:12 AM, Paul Kyzivat wrote:

> It seems to me that if we are willing to find this draft acceptable  
> then we should also just come out and state formally that any UA  
> sending early media via the gateway model should assume that it  
> probably won't be received unless it is aware of the policies in  
> effect on the entire path to the peer. Maybe that is the actual  
> state of affairs, but I hope not.
>
> Note that I am *not* opposed to service providers charging for  
> their services. If the stated purpose of this header was to  
> determine whether to charge for early media then I would have no  
> problem. Nor would I have a problem with a mechanism by which a UA  
> could ask to have early media blocked in cases where it would  
> otherwise be charged for it.
>
This seems a superior semantic to what has been proposed.

---

From: Dean Willis <[email-masked]>
Date: Mon, 24 Apr 2006 10:35:28 -0500

> would otherwise be billing for.

Quite true, but that's the way it works in the PSTN today.

If you call the American Airlines 1-800 service bot, the call does not 
actually enter a "connected" state until 1) Their first set of 
announcments is played out, and 2) you send a DTMF input for menu selection.

When one sticks a SIP-PSTN gateway in front of this (for example, in the 
old dynamicsoft office where we had Pingtel and Cisco 7960 phones 
connected through a Cisco 3640 gateway on an ISDN PRI), the entire 
first-menu transaction is seen as "early media" by the SIP-phone. This 
was occasionally a major problem, as either the phone or the gateway had 
a 30-second timer on its early-media state, and if I didn't navigate the 
AA menu quickly, I got disconnected. Since I was usually doing something 
complicated, I got disconnected a lot.

Personally, I wish we'd designed this without early-media at all. It's a 
painful bit of complexity introduced by the phone network that we didn't 
really need and probably should have rejected, and its only excuse for 
existing is to maintain the charging model of the PSTN, including the 
exploit against that charging model described as "rather odd" above.

But given what we have, transparent support of early media is required 
for normal communication through a PSTN gateway. Of course, we know this 
breaks horribly when cross-factored with parallel forking (Dean's first 
rule of forking: never fork in parallel if one leg might end up on the 
PSTN. Since you usually don't know, this leads to the second rule: never 
fork!).

That said, I do find myself wondering if the proposed P-header changes 
system behavior in an "unexpected" way, and my initial reaction (having 
read through the debate to-date) is that it very well might. And we 
really can't have P-headers making that kind of change.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Apr 2006 11:55:16 -0400

> would otherwise be billing for.

Its my impression that the only cases the carrier *wants* to permit are 
those where the early media is generated by servers controlled by it or 
its partners. This includes announcements, such as that a line has been 
disconnected, that people have been trained to expect to get for free. 
It also includes *features*, such as DND with PIN override, where the 
provider imagines it has a monopoly on provision of the service and is 
willing to bundle the cost into the callee's price for the feature.

I suspect that cases like AA Sabre getting some free minutes per call 
started out as artifacts that weren't intended to be used that way but 
weren't adequately protected, and which are now grandfathered in and 
protected by the power of a big customer to take its business elsewhere 
if the feature is removed.

	Paul

---

From: [email-masked]
Date: Mon, 24 Apr 2006 11:04:17 -0500

So we're saying that carriers are not only opening backward channels but also opening forward channels for early media and eating the cost ? 

James

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 24 Apr 2006 19:12:24 +0300

> PSTN. Since you usually don't know, this leads to the second rule: never 

i value forking a much more important service to customers than early
media.

-- juha

---

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 24 Apr 2006 16:49:17 -0400

> PSTN. Since you usually don't know, this leads to the second rule: never 

Or in practice, people use Rule 1 and 1/2:  Usually, people can tell in
advance which "numbers" might lead to a mandatory early-media session,
and they can avoid using them in parallel forking sessions.  (E.g., the
"also forward my extension to my call phone" number is unlikely to
require early media, but the "number dialed on the phone" is likely to.)
Which just underlies the general yuckiness of the situation.

Dale

---

From: Dean Willis <[email-masked]>
Date: Tue, 25 Apr 2006 09:07:22 -0500

On Apr 24, 2006, at 11:04 AM, [email-masked] wrote:

>
> So we're saying that carriers are not only opening backward  
> channels but also opening forward channels for early media and  
> eating the cost ?
>

Yep. So we're in a catch-22 where the PSTN people tell us they want  
to control media in a billable fashion based on the signaling, except  
for when they just spontaneously decide not to.

I maintain that accepting requirements from the PSTN that just don't  
make sense was a fundamental mistake.

Personally, I'd be tickled pink to just throw out the whole concept  
of early-media. You want to send media, send a 200 first. It changes  
the PSTN interworking state machine and doesn't preserve the  
(obviously broken) PSTN charging semantics (like "start charging on  
the 200"), but it makes life MUCH easier for the SIP implementations,  
and makes forking almost work. I think that's a reasonable compromise.

--
Dean

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 25 Apr 2006 12:46:34 -0400

I suspect it's a bit late to retract backwards compatibility with the PSTN
in SIP.  If we ever started again, I'd put that as the very first rule -- We
don't implement anything just because the PSTN does it some way.  I
certainly believe early media is a mistake, and we wouldn't do that in some
future protocol.

But, early media is a fact of life now in SIP 2.0, and I don't think we can
change it any more than we can deprecate forking.  

The question comes back to: do we need to add more mechanism to a broken
concept in the quest to maintain backwards compatibility to PSTN?

So, early media is a fact of life in the PSTN; you can send media before the
signaling completes.  You can't authorize it; it always works at least one
way.  So, I think we don't have to go beyond that.  I think there are
sufficient mechanisms to prohibit outbound early media in carrier
deployments.   They use SBCs for that.  I think the kind of carrier that
wants to monkey around with sometimes early media is okay and sometimes its
not is the kind of carrier that just has to have an SBC.  

I think carriers who don't need SBCs don't care about early media either
way.

Brian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Tuesday, April 25, 2006 10:07 AM
To: [email-masked]
Cc: Paul Kyzivat; Sipping
Subject: Re: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t
xt

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Apr 2006 13:54:01 -0400

Brian,

Using an SBC to to block early media is functionally no less bad than 
using a proxy to block early media. In fact they may well be assuming 
the use of an SBC even though they say "proxy" in order to pretend 
political correctness. In any case, the purpose of the proposed header 
can be viewed as providing a way to at least sometimes allow early 
media. I'm not sure which is worse - never allowing it or sometimes 
allowing it without the guy sending knowing if it will work.

I don't find what has been proposed to be especially constructive. But I 
think there is an opportunity to do something here by making some 
changes that allow early media in the gateway model to be *negotiated* 
(by the UAs *and* middleboxes), so that both parties end up knowing 
whether it is going to work. This could be used to recognize when 
forking will prevent early media from working.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 25 Apr 2006 19:50:24 -0500

On Apr 25, 2006, at 12:54 PM, Paul Kyzivat wrote:
>
> I don't find what has been proposed to be especially constructive.  
> But I think there is an opportunity to do something here by making  
> some changes that allow early media in the gateway model to be  
> *negotiated* (by the UAs *and* middleboxes), so that both parties  
> end up knowing whether it is going to work. This could be used to  
> recognize when forking will prevent early media from working.

Ok, let's advance a strawman argument.

1) If we were to have a standards-track way to negotiate the use of  
early media, would this obviate the need for the P-header hack under  
review?

2) What might such a standards-track mechanism look like?

Would an option-tag for early-media-positive and another for early- 
media-negative that could be placed in both Require: and Proxy- 
Require: by the originating UA be adequate? As I see it, this would  
lead to us trying the request one time with early-media-positive,  
potentially getting rejected by forking proxies or policy-enforcing  
proxies, retrying with early-media-negative, only to get rejected by  
a PSTN gateway that knows it needs early media to work . . . But at  
least we'd know exactly what was broken instead of just guessing in  
the dark like we are now.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Apr 2006 10:51:24 -0400

Dean,

Perhaps options could be used for this. But they would result in failing 
requests and retrying, with the resulting HERFP problems. And forking is 
one of the big problems in this regard so HERFP is a significant issue.

Rather than failing the call, perhaps it would be sufficient to simply 
have the UAC and UAS end up knowing whether early media is supported for 
the call. If not, the behavior can be adjusted accordingly or else the 
UAs can terminate the call early. This could be a header inserted by the 
UAC indicating if it supports sending or receiving early media, and then 
permitting a middle box along the path to reduce this if it constrains 
the early media in some way. Eventually it gets to the UAS, which can 
also reduce it if desired, and put the result in the response. It 
shouldn't be updated further on the way back. Then the UAC and UAS know 
what is supported end to end.

Dealing with forking will still be tricky. It may be necessary for the 
UAC to declare how it handles early media in forking cases, and then for 
the forking proxy to adjust things when it does fork. (I need to think a 
lot more about that.)

For the behavior that TISPAN is seeking, this probably wouldn't be 
enough. There would still need to be a way to assert privilege to use 
early media.

	Paul

Dean Willis wrote:
>> *negotiated* (by the UAs *and* middleboxes), so that both parties  end 
>> up knowing whether it is going to work. This could be used to  
> media-negative that could be placed in both Require: and Proxy- Require: 
> by the originating UA be adequate? As I see it, this would  lead to us 
> trying the request one time with early-media-positive,  potentially 
> getting rejected by forking proxies or policy-enforcing  proxies, 
> retrying with early-media-negative, only to get rejected by  a PSTN 
> gateway that knows it needs early media to work . . . But at  least we'd 
> know exactly what was broken instead of just guessing in  the dark like 
> we are now.
> 
> -- 
> Dean
>

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 28 Apr 2006 22:10:45 -0400

You guys crack me up.
Yes SBCs can stop early media, and can do it now (though it's not very
common for them to do it).  But here you have a draft that proposes a way
for a UAC to do it without an SBC, and only if the UAC wants to, so that
SBCs don't have to - isn't that good thing from your perspective?  

It's trying to do it in a way that only a proxy needs to give it an
indication of the trust level of the UAS.  And proxies do trust
determination for other things already in the IETF.

-hadriel

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Tuesday, April 25, 2006 12:47 PM
> To: 'Dean Willis'; [email-masked]
> Cc: 'Paul Kyzivat'; 'Sipping'
> Subject: RE: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t
> xt
>

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 29 Apr 2006 07:10:51 -0400

And here I though I was helping you :)

Let me be more clear:
  I think early media, in all forms, is a bad idea
     It was a mistake to allow early media
  I think stopping early media, in any form, is a bad idea
  I think creating new mechanisms to authorize or stop early media
    is a bad idea.

Those that want to have, or not have, early media have tools.
We don't need to create more tools.

Brian

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, April 28, 2006 10:11 PM
To: 'Brian Rosen'; 'Dean Willis'; [email-masked]
Cc: 'Paul Kyzivat'; 'Sipping'
Subject: RE: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t
xt

You guys crack me up.

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 29 Apr 2006 10:10:17 -0500

Well said.

----
François AUDET, Nortel Networks
mailto:[email-masked]

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Sat 29-Apr-06 4:10 AM
To: 'Hadriel Kaplan'; 'Dean Willis'; [email-masked]
Cc: 'Paul Kyzivat'; 'Sipping'
Subject: RE: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t xt

Let me be more clear:

Brian

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, April 28, 2006 10:11 PM
To: 'Brian Rosen'; 'Dean Willis'; [email-masked]
Cc: 'Paul Kyzivat'; 'Sipping'
Subject: RE: [Sipping] Expert review of draft-ejzak-sipping-p-em-auth-00.t
xt

You guys crack me up.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Sun, 30 Apr 2006 12:43:46 -0500

> determination for other things already in the IETF.

The question, as I see it, is "Is this 1) something that it's ok for  
a P-header to do, 2) something that is a general sort of problem that  
we should tackle as a standards track effort, or 3) something that  
should not be done at all?"

I believe Brian and Francois have argued for case 3, and that Paul's  
position was more-or-less "If we must do it, then it would need to be  
a standards-track extension". Please correct me if I'm wrong here,  
folks.

RFC 3427 lays out a few conditions for helping us make this decision:

    1.  A designated expert (as defined in RFC 2434 [4]) MUST review the
        proposal for applicability to SIP and conformance to these
        guidelines.  The Expert Reviewer will send email to the  
Transport
        Area Directors on this determination.  The expert reviewer can
        cite one or more of the guidelines that haven't been followed in
        his/her opinion.

    2.  The proposed extension MUST NOT define SIP option tags, response
        codes, or methods.

    3.  The function of the proposed header MUST NOT overlap with  
current
        or planned chartered extensions.

    4.  The proposed header MUST be of a purely informational nature,  
and
        MUST NOT significantly change the behavior of SIP entities which
        support it.  Headers which merely provide additional information
        pertinent to a request or a response are acceptable.  If the
        headers redefine or contradict normative behavior defined in
        standards track SIP specifications, that is what is meant by
        significantly different behavior.

    5.  The proposed header MUST NOT undermine SIP security in any  
sense.
        The Internet Draft proposing the new header MUST address  
security
        issues in detail as if it were a Standards Track document.  Note
        that, if the intended application scenario makes certain
        assumptions regarding security, the security considerations only
        need to meet the intended application scenario rather than the
        general Internet case.  In any case, security issues need to be
        discussed for arbitrary usage scenarios (including the general
        Internet case).

    6.  The proposed header MUST be clearly documented in an (Individual
        or Working Group) Informational RFC, and registered with IANA.

    7.  An applicability statement in the Informational RFC MUST clearly
        document the useful scope of the proposal, and explain its
        limitations and why it is not suitable for the general use of  
SIP
        in the Internet.

So let's take these one at a time.

1) Aki handled a review. He found the draft acceptable.  Other folks  
pointed out some aspects he may not have considered, so it would be  
useful to get his opinion about those aspects "post discussion".

2) The document defines no option tags, although I think Paul (or  
somebody on the thread he started) indicated that we may need an  
option tag in order to effectively negotiate this option.

3) If we recognize the underlying problem here and accept it as a  
general problem that we would work on with a standards-track SIP  
extension, then we'd run afoul here. Otherwise, probably not, and  
we're ok on this question.

4) This is where most of the argument is. Several folks have argued  
that we're changing the behavior of SIP entities in a non- 
interoperable way, and given the lack of an OPTION tag, can't  
negotiate or even detect a requirement for the non-interoperable  
behavior. This makes me very, very nervous. SIP is already complex  
enough -- deliberately introducing multiple-personality-disorder  
would not make it any better.

5) I think we're safe on the security considerations.

6) This document is most of what would be required to make an RFC. I  
think we've had some feedback in the review that would, at the least,  
require a revision or two.

7) I personally find the applicability statement a little week. It  
needs to explain the limitations and why it is not suitable for the  
general internet much more strongly. For example, the impact of not  
being able to negotiate the behavior needs to be discussed and the  
failure scenarios that Paul described need to be discussed. In short,  
we must make clear why the "IMS gateway" case is special, different  
from the common case, and requires handling in a non-standard manner.  
 From my perspectives, P-headers are appropriate only where we have a  
clearly constrained case that obviously won't occur in the general  
Internet. I'd like to point out that P-Asserted-Identity was probably  
not a good P-header, since it fails on Questions 3 and 5, and that  
this has caused us a substantial amount of grief. Live and learn, right?

Now, the good news (from my personal perspective) is I'm neither  
chair nor AD of the SIPPING working group, so I don't have to make a  
call here. Yay! But I will go on record (as a co-author of RFC 3427)  
that I don't believe that this draft, at this time, quite meets the  
publication requirements of RFC 3427, and that I remain uncertain  
(due to Question #4, above) as to whether it ever will.

--
Dean Willis