>> One problem with this that I can think of
stems from incompatible
>> commericial clients/UA's that I've test
with. Essentially some UA's forget
>> to increment the
version numbers in their SDP offers/answers. If we
>> implement
this approach, then we will miss a hold/unhold requests from such
>>
clients (ie. no callbacks). Currently the sdp is still passed
to
>> application so it is up to the application to make the decision
if the SDP
>> session info has actually changed or not - this offers
flexibility.
>>
>Keep in mind that this is only for
session-timer reINVITE or UPDATEs.
>So we do not expect the far side to
change the SDP on a session timer
>transaction.
reINVITEs used to put a media session on-hold are also
considered session refreshes. You cannot really tell the difference
between receiving a reINVITE intended to do a session refresh vs a reINVITE
intented to put a session on (or off) hold. Unless you try to use
something like the version in the SDP for this.... then your back to
the problem I mentioned above.
Scott