Re: [reSIProcate] session timers and InviteSession
On 10/7/05, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:
>
> Jason,
>
> 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.
> That being said. More comments inline...
>
> Scott
> ________________________________
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx on
> behalf of Jason Fischl
> Sent: Fri 10/7/2005 3:01 PM
> To: resiprocate
> Subject: [reSIProcate] session timers and InviteSession
>
>
>
> A few cases have come up with session-timers where I would like to
> change the way InviteSession works. All of the following cases are
> dealing with session-timers only so they assume the dialog is already
> set up.
>
> sender is the UAC that sends the UPDATE or INVITE
> receiver is the UAS that receives the UPDATE or INVITE
>
>
> sender INVITE
> a) receive 200 OK with sdp with same origin as previously
> - in this case we will always reINVITE with the same version as
> current local sdp
> - when the 200 OK is received we do not need to call onAnswer since
> nothing has changed
>
>
> [Scott] - Why look at origin? Isn't is it legal for the sender of the 200
> to change their SDP IP address / port. Given that, version is something we
> may want to use (initial point aside). Or maybe a version / origin combo?
>
I meant version in both cases. I guess it is feasible for the far end
to change its IP address on a reINVITE and we may need to consider
this case and call the new callback in this case as well.
>
> b) receive 200 OK with sdp with different origin as previously
> - the spec allows this to occur but I don't know what we should do. If
> we call onAnswer in this case it may cause grief for the application
> since onAnswer will be called without having called provideOffer(). I
> propose that we call a new handler onRemoteSdpModified() in this case.
>
>
> [Scott] - I'm OK with a new callback. But I didn't really have a problem
> with the onAnswer callback either.
>
It forces the applications to store more state to be able to deal with
an onAnswer call that doesn't match a provideOffer call.
>
> receiver INVITE (with sdp)
> - if the sdp differs (version) from current remote sdp call onOffer.
> Expect that the application will call provideAnswer.
>
> receiver INVITE (no sdp)
> - I don't think we handle this case correctly.
> - should call onOfferRequired.
>
>
> [Scott] I agree.
>
>
> sender UPDATE (no sdp)
> - no callbacks when 200 is received.
> - note that the api will not allow an UPDATE to occur during a
> session-timer that includes an SDP.
>
> receiver UPDATE (no sdp)
> - no callback when UPDATE is received. just send the 200.
>
> receiver UPDATE (with sdp)
> - call onOffer. provideAnswer will send the 200
>
>
> [Scott] - Shouldn't this just make the same checks as the reciever INVITE
> (with sdp) case?
>
Yes. it should be. It should also call the new callback