IMS
SMS over IMS

 

Overall sequence of SMS over IMS is very simple. Just send a message and wait for delivery report (this delivery report is optional). In IMS, both the short message and the report travel as SIP MESSAGE requests, and each request gets its own SIP response.

Comments from the initial post (Just to give you an idea on how the technology evolve) :

But when you are going into details especially for troubleshooting, there are a lot of small things you have to think of. I came across many troubleshooting case, but I haven't found any general rules that would clear out all of your problems. (It may be becauseIMS service is still in early phase as of now (Oct 2013), specification (RFC, 3GPP) is not so clear and the interpretation of those specification by the IMS stack developers seems to vary a lot.)

So my approach on this topic is to introduce various cases as much as possible so that you can absorbe the generic pattern.

Comments as of Feb 2017 :

Now pretty much everything is cleary defined in 3GPP specification 24.341 (Refer to the latest version of 24.341)

As of 24.341 v19.0.0, the core of the procedure has not changed since these captures were taken. The UE still carries the same RP and TP layers as in the CS domain, inside the body of a SIP MESSAGE request. So I'll first show the SIP rules around that body, and then go through one MO and one MT example line by line.

Followings are the list of example, I will go through in this page.

SIP Specification on SMS

SMS over IMS does not define a new short message format. The UE puts an RP message from 24.011 into the body of a SIP MESSAGE request, with the MIME type application/vnd.3gpp.sms. What 24.341 adds are the SIP rules around that body: a capability tag at registration, the content type, and an IP-SM-GW that relays between SIP and the SC.

Capability indcation in REGISTER

An IP-SM-GW can deliver an SMS over IMS only to a UE that can receive one. So the UE announces this in its REGISTER request, and the network keeps it with the registered contact. The capture below shows where the tag sits in a real REGISTER.

IR 92 2.2.1 SIP Registration Procedures says :

If a UE support SMS over IP, it should include a tag to indicate the capablity of SMS over IP as stated in 24.341 5.3.2.2 as below.

On sending a REGISTER request, the SM-over-IP receiver shall indicate its capability to receive traditional short messages over IMS network by including a "+g.3gpp.smsip" parameter into the Contact header according to RFC 3840

In RFC 3840, 5. Computing Capabilities

  • in order to identify them as feature parameters (as opposed to parameters for another SIP extension), they are encoded with a leading "+" sign in the Contact header field

Example :

< REGISTER > SIP capture from a test network. Field values are from a live capture, not from the specification.

REGISTER sip:test.3gpp.com SIP/2.0
Expires: 600000
Authorization: Digest ....
CSeq: 1 REGISTER
Max-Forwards: 70
Route: <sip:[2001:0:0:2::2]:5060;lr>
f: <sip:310410123456789@test.3gpp.com>;tag=1148585218
i: 229717043
k: pathsec-agree
l: 0
m: <sip:310410123456789@[2001:0:0:2::1]:5060>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.smsip;+sip.instance="<urn:gsma:imei:35858205-001765-1>"

The decoder view below splits the Contact header of the same REGISTER into its parameters.

Decoded Contact header of the REGISTER with the +g.3gpp.smsip parameter highlighted

The +g.3gpp.smsip parameter is a Contact parameter of its own, next to the ICSI for MMTEL and the sip.instance with the IMEI.

Capture, continued.

t: <sip:310410123456789@test.3gpp.com>
v: SIP/2.0/TCP [2001:0:0:2::1]:5060;branch=z9hG4bK1447958797smg;transport=TCP

This SIP message clip highlights the following parameters: Route, Authorization, Expires, CSeq, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

Note where the tag is. It is a feature parameter of the Contact header field, so it describes this one registered contact, not the user. 24.341 v19.0.0 clause 5.3.2.2 keeps the same rule, and clause 5.3.1.1 adds a note for the sending side. An SM-over-IP sender that expects a submit report also includes +g.3gpp.smsip in its REGISTER. The network later uses the tag in the other direction. The IP-SM-GW puts Accept-Contact: *;+g.3gpp.smsip;require;explicit in every MT MESSAGE, and the S-CSCF matches it against the registered contacts.

