Paul, I'm trying to find where in the spec (and which spec) I can see that it is OK to send an UPDATE without SDP body. Can you help me out? Have to convince some collegaues and cant find a good reference :) Regards, // Andreas
> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Monday, March 06, 2006 7:20 PM > To: Andreas Byström > Cc: [email protected] > Subject: Re: [Sip-implementors] Session Timer for B2BUA > > > > > Andreas Byström wrote: > > So Paul if I understand correctly, it is OK to send an > UPDATE request > > with no SDP in it? > > Yes. In fact this is one of the ways specified for doing > session timer. > > > What would be the expected response if the UA just > continues with the > > call? A 200 OK? > > Yes. If you are happy with the changes (however minimal) > proposed in the > UPDATE, then it makes sense to accept it with a 200. Its no-change if > everything is as before including having no session timer > before and not > establishing one as part of the update. If there had been a session > timer before, then an UPDATE necessarily either cancels the > old session > timer, or else renegotiates a new expiration for it. > > > If the UA responds with 4xx, would that imply that the > session should > > be tearn down? > > By "session" I think you mean "invite dialog usage". The > answer depends > on the particular error code. See the recent draft from > Robert Sparks: > draft-ietf-sipping-dialogusage-01.txt. > > Paul > > > Regards, > > // Andreas > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > > Sent: Saturday, March 04, 2006 12:28 AM > > To: Andreas Byström > > Cc: [email protected] > > Subject: Re: [Sip-implementors] Session Timer for B2BUA > > > > > > > > > > Andreas Byström wrote: > > > >>Hi all! > >> > >>I have a question regarding how a B2BUA should handle session timer. > >>The current case is that a call between A and B goes via a > B2BUA, the > >>B2BUA uses session timers to be able to have somewhat > secure billing, > > > > > > There is no reason for a UA to *request* session timer. If UA > > (including > > a B2BUA) wants to verify the sip signaling path > periodically it is free > > to do so without the use of session timer. > > > > (OTOH, it is good for the UA/B2BUA to *support* session > timer, in case > > some proxy along the path needs it. But it needn't propose the use.) > > > > > >>but A and B does > >>not support Session Timer. So what will happen is that > after time x is > >>that B2BUA must refresh the session timer towards B (I consider it > >>enough to have session timer on one call leg). The problem > is how to > >>handle SDP data. > > > > > > If you don't use session timer, then after time x (any x > you choose) > > you > > can send any convenient message to A and/or to B. It > doesn't have to be > > reINVITE. For instance OPTIONS comes to mind. It will check > continuity > > just as well as reINVITE without the offer/answer issues. > > > > OTOH, if you insist on using session timer... > > > > > >>1) Only reInvite and Update is allowed to be used to refresh session > >>timers (as according to RFC4028), right? > > > > > > Yes. > > > > > >>If B2BUA would use reInvite, if it send a reInvite to B without any > >>SDP data, B migth add a SDP offer in the 200 OK response > > > > > > There is no *might*. B MUST include offer in the first reliable > > response. > > > > > >>which means I have to > >>have a SDP response in the ACK... and I cant really do this without > >>including A... which I dont want to do (cant send the 200 > OK to A to > >>get SDP response since A did not trigger reInvite) > > > > > > You send a reINVITE to A with the offer from B. Wait for the answer > > from > > A and send that in the ACK to B. This is the standard 3pcc ploy. It > > works fine as long as it is only *re*INVITEs and they are responded > > promptly. (No alerting for the reinvite.) > > > > > >>2) Is there some way to send an reInvite, and indicate to > the recipent > >>(in this case B), that B should not insert a SDP offer in > the 200 OK? > > > > > > No. The offer is required. > > > > > >>The other option would be for B2BUA to refreash the session by > >>generating an Update to B when timer x triggers. > >>3) Is it allowed to send an UPDATE request without a SDP body? > > > > > > Yes. This is ideal for session timers, when they are needed. But it > > only > > works if the peer supports UPDATE. > > > > > >>Since there > >>is no ACK to 200 OK of a Update I guess it is not valid for > B to add a > >>SDP offer in 200 OK, which will prevent me from having the same > >>problems as in 2)... > > > > > > That is true. > > > > > >>4) What would be the expected behavior of a UA that > receives an update > >>without a SDP body? Just to keep the current voice/video session as > >>usuall? > > > > > > Yup. > > > > Paul > > > > > >>Thanks in advance! > >>// Andreas > >>_______________________________________________ > >>Sip-implementors mailing list [email protected] > >>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >> > > > > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
