>-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@xxxxxxxxxxxx] >Sent: Wednesday, March 04, 2009 7:28 PM >To: Sanjay Sinha (sanjsinh); SIPPING List >Subject: RE: PRACK update: other changes than >allowing SDP offerinPRACK to be rejected? > > >Hi, > >>Since RFC 3261 says that mid-dialog requests are processed atomic, I >>think UAS should not cease retransmission of the provisional response >>and wait for UAC to fix the error with PRACK. If it runs out of >>retransmissions, it should reject the Invite with 5xx response. > >So, do you agree that we in any case would need to say whether >an error response also ceases retransmission of the >provisional response - no matter what triggers that error response? No, I am not saying that, in fact I am saying that error response to Prack *does not* cease retransmission of provisional response. > >>Having re-read RFC 3262, I think offer handling in PRACK should be >>treated differently than Prack failing to match the response, because >>it mentions that retransmissions should cease when matching Prack is >>received. But sdp offer is not part of matching request to ongoing >>transaction. >>So I still think that answer should be sent in 200 OK with rejection >>represented in the answer followed by an UPDATE to restore previous >>media session. > >There could also be an intermediate which rejects the PRACK >offer, and it may not be willing/capable of generating >UPDATEs, because that would require rather heave B2BUA functionality. What are the use cases for an intermediate rejecting offer in Prack if it is not interested in media? > >Earlier there were also some other ideas, e.g: > >- don't include an SDP in the 200 >- don't update the SDP version number in the 200 I think this option is better than not sending any sdp in 200 OK, since that violates offer answer model. BTW, what about the other issue you brought up, about first reliable provisional response having an offer sdp for delayed media cases. IMO, that problem is more widespread compared to Prack offer case, which I think it used for precondition case. Thanks >- etc etc etc > >But, I think that we at that time decided not to go for any of those. > >Regards, > >Christer > > >> >-----Original Message----- >> >From: Christer Holmberg [mailto:christer.holmberg@xxxxxxxxxxxx] >> >Sent: Wednesday, March 04, 2009 4:26 PM >> >To: Sanjay Sinha (sanjsinh); SIPPING List >> >Subject: RE: PRACK update: other changes than >allowing SDP >> >offerinPRACK to be rejected? >> > >> > >> >Hi, >> > >> >>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? >> > >> >The same thing applies there, of course. So, maybe we should >> talk about >> >PRACK reject in general, instead of offer/answer. >> > >> >>I would think that the behavior would be same as if rejecting >> >the PRACK >> >because offer sdp is unacceptable. >> > >> >Sure, but that is not specified either at the moment :) >> > >> >I think the only PRACK reject use-case which is specified is >> when there >> >is no matching provisional response to acknowledge in the >> first place. >> > >> >...and, of course, in cases the call doesn't exist etc. >> > >> >>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. >> > >> >We could of course do that. However, I don't think the >> justfication is >> >the same. Here we are talking about rejecting an offer when it's >> >received - nothing more, nothing less :) >> > >> >Also, as you said, PRACK can be rejected for other reasons, >> so I think >> >we should focus on what happens if it is rejected - for whatever >> >reason. >> > >> >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
