There is backward compatibility issues with it. There are some old UAs
which do not support UPDATE. But if they do,  and it can be figured out
from Allow header, then I agree that UPDATE is better than re-Invite for
session refresh.
 
Sanjay


________________________________

        From: Hisham Khartabil [mailto:[EMAIL PROTECTED] 
        Sent: Tuesday, November 20, 2007 11:10 PM
        To: Paul Kyzivat (pkyzivat)
        Cc: [email protected]; Christer Holmberg
        Subject: Re: [Sip] SIPit 21: Question about offer answer
        
        
        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

Reply via email to