A heterogeneous communication interface retransmission control method and device based on closed transaction track, equipment and storage medium

Abstract

The present application relates to retransmission control of heterogeneous communication interfaces. A protocol analysis gateway stitches requests, synchronous observations and subsequent events into transaction traces according to communication service parties and interface semantic versions; obtains termination evidence and verifies that corresponding event channels are normal, and determines closed transaction traces. The gateway compares the highest protocol phase of each closed trace with the creation boundary of communication resources, and generates a retransmission permission, retransmission prohibition or pending state for synchronous observation identifiers. When the synchronous observation identifier of the current transaction matches the retransmission permission state, and the channel is normal during observation and no event is recorded at the deadline indicating that the transaction has reached or crossed the boundary, a retransmission request is generated; when it does not match, a retransmission request is generated only when it is clear that the service party does not accept the request, or the corresponding resource is not created and will not be created again. The state version and interface semantic version are verified before sending. The method can reduce duplicate messages, repeated outbound calls and occupied communication resources.

Description

Technical Field

[0001] This invention relates to the fields of communication protocol analysis, communication transaction association, and transmission control technology, and in particular to a method, apparatus, electronic device, and computer-readable storage medium for determining communication resource creation boundaries based on closed transaction trajectories and controlling retransmission of heterogeneous communication interfaces accordingly. Background Technology

[0002] Cloud communication platforms typically connect to multiple SMS, voice call, or messaging services simultaneously. After a business platform submits a request to the communication service interface, it first obtains a synchronous response, and subsequently may obtain asynchronous events through callbacks, SMPP receive links, call detail record (CDR) channels, SIP signaling channels, or status query interfaces. Different service providers, and even different versions of the same service provider's interfaces, may have inconsistent meanings for synchronous response codes, response body fields, and connection exceptions.

[0003] For example, if the connection is reset after the request subject has been written out, it could mean that the service provider did not receive the request, or it could mean that the service provider has established a message resource or call resource but the synchronous response has not been returned. If the business platform treats both of these results as failures and immediately resends them, it may result in a second SMS, a second outbound call, or a second billing; if it does not resend them at all, it will leave requests that did not actually reach the service provider as missed requests.

[0004] Existing implementations often employ fixed error code tables, fixed timeout retry rules, or proprietary idempotent keys. Fixed error code tables struggle to cover undocumented intermediate states and become invalid after interface semantics changes. Proprietary idempotent keys can only constrain services that support and correctly implement the key; they cannot prove whether an independently deliverable communication instance has been established in the upstream network.

[0005] Another approach is to first put the communication transaction into a pending verification state when the result of the synchronization request is unclear, and then verify it through the report delivery interface, callback event, or status query interface. If no corresponding record is detected within the preset waiting period, resend the request. Although this method delays the resend, its negative judgment is still based on the absence of a record within the waiting period. When the callback entry, receive binding, or event consumption link is abnormal, the absence of a record may be due to the failure to form downstream communication resources or the failure to receive the asynchronous event by the local party. Therefore, this cannot be used to prove that the original request stopped before the formation of communication resources.

[0006] Some interface management solutions form interface observation types based on request and response fields, or adjust interface call strategies based on historical success rates. However, if synchronous observations are not closed together with subsequent protocol events and asynchronous receive channel health records for the same communication transaction, the historical samples themselves may contain missing evidence; furthermore, the correspondence between the original observation type and the network execution phase may no longer hold after changes to the interface address, adapter build version, or response field set of the communication service provider.

[0007] Another type of implementation uses subsequent delivery receipts, call detail records, or SIP events for delivery statistics and operational analysis, but typically does not verify whether the asynchronous event receiving channel itself is functioning correctly. When the callback entry fails or the receiving queue is backlogged, simply interpreting "no subsequent events" as "no communication resources created" will still result in an erroneous retransmission.

[0008] Therefore, a technical solution is needed that can analyze synchronous observations and subsequent asynchronous event evidence in the same communication transaction, clearly distinguish between complete and missing evidence, and use the analysis results for current transaction retransmission control. Summary of the Invention

[0009] The technical problem this invention aims to solve is: in situations where the synchronous response semantics of heterogeneous communication service interfaces are inconsistent and the service provider may not support its own idempotent keys, how to determine whether an abnormal synchronization observation has crossed the communication resource creation boundary that would generate duplicate communication instances, thereby avoiding duplicate transmissions while retaining the necessary retransmission capability.

[0010] To address the aforementioned technical problems, this invention establishes a protocol analysis gateway between the business platform and the communication service interface. This gateway does not directly interpret a single response code as a retransmission instruction; instead, it first generates a communication transaction trace that can be verified by subsequent events.

