Subject: RE: [Sipping] Re: psychic early media behavior

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Sun, 2 Jul 2006 11:54:02 -0500

Dale,
I'm sorry, but your proposal will not work, besides being unacceptable to TISPAN.  The UAC and network cannot guarantee in advance to the UAS that early media will be rendered.  See RFC 3960 for known cases where this cannot happen.

The problem is that the existing RFCs that Paul referenced have requirements that cannot always be met.  That is the crux of our disagreement.

Your scheme attempts to prohibit a UAC/network from denying early media unless the UAS supports the extension and allows it.  Early media denial already occurs in some cases according to existing RFCs, and whether or not it occurs is not always known when the UAC issues its request, so this approach will just cause more problems with existing RFCs than it solves.  

The cat's already out of the bag and you're not going to be able to put it back in.

Richard 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, June 30, 2006 11:11 AM
> To: [email-masked]
> Subject: Re: [Sipping] Re: psychic early media behavior
> 
> 
>    From: "Michael Hammer \(mhammer\)" <[email-masked]>
> 
>    However, what I don't see is the case where it is the UAS that is
>    the one that requires the sending of early media vice the requestor
>    needing it.  It would be good to cover that case, as I suspect that
>    might occur more often.  Thus, discussion of inserting/modifying
>    headers/parameters in responses would be useful.
> 
> The situation where the UAS requires early media breaks into several
> cases --
> 
> 1) The UAS does not understand this mechanism.
> 
> 1a) If the UAC is prepared to deal with such a UAS in an RFC 3261
> manner (that is, accept early media without further negotiation), then
> it does not add "Require:  controlled-early-media", and the UAS
> accepts the request, and operation proceeds as in RFC 3261.
> 
> 1b) If the UAC requires further negotiation, it adds "Require:
> controlled-early-media", and the UAS rejects the request, thus
> ensuring both UAs are aware of the failure.
> 
> 1c) If the network requires further negotiation, it ensured that
> "Require:  controlled-early-media" was present in the request, and the
> UAS rejects the request.
> 
> 2) The UAS does understand this mechanism.
> 
> 2a)  The UAC and the network do not require further negotiation to
> pass early media.  In that case, the request is accepted, and early
> media proceed as in RFC 3261.
> 
> 2b) The UAC and/or the network require further negotiation.  When the
> request reaches the UAS, "Require: controlled-early-media" is present.
> The UAS accepts the request and invokes early media negotiation.
> 
> The whole point of the mechanism is that a UA that does not understand
> the extension cannot establish a dialog unless the other UA and the
> network between are prepared to pass early media on an RFC 3261 basis.
> 
> Dale
> 
> _______________________________________________
> 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: Sun, 02 Jul 2006 16:26:41 -0400

> Your scheme attempts to prohibit a UAC/network from denying early media unless the UAS supports the extension and allows it.  Early media denial already occurs in some cases according to existing R…

Well, in the context of those RFCs, the offerer *receives* early media 
if it is sent. So it has the *opportunity* to render it. If it doesn't, 
then it must accept the consequences.

But its a different situation when the media is quashed in the middle of 
the network, because the UA, acting for the user, doesn't have any say 
in it. Then we get into issues like whether the network is acting as an 
agent for the UA, or whether they have an adversarial relationship.

The situation is not so good for the answerer. It doesn't get to decide 
if the media it is sending will be rendered, and as you point out, 
Dale's proposal doesn't help very much with that. (Nor does yours.)

But I don't see how your proposal does any more than make a bad 
situation worse from the POV of the calling and called users. Since they 
can't count on ever having the early media get through, why not just 
block it all the time? That won't require any new mechanism.

> The cat's already out of the bag and you're not going to be able to put it back in.

I seems more like the cat is dead, and we have to decide whether to bury 
or try to resuscitate it.

I've not been a fan of the early-session approach (because I think it is 
so complex it won't be implemented correctly). But considering the 
problems with the alternatives, its sure looking like it SHOULD be used 
when it applies. That still leaves the gateway model for the specific 
case of gateways that don't know if they will or won't have media to 
transmit before the full dialog is established, or what its significance is.

So lets consider some cases. Context is that Alice is calling Bob. Bob's 
proxy may attempt to send the call to Bob1, or fork it to Bob1 and Bob2. 
BobN may be a sip ua that doesn't send early media, or may be a GW that 
does. For gateways, the early media may be ringback, or an out of 
service indication. Alice is in network using Richard's early media 
approval. Bob's proxy and gateways may be trusted for that mechanism by 
Alice's network or not.

In each case,
- in subcase (a) early media is unconditionally allowed,
- in subcase (b) Alice's UA and network require early media
   authorization, and Bob's UAs are trusted,
- in case (c) Alice's UA and network require early media
   authorization and Bob's UAs are not trusted,
- in subcase (d) Bob's network requires early media
   authorization while Alice and her network are not trusted
   and don't understand the mechanism.

1) Alice calls Bob. It goes to BoB1, a GW that sends 183 and
    inband ringback.
    a) Alice hears ringback. GOOD OUTCOME.
    b) Alice hears ringback. GOOD OUTCOME.
    c) Alice hears nothing until Bob1 returns final response.
       (Because there was no 180 to cause local ringback.)
       BAD OUTCOME.
       or:
       Alice's phone realizes early media won't be coming
       and plays local ringback on receiving a 183.
       TOLERABLE OUTCOME.
    d) Alice hears nothing until Bob1 returns final response.
       (Because there was no 180 to cause local ringback.)
       BAD OUTCOME.

