When a LTE handset client attempts to REGISTER with the IMS, an AAR is sent from the P-CSCF to the PCRF to establish a dedicated bearer for SIP signaling (as well as request notifications for certain access network event). There are a couple of problems with the flow descriptions, and I was hoping that someone could confirm that these are actual issues before I start working on a fix.
1. The "in" and "out" directions seem reversed. "in" corresponds to the uplink (UE to network), and "out" corresponds to the downlink (network to UE). In the AAR sent to the PCRF, the "in" description indicates the traffic "from" the UE, rather than "to" the UE. There is a similar problem with the "out" description. A fix would involve reversing "in" and "out".
2. The IP address and port number for the UE side are correct (in my case the UE has been allocated 172.25.152.195, and the client is using port 37843), but the network side is specified as IP address 127.0.0.1 and port number is the same as the open used by the client (in my case the P-CSCF has an IP address of 172.25.152.20 and a port number of 4060). I see in the source code that the P-CSCF address is hard-coded to "127.0.0.1". A fix would involve either using the actual UE-facing IP address and port number for the P-CSCF or wildcards. Another option would be to not try and setup a dedicated bearer for SIP signaling, and just use the default bearer (there shouldn't be anything else other than signaling-related traffic on the default bearer anyway). The access network HSS would specify that the default bearer was created with the appropriate parameters (QCI=5, AM, etc.).
This is the network message flow: 172.25.152.195 -> pcscf.core.ims1.test SIP 999 Request: REGISTER sip:provider1.test (fetch bindings) | pcscf.core.ims1.test -> 172.25.152.195 SIP 359 Status: 100 Trying (0 bindings) | pcscf.core.ims1.test -> pcrf.ims1.test DIAMETER 762 cmd=AARequest(265) flags=RP-- appl=3GPP Rx(16777236) h2h=28fe20b1 e2e=fe338ed9 pcrf.ims1.test -> pcscf.core.ims1.test DIAMETER 198 cmd=AAAnswer(265) flags=-P-- appl=3GPP Rx(16777236) h2h=2 e2e=13 pcscf.core.ims1.test -> 172.25.152.195 SIP 410 Status: 408 Request Timeout (0 bindings) |
This is the DIAMETER AAR message: Diameter Protocol Version: 0x01 Length: 696 Flags: 0xc0, Request, Proxyable Command Code: 265 AA ApplicationId: 3GPP Rx (16777236) Hop-by-Hop Identifier: 0x28fe20b1 End-to-End Identifier: 0xfe338ed9 AVP: Session-Id(263) l=40 f=-M- val=pcscf.core.ims1.test;548405219;1 AVP: Origin-Host(264) l=28 f=-M- val=pcscf.core.ims1.test AVP: Origin-Realm(296) l=22 f=-M- val=provider1.test AVP: Auth-Application-Id(258) l=12 f=-M- val=3GPP Rx (16777236) AVP: Vendor-Specific-Application-Id(260) l=32 f=-M- AVP: Destination-Realm(283) l=22 f=-M- val=core.ims1.test AVP: Subscription-Id(443) l=52 f=-M- AVP: Media-Component-Description(517) l=304 f=VM- vnd=TGPP AVP Code: 517 Media-Component-Description AVP Flags: 0xc0 AVP Length: 304 AVP Vendor Id: 3GPP (10415) Media-Component-Description: 00000206c0000010000028af0000000100000207c00000bc... AVP: Media-Component-Number(518) l=16 f=VM- vnd=TGPP val=1 AVP: Media-Sub-Component(519) l=188 f=VM- vnd=TGPP AVP Code: 519 Media-Sub-Component AVP Flags: 0xc0 AVP Length: 188 AVP Vendor Id: 3GPP (10415) Media-Sub-Component: 000001fdc0000010000028af00000001000001fbc0000046... AVP: Flow-Number(509) l=16 f=VM- vnd=TGPP val=1 AVP: Flow-Description(507) l=70 f=VM- vnd=TGPP val=permit out ip from 172.25.152.195 37843 to 127.0.0.1 37843 AVP: Flow-Description(507) l=69 f=VM- vnd=TGPP val=permit in ip from 127.0.0.1 37843 to 172.25.152.195 37843 AVP: Flow-Usage(512) l=16 f=VM- vnd=TGPP val=AF_SIGNALLING (2) AVP: Media-Type(520) l=16 f=VM- vnd=TGPP val=CONTROL (4) AVP: Codec-Data(524) l=28 f=VM- vnd=TGPP val=downlink\noffer\n AVP: Codec-Data(524) l=27 f=VM- vnd=TGPP val=uplink\nanswer\n AVP: Flow-Status(511) l=16 f=VM- vnd=TGPP val=ENABLED (2) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=CHARGING_CORRELATION_EXCHANGE (1) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=INDICATION_OF_LOSS_OF_BEARER (2) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=INDICATION_OF_RECOVERY_OF_BEARER (3) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=INDICATION_OF_RELEASE_OF_BEARER (4) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=INDICATION_OF_ESTABLISHMENT_OF_BEARER (now void) (5) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=IP-CAN_CHANGE (6) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=ACCESS_NETWORK_INFO_REPORT (12) AVP: Framed-IP-Address(8) l=12 f=-M- val=172.25.152.195 AVP: Authorization-Lifetime(291) l=12 f=-M- val=7200 AVP: Auth-Grace-Period(276) l=12 f=-M- val=0 AVP: Session-Timeout(27) l=12 f=-M- val=7200
Hi,
please carefully verify. I've tested the implementation against various PCRF's (NSN, Ericsson, ZTE, Huawei and others) and we didn't run into issues. I think they did care about the flow, but I never really looked into the specs....
There is an undocumented parameter "af_signaling_ip" (shame on me, I will add that when I'm back from holiday), which can be used to replace the 127.0.0.1.
Thanks, Carsten
2017-10-18 21:44 GMT-04:00 Ron McLeod ron.kamailio@mcleodnet.com:
When a LTE handset client attempts to REGISTER with the IMS, an AAR is sent from the P-CSCF to the PCRF to establish a dedicated bearer for SIP signaling (as well as request notifications for certain access network event). There are a couple of problems with the flow descriptions, and I was hoping that someone could confirm that these are actual issues before I start working on a fix.
- The "in" and "out" directions seem reversed. "in" corresponds to the
uplink (UE to network), and "out" corresponds to the downlink (network to UE). In the AAR sent to the PCRF, the "in" description indicates the traffic "from" the UE, rather than "to" the UE. There is a similar problem with the "out" description. A fix would involve reversing "in" and "out".
- The IP address and port number for the UE side are correct (in my case
the UE has been allocated 172.25.152.195, and the client is using port 37843), but the network side is specified as IP address 127.0.0.1 and port number is the same as the open used by the client (in my case the P-CSCF has an IP address of 172.25.152.20 and a port number of 4060). I see in the source code that the P-CSCF address is hard-coded to "127.0.0.1". A fix would involve either using the actual UE-facing IP address and port number for the P-CSCF or wildcards. Another option would be to not try and setup a dedicated bearer for SIP signaling, and just use the default bearer (there shouldn't be anything else other than signaling-related traffic on the default bearer anyway). The access network HSS would specify that the default bearer was created with the appropriate parameters (QCI=5, AM, etc.).
This is the network message flow: 172.25.152.195 -> pcscf.core.ims1.test SIP 999 Request: REGISTER sip:provider1.test (fetch bindings) | pcscf.core.ims1.test -> 172.25.152.195 SIP 359 Status: 100 Trying (0 bindings) | pcscf.core.ims1.test -> pcrf.ims1.test DIAMETER 762 cmd=AARequest(265) flags=RP-- appl=3GPP Rx(16777236) h2h=28fe20b1 e2e=fe338ed9 pcrf.ims1.test -> pcscf.core.ims1.test DIAMETER 198 cmd=AAAnswer(265) flags=-P-- appl=3GPP Rx(16777236) h2h=2 e2e=13 pcscf.core.ims1.test -> 172.25.152.195 SIP 410 Status: 408 Request Timeout (0 bindings) |
This is the DIAMETER AAR message: Diameter Protocol Version: 0x01 Length: 696 Flags: 0xc0, Request, Proxyable Command Code: 265 AA ApplicationId: 3GPP Rx (16777236) Hop-by-Hop Identifier: 0x28fe20b1 End-to-End Identifier: 0xfe338ed9 AVP: Session-Id(263) l=40 f=-M- val=pcscf.core.ims1.test;548405219;1 AVP: Origin-Host(264) l=28 f=-M- val=pcscf.core.ims1.test AVP: Origin-Realm(296) l=22 f=-M- val=provider1.test AVP: Auth-Application-Id(258) l=12 f=-M- val=3GPP Rx (16777236) AVP: Vendor-Specific-Application-Id(260) l=32 f=-M- AVP: Destination-Realm(283) l=22 f=-M- val=core.ims1.test AVP: Subscription-Id(443) l=52 f=-M- AVP: Media-Component-Description(517) l=304 f=VM- vnd=TGPP AVP Code: 517 Media-Component-Description AVP Flags: 0xc0 AVP Length: 304 AVP Vendor Id: 3GPP (10415) Media-Component-Description: 00000206c0000010000028af0000000100000207c00000bc... AVP: Media-Component-Number(518) l=16 f=VM- vnd=TGPP val=1 AVP: Media-Sub-Component(519) l=188 f=VM- vnd=TGPP AVP Code: 519 Media-Sub-Component AVP Flags: 0xc0 AVP Length: 188 AVP Vendor Id: 3GPP (10415) Media-Sub-Component: 000001fdc0000010000028af00000001000001fbc0000046... AVP: Flow-Number(509) l=16 f=VM- vnd=TGPP val=1 AVP: Flow-Description(507) l=70 f=VM- vnd=TGPP val=permit out ip from 172.25.152.195 37843 to 127.0.0.1 37843 AVP: Flow-Description(507) l=69 f=VM- vnd=TGPP val=permit in ip from 127.0.0.1 37843 to 172.25.152.195 37843 AVP: Flow-Usage(512) l=16 f=VM- vnd=TGPP val=AF_SIGNALLING (2) AVP: Media-Type(520) l=16 f=VM- vnd=TGPP val=CONTROL (4) AVP: Codec-Data(524) l=28 f=VM- vnd=TGPP val=downlink\noffer\n AVP: Codec-Data(524) l=27 f=VM- vnd=TGPP val=uplink\nanswer\n AVP: Flow-Status(511) l=16 f=VM- vnd=TGPP val=ENABLED (2) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=CHARGING_CORRELATION_EXCHANGE (1) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=INDICATION_OF_LOSS_OF_BEARER (2) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=INDICATION_OF_RECOVERY_OF_BEARER (3) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=INDICATION_OF_RELEASE_OF_BEARER (4) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=INDICATION_OF_ESTABLISHMENT_OF_BEARER (now void) (5) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=IP-CAN_CHANGE (6) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=ACCESS_NETWORK_INFO_REPORT (12) AVP: Framed-IP-Address(8) l=12 f=-M- val=172.25.152.195 AVP: Authorization-Lifetime(291) l=12 f=-M- val=7200 AVP: Auth-Grace-Period(276) l=12 f=-M- val=0 AVP: Session-Timeout(27) l=12 f=-M- val=7200
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Carsten Bock -
Ron McLeod