I thought it was already a MUST RFC3261 " If the INVITE does not contain a session description, the UAS is being asked to participate in a session, and the UAC has asked that the UAS provide the offer of the session. It MUST provide the offer in its first non-failure reliable message back to the UAC. In this specification, that is a 2xx response to the INVITE. " RFC3262 "If the UAC receives a reliable provisional response with an offer (this would occur if the UAC sent an INVITE without an offer, in which case the first reliable provisional response will contain the offer), it MUST generate an answer in the PRACK." Can you point to the text that says SDP offer does not need to occur in the 1st reliable response? Hisham 2009/3/31 Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>: > > Hi, > > One of the PRACK related issues presented in SFO is whether we should change > the requirement to include SDP offer in the first reliable provisional > response, if the INVITE does not contain SDP. > > Two use-cases, which the current requirement affect, were presented: > 1. H.323/SIP interworking, where an empty INVITE may have been received and > an SDP offer is not available when the first reliable 18x is to be sent > (please see meeting slides for details). > > 2. Call fowarding, when a 181 provisional is sent. The 181 may be sent by an > intermediate, and if the INVITE did not contain SDP a reliable 181 would be > required to contain an SDP offer. > > It was indicated that there may be backward compability issues. That of > course depends on the number of deployments where INVITE without SDP is sent > AND a reliable 18x without SDP offer would cause an error. > > Some people indicated concern, so I would like to ask what people think? > Would changing the rules cause problems in existing deploymentnts? > > 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
