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. I believe it would require a number of editorial changes in 3261. Because, currently the text more or less says that the re-transmission is ceased as soon as the PRACK is received, before it is further processed. But, there is probably nothing we can do about that. Also, a PRACK can be rejected for other reasons even if it contains an SDP body. It all depends how the receiver processes the request, so one must be prepared to receive a 4xx response for a PRACK carrying SDP. >>>>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. Sure, but that is not the issue. The issue is that if intermediate wants to reject the SDP offer in the PRACK, the intermediate would have to generate an UPDATE. Also, I don't think that PRACKs will be rejected because of SDP offer very often, so I doubt people would implement an UPDATE based solution anyway. So, I think it's better to simply say that the offer can be rejected with a 4xx response. >>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. I may have lost that one, but I'll check my archieve. >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. Seems valid. I guess this would happen if the call comes from a H.323 gateway, or from an application server doing 3pcc, but never the less... 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
