[reSIProcate] session timers and InviteSession
Scott Godin
slgodin at icescape.com
Sat Oct 8 13:11:09 CDT 2005
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20051008/15effad8/attachment.htm>
More information about the resiprocate-devel
mailing list