MO SMS Signal Flow

Before looking at a log, let's see the reference flow for a UE originated SM. The diagram below follows 24.341 Figure B.5-1. It shows which node answers each MESSAGE, because in a UE log you only see the messages on the first hop.

< 24.341 B.5 Signalling flows demonstrating successful UE originated SM submit procedure over IP >

MO SMS over IP signalling flow between UE, P-CSCF, S-CSCF and IP-SM-GW with steps 1 to 14

The first MESSAGE is answered with 202 Accepted. The submit report arrives later in a second MESSAGE, and the UE answers that one with 200 OK.

  • Steps 1, 2 and 4 carry the MESSAGE from the UE through the P-CSCF and the S-CSCF to the IP-SM-GW. The body is vnd.3gpp.sms with RP-User-Data holding an SMS-SUBMIT.
  • Step 3 is the S-CSCF evaluating its Initial Filter Criteria, which is how the MESSAGE reaches the IP-SM-GW.
  • Steps 5 to 7 return 202 Accepted to the UE.
  • Step 8 is the IP-SM-GW extracting the SM, forwarding it and receiving the report.
  • Steps 9 to 11 bring a new MESSAGE with RP-ACK holding an SMS-SUBMIT REPORT back to the UE, and steps 12 to 14 return 200 OK.

The two responses mean different things. 202 Accepted only says that the IP-SM-GW took the request. The real result of the submission is the RP-ACK or RP-ERROR in the later MESSAGE. 24.341 clause 5.3.1.2 also asks the UE to store the Call-ID of its MESSAGE, so that it can match the submit report to it.

MT SMS Signal Flow

The terminating flow runs in the other direction, and the order of the responses is reversed. The diagram below follows 24.341 Figure B.6-1, which includes the delivery report sent by the UE.

< 24.341 B.6 Signalling flows demonstrating successful UE terminated SM deliver procedure over IP >

MT SMS over IP signalling flow between UE, P-CSCF, S-CSCF and IP-SM-GW with steps 1 to 15

The UE answers the delivered MESSAGE with 200 OK, and then sends its own MESSAGE with the delivery report, which the IP-SM-GW answers with 202 Accepted.

  • Step 1 is the IP-SM-GW receiving the SM from the SC.
  • Steps 2 to 4 deliver the MESSAGE to the UE, with RP-DATA in a vnd.3gpp.sms body. The label in the diagram reads SMS-SUBMIT DELIVER, but 24.341 B.6 and the capture both show an SMS-DELIVER TPDU here.
  • Steps 5 to 7 return 200 OK to the IP-SM-GW.
  • Steps 8, 9 and 11 carry the UE's MESSAGE with RP-ACK holding an SMS-DELIVER-REPORT, and step 10 is the S-CSCF evaluating its Initial Filter Criteria.
  • Steps 12 to 14 return 202 Accepted, and step 15 is the IP-SM-GW forwarding the report to the SC.

For the delivery report, 24.341 clause 5.3.2.4 lists what the UE must fill in. The Request-URI and the To header contain the IP-SM-GW, whose address the UE takes from the P-Asserted-Identity of the delivered MESSAGE. The In-Reply-To header contains the Call-ID of the delivered MESSAGE, and the body contains RP-ACK or RP-ERROR.

  • The body is a plain RP message : SMS over IMS reuses 24.011 RP-DATA, RP-ACK and RP-ERROR inside application/vnd.3gpp.sms.
  • +g.3gpp.smsip marks the contact : the UE sets it in REGISTER, and the IP-SM-GW requires it in Accept-Contact for MT delivery.
  • 202 and 200 point in opposite directions : MO gets 202 Accepted first and gives 200 OK later, and MT does the reverse.

MO SMS - Example 1

Following is an example of MO SMS over IMS. If you want to get the detailed description of the specification, refer to 34.229 18.1 Mobile Originating SMS

 

Direction

Message

UA --> NW

Request : MESSAGE <URI> | (RP) RP-DATA (MS to Network)

UA <-- NW

202 Accepted

UA <-- NW

Request : MESSAGE <URI> | (RP) RP-ACK (Network to MS)

UA --> NW

200 OK

 