[0011] The request log should at least store the local transaction identifier, the service provider identifier, the interface semantic version, the target communication parameter summary, and the write phase. The synchronous observation log should at least store the connection status, response code, existence of response fields, and the obtainable service provider transaction identifier. Asynchronous communication event logs include delivery receipts, SIP session events, call detail record (CDR) events, recording task events, or active status query results.

[0012] The protocol analysis gateway concatenates the above records into the same transaction trajectory based on field inheritance relationships. The native protocol identifier is used preferentially for field inheritance relationships; if the native protocol identifier is incomplete, a composite fingerprint that has been excluded from collisions can be used, but trajectories that have not been excluded from collisions do not participate in state generation.

[0013] A transaction trajectory cannot be considered closed solely due to the expiration of the waiting time. The trajectory must contain termination evidence as defined by the protocol or the service provider's interface, or an authoritative final state obtained through an active state query. Simultaneously, it must demonstrate that the asynchronous event receiving channels enabled in the phase configuration set for the business type to which the corresponding communication transaction belongs, and used to receive events that prove the formation of independently executable communication resources, were able to access and consume events normally during the observation period. Only when all the above conditions are met does the absence of subsequent events have a negative meaning. An authoritative final state refers to a state query result that can be uniquely associated with the corresponding communication transaction, and, according to the state meaning declared in the current interface semantic version and phase configuration, has made a definitive conclusion regarding whether the original request was accepted, whether the corresponding communication resource has been formed, and whether there is still a subsequent state path leading to the boundary of the communication resource creation. Returns from ordinary queries such as "no record found," "processing," "incomplete results," or "query unavailable" are not considered authoritative final states. The phrase "not created and will not be created in the future" in this specification means that the query result not only indicates that there is no corresponding communication resource at the time of the query, but also that, according to the state transition relationship defined by the current interface semantic version, the transaction no longer has a subsequent path to enter the boundary of communication resource creation; if it is still possible to be accepted asynchronously, continue to be processed, or form a communication resource, then it will remain pending confirmation.

[0014] This invention isolates trajectories based on the communication service provider and the semantic version of the interface. The interface semantic version can consist of an interface address digest, adapter build version, a digest of the response field name set, or a digest of the interface description file. This isolation prevents the historical state of older versions from being directly applied to newer versions where field meanings have changed.

[0015] Synchronization observation records are normalized to form synchronization observation identifiers. Field normalization removes transaction-varying fields such as random request identifiers, timestamps, and communication service transaction identifiers, while retaining the transport layer write phase, connection closure type, response code, stable field values, and field existence. Therefore, the same type of synchronization anomaly can be compared across multiple closed trajectories.

[0016] An ordered protocol phase includes at least the following stages: request not received by the service provider, request received by the service provider but not yet forming an independent communication resource, independent communication resource formed, submitted to the bearer network, reached the receiving side, and termination. Different services use different phase evidence, but all clearly define the boundaries of communication resource creation. The protocol phase mapping sub-unit determines the highest protocol phase reached by each closed transaction trajectory based on the protocol fields and event sequence.

[0017] The communication resource creation boundary indicates that if a service request is recreated at the corresponding stage, a second independently executable or deliverable communication instance can be formed. When multiple candidate stages exist for the same service type, the earliest stage in the stage configuration set for the service type, communication service provider, and interface semantic version of the corresponding communication transaction that can prove the formation of an independent communication instance will be determined as the communication resource creation boundary. In messaging services, this boundary can be confirmed by the message identifier of the communication service provider marked as having established an independent message resource by the current interface semantic version; in calling services, the establishment of the called party session is used as the boundary, and the called party ringing event and the uniquely associated call detail record session are cross-boundary evidence after reaching this boundary. The cross-boundary event referred to in this specification is a subsequent communication event that can be uniquely associated with the corresponding communication transaction and prove that the transaction has reached or crossed the communication resource creation boundary.

[0018] For the same communication service provider, interface semantic version, and synchronization observation identifier, asymmetric rules are used for state generation. A "no retransmission" state is generated if any closed trajectory crosses the communication resource creation boundary. A "retransmission allowed" state is generated only if no cross-boundary closed trajectory exists, and the number of closed trajectories before the boundary is not less than the positive integer thresholds configured for the communication service provider and interface semantic version respectively. Otherwise, a "pending confirmation" state is generated.

[0019] When controlling the current transaction, historical state and current observation are used together for judgment. A retransmission request is generated if the synchronization observation identifier of the current communication transaction matches the retransmission-allowed state, and if the access and consumption states of all event receiving channels enabled in the phase configuration set for the service type to which the current communication transaction belongs are normal during the current observation period, and no cross-boundary events are recorded before the observation deadline. For current communication transactions whose synchronization observation identifier does not match the retransmission-allowed state, a retransmission request is generated only if the status query clearly indicates that the communication service provider did not accept the original request, or did not create and will not create the corresponding communication resource subsequently. Before the retransmission request is actually sent, a condition update is performed on the corresponding status record to verify that the status version and interface semantic version have not changed; the request is sent only if the condition update is successful, and stops sending and is converted to pending confirmation if it fails.

