There was a discussion a while back to establish exactly the scope of
validity of the infomration carried in the Allow-* headers. We
finally decided that no clear definition could be made.
In any case, the UA has to be prepared for the failure of any request.
In the case of an UPDATE, clearly it is an extention that is intended
to modify the state of the dialog/session, and so its failure would be
expected to leave the dialog in the previous state. Why RFC 5057
would prescribe that an existing usage is terminated is beyond me.
Perhaps that revolves around the word "integral" -- an INVITE instance
that does not accept UPDATE is conceivable. In the end, the UAC has
to have a strategy for continuing if the UPDATE is rejected, even if
the strategy is just to send BYE.
In practice, it seems that the most workable strategy is that the UAC
should plan what it intends to do based on the Allow information that
it has received from the other UA, but it has to have some strategy
for dealing with the failure of any request.
As others have noted, it is common for B2BUAs to replace "one end"
dialog without changing the "other end" dialog, and so Allow
information can become obsolete at any time, without notice.
Harbhanu summarizes the situation well:
The scope of these things is very unclear. About all you can
***reliably** assume is that they are true at the time they are
conveyed***.
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
