|
List Info
Thread: RE: SIPit 21: Question about offer answer
|
|
| RE: SIPit 21: Question about offer
answer |
 
United States |
2007-11-21 08:02:16 |
|
| 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
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 < pkyzivat cisco.com">pkyzivatcisco.com>
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: comcast.net">Dale.Worleycomcast.net [mailto:comcast.net">Dale.Worleycomcast.net]
>>;
Sent: 20. marraskuuta 2007 3:39
>> To: ietf.org">sipietf.org
>> Subject: Re: [Sip]
SIPit 21: Question about offer answer
>>
>> From: Paul Kyzivat <cisco.com">pkyzivatcisco.com>
>>
>> ; 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
>> cs.columbia.edu">sip-implementorscs.columbia.edu
for questions on current sip
>> Use ietf.org">sippingietf.org 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 cs.columbia.edu">sip-implementorscs.columbia.edu
for questions on current sip
> Use ietf.org">sippingietf.org 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 cs.columbia.edu">sip-implementorscs.columbia.edu
for questions on current sip
Use ietf.org">sippingietf.org for new developments on
the application of sip
|
| RE: SIPit 21: Question about offer
answer |
 
Sweden |
2007-11-21 08:13:12 |
|
| 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
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
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 <cisco.com">pkyzivatcisco.com> 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: comcast.net">Dale.Worleycomcast.net
[mailto:comcast.net">Dale.Worleycomcast.net]
>>;
Sent: 20. marraskuuta 2007 3:39
>> To: ietf.org">sipietf.org
>> Subject: Re: [Sip]
SIPit 21: Question about offer answer
>>
>> From: Paul Kyzivat <cisco.com">pkyzivatcisco.com>
>>
>> ; 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
>>
cs.columbia.edu">sip-implementorscs.columbia.edu
for questions on current sip
>> Use ietf.org">sippingietf.org 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 cs.columbia.edu">sip-implementorscs.columbia.edu
for questions on current sip
> Use ietf.org">sippingietf.org 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 cs.columbia.edu">sip-implementorscs.columbia.edu
for questions on current sip
Use ietf.org">sippingietf.org for new developments
on the application of
sip
|
[1-2]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|
comcast.ne