Paul,
Thanks for your answer. I had looked into preconditions, in particular the
examples given in section 9 of RFC 3725, but I had difficulties working out
how to use it to get around this particular problem. I guess once the two
UAs have reached the point in signalling that they can then send UPDATE
requests to each other through the controller, then one could send an UPDATE
request asking for media with security, say, and if that results in a 488 it
could try again asking for media without security. Preconditions would play
a role only in that it would delay alerting until this stage is reached. We
get to this stage roughly as shown in the example in 9.2, but the SDP offer
in the 183 from would need to be for no media.
I need to work it through a bit more to see which UA takes which role and if
it works when one of the UAs drives it in this way even though the other UA
and/or the controller are unaware of this procedure.
Of course, Cullen's proposal for multipart MIME alternatives would avoid
these problems, but that didn't progress too far at the last IETF.
John
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Sent: 05 May 2005 14:18
To: Elwell, John
Cc: Jonathan Rosenberg; Peterson, Jon;
Gonzalo.Camarillo at ericsson.com; schulzrinne at cs.columbia.edu;
sipping at ietf.org; Hammer Bernhard; Schmidt Christian
Subject: Re: [Sipping] Question on RFC 3725 (3PCC)
Elwell, John wrote:
I have a concern about the working of 3PCC when an SDP
offer is rejected.
In flow 1, what if the SDP offer from A is rejected by B? B
will send a
488 response to the controller, but this cannot be relayed
back to A.
Presumably the only action that the controller can do is to
send an ACK
to A (but that should contain an SDP answer, so how is it
populated?)
Lacking something better, I think the controller simply
derives an SDP
answer from the offer, rejecting (with port=0) each offered
media line.
and then a BYE to A. A will never receive the reason for
failure. In
Well, I think a Reason header in the BYE is a way to convey this. But
I'm not sure if there is a good reason for this purpose.
particular, if the reasons for failure was the rejection of key
management for payload encryption, A cannot retry (e.g.,
without payload
encryption). Of course, the controller can retry, but it
will probably
yield the same result.
After ACKing the first invite it could try again with a reinvite. For
instance it might flip sides and first send an offerless invite to B,
and use the result to reinvite A. That might yield better results.
This whole thing would work better with preconditions -
perhaps the new
conn precondition. Then there would be no alerting of either
side until
all these details were sorted out.
I won't discuss flow 2, because that is not recommended.
For flows 3 and 4 considerations are similar to flow 1,
except that A
rejects the offer from B and B does not get to find out why
the call failed.
Has this been discussed and has any solution been identified?
I don't recall this having been discussed.
Paul