IMO you shouldn't be attempting to partially support UPDATE - only for
session timer, without support for offer/answer. There is no reason to
expect that all UAs you interact with will be able to deal with that
level of granularity in the use of UPDATE, and I don't think you will be
able to find a way to have them declared non-compliant if they don't.
If you don't support it fully, the safest thing to do would be to always
reject UPDATE with a 405, and never include it in an Accept. If the peer
UA supports session timer, it probably should be using reINVITE in this
case, but if it tries UPDATE it should get the clue and try again with
reINVITE.
Alternatively, if you happened to get an UPDATE you can handle, you
could still go ahead and process it, while continuing to deny that you
accept it. Meanwhile, reject usages you can't handle with a 405.
But I think you will always be on shaky ground here. Better to fully
implement UPDATE.
Paul
Gary Cote wrote:
> Barry,
>
> My suggestion would be to add UPDATE to the Allow header, but to
> return a 488 response and include an empty Accept header. That should
> signify to the UAC that your UAS does not accept message bodies for
> UPDATE methods. I don't think it's stated explicitly, but I interpret
> the Accept header to be method-specific (It makes sense to me that
> some method types would support message bodies that others don't). So
> it shouldn't have any implications on what message bodies your UAS
> supports for INVITE methods.
>
> Note that, even if this is correct according to a precise
> interpretation of the specs, there's no guarantee that all UAC
> implementations will get the hint. So I think this whole scenario puts
> you on thin ice, as far as interoperability goes. But I suspect you
> knew that already.
>
> Alternatively, you could indicate support for session timers by
> putting the "timer" option tag in the Supported header, but not put
> UPDATE in the Allow header. I don't think it's a good idea, because
> it's quite inconsistent. But it might just do the trick (or it might
> confuse the UAC even further. Who knows?)
>
> Just some food for thought ... good luck.
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
