[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Re: psychic early media behavior
Ejzak, Richard P (Richard) wrote:
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.
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
Richard
-----Original Message-----
From: Dale.Worley at comcast.net [mailto:Dale.Worley at comcast.net]
Sent: Friday, June 30, 2006 11:11 AM
To: sipping at ietf.org
Subject: Re: [Sipping] Re: psychic early media behavior
From: "Michael Hammer \(mhammer\)" <mhammer at cisco.com>
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP