Pl. see inline ...
From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Christer Holmberg
Sent: Wednesday, March 04, 2009 1:19 PM
To: SIPPING List
Subject: Re: PRACK update: other changes than allowing SDP offerinPRACK to be rejected?Hi,Now, when everybody is in offer/answer mode, please let me remind me of the other issue we need to solve: rejecting SDP offers in PRACKs.The status at the moment is that we agreed that one should be able to reject an SDP offer in a PRACK with a 4xx response.
[Sanjay Sinha (sanjsinh)] What happens if PRACK needs to be rejected for reason other than for offer-answer, like say CSEQ or RAck header is malformed? I would think that the behavior would be same as if rejecting the PRACK because offer sdp is unacceptable.Moreover for rejecting offer in PRACK, I think a non error response approach may be good. Probably Gonzallo's rollback proposal mechanism can be followed here also, ie send 200 OK to PRACK with port number set to 0 or c line set to 0 or media attribute line set to inactive and then have UAS send an UPDATE to go back to the earlier negotiated offer-answer session.Q1. One of the questions were whether that 4xx response should also terminate the re-transmission of the reliable 18x response the PRACK is supposed to acknowledge.- One problem with saying that the re-transmission of the 18x shall stop is that if an intermediate rejects the PRACK, the UAS will still re-transmit the 18x - eventhough the UAC will think the re-transmission has ceased.- One problem with saying that the re-transmission of the 18x shall not stop (basically meaning that the UAC would have to send a new PRACK) is that the current PRACK RFC more or less says that the re-transmission stops when the PRACK is received - no matter what the response code is going to be (maybe it was written in that way because it was assumed that the response code would always be 200).So, we really need some input and thoughts on that.Q2. Another issue was whether we were going to loose up some other PRACK restrictings, e.g. that the first reliable 18x must contain an SDP offer if the INVITE didn't. We agreed that we are NOT going to do that, unless someone can show that the current rules causes problems.
[Sanjay Sinha (sanjsinh)] I think there should be some explanation for why the first reliable provisional response needs to have offer sdp. I do not have first hand experience, but I have been in discussion where it was mentioned that this rule causes problem in interworking scenarios, say with a H323 gw. In that case, the media is not available till capabilities exchange is done and OLC received. So for SIP responses to be sent in response to H225 signaling, ALERT/PROGRESS etc., far end sdp is not available.SanjaySo, if you have use-cases or scenarios where the first-reliable-18x-must-contain-SDP-offer rule causes problems, please post them on the list.Regards,Christer
_______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
