21 Nov
2018
21 Nov
'18
12:30 a.m.
I am working on a VoLTE/IMS scenario to transfer text messages as SMS over
IP (+g.3gpp.smsip feature) between UE's. This is a high-level view of the
message flows between the endpoints (not showing CSCFs):
UE1 IP-SM-GW
|---- MESSAGE (SUBMIT) --------------->|
|<------------------- 202 ACCEPTED ----|
| |
|<-------- MESSAGE (SUBMIT_REPORT) ----|
|---- 200 OK ------------------------->|
|
UE2 |
| |
|<-------------- MESSAGE (DELIVER) ----|
|---- 200 OK ------------------------->|
The messages does get transferred from UE1 to UE2 successfully. Since this
is GSM-style SMS, the OA (originating address) and DA (destination address)
are specified using telephone numbers, not sip addresses. This is not a
problem for the DA, since it is specified in the SUBMIT TPDU from the
originating handset, but when the IP-SM-GW sends the DELIVER TPDU it needs
to specify the OA so that the recipient knows who sent the SMS, and this was
not provided in the MESSAGE with the SMS-SUBMIT.
According to 3GPP TS 24.341 (http://www.qtc.jp/3GPP/Specs/24341-b20.pdf):
"The IP-SM-GW will have to use an address of the SM-over-IP sender that the
SC can process (i.e. an E.164 number). This address will come from a tel
URI in a P-Asserted-Identity header (as defined in RFC 3325 [13]) placed in
the SIP MESSAGE request by the P-CSCF or S-CSCF."
Looking at the MESSAGE request sent from the S-CSCF to the IP-SM-GW, it
looks like neither the P-CSCF nor the S-CSCF is providing the tel address in
a P-Asserted-Identity header:
MESSAGE tel:+3108012345680 SIP/2.0
Route: <sip:defaultapp@tas.core.ims1.test;lr>,
<sip:iscmark@scscf.core.ims1.test:6060;lr;s=1;h=0;d=0;a=7369703a303031303330
31323334353637383940696d732e6d6e633030332e6d63633030312e336770706e6574776f72
6b2e6f7267>
P-Served-User:
<sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org>;sescase=orig;regstat
e=reg
f: <sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org>;tag=2703358633
t: <tel:+3108012345680>
CSeq: 555874977 MESSAGE
i: 2703358625_2324045032@2001:470:eb88:b021:27f:9507:589d:c201
Via: SIP/2.0/UDP
[2001:470:EB88:150:0:0:0:22]:6060;branch=z9hG4bKb857.bd3345ba81ec10b1d11639d
9c7414606.0;i=a
Via: SIP/2.0/TCP
[2001:470:EB88:150:5054:FF:FE44:BFC9];branch=z9hG4bKb857.be53cc1c583b9c5f9dc
ebf3306f2b7c1.0
v: SIP/2.0/UDP
[2001:470:eb88:b021:27f:9507:589d:c201]:8906;rport=8013;branch=z9hG4bK355262
2488
Max-Forwards: 68
P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=0010300030000001
c: application/vnd.3gpp.sms
Allow: MESSAGE
d: no-fork
User-Agent: Xiaomi_Redmi 3S_Android6.0.1_9
l: 27
P-Charging-Vector: icid-value=49565300000000511100004B01000000;
icid-generated-at=2001:470:EB88:150:5054:FF:FE44:BFC9
P-Asserted-Identity: <sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org>
P-Visited-Network-ID: core.ims1.test
Message Body
GSM A-I/F RP - RP-DATA (MS to Network)
Message Type RP-DATA (MS to Network)
RP-Message Reference
RP-Message Reference: 0x05 (5)
RP-Originator Address
RP-Destination Address - (3108012345680)
RP-User Data
Length: 14
TPDU (not displayed)
GSM SMS TPDU (GSM 03.40) SMS-SUBMIT
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
..1. .... = TP-SRR: A status report is requested
...0 0... = TP-VPF: TP-VP field not present (0)
.... .0.. = TP-RD: Instruct SC to accept duplicates
.... ..01 = TP-MTI: SMS-SUBMIT (1)
TP-MR: 92
TP-Destination-Address - (8000)
TP-PID: 0
TP-DCS: 0
TP-User-Data-Length: (5) depends on Data-Coding-Scheme
TP-User-Data
SMS text: HELLO
Is this something that in configurable at the P-CSCF or the S-CSCF, or would
it require now development?
Thanks,
Ron
21 Nov
21 Nov
9:35 a.m.
Hi Ron,
You can't change it on the Proxy-CSCF, but on the HSS. According to 3GPP
Specs, the first identity associated to an IMPI is the "default-identity",
which is typically used by the phone and asserted by the Proxy-CSCF.
Thanks,
Carsten
Am Mi., 21. Nov. 2018, 00:31 hat Ron McLeod <ron.kamailio(a)mcleodnet.com>
geschrieben:
I am working on a VoLTE/IMS scenario to transfer text messages as SMS over
IP (+g.3gpp.smsip feature) between UE’s. This is a high-level view of the
message flows between the endpoints (not showing CSCFs):
UE1 IP-SM-GW
|---- MESSAGE (SUBMIT) --------------->|
|<------------------- 202 ACCEPTED ----|
| |
|<-------- MESSAGE (SUBMIT_REPORT) ----|
|---- 200 OK ------------------------->|
|
UE2 |
| |
|<-------------- MESSAGE (DELIVER) ----|
|---- 200 OK ------------------------->|
The messages does get transferred from UE1 to UE2 successfully. Since
this is GSM-style SMS, the OA (originating address) and DA (destination
address) are specified using telephone numbers, not sip addresses. This is
not a problem for the DA, since it is specified in the SUBMIT TPDU from the
originating handset, but when the IP-SM-GW sends the DELIVER TPDU it needs
to specify the OA so that the recipient knows who sent the SMS, and this
was not provided in the MESSAGE with the SMS-SUBMIT.
According to 3GPP TS 24.341 (http://www.qtc.jp/3GPP/Specs/24341-b20.pdf):
"The IP-SM-GW will have to use an address of the SM-over-IP sender that
the SC can process (i.e. an E.164 number). This address will come from a
tel URI in a P-Asserted-Identity header (as defined in RFC 3325 [13])
placed in the SIP MESSAGE request by the P-CSCF or S-CSCF."
Looking at the MESSAGE request sent from the S-CSCF to the IP-SM-GW, it
looks like neither the P-CSCF nor the S-CSCF is providing the tel address
in a P-Asserted-Identity header:
MESSAGE tel:+3108012345680 SIP/2.0
Route: <sip:defaultapp@tas.core.ims1.test;lr>,
<sip:iscmark@scscf.core.ims1.test
:6060;lr;s=1;h=0;d=0;a=7369703a30303130333031323334353637383940696d732e6d6e633030332e6d63633030312e336770706e6574776f726b2e6f7267>
P-Served-User: <sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org
;sescase=orig;regstate=reg
f: <sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org>;tag=2703358633
t: <tel:+3108012345680>
CSeq: 555874977 MESSAGE
i: 2703358625_2324045032@2001:470:eb88:b021:27f:9507:589d:c201
Via: SIP/2.0/UDP
[2001:470:EB88:150:0:0:0:22]:6060;branch=z9hG4bKb857.bd3345ba81ec10b1d11639d9c7414606.0;i=a
Via: SIP/2.0/TCP
[2001:470:EB88:150:5054:FF:FE44:BFC9];branch=z9hG4bKb857.be53cc1c583b9c5f9dcebf3306f2b7c1.0
v: SIP/2.0/UDP
[2001:470:eb88:b021:27f:9507:589d:c201]:8906;rport=8013;branch=z9hG4bK3552622488
Max-Forwards: 68
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;
utran-cell-id-3gpp=0010300030000001
c: application/vnd.3gpp.sms
Allow: MESSAGE
d: no-fork
User-Agent: Xiaomi_Redmi 3S_Android6.0.1_9
l: 27
P-Charging-Vector: icid-value=49565300000000511100004B01000000;
icid-generated-at=2001:470:EB88:150:5054:FF:FE44:BFC9
P-Asserted-Identity: <
sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org>
P-Visited-Network-ID: core.ims1.test
Message Body
GSM A-I/F RP - RP-DATA (MS to Network)
Message Type RP-DATA (MS to Network)
RP-Message Reference
RP-Message Reference: 0x05 (5)
RP-Originator Address
RP-Destination Address - (3108012345680)
RP-User Data
Length: 14
TPDU (not displayed)
GSM SMS TPDU (GSM 03.40) SMS-SUBMIT
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
..1. .... = TP-SRR: A status report is requested
...0 0... = TP-VPF: TP-VP field not present (0)
.... .0.. = TP-RD: Instruct SC to accept duplicates
.... ..01 = TP-MTI: SMS-SUBMIT (1)
TP-MR: 92
TP-Destination-Address - (8000)
TP-PID: 0
TP-DCS: 0
TP-User-Data-Length: (5) depends on Data-Coding-Scheme
TP-User-Data
SMS text: HELLO
Is this something that in configurable at the P-CSCF or the S-CSCF, or
would it require now development?
Thanks,
Ron
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
8:59 p.m.
New subject: IMS: SMS over IP - how to get the originator's tel address?
Carsten – thanks for the reply.
I am not trying to change it – the tel identity (and other public identities) is already
defined in the profile stored in the HSS; I want the S-CSCF to insert P-Preferred-Identity
headers for the IMPU’s associated with the UE, which it already knows since it downloaded
the profile directly from the HSS.
The P-CSCF and the handset itself may know these public identities as well if it would
have SUBSCRIBEd for registration events from the S-CSCF, but in practice, I do not see the
handset providing anything other than the IMPI, and the Kamailio-based P-CSCF with my
current configuration does not insert any P-Asserted-Identity headers.
TS 24.341 does suggest that either the P-CSCF or the S-CSCF could insert the header(s),
and in the examples provided in Annex B.5 of the same document show the additional
P-Asserted-Identity header being added by the S-CSCF before forwarding the request to the
IP-SM-GW:
UE to P-CSCF
MESSAGE sip:sc.home1.net SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp; branch=z9hG4bKnashds7
Max-Forwards: 70
Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>,
<sip:orig@scscf1.home1.net;lr>
P-Preferred-Identity: "John Doe" <sip:user1_public1@home1.net>
From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:sc.home1.net.net>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 666 MESSAGE
Content-Type: application/vnd.3gpp.sms
Content-Length: (...)
P-CSCF to S-CSCF
MESSAGE sip:sc.home1.net SIP/2.0
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f341, SIP/2.0/UDP
[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp; branch=z9hG4bKnashds7
Max-Forwards: 69
Route: <sip:orig@scscf1.home1.net;lr>
P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>
From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:sc.home1.net>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 666 MESSAGE
Content-Type: application/vnd.3gpp.sms
Content-Length: (...)
S-CSCF to IP-SM-GW
MESSAGE sip:sc.home1.net SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a651, SIP/2.0/UDP
pcscf1.visited1.net;branch=z9hG4bK240f341, SIP/2.0/UDP
[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp; branch=z9hG4bKnashds7
Max-Forwards: 68
Route: <sip:ipsmgw.home1.net;lr>,
<sip:cb03a0s09a2sdfglkj490333@scscf1.home1.net;lr>
P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>
P-Asserted-Identity: tel:+12125551111
From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:sc.home1.net>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 666 MESSAGE
Content-Type: application/vnd.3gpp.sms
Content-Length: (...)
Ron
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Carsten Bock
Sent: Wednesday, November 21, 2018 12:35 AM
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] IMS: SMS over IP - how to get the originator's tel address?
Hi Ron,
You can't change it on the Proxy-CSCF, but on the HSS. According to 3GPP Specs, the
first identity associated to an IMPI is the "default-identity", which is
typically used by the phone and asserted by the Proxy-CSCF.
Thanks,
Carsten
Am Mi., 21. Nov. 2018, 00:31 hat Ron McLeod <ron.kamailio(a)mcleodnet.com>
geschrieben:
I am working on a VoLTE/IMS scenario to transfer text messages as SMS over IP
(+g.3gpp.smsip feature) between UE’s. This is a high-level view of the message flows
between the endpoints (not showing CSCFs):
UE1 IP-SM-GW
|---- MESSAGE (SUBMIT) --------------->|
|<------------------- 202 ACCEPTED ----|
| |
|<-------- MESSAGE (SUBMIT_REPORT) ----|
|---- 200 OK ------------------------->|
|
UE2 |
| |
|<-------------- MESSAGE (DELIVER) ----|
|---- 200 OK ------------------------->|
The messages does get transferred from UE1 to UE2 successfully. Since this is GSM-style
SMS, the OA (originating address) and DA (destination address) are specified using
telephone numbers, not sip addresses. This is not a problem for the DA, since it is
specified in the SUBMIT TPDU from the originating handset, but when the IP-SM-GW sends the
DELIVER TPDU it needs to specify the OA so that the recipient knows who sent the SMS, and
this was not provided in the MESSAGE with the SMS-SUBMIT.
According to 3GPP TS 24.341 (http://www.qtc.jp/3GPP/Specs/24341-b20.pdf):
"The IP-SM-GW will have to use an address of the SM-over-IP sender that the SC can
process (i.e. an E.164 number). This address will come from a tel URI in a
P-Asserted-Identity header (as defined in RFC 3325 [13]) placed in the SIP MESSAGE request
by the P-CSCF or S-CSCF."
Looking at the MESSAGE request sent from the S-CSCF to the IP-SM-GW, it looks like neither
the P-CSCF nor the S-CSCF is providing the tel address in a P-Asserted-Identity header:
MESSAGE tel:+3108012345680 SIP/2.0
Route: <sip:defaultapp@tas.core.ims1.test;lr>,
<sip:iscmark@scscf.core.ims1.test:6060;lr;s=1;h=0;d=0;a=7369703a30303130333031323334353637383940696d732e6d6e633030332e6d63633030312e336770706e6574776f726b2e6f7267>
P-Served-User: <sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org
<mailto:sip%3A001030123456789@ims.mnc003.mcc001.3gppnetwork.org>
>;sescase=orig;regstate=reg
f: <sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org
<mailto:sip%3A001030123456789@ims.mnc003.mcc001.3gppnetwork.org>
>;tag=2703358633
t: <tel:+3108012345680>
CSeq: 555874977 MESSAGE
i: 2703358625_2324045032@2001:470:eb88:b021:27f:9507:589d:c201
Via: SIP/2.0/UDP
[2001:470:EB88:150:0:0:0:22]:6060;branch=z9hG4bKb857.bd3345ba81ec10b1d11639d9c7414606.0;i=a
Via: SIP/2.0/TCP
[2001:470:EB88:150:5054:FF:FE44:BFC9];branch=z9hG4bKb857.be53cc1c583b9c5f9dcebf3306f2b7c1.0
v: SIP/2.0/UDP
[2001:470:eb88:b021:27f:9507:589d:c201]:8906;rport=8013;branch=z9hG4bK3552622488
Max-Forwards: 68
P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=0010300030000001
c: application/vnd.3gpp.sms
Allow: MESSAGE
d: no-fork
User-Agent: Xiaomi_Redmi 3S_Android6.0.1_9
l: 27
P-Charging-Vector: icid-value=49565300000000511100004B01000000;
icid-generated-at=2001:470:EB88:150:5054:FF:FE44:BFC9
P-Asserted-Identity: <sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org
<mailto:sip%3A001030123456789@ims.mnc003.mcc001.3gppnetwork.org> >
P-Visited-Network-ID: core.ims1.test
Message Body
GSM A-I/F RP - RP-DATA (MS to Network)
Message Type RP-DATA (MS to Network)
RP-Message Reference
RP-Message Reference: 0x05 (5)
RP-Originator Address
RP-Destination Address - (3108012345680)
RP-User Data
Length: 14
TPDU (not displayed)
GSM SMS TPDU (GSM 03.40) SMS-SUBMIT
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
..1. .... = TP-SRR: A status report is requested
...0 0... = TP-VPF: TP-VP field not present (0)
.... .0.. = TP-RD: Instruct SC to accept duplicates
.... ..01 = TP-MTI: SMS-SUBMIT (1)
TP-MR: 92
TP-Destination-Address - (8000)
TP-PID: 0
TP-DCS: 0
TP-User-Data-Length: (5) depends on Data-Coding-Scheme
TP-User-Data
SMS text: HELLO
Is this something that in configurable at the P-CSCF or the S-CSCF, or would it require
now development?
Thanks,
Ron
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
22 Nov
22 Nov
3:10 p.m.
Hi Ron,
You should check the response to the "200 OK" to a "REGISTER". It
should
contain one or more "P-Associated-Identities", with the first one being the
default one. If no associated identity matches, the Proxy-CSCF will add the
default one as P-Asserted-Identity.
Thanks,
Carsten
--
Carsten Bock
CEO (Geschäftsführer)
ng-voice GmbH
Millerntorplatz 1
20359 Hamburg / Germany
http://www.ng-voice.com
mailto:carsten@ng-voice.com
Office +49 40 5247593-40
Fax +49 40 5247593-99
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
Am Mi., 21. Nov. 2018 um 21:01 Uhr schrieb Ron McLeod <
ron.kamailio(a)mcleodnet.com>gt;:
Carsten – thanks for the reply.
I am not trying to change it – the *tel* identity (and other public
identities) is already defined in the profile stored in the HSS; I want the
S-CSCF to insert P-Preferred-Identity headers for the IMPU’s associated
with the UE, which it already knows since it downloaded the profile
directly from the HSS.
The P-CSCF and the handset itself *may* know these public identities as
well if it would have SUBSCRIBEd for registration events from the S-CSCF,
but in practice, I do not see the handset providing anything other than the
IMPI, and the Kamailio-based P-CSCF with my current configuration does not
insert any P-Asserted-Identity headers.
TS 24.341 does suggest that either the P-CSCF or the S-CSCF could insert
the header(s), and in the examples provided in Annex B.5 of the same
document show the additional P-Asserted-Identity header being added by the
S-CSCF before forwarding the request to the IP-SM-GW:
*UE to P-CSCF*
MESSAGE sip:sc.home1.net SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;
branch=z9hG4bKnashds7
Max-Forwards: 70
Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <
sip:orig@scscf1.home1.net;lr>
P-Preferred-Identity: "John Doe" <sip:user1_public1@home1.net>
From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:sc.home1.net.net>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 666 MESSAGE
Content-Type: application/vnd.3gpp.sms
Content-Length: (...)
*P-CSCF to S-CSCF*
MESSAGE sip:sc.home1.net SIP/2.0
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f341, SIP/2.0/UDP
[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp; branch=z9hG4bKnashds7
Max-Forwards: 69
Route: <sip:orig@scscf1.home1.net;lr>
P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>
From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:sc.home1.net>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 666 MESSAGE
Content-Type: application/vnd.3gpp.sms
Content-Length: (...)
*S-CSCF to IP-SM-GW*
MESSAGE sip:sc.home1.net SIP/2.0
Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a651, SIP/2.0/UDP
pcscf1.visited1.net;branch=z9hG4bK240f341, SIP/2.0/UDP
[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp; branch=z9hG4bKnashds7
Max-Forwards: 68
Route: <sip:ipsmgw.home1.net;lr>, <
sip:cb03a0s09a2sdfglkj490333@scscf1.home1.net;lr>
P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>
P-Asserted-Identity: tel:+12125551111
From: <sip:user1_public1@home1.net>; tag=171828
To: <sip:sc.home1.net>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 666 MESSAGE
Content-Type: application/vnd.3gpp.sms
Content-Length: (...)
Ron
*From:* sr-users [mailto:sr-users-bounces@lists.kamailio.org] *On Behalf
Of *Carsten Bock
*Sent:* Wednesday, November 21, 2018 12:35 AM
*To:* Kamailio (SER) - Users Mailing List
*Subject:* Re: [SR-Users] IMS: SMS over IP - how to get the originator's
tel address?
Hi Ron,
You can't change it on the Proxy-CSCF, but on the HSS. According to 3GPP
Specs, the first identity associated to an IMPI is the "default-identity",
which is typically used by the phone and asserted by the Proxy-CSCF.
Thanks,
Carsten
Am Mi., 21. Nov. 2018, 00:31 hat Ron McLeod <ron.kamailio(a)mcleodnet.com>
geschrieben:
I am working on a VoLTE/IMS scenario to transfer text messages as SMS over
IP (+g.3gpp.smsip feature) between UE’s. This is a high-level view of the
message flows between the endpoints (not showing CSCFs):
UE1 IP-SM-GW
|---- MESSAGE (SUBMIT) --------------->|
|<------------------- 202 ACCEPTED ----|
| |
|<-------- MESSAGE (SUBMIT_REPORT) ----|
|---- 200 OK ------------------------->|
|
UE2 |
| |
|<-------------- MESSAGE (DELIVER) ----|
|---- 200 OK ------------------------->|
The messages does get transferred from UE1 to UE2 successfully. Since
this is GSM-style SMS, the OA (originating address) and DA (destination
address) are specified using telephone numbers, not sip addresses. This is
not a problem for the DA, since it is specified in the SUBMIT TPDU from the
originating handset, but when the IP-SM-GW sends the DELIVER TPDU it needs
to specify the OA so that the recipient knows who sent the SMS, and this
was not provided in the MESSAGE with the SMS-SUBMIT.
According to 3GPP TS 24.341 (http://www.qtc.jp/3GPP/Specs/24341-b20.pdf):
"The IP-SM-GW will have to use an address of the SM-over-IP sender that
the SC can process (i.e. an E.164 number). This address will come from a
tel URI in a P-Asserted-Identity header (as defined in RFC 3325 [13])
placed in the SIP MESSAGE request by the P-CSCF or S-CSCF."
Looking at the MESSAGE request sent from the S-CSCF to the IP-SM-GW, it
looks like neither the P-CSCF nor the S-CSCF is providing the tel address
in a P-Asserted-Identity header:
MESSAGE tel:+3108012345680 SIP/2.0
Route: <sip:defaultapp@tas.core.ims1.test;lr>,
<sip:iscmark@scscf.core.ims1.test
:6060;lr;s=1;h=0;d=0;a=7369703a30303130333031323334353637383940696d732e6d6e633030332e6d63633030312e336770706e6574776f726b2e6f7267>
P-Served-User: <sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org
;sescase=orig;regstate=reg
f: <sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org>;tag=2703358633
t: <tel:+3108012345680>
CSeq: 555874977 MESSAGE
i: 2703358625_2324045032@2001:470:eb88:b021:27f:9507:589d:c201
Via: SIP/2.0/UDP
[2001:470:EB88:150:0:0:0:22]:6060;branch=z9hG4bKb857.bd3345ba81ec10b1d11639d9c7414606.0;i=a
Via: SIP/2.0/TCP
[2001:470:EB88:150:5054:FF:FE44:BFC9];branch=z9hG4bKb857.be53cc1c583b9c5f9dcebf3306f2b7c1.0
v: SIP/2.0/UDP
[2001:470:eb88:b021:27f:9507:589d:c201]:8906;rport=8013;branch=z9hG4bK3552622488
Max-Forwards: 68
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;
utran-cell-id-3gpp=0010300030000001
c: application/vnd.3gpp.sms
Allow: MESSAGE
d: no-fork
User-Agent: Xiaomi_Redmi 3S_Android6.0.1_9
l: 27
P-Charging-Vector: icid-value=49565300000000511100004B01000000;
icid-generated-at=2001:470:EB88:150:5054:FF:FE44:BFC9
P-Asserted-Identity: <
sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org>
P-Visited-Network-ID: core.ims1.test
Message Body
GSM A-I/F RP - RP-DATA (MS to Network)
Message Type RP-DATA (MS to Network)
RP-Message Reference
RP-Message Reference: 0x05 (5)
RP-Originator Address
RP-Destination Address - (3108012345680)
RP-User Data
Length: 14
TPDU (not displayed)
GSM SMS TPDU (GSM 03.40) SMS-SUBMIT
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
..1. .... = TP-SRR: A status report is requested
...0 0... = TP-VPF: TP-VP field not present (0)
.... .0.. = TP-RD: Instruct SC to accept duplicates
.... ..01 = TP-MTI: SMS-SUBMIT (1)
TP-MR: 92
TP-Destination-Address - (8000)
TP-PID: 0
TP-DCS: 0
TP-User-Data-Length: (5) depends on Data-Coding-Scheme
TP-User-Data
SMS text: HELLO
Is this something that in configurable at the P-CSCF or the S-CSCF, or
would it require now development?
Thanks,
Ron
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
1990
days inactive
1992
days old
3 comments
2 participants
participants (2)
-
Carsten Bock -
Ron McLeod