Andreas, An in-dialog OPTIONS (i.e. with both from and to-tag) might detect the restart, but unfortunately RFC3261 is not very clear on this. One would wish that a UA returns 481 when the dialog does not exist. However, "The response code chosen MUST be the same that would have been chosen had the request been an INVITE" does not guarantee this, as UAS might accept INVITEs with a to-tag to support failover
(as an aside, IMO that text in RFC3261 should be clarified stating that it only applies to final responses - one would not want a 180 response) Perhaps you could somehow trigger the crash detection, e.g. using target-dialog or other means. Ideally, RFC3261 would be updated to state that failover is not appropriate for OPTIONS (and hence 481 would result, as a desirable feature to detect restarts) As to support for OPTIONS: "All UAs MUST support the OPTIONS method." (RFC3261 section 11). But always check the 'Allow' header Regards, jeroen ----- Original Message ----- From: "Andreas Byström" <[EMAIL PROTECTED]> To: "'Paul Kyzivat'" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Monday, March 06, 2006 6:33 AM Subject: Re: [Sip-implementors] Session Timer for B2BUA 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
