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. And you think that is clear in the RFC, so no change/update is needed for that? >>>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? The intermediate WOULD most likely be interested in media. >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. Well, so far nobody has demonstrated that the rule about the first reliable provisional response would cause problems. If you have scenarios where it does cause problem, please let us know. 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
