Correction: Editorial changes to 3262. > -----Original Message----- > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Christer Holmberg > Sent: 6. maaliskuuta 2009 14:29 > To: Sanjay Sinha (sanjsinh); SIPPING List > Subject: Re: PRACK update: other changes than > allowingSDPofferinPRACK 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. > > 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 > _______________________________________________ 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
