Subject: [Sipping] Question on RFC 3725 (3PCC)

From: "Elwell, John" <[email-masked]>
Date: Thu, 05 May 2005 09:52:45 +0100

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?) and then a BYE to A.
A will never receive the reason for failure. In 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.

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?

John

_______________________________________________
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: Thu, 05 May 2005 09:17:34 -0400

Elwell, John wrote:
> 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.

> Has this been discussed and has any solution been identified?

I don't recall this having been discussed.

	Paul