Re: [Sip] [Sipping] INVITE dialogs

[Paul Kyzivat <pkyzivat at cisco.com>]

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
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip