[SR-Users] Problems with AAR over Rx Interface

[Ron McLeod]

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