[0020] For messages in the pending confirmation status, the system does not directly resend the message. Instead, it calls the service provider's status query interface, extends the event observation period, or transfers the message to manual processing. The pending confirmation status indicates that the existing evidence is insufficient to determine whether to retransmit, and does not trigger automatic retransmission.

[0021] When the interface semantic version changes, or when a subsequent event that is inconsistent with the existing state but can be uniquely associated with the original transaction is received after the existing state has been generated, the corresponding synchronization observation flag immediately becomes invalid. The current transaction after invalidation becomes pending confirmation, and closed trajectories are re-accumulated.

[0022] Compared to a fixed error code table, this invention bases retransmission judgment on complete, traceable transaction evidence; compared to ordinary receipt statistics, this invention verifies the availability of the receipt receiving channel and directly uses the communication resource creation boundary for transmission control; compared to simple idempotent keys, this invention can be used in scenarios where the service provider does not support its own idempotent keys.

[0023] The present invention has at least the following beneficial effects: First, it reduces duplicate SMS messages and duplicate outbound calls generated after synchronization timeouts or connection resets, thereby reducing the consumption of additional signaling, session, and message resources; Second, it allows controlled retransmission of requests that stop before the boundary of communication resource creation, reducing missed transmissions; Third, subsequent events that cause changes in interface semantic version or inconsistencies with existing states can invalidate old states, avoiding the application of old interface conclusions to new interfaces; Fourth, status queries and audit records retain protocol evidence on which each retransmission decision is based, facilitating operation and maintenance review. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the system structure according to an embodiment of the present invention.

[0025] Figure 2 This is a schematic diagram of the retransmission control process according to an embodiment of the present invention.

[0026] Figure 3 This is a schematic diagram of communication transaction field inheritance and trajectory splicing in an embodiment of the present invention.

[0027] Figure 4 This is a schematic diagram illustrating the generation of the three-state retransmission state in an embodiment of the present invention.

[0028] Figure 5 This is a schematic diagram illustrating interface semantic version changes and state failures in an embodiment of the present invention.

[0029] Figure 6 This is a schematic diagram of the protocol phases in the message interface and call interface according to an embodiment of the present invention. Detailed Implementation

[0030] The embodiments of the present invention will be further described below with reference to the accompanying drawings. These embodiments are used to illustrate the technical solution and do not limit the scope of protection of the claims.

[0031] like Figure 1As shown, the service platform 101 connects to the communication service interface 120 via the protocol analysis gateway 110, and the communication service interface 120 then communicates with the receiving terminal 140 via the bearer network 130. The protocol analysis gateway 110 includes a trajectory stitching unit 111, a closure determination unit 112, a boundary state unit 113, a state query unit 114, and a retransmission control unit 115. The boundary state unit 113 includes a protocol phase mapping subunit, a state generation subunit, and a state failure subunit; each of the above units and subunits implements the function of the corresponding module in claim 8. The above units can be deployed in the same service process or distributed through a message bus.

[0032] Protocol analysis gateway 110 generates a local transaction identifier for each service submission. Before triggering a network transmission action, protocol analysis gateway 110 writes its local transaction identifier and its association with the request record into recoverable storage, so that the transaction trajectory can be resumed by subsequent events in the event of a process exception after the request is written. The request record also stores the adapter build version, target communication service provider, interface address digest, request type, and target communication parameter digest. Sensitive numbers or message text can store irreversible digests; plaintext storage in the analysis database is not required.

[0033] Synchronous observations are recorded according to the actual network process. The write phase can distinguish between: connections not yet established, connections established but request headers incomplete, request bodies complete, response headers received, partial response bodies received, and complete responses received. For long-lived connection protocols, the connection session identifier and sequence number are also recorded.

[0034] In the HTTP message interface, the local request identifier can be passed through the request header; when the service returns a message identifier in the synchronous response, it adds the message identifier to the transaction record. When subsequent callbacks carry message identifiers, the trajectory splicing unit 111 first associates them according to the message identifier; transactions that do not return a message identifier remain pending and are processed through status query or a composite fingerprint after collision exclusion.

[0035] In the SMPP interface, the first link can be established using the sequence_number of submit_sm and submit_sm_resp, and the second link can be established using the message_id in submit_sm_resp and the received_message_id in the delivery_sm receipt. Only when the link chains are continuous can the relevant trajectory be used as closure evidence.

