1. the situation of inconsistent media level(perhaps it is impossible)
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.
And UAC's "in use" media is the one before Re-INVITE.
Some people may say that UAS could send 180 after its Precondition OK. But it is optional for Re-INVITE.
And if 180 is not 100rel, no one can assure UAC would recv it.
2. the derived problem
If the situation mentioned above is possible, there are something derived from it:
o If UAC do not conf the UAS, UAC have some cases can see the Precondition OK by SDP:
If the UAS conf UAC, UAC will send UPDATE, and at that time UAS is OK.
o UAC have some cases can see 180. And this is signal of resuming.
o Time of 4xx, before Precondition OK or not.
The indeterminacy of such situation would make UA's session parameters uncertain.
From user's view, with/without precondition; having or having no 180; Time of 4xx would make session parameters uncertain.
It will be a puzzle for them.
| Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>
2009-02-27 00:20 |
|
Hi,
> 2.1.2. Confirmed state but not enough for usage
this point does not apply to the proposal because we are not performing
any rollback at the media level. Whatever media parameters are being
used they will still be used after the re-INVITE fails. Therefore, the
point where the re-INVITE fails does not represent any discontinuity in
the media session. The media session continues as it was before the
failure of the re-INVITE.
> 2.1.4. Illegal using session parameters
>
> The modification in media level can be used illegally, while the
> modification is unsuccessful in signal level.
this does not apply to the proposal because the proposal does not
specify any new media usage. It simply tells the endpoints to continue
doing what they were already doing.
> 2.2. Drawback of manual rollback
this does not apply to the proposal because there is no rollback at the
media level.
> 2.2.1. Problems for ordinary SDP
>
> Sections mentioned above introduced "manual rollback" using a new Re-
> INVITE as the way to resume the session under ambiguous situations.
> But *if the two sides have no consistent view of session state, no
> matter which side sends the new Re-INVITE, the other side will treat
> it as violation of session continuity* because of different view of
> session state.
you provided a few examples of situations where the endpoints may have
inconsistent views of the session state. None of the examples were
valid. 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.
> 2.2.2. Problems for non-integrative SDP
>
> Because the SDP just describes part of the session, not all aspects
> of the session. It must be combined with the previous one(or ones)
> to show the effects, as the formula:
>
> *"current session state" = "previous session state" + "modification
> session description"*.
>
> & nbsp; Even if using a new Re-INVITE with "modification session
> description", we can not rebulid the "current session state" without
> the definition of the "previous session state". So, the "previous
> session state" is important here, and we still need to give out a
> precise definition of session state to get the "previous session
> state" here.
in the proposal we are discussing here, we do not need to rebuild any
state because we just continue using the current media state. Therefore,
this drawback does not apply to the proposal either.
Thanks,
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
