[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

_______________________________________________
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