Pl. see inline.. >-----Original Message----- >From: sipping-bounces@xxxxxxxx >[mailto:sipping-bounces@xxxxxxxx] On Behalf Of Christer Holmberg >Sent: Thursday, March 05, 2009 12:33 PM >To: Sanjay Sinha (sanjsinh); SIPPING List >Subject: Re: PRACK update: other changes than >allowing SDPofferinPRACK 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. > >And you think that is clear in the RFC, so no change/update is >needed for that? No it is not and I think putting together a document clarifying that will be good. > > >>>>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. Then I think intermediate should also update media to be in previous state before offer was rejected. > >>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. I sent you one, about interop with H323 gw, in case of slow start. Here is another one involving a call forward (CFALL or CFBusy) on a SIP device - INVITE without SDP comes into a SIP PBX for user A. User A has forwarded their calls to user B or User A has CFBusy to B. SIP PBX sends a 181 to UAC. This 181 does not have SDP as the PBX has not yet routed the call to user B. If PRACK is enabled, this will violate the first reliable provisional response MUST have SDP rule. SIP PBX then routes the call to user B and sends 183 Session Progress with the offer SDP. I will ask around to see if there are any more. Thanks > >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 > _______________________________________________ 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
