Pl. see inline .. >-----Original Message----- >From: sipping-bounces@xxxxxxxx >[mailto:sipping-bounces@xxxxxxxx] On Behalf Of Paul Kyzivat (pkyzivat) >Sent: Tuesday, March 31, 2009 2:25 AM >To: Christer Holmberg >Cc: sipping@xxxxxxxx >Subject: Re: PRACK: Change MUST requirement to >include SDP offer in first reliable provisional response > > > >Christer Holmberg wrote: >> >> 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). > >This is the issue I hear complaints about. > >> 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. > >This is only an issue if the INVITE contained Require:100rel. >(And AFAIK that is rarely the case. If it was the case the 181 >could simply be >omitted.) That's true, but since 181 is a response code defined in rfc 3261, this use case is valid when Invite has Require:100rel. And the solution should take care of this use case. > >Otherwise, an unreliable 181 can be sent, which needn't have SDP. > >Another possibility would be to send a 181 with bogus SDP. For >instance it could have c=0 and port=0 for all the media. That >could work even reliably. Problem is that bogus sdp interpretation varies depending on implementation. Some use the method you describe above, some others use media attributes, some other variations in m line. > And it wouldn't affect any real >answers because it will have a unique to-tag. > >> 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? > >I'll have to ask around. As you suggested, maybe getting some feedback from upcoming SIPIt should also help. Thanks > > Paul > >> 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 > _______________________________________________ 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
