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?
>
>
>
> ---> 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.
Hmm. I thought everyone was doing them as B2BUAs. I appreciate someone
trying to do them as proxies.
I'm sorry to say that a "call Stateful proxy with the right to
administratively terminate the call by sending BYE to both ends" ceases
to be a proxy when it sends the BYE. In fact, at that point it must
retroactively not have been a proxy since the beginning of the session,
even though there was no way to detect that.
But lets ignore that and give you a pass for now. :-)
>> 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.
Note that here, UAS is implementing session timer primarily as a benefit
to proxies along the path. And in this scenario its the node that fails.
S-CSCF1 implements session timer to protect itself, and in the end it does.
The nodes that don't implement session timer have to have some other
mechanism to protect themselves. For the proxies, there is little else
they can do. I think they are just broken. In the absence of session
timer support on the call they shouldn't be keeping any call state. UAC
probably has no great problem. It will give up its state when its user
hangs up, or when it has occasion to do signaling and that fails.
> 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?
The problem with such audits is that there is nothing a *proxy* can do
to test the validity of the session. About all you could do is put a
maximum on how long you think a session should be allowed to exist, and
give up state at that time, even if the session is still active. That
isn't a very acceptable solution.
Note that proxies that support and depend on session timer are dependent
that either the UAC or UAS support it. If not, they are stuck. I guess
if the node is sufficiently capable it could revert to being a B2BUA in
that case. But that is difficult because it may not know that session
timer isn't supported until it receives the response from the UAS, and
then its almost too late. To insert itself in the middle at that point I
guess it would have to send an INVITE/Replaces in both directions.
Thanks,
Paul
>> 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
