Dushyant, P-CSCF1, S-CSCF2 and P-CSCF2 should also implement session-timers to remove their hung state. If they do not support session-timers, they are non-compliant and you really can not do much. This is recommended and widely used way. There are other ways like audit that you mentioned or using OPTIONS but all of these have inter-operation problems. Also, a RFC compliant UAS should not decrease session-expires below Min-SE. If it does, SCSCF can terminate session once the session gets established by sending BYE to both sides.
On Sat, Sep 6, 2008 at 11:48 AM, dushyant <[EMAIL PROTECTED]>wrote: > > Hi All, > > > > > > We are developing IMS core network nodes esp. CSCF. I have a query > related > > > to implementation of RFC 4028 especially w.r.t. 3GPP TS 24.229 and 3GPP > TS > > > 32.260 procedures. > > > > Which of the P/I/S-CSCFs are B2BUAs? All of them? > > > > ---> Currently, in our product line none of them is a B2BUA though they are > call Stateful proxies. P-CSCF and IBCF could be B2BUA if ALG functionality > is merged with them. S-CSCF is a call Stateful proxy with the right to > administratively terminate the call by sending BYE to both ends. > > > > > 1. As per 3GPP TS 24.229 - When the P-CSCF receives from > the > > > UE an INVITE request, the P-CSCF may require the periodic refreshment of > the > > > session to avoid hung states in the P-CSCF. If the P-CSCF requires the > > > session to be refreshed, then the P-CSCF shall apply the procedures > > > described in RFC 4028 clause 8. This clause says "When the current time > > > equals or passes the session expiration for a session, the proxy MAY > remove > > > associated call state, and MAY free any resources associated with the > call. > > > Unlike the UA, it MUST NOT send a BYE". > > > > 4028 is written to address the situation of a pair of UAs in a session > > that may involve some Record-Routed proxies. It doesn't directly address > > the situation where intermediate nodes are B2BUAs. A B2BUA should be > > treated as a pair of UAs, each with a session. Session timer needs to be > > managed on each session. There is no requirement that session timer > > refreshes be propagated across the B2BUA, though you may of course do so > > if you wish. > > > > I will also mention again, as I do every few months when this comes up, > > that there is no *need* for a UA to *request* session timer. The real > > value of session timer is to provide a way for a *proxy* to request > > periodic updates, since a proxy can't initiate any in-session signaling > > itself. A UA can initiate signaling any time it desires to verify the > > state of the path and the other end - it doesn't have to negotiate > > session timer before doing that. > > > > > 2. Now, consider a case when UAC, P-CSCF1, S-CSCF2 and > P-CSCF2 > > > don't support but SCSCF1 and UAS support session refreshment. On timer > > > expiry UAS doesn't generate a BYE and SCSCF1 removes its respective call > > > context. In such a case how will UAC, P-CSCF1, S-CSCF2 and P-CSCF2 > release > > > their hung states??? > > > > First, can you please define exactly what happens during the initial > > call establishment? Assuming these are all B2BUAs, exactly what session > > timer headers are passed between which nodes? I think once that is > > sorted out it will be easy to answer your question. > > > > ---> As mentioned above none of them is B2BUA. The call is established as a > normal call and timers flow between SCSCF1 and UAS in the response to > INVITE. The refresher is UAS and the UAS doesn't send a BYE at the expiry > of > the timer and S-CSCF1 kills its call context. In such a case how will UAC, > P-CSCF1, S-CSCF2 and P-CSCF2 release their hung states though I concede, it > would be a rare case. > > In the current telecom systems there are facilities for audits which run at > regular intervals and clear the hung states of the call. Is this RFC to be > implemented as a confirmatory test for clearing such calls? > > > > > > > > > 2. On session expiration will S-CSCF1 send any trigger > towards > > > charging data function (on Diameter)??? If yes, there are various AVPs > which > > > might not get filled. > > > > That is an IMS question. This is the wrong forum to discuss it. > > > > Thanks, > > Paul > > > > > 3. As per 3GPP TS 32.260 charging data function starts an > > > interim timer when it expects Account charging request from Charging > trigger > > > function at CSCF nodes. What is correlation between this timer and > session > > > refreshment timer? > > > > > > 4. The header Min-SE has been defined to avoid unnecessary > > > load of session refreshment at proxies. Proxy can decide the maximum rate > at > > > which it wants to receive the Session refreshment request. The headers > > > Session-Expires and Min-SE are checked only in requests. Consider a case > > > when UAC is a 'refresher' and UAS decreases the value of session expires > to > > > a very low value in response. In responses the proxies are not supposed > to > > > check the session expiry timer, so effectively the purpose of Min-SE > (that's > > > to avoid unnecessary load) gets defeated. In such a scenario, in my > opinion > > > proxies should be allowed to modify these headers in response also. > > > > > > > > > > > > Finally, my question is how important is to implement this RFC, as even > in > > > the current telecom systems there are facilities for audits which run at > > > regular intervals and clear the hung states of the call. > > > > > > > > > > > > Can anybody provide tell me at which mailing list should I pose the > queries > > > related to 3GPP TS IMS procedures? > > > > Again, I ask, can anybody suggest me the mailing list of IMS forum? > > > > > > > > > > > > > > Dushyant P S Dhalia > > > > > > _______________________________________________ > > > 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