NOTE : If you want to see the contents of full log with Amarisoft Log viewer, go to LogAnalysis section and click on 'Sample Log' in this tutorial of Amarisoft TechAcademy.

Request: MESSAGE tel:19037029920;phone-context=TestIMS.com | RP-DATA - MS to Network

This is step 1 of the MO flow. Look at two addresses first. The Request-URI and the To header carry the SC address 19037029920, and the real recipient 555 appears only inside the TPDU as TP-Destination-Address.

< MESSAGE with RP-DATA, MS to Network > SIP capture from a test network. Field values are from a live capture, not from the specification.

MESSAGE tel:19037029920;phone-context=TestIMS.com SIP/2.0
f: "Test" <sip:+11234567890@test.3gpp.com>;tag=834037901
t: <tel:19037029920;phone-context=TestIMS.com>
CSeq: 834037887 MESSAGE
i: 834037887_2367153256@2001:0:0:1::1
v: SIP/2.0/UDP [2001:0:0:1::1]:5060;branch=z9hG4bK253093091
Max-Forwards: 70
Route: <sip:[2001:0:0:1::2]:5060;lr>
c: application/vnd.3gpp.sms
Allow: MESSAGE

This SIP message clip highlights the following parameters: Route, CSeq, Max-Forwards, Allow. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

Capture, continued.

Request-Disposition: no-fork
User-Agent: Test User Agent
l: 28
v: SIP/2.0/UDP [2001:0:0:1::1]:5060;branch=z9hG4bK253093091
Route: <sip:[2001:0:0:1::2]:5060;lr>
c: application/vnd.3gpp.sms
Allow: MESSAGE

This SIP message clip highlights the following parameters: Route, Allow, User-Agent. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

Capture, continued.

Request-Disposition: no-fork
User-Agent: Test User Agent

This SIP message clip highlights the following parameters: User-Agent. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

Capture, continued.

Message Body
    GSM A-I/F RP - RP-DATA (MS to Network)
    RP-Message Reference
        RP-Message Reference: 0x05 (5)
    RP-Origination Address
        Length: 0
    RP-Destination Address - (19037029920)
        0... .... = TP-RP: TP Reply Path parameter is not set in this SMS SUBMIT/DELIVER
        .0.. .... = TP-UDHI: The TP UD field contains only the short message
        ..0. .... = TP-SRR: A status report is not requested
        ...1 0... = TP-VPF: TP-VP field present - relative format (2)
        .... .0.. = TP-RD: Instruct SC to accept duplicates
        .... ..01 = TP-MTI: SMS-SUBMIT (1) // This is indication of MO-SMS
    TP-MR: 88
    TP-Destination-Address - (555)
        Length: 3 address digits
        1... .... :  No extension
        .000 .... :  Type of number: (0) Unknown
        .... 0001 :  Numbering plan: (1) ISDN/telephone (E.164/E.163)
        TP-DA Digits: 555
    TP-PID: 0
        00.. .... :  defines formatting for subsequent bits
        ..0. .... :  no telematic interworking, but SME-to-SME protocol
        ...0 0000 :  the SM-AL protocol being used between the SME and the MS (0)
    TP-DCS: 0
        00.. .... = Coding Group Bits: General Data Coding indication (0)
        Special case, GSM 7 bit default alphabet
    TP-Validity-Period: 24 hours 0 minutes
    TP-User-Data-Length: (12) depends on Data-Coding-Scheme
    TP-User-Data
        SMS text: MO SMS Test

This layout follows 24.341 clause 5.3.1.2. The Request-URI and the To header shall contain the PSI of the SC, and the body shall contain an RP-DATA message from 24.011. The RP-Origination Address has Length 0, which matches the note in 24.341 B.5 that the originating address includes only the length indicator. TP-MTI = 01 marks an SMS-SUBMIT, as the author's comment in the capture says.

Some header lines, such as Request-Disposition, User-Agent and Route, appear twice in the capture. They are left as recorded. Keep RP-Message Reference 0x05 in mind, because the RP-ACK in the next message carries the same value.

Request: MESSAGE sip:+11234567890@test.3gpp.com | RP-ACK - Network to MS