[0036] In the SIP call interface, Call-ID, CSeq, and Via branch parameters can be used to associate requests and responses, and the communication service provider's call identifier, conversation identifier, or CDR session identifier can be included in the same track. If the communication service provider's HTTP control plane and SIP media control plane use different identifiers, the adapter preserves the inheritance relationship when both first appear simultaneously.

[0037] The closure determination unit 112 maintains a termination evidence table. Termination evidence for messaging services can be a final delivery receipt, a final failure receipt, or an authoritative final state returned by a status query; termination evidence for call services can be a combination of a SIP termination event and a final CDR, a final state returned by a query from the communication service provider, or a query result explicitly indicating that the call request was not accepted and will not be subsequently created as a call resource. The termination evidence table stores returned states that can serve as authoritative final states and their mappings to ordered protocol stages according to the interface semantic version; query results not mapped to termination states are not used to draw the conclusion "will not be subsequently created."

[0038] The closure determination also reads the health records of each asynchronous event receiving channel enabled in the stage configuration. For example, the callback entry is consistently available during the observation period, authentication is normal, and the event queue can advance the consumption level; or the Short Message Peer-to-Peer Protocol (SMPP) receiving binding remains normal and no backlog exceeding the threshold occurs. If no business events arrive during the observation period, the event consumption status is considered normal only after obtaining the channel integrity record covering that period; this record can be formed by message broker progress markers, heartbeat events generated by the communication service provider, or probe events processed along the same authentication and consumption path, indicating that the event stream processing progress has reached the observation deadline. Heartbeats from the local business process alone are not sufficient evidence. If any enabled channel is unavailable during a critical period or lacks an integrity record covering the observation period, it is not considered to be terminated before the boundary, even if the trajectory temporarily has no subsequent events.

[0039] For Session Initiation Protocol (SIP) signaling channels, verification is performed by collecting session status via signaling, monitoring the continuous operation of the protocol stack receiving process, and confirming that the signaling processing progress has reached the observation deadline. For Call Detail Record (CDR) channels, verification is performed by retrieving CDR task status, the coverage area of ​​the most recently successful batch, and the entry threshold. If the communication service provider cannot provide verifiable batch or billing threshold information, the CDR channel must not be used alone to terminate before the boundary is interpreted as an unseen event.

[0040] The observation period begins when the synchronous observation record is formed, and the observation duration is configured according to the communication service provider and interface semantic version. The observation end time is determined by the synchronous observation record formation time and the observation duration. The observation period can end when a termination event or a status query final state is obtained. The channel access status, event consumption status, and channel integrity records have the same channel identifier and time reference as the asynchronous event records; trajectories for which termination evidence has not been obtained by the observation end time remain in a non-closed state. Subsequently, when a late termination event is obtained, the channel status from the formation of the synchronous observation to the arrival of the late termination event is supplemented and verified; if the supplementary verification fails, the trajectory is still not considered a closed sample.

[0041] In one embodiment, the system concatenates the communication service provider identifier, request address digest, adapter build version, response field name set digest, and interface description file digest to generate an interface semantic version identifier. When a participating field changes, the historical synchronization observation identifier is marked as invalid and stopped from being used for new transactions.

[0042] The field normalization rules for synchronization observation identifiers are determined by both the field type and historical differences. Transactionally changing fields explicitly marked as request identifiers, message identifiers, call identifiers, timestamps, or random numbers are removed; stable fields retain their field name, value, and whether they are missing. For cases where the response body is incomplete, the synchronization observation identifier also retains the received length range and the connection closure type.

[0043] The ordered protocol phases are described by the phase configuration settings set by the adapter for the service type to which the communication transaction belongs. The phase configuration lists each protocol phase, the evidence required to enter the corresponding protocol phase, evidence of inconsistencies with the corresponding protocol phase, and the event receiving channels and their enabling status for receiving events that prove an independently executable communication resource has been formed. Phases cannot proceed solely based on elapsed time. For example, a message interface cannot assume a message resource has been formed simply by waiting a few seconds without a message identifier, service provider acceptance confirmation event, or status query result.

[0044] The first implementation involves message sending. The business platform submits a logistics notification; after the HTTP request body is written, the connection is reset, and the synchronization observation is recorded as "request body completed + no complete response + connection reset". A subsequent callback displays the corresponding service-side message identifier and the final delivery receipt. This transaction trajectory closes under the condition that the asynchronous channel is healthy and has already crossed the communication resource creation boundary that forms an independent message identifier. Therefore, the same synchronization observation identifier under this version is marked as "do not retransmit".

