Hi, 1) I just sent you an email about our point 1 below explaining you thegeneral issue in SIP and discussing its implication. I will not repeatthe same arguments here. 2) On your point 2 below, nothing that has not been negotiated at thesignalling level can be used. Therefore, endpoints will not be able touse media illegally. 3) I already answered your point 3 below in a previous email. Sessioncontinuity is achieved by continuing using the session parameterscurrently in use when the re-INVITE fails. 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: 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. _______________________________________________Sipping mailing list https://www.ietf.org/mailman/listinfo/sippingThis list is for NEW development of the application of SIPUse sip-implementors@xxxxxxxxxxxxxxx for questions on current sipUse sip@xxxxxxxx for new developments of core SIP
