Re: 答复: Re: 答复: Re: 答复: Re: 答复: Re: 答复: Re: 答复: Re: Closing the offer/answer rollback issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux