Comments inline.
| Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>
发件人: sipping-bounces@xxxxxxxx 2009-03-04 00:16 |
|
Hi,
> Comments for
> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-reinvite-00.txt
>
> 1. I think that it is BCP level. And the solution can be effective by
> restricting Non-2xx when Offer/Answer pair has been exchanged.
yes, we will need to decide on the status (BCP vs. PS vs. Informational)
at some point.
> 2. Your proposal considered legacy UAS. But currently, the situation is
> legacy UAC with legacy UAS. And it is the original issue.
the draft describes the behavior of a new UAC that faces a legacy UAS,
which is the interesting situation. Other situations are not interesting
because a legacy UAC will be able to do the right thing when facing a
new UAS and if we have a legacy UAC against a legacy UAS, there is
nothing we can do because they were implemented some time ago and are
already out there.
[Gao] "Legacy UAC with legacy UAS" is the all, currently. And I think will be the most in near future.
It is not practical to talk "new UAC that faces a legacy UAS" without talking "Legacy UAC with legacy UAS". Because use the legacy UAS to call the same type UA, it is the situation of "Legacy UAC with legacy UAS".
> 3. "In order to undo changes that were already executed, the UAS uses a new
> offer/answer exchange or a target refresh request."
> If the new offer/answer exchange need precondition, the other side can
> reject it with 504. then the modification(undo changes) may not be done
> by UPDATE/200OK. And Re-INVITE can not be used here(for the pending
> original Re-INVITE).
The whole point is that the UAS should not send an error response. It
should send a 200 (OK) to the re-INVITE and then use traditional
mechanisms (i.e., UPDATEs or re-INVITEs) to modify the session if needed.
[Gao] I don't think so.
When one side using Re-INVITE to removing a media stream, perhaps with other modification. Offer/Answer has been exchanged before user's rejection.
Then the UPDATE(for undo) will reopen the removed media stream. Precondition may be need here. Then the other side can reject it.
But you can restrict UA MUST response 200OK to the undo UPDATE.
> Comments for
> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-precons-00.txt
>
> 1. "However, the fact that the UAs can start using the new media
> parameters does not mean that they need to start using them
> immediately." Yes.
we agree on this one, then.
> More than one Offer/Answer pais before Precondition Ok, and Caller can
> be answerer for some and Callee for the others. Then the two sides may
> waiting peer using new parameters
> after Precondition OK. It may be deadlock.
No, they will not be a deadlock because the UAS is in charge of starting
using the new parameters and of initiating a new offer/answer exchange.
[Gao] For UPDATE, the UAS can be different one of UAS of Re-INVITE.
And, RFC3264's restriction in media level is about answerer. So in suspending state, your proposal
has the situation both Caller and Callee are answerers.
If your proposals restrict that it is UAS of Re-INVITE to do it, IMO, it is violation of RFC3264.
UAS of Re-INVITE can be offerer of some Offers before suspending state, I think by RFC3264, UAS of Re-INVITE should wait for the other side to start using the new parameters.
Thanks for your comments,
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
-------------------------------------------------------- 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
