Feature #3069
investigate multiple CM Service Request on the same conn
0%
Description
TS 24.008 Section 4.5.2:
According to the protocol architecture described in 3GPP TS 24.007
[20], each CM entity will have its own MM connection. These different
MM connections are identified by the protocol discriminator PD and,
additionally, by the transaction identifier TI.
So for example, one could have multiple calls (same pdisc, but different TI),
or one could have SMS ongoing while a call (different pdisc+TI).
Testing an SMS sent during an ongoing call indeed shows a secondary CM Service Request.
In attached pcap it seems that we are already handling the situation rather well.Nevertheless, take a close look:
- are we handling the TI properly?
- make sure that the tear down of one service handling doesn't cut short any other pending CM Service Requests,
especially if one CM Service Request concludes while the another has just sent the CM Service Request and we are still waiting for the actual CC/RR/... service request following.
(I also notice in attached PCAP that DTMF requests are rejected, and that a call Hold command is rejected; that may have to become separate issues.)
Related issues
History
#1 Updated by laforge almost 3 years ago
neels wrote:
(I also notice in attached PCAP that DTMF requests are rejected, and that a call Hold command is rejected; that may have to become separate issues.)
both are expected with the internal MNCC handler.
#2 Updated by laforge almost 3 years ago
- Assignee set to sysmocom
#3 Updated by laforge almost 3 years ago
- Assignee changed from sysmocom to neels
#4 Updated by neels almost 3 years ago
- Has duplicate Feature #3156: make sure we handle N overlapping CM Service Requests properly added
#5 Updated by neels over 1 year ago
Sort of related: osmo-msc master has been refactored and now supports multiple use counts of identical type on an ongoing connection (e.g., two SMS transactions at the same time without causing refcount errors)
