Attention is currently required from: laforge, neels, pespin.
2 comments:
Patchset:
But how is the program on the other side of GSUP supposed to know it may want to test sending SMS for that subscriber? do you mind explaining? I think it's good to have it here. There's some sort of event "Location Updated" sent there? (I guess to the HLR in this case?)
"Welcome SMS": keep in mind that it was just a guess from my side. It should be possible to get an LU event notification over the CTRL interface, for instance, but I don't think this is implemented currently.
The customer mentioned in the ticket that they simply want to optimize delivery of MT SMS queued in their SMSC by re-using the existing RR connection. So imagine there is a pending MT SMS for a subscriber, which is "offline" (detached).
The SMSC does not (and is not supposed to) know whether the recipient subscriber is "online" or not, so it would attempt to perform MT SMS delivery first. The MSC would either respond with an error immediately, knowing that the subscriber is explicitly detached, or try to page the subscriber and respond with an error on timeout.
If MT SMS delivery fails due to unavailability of the recipient, the SMSC is supposed to wait for the `readyForSM` notification from the MSC. The MSC is expected to send such a notification when the subscriber is back "online" by performing Location Updating procedure. But not unconditionally!
The VLR/MSC (and HLR too, AFAIR) needs to maintain the `MNRF (MS Not Reachable Flag)` for each subscriber. This flag is set when MT SMS delivery fails, and this flag triggers sending of the `readyForSM` notification. Unfortunately, this is not fully implemented in osmo-msc.
So this is how (in general) the external SMSC entity is supposed to know that it can attempt to deliver a MT SMS again. Regardless of the state of the `MNRF` in osmo-msc, this new X5 timer is still useful since it allows to accomodate for non-zero link delay between the MSC and an SMSC. This timer will play well with the `MNRF`, if we ever will have a chance to implement it properly.
File src/libmsc/msc_a.c:
Patch Set #2, Line 192: osmo_timer_schedule(&msc_a->lu_delay_timer, Tval, 0);
Yes that's for sure true during the usual operation. […]
Done
To view, visit change 36760. To unsubscribe, or for help writing mail filters, visit settings.