[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