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(a)mcleodnet.com>om>:
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
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
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/