2) Call forks to Bob1 & Bob2, both of which act like (1).
    a) Alice hears ringback from one of them.
       GOOD OUTCOME.
    b) Alice hears ringback from one of them.
       GOOD OUTCOME.
    c) Alice hears nothing until receiving a final respoonse.
       (Because there was no 180 to cause local ringback.)
       BAD OUTCOME.
       or:
       Alice's phone realizes early media won't be coming
       and plays local ringback on receiving a 183.
       TOLERABLE OUTCOME.
    d) Alice hears nothing until Bob1 returns final response.
       (Because there was no 180 to cause local ringback.)
       BAD OUTCOME.

3) Alice calls Bob. It goes to BoB1, a GW that sends an
    inband out of service message.
    a) Alice hears the message. GOOD OUTCOME.
    b) Alice hears the message. GOOD OUTCOME.
    c) Alice hears nothing until Bob1 returns final response.
       BAD OUTCOME.
       or:
       Alice's phone realizes early media won't be coming
       and plays local ringback (wrong) on receiving a 183.
       BAD OUTCOME.
    d) Alice hears nothing until Bob1 returns final response.
       BAD OUTCOME.

4) Call forks to Bob1 & Bob2, both of which act like (3).
    a) Alice hears the message from one of them.
       TOLERABLE OUTCOME.
    b) Alice hears the message from one of them.
       TOLERABLE OUTCOME.
    c) Alice hears nothing until Bob1 returns final response.
       BAD OUTCOME.
       or:
       Alice's phone realizes early media won't be coming
       and plays local ringback (wrong) on receiving a 183.
       BAD OUTCOME.
    d) Alice hears nothing until Bob1 returns final response.
       BAD OUTCOME.

5) Call forks to Bob1 (acting like (1)) and Bob2 (acting
    like (3)).
    a) Alice hears the ringback from Bob1.
       TOLERABLE OUTCOME.
       or
       Alice hears the message from Bob2.
       BAD OUTCOME.
       or
       Alice hears the message from Bob2, then when it
       completes, hears the ringback from Bob1.
       BARELY TOLERABLE OUTCOME ???
    b) same as (a)
    c) Alice hears nothing until receiving a final respoonse.
       (Because there was no 180 to cause local ringback.)
       BAD OUTCOME.
       or:
       Alice's phone realizes early media won't be coming
       and plays local ringback on receiving a 183.
       TOLERABLE OUTCOME.
    d) Alice hears nothing until Bob1 returns final response.
       BAD OUTCOME.

6) Call forks to Bob1 (acting like (1)) and Bob2 (a UA that
    sends 180, no early media).
    a) Alice hears local ringback. GOOD OUTCOME.
       or
       Alice hears inband ringback. GOOD OUTCOME.
    b) Alice hears local ringback. GOOD OUTCOME.
       or
       Alice hears inband ringback. GOOD OUTCOME.
    c) Alice hears local ringback. GOOD OUTCOME.
    d) Alice hears local ringback. GOOD OUTCOME.
       or
       Alice hears inband ringback. GOOD OUTCOME.

7) Call forks to Bob1 (acting like (2)) and Bob2 (a UA that
    sends 180, no early media).
    a) Alice hears local ringback. GOOD OUTCOME.
       or
       Alice hears inband message. BAD OUTCOME.
       or
       Alice hears the message from Bob1, then when it
       completes, hears local ringback.
       BARELY TOLERABLE OUTCOME ???
    b) Alice hears local ringback. GOOD OUTCOME.
       or
       Alice hears inband message. BAD OUTCOME.
       or
       Alice hears the message from Bob1, then when it
       completes, hears local ringback.
       BARELY TOLERABLE OUTCOME ???
    c) Alice hears local ringback. GOOD OUTCOME.
    d) Alice hears local ringback. GOOD OUTCOME.

(Somebody please check the above. I could easily have messed it up.)

Summarizing:

          No-authorization  Authorization   Authorization
          required          granted         refused
          (a)               (b)             (c)         (d)

1)       GOOD              GOOD             BAD/       BAD
                                             TOLERABLE

2)       GOOD              GOOD             BAD/       BAD
                                             TOLERABLE

3)       GOOD              GOOD             BAD        BAD

4)       TOLERABLE         TOLERABLE        BAD        BAD

5)       TOLERABLE/        TOLERABLE/       BAD        BAD
          BAD/              BAD/
          BARELY TOLERABLE  BARELY TOLERABLE

6)       GOOD              GOOD             GOOD       GOOD

7)       GOOD/             GOOD/            GOOD       GOOD
          BAD/              BAD/
          BARELY TOLERABLE  BARELY TOLERABLE

So, for an entirely closed network the proposed authorization approach 
does no harm over just allowing unconditionally. But for interop cases 
it always makes things worse, except for case 7 where the interop case 
actually comes out better than either other case.(!?)

I don't think the above is a good situation for those that value open 
networks.

	Paul

---

From: [email-masked]
Date: Tue, 4 Jul 2006 14:45:32 -0400

From: "Ejzak, Richard P (Richard)" <[email-masked]>

   Your scheme attempts to prohibit a UAC/network from denying early
   media unless the UAS supports the extension and allows it.

Um, well, no.  The point of the scheme is that if some combination of
the UAS/UAC/network would deny early media (absent the correct
negotiation to activate it), and the UAS or UAC is incapable of being
notified of that fact (because it does not support the right
extension), then the call would not complete to begin with due to 420
or 421.

This satisfies Paul's complaint -- If a pure-3261 UA can make a
connection, then early media will work.

My guess is that it probably works in all cases that TISPAN cares
about, because TISPAN is concerned about UAs supplied by the network
operators who need to regulate early media, and those UAs (we can
assume) implement the extension, and know how to negotiate regarding
early media.

The real problem comes in situations where one or both UAs don't
understand the extension, but early media aren't actually required in
for the call.  Can we devise a scheme which allows the bulk of these
calls to succeed?

Dale