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