This is step 11 of the MO flow, the submit report coming back in a new MESSAGE. Two fields link it to the message above. One is the In-Reply-To header, and the other is the RP-Message Reference inside the body.

< MESSAGE with RP-ACK, Network to MS > SIP capture from a test network. Field values are from a live capture, not from the specification.

MESSAGE sip:+11234567890@test.3gpp.com SIP/2.0
Via: SIP/2.0/UDP [2001:0:0:1::2]:5060;branch=z9hG4bK-b6999e582ee8a42f22e8aafe5f68f47b;rport
Via: SIP/2.0/UDP [2001:0:0:1::2]:60393;branch=z9hG4bK00476613
Max-Forwards: 69
From: <sip:1111@test.3gpp.com>;tag=00476613
To: <sip:+11234567890@test.3gpp.com>
Call-ID: 20131016-151124@[2001:0:0:1::2]:60393
CSeq: 1 MESSAGE

This SIP message clip highlights the following parameters: Via, CSeq, Call-ID, From, To, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

Capture, continued.

Request-Disposition: fork, parallel
Accept-Contact: *;+g.3gpp.smsip;require;explicit // This indicate that this SIP message is a SMS message
Content-Type: application/vnd.3gpp.sms  // This indicates that the SMS is in 3GPP format (not 3GPP2 format)

This SIP message clip highlights the following parameters: Content-Type, Accept-Contact. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

Capture, continued.

In-Reply-To: 834037887_2367153256@2001:0:0:1::1
P-Called-Party-ID: <sip:+11234567890@test.3gpp.com>
Content-Length: 13

This SIP message clip highlights the following parameters: Content-Length. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

Capture, continued.

Record-Route: <sip:[2001:0:0:1::2];lr>
Message Body
    GSM A-I/F RP - RP-ACK (Network to MS)
        RP-Message Reference
            RP-Message Reference: 0x05 (5)
        RP-User Data
            Element ID: 0x41
            Length: 9
        TPDU (not displayed)
    GSM SMS TPDU (GSM 03.40) SMS-SUBMIT REPORT
        .0.. .... = TP-UDHI: The TP UD field contains only the short message
        .... ..01 = TP-MTI: SMS-SUBMIT REPORT (1)
        TP-Parameter-Indicator
            0... .... :  No extension
            .000 0... :  Reserved
            .... .0.. :  TP-UDL not present
            .... ..0. :  TP-DCS not present
            .... ...0 :  TP-PID not present
        TP-Service-Centre-Time-Stamp
            Year 33, Month 13, Day 03
            Hour 13, Minutes 63, Seconds 13
            Timezone: GMT + 13 hours 15 minutes

In-Reply-To carries 834037887_2367153256@2001:0:0:1::1, which is the Call-ID of the MO MESSAGE above, and RP-Message Reference 0x05 matches too. 24.341 clause 5.3.1.2 tells the sender how to use this. If the UE supports In-Reply-To and the header points to its own short message, it answers with 200 OK, as the table above shows. If the header points to a message the UE did not send, it answers with 488 Not Acceptable Here.

The TP-Service-Centre-Time-Stamp in this capture reads Year 33, Month 13, Hour 13, Minutes 63 and a time zone of GMT + 13 hours 15 minutes. Month 13 and minute 63 cannot be a real date and time, so do not read this field as the SC time in this log. The capture is left as recorded.

  • The SC address is the Request-URI : the MO MESSAGE goes to the PSI of the SC, and the recipient number is inside the TPDU.
  • Two fields tie the report to the SM : In-Reply-To carries the original Call-ID, and RP-Message Reference repeats 0x05.
  • 202 Accepted is not delivery : only the RP-ACK in the later MESSAGE confirms that the SC accepted the SM.

MT SMS - Example 1

Following is an example of MT SMS over IMS. If you want to get the detailed description of the specification, refer to 34.229 18.2 Mobile Terminating SMS

 

Direction

Message

UA <-- NW

Request : MESSAGE <URI> | (RP) RP-DATA (Network to MS)

UA --> NW

200 OK

UA --> NW

Request : MESSAGE <URI> | (RP) RP-ACK (MS to Network)

