| Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>
2009-02-27 17:06 |
|
Hi,
I prefer to think that our discussion is friendly, everything is just becasue of different thoughtway :).
1) I just sent you an email about our point 1 below explaining you the
general issue in SIP and discussing its implication. I will not repeat
the same arguments here.
[Gao] Is it a real case without violation of current RFCs? YES/NO is enough.
2) On your point 2 below, nothing that has not been negotiated at the
signalling level can be used. Therefore, endpoints will not be able to
use media illegally.
[Gao] I just said the situation two sides have successful media modification, then user rejected.
With precondition, it is alway so.
And by your proposal, the parameters is useful. Why say it "nothing can be used".
3) I already answered your point 3 below in a previous email. Session
continuity is achieved by continuing using the session parameters
currently in use when the re-INVITE fails.
[Gao] User just rejected it. And the way as your proposal is to issue a new Re-INVITE or UPDATE.
If it is using Re-INVITE, and the other side need user permition, so during the time, use can not using the parameters they prefer.
As your saying, the original parameters user rejected is useable now. But it is what user just rejected.
So, from user's view, it is violation. Do you think so.
I do not prefer to explain to user the interval media clip in modification rejecting (if the way accepted by IETF).
Thanks,
Gonzalo
gao.yang2@xxxxxxxxxx wrote:
>
> 1. the situation of inconsistent media level
>
> UAC UAS
>
> Re-INVITE---------->(Offer)
> <----------------183(Answer)
> PRACK-------------->
>
> Offer is optional;
> Answer is mandatory;
>
> UAS is the resumer of suspended session, so:
> A UAS that is not capable of unilaterally meeting all of the
> mandatory preconditions MUST include a confirm-status attribute in
> the SDP (offer or answer) that it sends (see Section 7).
>
> If UAC do not conf the UAS，UAC could never see the Precondition OK by SDP.
>
> So, it can be that UAS see the Precondition OK, but UAC do not.
>
> Then, after 4xx of Re-INVITE, UAS's "in use" media is the one after
> Re-INVITE. In your examle, that is:
> audio stream: audio codec 2
> video stream: video codec 2 (subject to preconditions OK)
>
>
>
> And UAC's "in use" media is the one before Re-INVITE.
> audio stream: audio codec 2
> video stream: video codec 1 (subject to preconditions is not OK)
>
> You tell me yesterday:
> If you could provide a valid example, it would help us understand
> if there is a problem here.
>
> In any case, if endpoints end up with an inconsistent view of the
> parameters in use, it would be a *bigger problem* than the issue we are
> talking about here, because it would mean that the media session between
> them would not work.
>
> I think it is. Do you think it is? YES/NO
>
>
>
> 2. illegal of media use
> It is a real problem, no matter in signalling level what the state
> should be.
> I want to ask could end user using the session parameters? YES/NO
>
>
> 3. violation of session continuity
> It is a real problem. Do you think so? YES/NO
> And the accessorial is that is it the most case?
> I know your answer.
>
>
>
>
> *Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>*
>
> 2009-02-27 16:40
>
>
> 收件人
> gao.yang2@xxxxxxxxxx
> 抄送
> christer.holmberg@xxxxxxxxxxxx, sipping@xxxxxxxx
> 主题
> Re: 答复: Re: 答复: Re: [Sipping] Closing the offer/answer rollback
> issue //discussion: the situation of inconsistent media level
>
>
>
>
>
>
>
>
> Hi,
>
> I have already addressed your concerns on the three points below in this
> email thread. If you think something is not completely or properly
> addressed, explain it or provide an example. Going in circles and
> discussing again what we have already discussed would be pointless.
>
> Thanks,
>
> Gonzalo
>
> gao.yang2@xxxxxxxxxx wrote:
> >
> > Dear Gonzalo Camarillo
> >
> > And I think:
> >
> > 1. the situation of inconsistent media level
> >
> > 2. illegal of media use
> >
> > 3. violation of session continuity
> >
> > Still exist.
> >
> > And talking about "the situation of inconsistent media level", I just
> > talk the session state can be inconsistent from two sides.
> > But you think it is "signalling-media synchronization" issue. I do not
> > think it is.
> >
> > And talking "illegal of media use", you restrcited me talking media
> > level usage.
> >
> > And talking "violation of session continuity", you think it is not the
> > most case.
> >
> > Gao
> >
> >
> >
> >
> > *Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>*
> >
> > 2009-02-27 16:08
> >
> >
> > 收件人
> > gao.yang2@xxxxxxxxxx
> > 抄送
> > christer.holmberg@xxxxxxxxxxxx, sipping@xxxxxxxx
> > 主题
> > Re: 答复: Re: [Sipping] Closing the offer/answer
> rollback issue
> > //discussion: the situation of inconsistent media level
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi,
> >
> > > Current definition of "in use" is the one proposed by Holmberg
> yesterday:
> >
> > no, we are discussing the proposal in my original email. As I have said
> > before, the idea is to have focused discussions without jumping from
> > topic to topic before resolving any of them.
> >
> > In any case, so far we have not found any requirement that would not be
> > met by the straw-man proposal in my original email. If we do not find
> > any soon, we will be making a decision shortly.
> >
> > 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.
>
>
>
> --------------------------------------------------------
> 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.
-------------------------------------------------------- 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
