| Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>
2009-02-27 15:37 |
|
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.
[Gao] RFC3261:
If a UA receives a non-2xx final response to a re-INVITE, the session
parameters MUST remain unchanged, as if no re-INVITE had been issued.
However, the
failure of the re-INVITE does not cause the existing call to fail -
the session continues using the previously negotiated
characteristics.
> > 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.
[Gao] Why think after 4xx, the "most" case is that user prefer to using the media negotiated in Re-INVITE.
I think rejecting is the "most" case.
But this is subjective branching :).
>
> > 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.
[Gao] I think the usage should be restricted by signaling, while not end users' consciousness. :)
Cheers,
Gonzalo
-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ 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
