RE: [reSIProcate] session timers and InviteSession

["Scott Godin" <slgodin@xxxxxxxxxxxx>]

Title: [reSIProcate] session timers and InviteSession

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.

 

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?

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.

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?

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel