Rockson Li (zhengyli) wrote:
Some comments for scenario 4 below. thanks
-Rockson
Snipping down to there, then response.
SCENARIO 4.
UAC UAS
ini-INVITE
------------------------------------------------------>
offer
183(reliable)
<------------------------------------------------------
answer
PRACK
------------------------------------------------------>
offer
200(PRACK)
----------------------
/ answer
/
/ 200(ini-INVITE)
<----------------------------/-------------------------
/ no sdp
/
ACK /
-------------------------/---------------------------->
/
/ re-INVITE
! <---------------------/--------------------------------
/ offer
/
<-------------------
200(re-INVITE)
------------------------------------------------------>
answer
ACK
<------------------------------------------------------
At the point marked "!", the UAC cannot respond to the re-INVITE
immediately. It must buffer this request until it receives
200(PRACK), which completes the ongoing offer/answer exchange.
I think the alarm bells go off for the UAC when it receives the 200 for
the ini-invite. It really shouldn't want to send the ACK yet, because as
far as it is concerned, it has an unanswered offer outstanding.
So my inclination would be that the UAC should just ignore the
200(ini-INVITE), sending no ACK. This will force the UAS to retransmit
it. The UAC doesn't know that the PRACK with answer is enroute, but in
this case it would then probably arrive before the 200 is retransmitted,
so things would recover.
But this is an interesting case to call out.
As I noted above, I just rewrote section 4.1 of the offer/answer draft,
but it is lacking your scenarios 1 & 4. If you have any thoughts on how
to better treat section 4.1 I would be pleased to hear them.
[RL] actually, I think caller here could respond 491 for re-INVITE with
offer here, RFC3311 sec 5.2 has similar case.
<snip>
If an UPDATE is received that contains an offer, and the UAS has
generated an offer (in an UPDATE, PRACK or INVITE) to which it has
not yet received an answer, the UAS MUST reject the UPDATE with a 491
response.
</snip>
If the UAC lets things get that far, then a 491 might be appropriate.
But as I noted above, the UAC already has a problem when it gets the 200
to the initial invite, because it has an incomplete o/a. It doesn't know
how that is going to work out.
*IF* it decides to send the ACK and then wait for the 200(PRACK), then
what you suggest makes sense.
If it fails to send the ACK, then that should squelch the possibility of
getting the reINVITE.
Thanks,
Paul
_______________________________________________
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
