dushyant 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?

> 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.

> 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? 
> 
>  
> 
> 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

Reply via email to