Anton,
I don't think I understand you. Comments inline.
Anton Tveretin wrote:
Hi,
First, preconditions could (and IMHO SHOULD) be satisfied before
re-INVITE. So anyway, they will be rolled back explicitly if re-INVITE
fails. IMHO normal diagram for re-INVITE would look like this, am I
right? (Adding a new stream)
IIUC, you are assuming that a session has already been established with
one or more media streams before the below?
-->RSVP:Path
<--RSVP:Resv
-->RSVP:ResvConf
If these RSVP messages are for a contemplated new media stream, where
are you sending them? You don't know where the media stream will terminate.
-->SIP:INVITE(offer);
<--SIP:180(no SDP)
I think the UAS can't return 180 until it knows the resources are
available to establish the new stream.
<--RSVP:Path
-->SIP:PRACK
<--SIP:200 PRACK
-->RSVP:Resv
<--RSVP:ResvConf
---waiting for user to accept or reject new media---
<--SIP:200 INVITE(answer)
-->SIP:ACK
I mean, 1xx responses to re-INVITE should not contain SDP, as there is
no reason.
The reason is so that the UAC will know if there will indeed be a new
media stream, and where it will terminate. Until it knows that, how can
it do the RSVP to reserve resources for the path?
I'll stop commenting here because without agreement on this its hard to
talk about more.
Thanks,
Paul
Second, UPDATE easily goes into race conditions with re-INVITE. Recall
Gao's diagram:
-->re-INVITE (F1)
<--1xx (F2)
<--UPDATE (F3)
F2 and F3 may be delivered out of order. So there will be no way to tell
whether F1 or F3 came out first. This is also true even both re-INVITE
and UPDATE were sent by the same UA. Only SDP versioning helps.
So UPDATE is not a part of re-INVITE transaction if it contained no SDP.
IMO everything that clearly is a part of re-INVITE transaction, must be
rolled back.
Consider the following:
-->re-INVITE(offer1)
<--180(answer1)
-->PRACK
<--200 PRACK
-->UPDATE(offer2)
<--200 UPDATE(answer2)
<--603 INVITE
-->ACK
Still, UA at left might not commited the second O/A pair (if responses
to the re-INVITE and UPDATE were re-ordered).
Regards
_______________________________________________
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
_______________________________________________
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
