[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Question on RFC 3725 (3PCC)
- To: "Elwell, John" <john.elwell at siemens.com>
- Subject: Re: [Sipping] Question on RFC 3725 (3PCC)
- From: Paul Kyzivat <pkyzivat at cisco.com>
- Date: Thu, 05 May 2005 09:17:34 -0400
- Cc: Schmidt Christian <christian-schmidt at siemens.com>, "Peterson, Jon" <jon.peterson at neustar.biz>, Hammer Bernhard <bernhard.hammer at siemens.com>, schulzrinne at cs.columbia.edu, sipping at ietf.org, Gonzalo.Camarillo at ericsson.com
- List-help: <mailto:sipping-request@ietf.org?subject=help>
- List-id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
- List-post: <mailto:sipping@ietf.org>
- List-subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
- References: <50B1CBA96870A34799A506B2313F26670561A892@ntht201e.siemenscomms.co.uk>
- Sender: sipping-bounces at ietf.org
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
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