Hisham Khartabil wrote:
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?
I suppose we could, but you can only do that if both sides support
UPDATE. Since its optional, those who implement session timer must be
prepared to do it with reINVITE.
I really don't understand the issue here. If you send a reINVITE with
unchanged SDP and you get back an answer that is changed, just deal with
it. Why is this a problem?
Paul
Hisham
On 21/11/2007, *Paul Kyzivat* <[EMAIL PROTECTED]
<mailto:[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]>
[mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>]
>> Sent: 20. marraskuuta 2007 3:39
>> To: [email protected] <mailto:[email protected]>
>> Subject: Re: [Sip] SIPit 21: Question about offer answer
>>
>> From: Paul Kyzivat <[EMAIL PROTECTED]
<mailto:[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]
<mailto:[EMAIL PROTECTED]> for questions on current sip
>> Use [EMAIL PROTECTED] <mailto:[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]
<mailto:[EMAIL PROTECTED]> for questions on current sip
> Use [EMAIL PROTECTED] <mailto:[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]
<mailto:[EMAIL PROTECTED]> for questions on current sip
Use [EMAIL PROTECTED] <mailto:[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
