There have been a number of replies to this, some right, some wrong.
There are actually some interesting issues here. More comments inline.
Paul
Nina Garaca wrote:
> Hi All,
>
> I have some questions regarding the UPDATE request:
>
> Q1: Is it a valid situation for UPDATE response (read response to UPDATE
> request) to come after the 2xx final response to the initial INVITE?
Yes.
> Will it update the remote target of the dialog.
Yes.
> A B
>
> INVITE
> |-------------------------------------->|
> 180 rel
> |<--------------------------------------| /Early dialog established/
> PRACK
> |-------------------------------------->|
> 200 (PRACK)
> |<--------------------------------------|
> UPDATE
> |-------------------------------------->|
> 200 OK (INVITE)
> |<--------------------------------------|
> 200 OK (UPDATE)
> |<--------------------------------------|
This is one way things could have occurred for A to see this sequence. A
couple of other ways it could have happened are:
- the UPDATE might not have arrived at B until after B sent the 200 INVITE.
- the UPDATE might have arrived at B as show. B may then have first sent
the 200 UPDATE and then the 200 INVITE, but the 200 UPDATE might arrive
at A as show, after the 200 INVITE.
These are all legal and possible scenarios. And A has no way to
distinguish between them, so A will of course take the same action in
any of these cases. So A had better not do anything in the UPDATE that
is dependent on it arriving before B responds to the INVITE, and B had
better not do anything in the response to the UPDATE that depends on it
arriving in a particular order relative to its response to the invite.
Doing target refreshes before the invite has completed will be very
tricky to get right unless both the old and new target remain valid for
awhile. (Actually this is true *after* the invite completes too.) Note
that while A is attempting a target refresh via UPDATE, B can be sending
an UPDATE to A using the old target. And B may be attempting to change
its target as well.
> Q2: What is happening if this was non 2xx final response such as 408 or
> 481or maybe 491? This is very strange situation because 2xx to INVITE
> has already established the confirmed dialog, and 408 or 481 to UPDATE
> should tear down the dialog. 491 response should cause sending the
> UPDATE once more. Am I right?
Again, note the possibilities caused by different orderings seen at A
and B. The cases you cite above aren't at all strange in some orderings.
I think these things must simply be taken at face value.
> Q3: I understand that UPDATE shouldn't be used when confirmed dialog is
> established, but still , what is happening if the final response to
> reINVITE hasn't been received yet, is it valid to try to UPDATE the dialog?
As someone mentioned, UPDATE *may* be used within a confirmed dialog.
> Q4: Q1 and Q2 in the case of reINVITE.
Well, typically there won't be any provisional responses for a reinvite,
so normally it won't come up. But they are still possible. I don't see
why the answers would be any different.
Paul
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