[0045] For the first embodiment described above, if the current transaction has not received a callback after the synchronization connection is reset, the system does not immediately resend the request. Instead, it first queries based on the communication service provider's message identifier, the local transaction identifier, or the target parameter summary. If the query result indicates that the corresponding communication resource already exists, the process continues to block. Only when the query result is uniquely associated with the current transaction and clearly indicates, according to the current interface semantic version, that the original request was not accepted, or that the corresponding communication resource has not been created and no longer has a subsequent state path to the boundary of communication resource creation, is the current transaction allowed to generate a retransmission request. If the result only indicates that the resource has not yet been found or that processing may continue, it does not meet the requirement of "will not be created subsequently," and is therefore kept pending confirmation.

[0046] The second embodiment still involves message sending. An interface experiences a name resolution failure before connection establishment, and the request does not enter the communication service provider's network. The number of similar closed trajectories is not less than the positive integer threshold configured according to the semantic version of the communication service provider and interface, and all terminate before the communication resource creation boundary. Based on this, the system generates a retransmission-allowed state for the synchronization observation identifier. If the current transaction has the same synchronization observation identifier, and the callback entry, authentication, consumer heartbeat, and consumption level are all normal during the observation period, and no cross-boundary events are recorded before the deadline, the system generates a controlled retransmission request. For transactions that do not match the retransmission-allowed state, a retransmission request is only generated if the status query clearly indicates that the original request was not accepted, or that the corresponding communication resource has not been created and will not be created subsequently.

[0047] The third embodiment is a voice call. The service platform requests to create an outbound call. The control interface times out before returning, but the SIP side subsequently receives an INVITE with the corresponding Call-ID and the called party rings. The final CDR also includes the communication service provider's call identifier. This closed loop proves that an independent called party session has been established. The system prohibits the application layer from recreating the call to prevent the same user from receiving two outbound calls.

[0048] If no SIP event occurs after the call control interface times out, but a backlog occurs in the callback queue at the same time, the trajectory remains open and the status is pending confirmation. The status query unit 114 queries by the communication service provider's call identifier or the local transaction identifier; if no clear result can be obtained, it is transferred to manual processing, rather than interpreting the absence of an event as the call not being created.

[0049] To prevent erroneous associations of composite fingerprints, when multiple candidate transactions exist within the same tenant, with the same target parameter summary, and overlapping time intervals, the trajectory stitching unit 111 marks the association as a conflict. Conflicting trajectories can be used for operational investigations but are not used to generate retransmission-allowed states. Only the trajectory corresponding to a composite fingerprint that is unique and has not collided with other transactions within the same time interval participates in state generation.

[0050] State generation uses asymmetric evidence strength. Prohibiting retransmission requires only one closed trajectory to prove that the same synchronous observation identifier may cross the boundary created by the communication resource; allowing retransmission requires that the number of closed trajectories is not less than a positive integer threshold configured according to the communication service provider and interface semantic version, and that all these closed trajectories terminate before the boundary and that there are no events inconsistent with the conclusion during the corresponding observation period. This asymmetric rule stops automatic retransmission when cross-boundary samples have appeared, and keeps the status pending confirmation when the number of samples before the boundary is insufficient.

[0051] The above-mentioned asymmetric evidence rule can be expressed as:

[0052] (∃ τ ∈ T p,v,o cl : b ( τ ) ≥ b 0) ⇒ S p,v,o = F

[0053] (| T p,v,o cl | ≥ N p,v ∧ ∀ τ ∈ T p,v,o cl : b ( τ )< b 0) ⇒ S p,v,o = A