UA <-- NW

202 Accepted

 

NOTE : If you want to see the contents of full log with Amarisoft Log viewer, go to LogAnalysis section and click on 'Sample Log' in this tutorial of Amarisoft TechAcademy.

Request: MESSAGE sip:+11234567890@test.3gpp.com | RP-DATA - Network to MS

This is step 4 of the MT flow, the SM arriving at the UE. Compare its headers with the MO request above. This time the network adds Accept-Contact with +g.3gpp.smsip, and the TPDU is an SMS-DELIVER.

< MESSAGE with RP-DATA, Network to MS > SIP capture from a test network. Field values are from a live capture, not from the specification.

MESSAGE sip:+11234567890@test.3gpp.com SIP/2.0
Via: SIP/2.0/UDP [2001:0:0:1::2]:5060;branch=z9hG4bK-ad54683f54403f46ff8d8b553521e588;rport
Via: SIP/2.0/UDP [2001:0:0:1::2]:60393;branch=z9hG4bK0047D4EC
Max-Forwards: 69
From: <sip:1111@test.3gpp.com>;tag=0047D4EC
To: <sip:+11234567890@test.3gpp.com>
Call-ID: 20131016-151152@[2001:0:0:1::2]:60393
CSeq: 1 MESSAGE

This SIP message clip highlights the following parameters: Via, CSeq, Call-ID, From, To, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

Capture, continued.

Request-Disposition: no-fork
Accept-Contact: *;+g.3gpp.smsip;require;explicit // This indicate that this SIP message is a SMS message
Content-Type: application/vnd.3gpp.sms // This indicates that the SMS is in 3GPP format (not 3GPP2 format)

This SIP message clip highlights the following parameters: Content-Type, Accept-Contact. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

Capture, continued.

Content-Transfer-Encoding: binary
P-Called-Party-ID: <sip:+11234567890@test.3gpp.com>
Content-Length: 41

This SIP message clip highlights the following parameters: Content-Length. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

Capture, continued.

Record-Route: <sip:[2001:0:0:1::2];lr>
Message Body
    GSM A-I/F RP - RP-DATA (Network to MS)
    RP-Message Reference
    RP-Origination Address - (999999)
        Length: 4
        1... .... = Extension: No Extension
        .000 .... = Type of number: unknown (0x00)
        .... 0001 = Numbering plan identification: ISDN/Telephony Numbering (Rec ITU-T E.164) (0x01)
        BCD Digits: 999999
    RP-Destination Address
    RP-User Data
    GSM SMS TPDU (GSM 03.40) SMS-DELIVER
        0... .... = TP-RP: TP Reply Path parameter is not set in this SMS SUBMIT/DELIVER
        .0.. .... = TP-UDHI: The TP UD field contains only the short message
        ..0. .... = TP-SRI: A status report shall not be returned to the SME
        .... .1.. = TP-MMS: No more messages are waiting for the MS in this SC
        .... ..00 = TP-MTI: SMS-DELIVER (0) // This is indication of MT-SMS
    TP-Originating-Address - (1234567890)
        Length: 10 address digits
        1... .... :  No extension
        .000 .... :  Type of number: (0) Unknown
        .... 0001 :  Numbering plan: (1) ISDN/telephone (E.164/E.163)
        TP-OA Digits: 1234567890
    TP-PID: 0
        00.. .... :  defines formatting for subsequent bits
        ..0. .... :  no telematic interworking, but SME-to-SME protocol
        ...0 0000 :  the SM-AL protocol being used between the SME and the MS (0)
    TP-DCS: 0
        00.. .... = Coding Group Bits: General Data Coding indication (0)
        Special case, GSM 7 bit default alphabet
    TP-Service-Centre-Time-Stamp
        Year 13, Month 10, Day 16
        Hour 15, Minutes 11, Seconds 29
        Timezone: GMT + 5 hours 0 minutes
    TP-User-Data
        SMS text: this is a mt sms test message

