[SR-Users] IMS: SMS over IP - how to get the originator's tel address?

Carsten Bock carsten at ng-voice.com
Thu Nov 22 15:10:53 CET 2018


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 at 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 at mcleodnet.com>:

> 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 at scscf1.home1.net;lr>
>
> P-Preferred-Identity: "John Doe" <sip:user1_public1 at home1.net>
>
> From: <sip:user1_public1 at 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 at scscf1.home1.net;lr>
>
> P-Asserted-Identity: "John Doe" <sip:user1_public1 at home1.net>
>
> From: <sip:user1_public1 at 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 at scscf1.home1.net;lr>
>
> P-Asserted-Identity: "John Doe" <sip:user1_public1 at home1.net>
>
> P-Asserted-Identity: tel:+12125551111
>
> From: <sip:user1_public1 at 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 at 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 at 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 at tas.core.ims1.test;lr>,
> <sip:iscmark at scscf.core.ims1.test
> :6060;lr;s=1;h=0;d=0;a=7369703a30303130333031323334353637383940696d732e6d6e633030332e6d63633030312e336770706e6574776f726b2e6f7267>
>
> P-Served-User: <sip:001030123456789 at ims.mnc003.mcc001.3gppnetwork.org
> >;sescase=orig;regstate=reg
>
> f: <sip:001030123456789 at ims.mnc003.mcc001.3gppnetwork.org>;tag=2703358633
>
> t: <tel:+3108012345680>
>
> CSeq: 555874977 MESSAGE
>
> i: 2703358625_2324045032 at 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 at 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20181122/227a5b65/attachment.html>


More information about the sr-users mailing list