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. 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. Sanjay >-----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