The header set matches 24.341 Table B.6-1 and B.6-2 closely. Request-Disposition: no-fork, Accept-Contact: *;+g.3gpp.smsip;require;explicit and Content-Type: application/vnd.3gpp.sms all appear there. Content-Transfer-Encoding: binary follows the note in 24.341 that the body uses binary transfer encoding. TP-MTI = 00 marks the SMS-DELIVER, and TP-OA carries the sender 1234567890.

The UE answers this request with 200 OK before it sends the delivery report, as the table above shows. The 200 OK only confirms the SIP transaction. The UE reports the result for the SM in the RP-ACK of the next message.

Request: MESSAGE sip:1111@test.3gpp.com;phone-context=TestIMS.com | RP-ACK - MS to Network

This is step 8 of the MT flow, the delivery report from the UE. It is the smallest message on this page, because an RP-ACK for a successful delivery carries almost nothing except the RP-Message Reference.

< MESSAGE with RP-ACK, MS to Network > SIP capture from a test network. Field values are from a live capture, not from the specification.

MESSAGE sip:1111@test.3gpp.com;phone-context=TestIMS.com SIP/2.0
f: "Test" <sip:+11234567890@test.3gpp.com>;tag=834066458
t: <sip:1111@test.3gpp.com;phone-context=TestIMS.com>
CSeq: 834066445 MESSAGE
i: 834066446_2367161720@2001:0:0:1::1
v: SIP/2.0/UDP [2001:0:0:1::1]:5060;branch=z9hG4bK502862226
Max-Forwards: 70
Route: <sip:[2001:0:0:1::2]:5060;lr>
c: application/vnd.3gpp.sms
Allow: MESSAGE

This SIP message clip highlights the following parameters: Route, CSeq, Max-Forwards, Allow. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

Capture, continued.

Request-Disposition: no-fork
User-Agent: Test User Agent
l: 6

This SIP message clip highlights the following parameters: User-Agent. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

Capture, continued.

Message Body
    GSM A-I/F RP - RP-ACK (MS to Network)
    RP-Message Reference
        RP-Message Reference: 0x00 (0)
    RP-User Data
        Element ID: 0x41
        Length: 2
        TPDU (not displayed)
    GSM SMS TPDU (GSM 03.40) SMS-DELIVER REPORT
        .0.. .... = TP-UDHI: The TP UD field contains only the short message
        .... .0.. = TP-MMS: More messages are waiting for the MS in this SC
        .... ..00 = TP-MTI: SMS-DELIVER REPORT (0)
    TP-Parameter-Indicator
        0... .... :  No extension
        .000 0... :  Reserved
        .... .0.. :  TP-UDL not present
        .... ..0. :  TP-DCS not present
        .... ...0 :  TP-PID not present

Check this capture against 24.341 v19.0.0 clause 5.3.2.4 and you will find two differences. The clause requires an In-Reply-To header with the Call-ID of the delivered MESSAGE, and this 2013 capture has none. The clause also puts the IP-SM-GW address in the Request-URI and the To header. Here the UE uses sip:1111@test.3gpp.com, which is the From address of the delivered MESSAGE. The delivered MESSAGE in this capture shows no P-Asserted-Identity, which is where a current UE takes the IP-SM-GW address from.

The TPDU is an SMS-DELIVER-REPORT with TP-MTI = 00. The TP-Parameter-Indicator shows that TP-PID, TP-DCS and TP-UDL are all absent, so the report carries no user data.

  • The network requires the SMS capability : Accept-Contact with +g.3gpp.smsip;require;explicit sends the request only to a contact that registered the tag.
  • 200 OK first, report later : the UE confirms the SIP transaction at once, and it reports the SM result in its own MESSAGE.
  • Old captures miss In-Reply-To : 24.341 now requires it in the delivery report, so a current UE log should show it.

Reference

  • 3GPP TS 24.341 v19.0.0 - clause 5.3.1.2 Submitting a short message, 5.3.2.2 Registration, 5.3.2.4 Sending a delivery report, Annex B.5 and B.6
  • 3GPP TS 24.011 v20.0.0 - RP messages RP-DATA and RP-ACK
  • 3GPP TS 23.040 v20.0.0 - SMS-SUBMIT, SMS-DELIVER and the report TPDUs
  • IETF RFC 3840 - Indicating User Agent Capabilities in SIP