Thanks for your response Paul! If I want to verify that a specific session is still up, the OPTIONS request is not enough, right? If I use options each 3rd minute, and the UA restarts in these 3 minutes, there is no way for the B2BUA to know if a specific call is up or not? So I guess I'm stuck with using either OPTIONS or reInvite...
Has anyone got a clue about how wide support for OPTIONS reqiest is supported? Almost every UA? 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
