My view on this is that if you don't want to send SDP but you have to when sending a re-INVITE, then send UPDATE without the SDP. Can we update session timer to say that?
Hisham On 21/11/2007, Paul Kyzivat <[EMAIL PROTECTED]> wrote: > > > > Christer Holmberg wrote: > > Hi, > > > > What if the offerer is not "prepared" to receive an updated answer (it > > only included the "offer" because it had to)? How can it "reject" the > > answer? > > It can't. At best it can make a counter offer after the fact, or > terminate the call after the fact. > > But that clearly isn't a good policy. You should design your UA so that > this isn't an issue. When you make an offer you must always be prepared > for the answer be anything that is compatible with the offer. > > > I personally think that an unchanged o- line in the offer should not > > allow the answer to change. > > > > One could of course change the o- line in the offer - even if the offer > > itself hasn't changed - and that would then allow the answer to be > > changed. > > Personally I think the o-line changing or not is just an extra > complication that should never have been there as a factor. Whether the > o-line changes or not isn't what matters. What matters is whether the > rest of the SDP changes. At best the o-line is a hint about whether the > rest changed or not, and simply introduces the potential error case > where the SDP doesn't agree with what the o-line is hinting. (So what > should you do if the o-line is unchanged but the SDP is changed?) > > But as things are written, you are expected to make the o-line the same > if the rest of the SDP is the same. The o-line in the offer has > *nothing* to do with what is in the answer. > > Paul > > > Just some thinking... > > > > Regards, > > > > Christer > > > > > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >> Sent: 20. marraskuuta 2007 3:39 > >> To: [email protected] > >> Subject: Re: [Sip] SIPit 21: Question about offer answer > >> > >> From: Paul Kyzivat <[EMAIL PROTECTED]> > >> > >> A 3pcc controller doing a transfer may well send an > >> offerless invite to > >> one UA and then send the offer it gets back to an entirely > >> different UA > >> than had been in the session before. So of course the > >> answer will be > >> entirely different. > >> > >> Hmmm, "my" music-on-hold proposal does that, too. > >> > >> Dale > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use > >> [EMAIL PROTECTED] for questions on current sip > >> Use [EMAIL PROTECTED] for new developments on the application of sip > >> > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip >
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
