Hi,
RFC4028 already allows the usage of UPDATE, so I guess the issue is more
to make sure one doesn't send an unchanged offer unless he is ready to
receive a modified answer.
If I remember correctly the initial idea the session-timer was, that is
some entity in the path had lost state of the call, the re-INVITE would
re-initiate the call.
However, that is not the case anymore. As far as I understand, the
session-timer is only used to indicate that the session is still active,
and if no re-INVITE/UPDATE is received the session can be released.
You could do this even with...... INFO ;)
Regards,
Christer
________________________________
From: Sanjay Sinha (sanjsinh) [mailto:[EMAIL PROTECTED]
Sent: 21. marraskuuta 2007 16:02
To: Hisham Khartabil; Paul Kyzivat (pkyzivat)
Cc: [email protected]; Christer Holmberg
Subject: RE: [Sip] SIPit 21: Question about offer answer
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
