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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 18 Apr 2006 16:43:44 -0400

Richard,

I read through the draft looking for how receipt of the following would
be handled:

"Thank you for calling the XXX line, the charges for this call will be
$10/minute rounded up to the nearest half hour.  If you have reached
this number by mistake, please hang up immediately as charges are
non-refundable.  Too bad we have intentionally messed up the
authorization for early media, so you likely did not even hear this
message.  Too bad.  Pay up promptly when you get the bill."

In, summary the design is fail-safe toward no media in the absence of
perfectly working authorization, but possibly putting the burden for
mistakes when it is not done correctly on the end-user who may have
little control over it.  I guess I am worried about unintended
consequences here.

On the other hand, if the intent is to break early media and drive
signaling design away from inband (in media) exchanges toward signaled
data exchanges rendered at the endpoint, then maybe this is not such a
bad thing to do. :)

I also did not understand the statements about not being useful for
interconnect, but then most of the subsequent discussion was about use
inter-domain.  It also seemed as though all existing proxies and
endpoint would be immediately rendered non-conforming until they added
this feature.  So much for backward compatibility.  (Those devices would
not work as they normally would before the feature was imposed.  To get
back to what they had before, they would have to add the feature.)

Lastly, some of the directionality should be checked.  In the INVITE
usage, if I understood this correctly, if a UAC wants to get only
backward media (receive it), it would advertise send-only???

Mike

> -----Original Message-----
> From: Ejzak, Richard P (Richard) [mailto:[email-masked]] 
> Sent: Tuesday, April 18, 2006 11:43 AM
> To: Dave Oran (oran); Paul Kyzivat (pkyzivat)
> Cc: Cullen Jennings (fluffy); Jon Peterson; Gonzalo 
> Camarillo; Mary Barnes; sipping; Aki Niemi
> Subject: RE: [Sipping] Expert review of 
> draft-ejzak-sipping-p-em-auth-00.t xt
> 
> 
> David R Oran wrote:
> > On Apr 18, 2006, at 9:12 AM, Paul Kyzivat wrote:
> > > 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.
> 
> This is just a particular (and reasonable) early media 
> policy.  One would still require some mechanism to signal the 
> use of authorized (free) early media through the network to 
> implement such a policy.  (And the P-header in the draft 
> would enable one to implement such a policy.)
> 
> I see no value in constraining the draft to only support the 
> policy you propose, however.  It wouldn't be "local policy" 
> then, would it?
> 
> Richard
> 
> _______________________________________________
> 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: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 18 Apr 2006 18:02:33 -0400

Hi Mike, comments inline...

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Tuesday, April 18, 2006 4:44 PM
> 

The XXX (why 30? ;) line UAS would give a 30 second grace period after the
call is _connected_ during which they'd replay the message and their billing
system would charge $0.  They'd learn to do that when they get the first
customer ticket, or when they try it themselves from the PSTN.  If they
don't want to pay the provider for those first 30 seconds, they'd work a
deal with them.  Otherwise it would be indistinguishable from "The following
are the movie times for this theater..."  

> little control over it.  I guess I am worried about unintended

Early media is already being blocked at or to PSTN-GW UACs today in some
deployments - this new header just lets the UACs play early media when they
feel it's appropriate.  The intended consequence is it lets early media work
to such UACs, when it didn't before.  Without this header, the only early
media they'll ever handle is after the 200ok.  

> back to what they had before, they would have to add the feature.)

Why is that?  There are some which "work" today, and such UACs are either
forced to not play early media, or an intermediary is configured to block it
for them.  So to relax that restriction, you need to update such UAs and the
proxies which are topologically capable of making such trust-decisions. (not
all proxies, not all UASs, not all UACs)  For the legacy UAs, they'd still
get no early media, as they didn't before.  

If your UACs didn't block early media before, then upgrading to this
mechanism can be done slowly - by starting at the trust-boundary proxies,
then upgrading trusted UAS's to insert the headers, and lastly changing the
UACs one-at-a-time to block and look for the headers.  And that's only if
you want this behavior, for your private network.

> backward media (receive it), it would advertise send-only???

There's nothing put in an Invite, I think.  The header is only put in the
18x response to the Invite, by the UAS.  So it's taking the same syntax
semantics as the SDP answer from the UAS.

-hadriel