[0054] In the formula, p , v and o These respectively represent the communication service provider, the interface semantic version, and the synchronization observation identifier; T p,v,o cl Represents the set of closed transaction trajectories corresponding to the three, | T p,v,o cl | indicates the number of closed trajectories in the set; b ( τ This indicates the highest protocol stage reached by the closed transaction trajectory. b 0 indicates the boundary of communication resource creation; greater than or equal to indicates that the boundary has been reached or crossed in the ordered protocol phase; less than indicates that it is located before the boundary. N p,v This represents the threshold number of closed trajectories configured according to the communication service provider and the interface semantic version, and the threshold is a positive integer;S p,v,o This indicates the retransmission status of the corresponding communication service provider, interface semantic version, and synchronization observation identifier; F and A These represent the states of "retransmission prohibited" and "retransmission allowed," respectively. If neither of these conditions is met, the state is "pending confirmation."

[0055] The greater than or equal to relationship in the above formula indicates that the closed transaction trajectory has reached or exceeded the communication resource creation boundary.

[0056] The positive integer threshold N is pre-determined based on the communication service provider and the interface semantic version. It specifies the minimum number of uniquely associated, fully evidenced closed trajectories, all ending before the communication resource creation boundary, required for automatic retransmission control, provided no cross-boundary closed trajectories exist. N is selected based on the range of achievable closed evidence under the same communication service provider and interface semantic version, and is not replaced by the expiration of waiting time, absence of subsequent events, or a single failure record. When the number of closed trajectories is less than N, the system only generates a pending confirmation state; when the number is not less than N, the system continues to receive subsequent events uniquely associated with the original transaction. When the interface semantic version changes or subsequent events occur that are inconsistent with the existing state, the existing state becomes invalid, and closed trajectories are re-accumulated on the new version or updated evidence set. N only determines whether automatic control is initiated; it does not change the criteria for judging whether a single trajectory is closed or crosses the communication resource creation boundary.

[0057] The current transaction control reads the channel health record and cross-boundary event record during the current observation period. Synchronous observation identifier matching allows retransmission, but if the current transaction already contains a communication service provider message identifier, called-side session, or other cross-boundary evidence, the retransmission control unit 115 blocks new transmission requests.

[0058] When an interface semantic version change occurs, the version detector first stops using the existing state and then puts the trajectory generated by the new version into a separate set. When a subsequent event inconsistent with the existing state is received, the system records the original request, synchronous observation, asynchronous channel state, and termination evidence corresponding to the event, and invalidates the state of the synchronous observation identifier of the same version.

[0059] To avoid race conditions between state invalidation and retransmission, the state record carries a monotonic version number. After reading the state, the retransmission control unit verifies that the state version and interface semantic version have not changed by conditional update before sending a retransmission request; if the state is invalidated during this interval, the retransmission request is suppressed, and the current communication transaction is set to pending confirmation.

[0060] The system generates a new local transaction identifier for controlled retransmissions and maintains the retransmission relationship between the old and new transactions. This relationship is used for auditing and subsequent duplicate detection, but it cannot replace boundary judgment for communication resource creation. For service providers that support idempotent keys, idempotent keys can be carried as additional protection.

[0061] During implementation, original request records, synchronous observations, asynchronous events, channel health levels, interface semantic versions, synchronous observation identifiers, protocol phases, state changes, and final control results should be preserved. Sensitive fields can be anonymized or summarized, but the inheritance relationships of fields used for transaction associations must be verifiable.

[0062] A set of functional verification processes includes: scenarios where the synchronous connection is disconnected after the request body is constructed but the communication service continues to establish resources; scenarios where the connection construction fails before it is established and the query confirmation is not accepted; scenarios where callback consumption is disabled, making the channel unavailable; scenarios where the old synchronous observation flag is replayed after the interface response field is changed; and scenarios where subsequent events inconsistent with the existing state are injected after the state is generated. Each process verifies retransmission prohibited, retransmission allowed, pending confirmation, and state invalidation respectively.

[0063] Synchronous observation identifiers, interface semantic versions, and stage states can be implemented using field normalization and a deterministic state machine. The state record must at least store the interface semantic version, state version, and closed trajectory index used during generation; before sending a retransmission request, the state record is updated to verify that these versions have not changed.

[0064] This invention can be used for SMS notifications, cloud calls, cloud customer service outbound calls, logistics notifications, government hotlines, and other scenarios where communication instances are created through heterogeneous communication service interfaces. In all of these scenarios, request records, synchronization observation records, and subsequent protocol events that can be associated with the same transaction are saved. Fourth Implementation Example: Verification of Retransmission Control Function

[0065] This embodiment illustrates the verification method of the retransmission control unit by pre-defining deterministic scenarios with input records, event arrival order, and state change conditions. Each scenario uses request records, synchronous observation records, asynchronous event records, channel health records, interface semantic versions, and state versions as observable inputs, and checks the state the state machine should enter and the audit records that should be generated. This embodiment only specifies the verification conditions and expected behavior; it does not use the expiration of the waiting time or the absence of events as sole evidence that communication resources have not been created.

[0066] Scenario 1: Connection failure before establishment. The request log indicates that the connection has not yet been established. The write phase occurs before the service receives the request. The status query returns the authoritative final state uniquely associated with the transaction, indicating, according to the current interface semantic version, that the original request was not accepted and no longer has a subsequent state path to the communication resource creation boundary. In this case, even if the synchronization observation identifier does not match the retransmission allowed state, a retransmission request should still be generated; before sending, the state version and interface semantic version should still be updated conditionally. The audit log should save the request write phase, the query result and the transaction's associated fields, the authoritative final state mapping, the condition update result, the old and new transaction identifiers, and the retransmission relationship. If the query only indicates that no record was found or that processing may continue, the expected status is pending confirmation.

[0067] Scenario 2 involves a request body that has been written, a synchronous response lost, and a subsequent communication resource created by the service provider. Subsequent events carry a service provider transaction identifier uniquely linked to the original transaction or other cross-boundary evidence, proving that the transaction reached or exceeded the communication resource creation boundary. When the enabled event receiving channel is functioning normally, the trajectory should close and generate a no-retransmission state. Current transactions corresponding to the same communication service provider, interface semantic version, and synchronization observation identifier should not be automatically retransmitted. Audit logs should preserve the trajectory splicing basis, the highest protocol stage, the communication resource creation boundary, cross-boundary events, closure determination, and the reason for prohibiting retransmission.

[0068] Scenario 3 involves an interrupted event reception channel. The current transaction did not record any cross-boundary events at the observation deadline, but at least one event reception channel enabled in the phase configuration is unaccessible, authentication is faulty, the consumption level has not advanced, or there is a lack of channel integrity records covering the observation period. This transaction trajectory must not close due to the absence of events; the expected status is "pending confirmation," and no automatic retransmission request should be generated. Audit logs should retain the abnormal channel identifier, abnormal time range, consumption level or integrity record gap, as well as subsequent status queries, extended observation periods, or branches requiring manual processing.

[0069] Scenario 4 involves changes to the semantic version of the interface. After state generation, the participating fields in the interface address digest, adapter build version, response field name set digest, or interface description file digest change. The version detector should stop using existing states, invalidate the states corresponding to the original synchronous observation identifiers, and place the transaction traces generated by the new version into a separate set; until sufficient closure evidence is formed for the new version, the current transaction remains pending confirmation. The audit log should save the interface semantic version before and after the change, the participating fields that triggered the invalidation, the invalidated states, and the new version trace set identifier.

[0070] Scenario 5 involves events that are late and inconsistent with the existing state. After the retransmission state is established, a subsequent event is received that can uniquely link to the original transaction and prove that the transaction has reached or exceeded the communication resource creation boundary. The system should record this event and its associated evidence, invalidate the existing state corresponding to the same communication service provider, interface semantic version, and synchronization observation identifier, and change the affected current transaction to pending confirmation; whether the late event closes the original trajectory should also be verified by supplementing the verification of the channel state from the time of synchronization observation formation to the time of arrival of the late event. The audit log should save the late event, the scope of supplementary verification, the state before and after the failure, and the reason for the failure.

[0071] Scenario 6 involves concurrent state failure before retransmission. After the retransmission control unit reads the retransmission permission status but before actual transmission, subsequent events such as changes or inconsistencies in the interface semantic version cause the state version to increment. Condition updates should fail due to inconsistencies between the read and current versions; the system should suppress transmission and set the current transaction to pending confirmation. Audit logs should save the read state version, the current version at the time of condition update, the interface semantic version, the reason for update failure, and the non-transmission flag to demonstrate that the race condition between state failure and transmission did not lead to duplicate requests.

[0072] When verifying the above scenarios, the retransmission status should also meet the asymmetric evidence rule: there are no cross-boundary closed trajectories under the same communication service provider and interface semantic version, and the number of closed trajectories before the boundary is not less than a pre-configured positive integer threshold N. The verification record should be able to trace the index of the closed trajectory involved in the counting, the closure evidence of each trajectory, and the highest protocol stage; unclosed trajectories, associated conflicting trajectories, and trajectories with insufficient channel integrity are not included in N. This verification is used to confirm whether the state transition and audit fields comply with the rules described in this specification, and does not constitute a statement on the specific number of runs, sample size, or performance results.

Claims

1. A retransmission control method for heterogeneous communication interfaces, executed by a protocol analysis gateway located between a service platform and at least one communication service interface, characterized in that, include: S1. Group the request records, synchronization observation records, and subsequent communication event records of communication transactions according to the communication service provider identifier and interface semantic version, and concatenate the transaction trajectories belonging to the same communication transaction based on the transaction association field; S2. When the transaction trajectory obtains the authoritative final state returned by the protocol termination event or status query, and it is verified that the access status and event consumption status of each event receiving channel enabled in the stage configuration set for the service type to which the communication transaction belongs, used to receive events that can prove that an independently executable communication resource has been formed, are normal during the observation period, the transaction trajectory is determined as a closed transaction trajectory, wherein the stage configuration declares an ordered protocol stage according to the service type, S3. Convert synchronization observation records into synchronization observation identifiers, and determine the position of the highest protocol stage reached by each closed transaction trajectory relative to the communication resource creation boundary based on the protocol fields and event sequence of each closed transaction trajectory. The communication resource creation boundary is the earliest protocol stage in the stage configuration that can prove that an independently executable communication resource has been formed. S4. For the same communication service provider, interface semantic version, and synchronization observation identifier, generate a no-retransmission state when any closed transaction trajectory reaches or crosses the communication resource creation boundary. This is done when the number of closed transaction trajectories is not less than the closed trajectory number threshold, and each closed transaction trajectory... When all trajectories stop before the communication resource creation boundary, a retransmission-allowed state is generated; otherwise, a pending confirmation state is generated. The threshold for the number of closed trajectories is a positive integer pre-set according to the communication service provider and the interface semantic version. S5: For current communication transactions whose synchronization observation identifier matches the retransmission-allowed state, if the access status and event consumption status of each event receiving channel are normal during the current observation period, and no event that can prove that the current communication transaction has reached or crossed the communication resource creation boundary is recorded by the observation deadline, a retransmission request is generated. S6: For current communication transactions whose synchronization observation identifier does not match the retransmission-allowed state, a retransmission request is generated only if the status query clearly indicates that the communication service provider... If the current request is not accepted, or if the corresponding communication resource is not created and will not be created in the future, a retransmission request will be generated; S7. Before sending the retransmission request, perform a condition update on the status record corresponding to the communication service provider identifier, interface semantic version, and synchronization observation identifier of the current communication transaction to verify that the status version and interface semantic version of the status record have not changed; send the retransmission request only when the condition update is successful, and suppress the sending and set the current communication transaction to pending confirmation when the condition update fails; S8. When a change in interface semantic version is detected, or when a subsequent event that can be uniquely associated with the corresponding communication transaction and is inconsistent with the existing state is received, invalidate the state of the corresponding synchronization observation identifier.

2. The method according to claim 1, characterized in that, The transaction association fields include at least two of the following: the local request identifier, the SMPP binding session identifier and the sequence number within the binding session, the communication service provider message identifier, and the received message identifier in the delivery receipt in the message interface; or at least two of the following: the local request identifier, the SIP Call-ID, CSeq, Via branch parameter, the communication service provider call identifier, and the call detail record session identifier in the call interface.

3. The method according to claim 1, characterized in that, The observation duration is configured according to the communication service provider and the interface semantic version, and the observation cutoff time is determined by the formation time of the synchronous observation record of the corresponding communication transaction and the observation duration. The access status of the callback channel is verified by the access reachability and authentication results, the access status of the SMPP channel is verified by the receive binding status, the access status of the SIP signaling channel is verified by the signaling acquisition session status, and the access status of the call detail record (CDR) channel is verified by the CDR retrieval task status and authentication results. When an event arrives, the continuous consumption level of the corresponding channel is also verified and the queue backlog does not exceed the threshold. If no service event arrives during the observation period, the observation is only performed when the coverage is obtained. After the channel integrity record indicating that the event flow processing progress has reached the observation deadline is covered during this period, the event consumption status is considered normal. The channel integrity record is formed by message broker progress markers, heartbeat events generated by the communication service provider, or probe events processed along the same authentication and consumption path. Heartbeats from the local business process alone are not sufficient evidence. Transaction trajectories that have not yet obtained a protocol termination event or authoritative final state at the observation deadline remain in a non-closed state. When a late termination event is obtained later, the transaction trajectory is determined to be a closed transaction trajectory only after supplementing the verification of the channel status from the time of synchronous observation formation to the time of arrival of the late termination event.

4. The method according to claim 1, characterized in that, The interface semantic version is determined by the communication service provider identifier, the interface address digest, the response field name set digest, and the adapter build version or interface description file digest. If any item involved in determining the interface semantic version changes, or if a subsequent event occurs that is inconsistent with the existing synchronous observation identifier state, the state of the corresponding synchronous observation identifier will be invalidated.

5. The method according to claim 1, characterized in that, The synchronous observation identifier also includes a stable field value retained after the synchronous observation record has undergone field normalization processing, wherein the field normalization processing removes random identifiers, timestamps, and communication service provider transaction identifiers.

6. The method according to claim 1, characterized in that, For message sending services, the communication service provider's message identifier, message center acceptance confirmation event, or delivery receipt marked as an established independent message resource by the current interface semantic version serves as evidence of reaching or exceeding the communication resource creation boundary; for call services, the SIP conversation jointly determined by Call-ID, local tag, and remote tag, the called party's ringing event, or a uniquely associated call detail record session identifier serves as evidence of reaching or exceeding the communication resource creation boundary.

7. The method according to claim 1, characterized in that, When the transaction association field used to splice the transaction trajectory is incomplete, a composite fingerprint is generated by combining the business tenant identifier, target number summary, submission time range, and message content summary or call parameter summary. Only the trajectory corresponding to the composite fingerprint that has passed the uniqueness verification and has not collided with other transactions in the same time interval is used to generate the retransmission allowed state or the retransmission prohibited state.

8. A retransmission control device for a heterogeneous communication interface, characterized in that, It includes a trajectory stitching module, a closure determination module, a protocol phase mapping module, a state generation module, a state query module, a retransmission control module, and a state failure module; each module is configured to perform the method described in any one of claims 1 to 7.

9. An electronic device comprising a processor and a memory, wherein the memory stores a computer program, characterized in that, When the computer program is executed by the processor, it causes the processor to perform the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 7.

Images