Re: [Sipping] 答复: Re: 答复: Re: 答复: Re: 答复: Re: 答复: Re: 答复: Re: Closing the offer/answer rollback issue

[Gonzalo Camarillo <Gonzalo.Camarillo at ericsson.com>]

Hi,

> no, we are not specifying any new rules about how to control the media
> state. To decide the media state in use at any given point, we are just
> using the traditional rules we use to control media. No new rules here.
> Therefore, your point above is not valid.
> 
> [Gao] I think it is violation of RFC3261, which has the semantics of 
> rejecting.

we cannot violate any RFC because we are not specifying *any* new rules
for media control.

>  > 2. Is the session state the one user prefer?
> 
> we need to decide what will be the default media state after the
> re-INVITE fails. The idea is that we define a default behavior that is
> in line with what the user prefers *most of the time*. Obviously, there
> will be cases where the user prefers something else because the default
> behavior cannot possibly cover all cases. In those cases where the user
> prefers something else, the user can issue a new re-INVITE or UPDATE.
> 
> [Gao]  Issue a new re-INVITE or UPDATE, would have the drawback I 
> mentioned.
> That is manual rollback called in folk.

As I said in the paragraph above, we need to find a solution that does
not require a new re-INVITE or UPDATE most of the time. However, when
the user preferences are not the default, there is no way around it. You
will need the new offer/answer exchange.

> 
>  > If A want to use vedio, and B reject it. But A and B can use vedio and
>  > say that they have rejected using it by signal, and operater can not
>  > bill it.
> 
> If B rejects the video stream the operator should not be charging for it
> because there is no video stream to charge for.
> 
> [Gao] But A and B can still using it illegal.

if a stream is rejected, it will not be in use. We do not indent to
change that rule anywhere.

Cheers,

Gonzalo