Hi Paul, I'm not sure what you're asking here. In the logs you've attached it looks like a LIR is made for the terminating user in a SUBSCRIBE. This SUBSCRIBE is proxied by Clearwater, not processed, so it's being sent onto the terminating user, rather than absorbed by Clearwater.
Ellie From: Paul Sun [mailto:[email protected]] Sent: 03 December 2014 02:18 To: Eleanor Merry; [email protected] Subject: RE: [Clearwater] 489 Event Package Not supported Hi Ellie I think this is the case. can you further explain why ? - PS 03-12-2014 01:40:27.697 UTC Debug ifchandler.cpp:556: Result group 3 val false 03-12-2014 01:40:27.697 UTC Debug ifchandler.cpp:569: iFC does not match 03-12-2014 01:40:27.697 UTC Info scscfsproutlet.cpp:861: Completed applying originating services 03-12-2014 01:40:27.697 UTC Debug scscfsproutlet.cpp:1223: Translating URI 03-12-2014 01:40:27.697 UTC Debug scscfsproutlet.cpp:218: ENUM is enabled 03-12-2014 01:40:27.697 UTC Debug scscfsproutlet.cpp:225: SIP URI - user = 95200000000 03-12-2014 01:40:27.697 UTC Debug scscfsproutlet.cpp:244: Global number or look-ups allowed for non-global numbers 03-12-2014 01:40:27.697 UTC Debug scscfsproutlet.cpp:250: Performing ENUM lookup for user 95200000000 03-12-2014 01:40:27.698 UTC Debug dnsresolver.cpp:141: Sending DNS NAPTR query for 0.0.0.0.0.0.0.0.2.5.8.e164.arpa 03-12-2014 01:40:27.700 UTC Debug enumservice.cpp:446: Got NAPTR record: 2 1 "E2U+sip" "u" "!(^.*$)!sip:\[email protected]!" 03-12-2014 01:40:27.700 UTC Debug enumservice.cpp:69: Split regex into match=(^.*$), replace=sip:\[email protected] 03-12-2014 01:40:27.700 UTC Debug enumservice.cpp:386: Enum lookup completes: sip:[email protected] 03-12-2014 01:40:27.700 UTC Debug scscfsproutlet.cpp:1234: Update request URI to sip:[email protected] 03-12-2014 01:40:27.700 UTC Info scscfsproutlet.cpp:1025: Routing to I-CSCF sip:sprout.synaplabs.com:5052;transport=TCP 03-12-2014 01:40:27.700 UTC Debug sproutletproxy.cpp:1136: Sproutlet send_request 0x7f64284a4bc0 03-12-2014 01:40:27.701 UTC Verbose sproutletproxy.cpp:1161: scscf-0x7f642848deb0 sending Request msg SUBSCRIBE/cseq=1 (tdta0x7f64284a45b0) on fork 0 03-12-2014 01:40:27.701 UTC Debug sproutletproxy.cpp:1477: Processing actions from sproutlet - 0 responses, 1 requests 03-12-2014 01:40:27.701 UTC Debug sproutletproxy.cpp:1512: Processing request 0x7f64284a4658, fork = 0 03-12-2014 01:40:27.701 UTC Debug sproutletproxy.cpp:1630: scscf-0x7f642848deb0 transmitting request on fork 0 03-12-2014 01:40:27.701 UTC Debug sproutletproxy.cpp:1644: scscf-0x7f642848deb0 store reference to non-ACK request Request msg SUBSCRIBE/cseq=1 (tdta0x7f64284a45b0) on fork 0 03-12-2014 01:40:27.701 UTC Debug sproutletproxy.cpp:1469: Removing message 0x7f64284a4bc0 => txdata 0x7f64284a4658 mapping 03-12-2014 01:40:27.701 UTC Debug sproutletproxy.cpp:110: Find target Sproutlet for request 03-12-2014 01:40:27.701 UTC Debug sproutletproxy.cpp:144: Found next routable URI: sip:sprout.synaplabs.com:5052;transport=TCP;lr 03-12-2014 01:40:27.701 UTC Debug sproutletproxy.cpp:174: No Sproutlet found using service name or host 03-12-2014 01:40:27.701 UTC Debug sproutletproxy.cpp:179: Find default service for port 5052 03-12-2014 01:40:27.701 UTC Verbose sproutletproxy.cpp:976: Created Sproutlet icscf-0x7f64284061c0 for Request msg SUBSCRIBE/cseq=1 (tdta0x7f64284a45b0) 03-12-2014 01:40:27.701 UTC Debug pjutils.cpp:693: Cloned tdta0x7f64284a45b0 to tdta0x7f64284b80d0 03-12-2014 01:40:27.701 UTC Debug sproutletproxy.cpp:1037: Remove top Route header Route: <sip:sprout.synaplabs.com:5052;transport=TCP;lr> 03-12-2014 01:40:27.701 UTC Debug sproutletproxy.cpp:1462: Adding message 0x7f64284b86e0 => txdata 0x7f64284b8178 mapping 03-12-2014 01:40:27.701 UTC Verbose sproutletproxy.cpp:1336: icscf-0x7f64284061c0 pass initial request Request msg SUBSCRIBE/cseq=1 (tdta0x7f64284b80d0) to Sproutlet 03-12-2014 01:40:27.701 UTC Debug acr.cpp:1495: Create RalfACR for node type BGCF with role Terminating 03-12-2014 01:40:27.701 UTC Debug acr.cpp:48: Created ACR (0x7f64283d1580) 03-12-2014 01:40:27.701 UTC Debug acr.cpp:195: Created BGCF Ralf ACR 03-12-2014 01:40:27.701 UTC Debug acr.cpp:274: Set record type for I-CSCF, BGCF, IBCF, AS to EVENT_RECORD 03-12-2014 01:40:27.701 UTC Debug acr.cpp:1194: Found a P-Charging-Function-Address header 03-12-2014 01:40:27.701 UTC Debug acr.cpp:1213: 1 ccfs and 0 ecfs 03-12-2014 01:40:27.701 UTC Debug icscfsproutlet.cpp:408: I-CSCF initialize transaction for non-REGISTER request 03-12-2014 01:40:27.701 UTC Debug icscfsproutlet.cpp:430: Terminating request 03-12-2014 01:40:27.701 UTC Debug icscfrouter.cpp:362: Perform LIR - impu sip:[email protected], originating false, auth_type None 03-12-2014 01:40:27.701 UTC Debug httpresolver.cpp:70: HttpResolver::resolve for host hs.synlabs.com, port 8888, family 2 03-12-2014 01:40:27.701 UTC Debug baseresolver.cpp:511: Attempt to parse hs.synlabs.com as IP address 03-12-2014 01:40:27.701 UTC Debug dnscachedresolver.cpp:179: Pulling 1 records from cache for hs.synlabs.com A 03-12-2014 01:40:27.701 UTC Debug baseresolver.cpp:359: Found 1 A/AAAA records, randomizing 03-12-2014 01:40:27.701 UTC Debug baseresolver.cpp:501: 192.168.1.214:8888 transport 6 is not blacklisted 03-12-2014 01:40:27.701 UTC Debug baseresolver.cpp:380: Added a server, now have 1 of 5 03-12-2014 01:40:27.701 UTC Debug baseresolver.cpp:418: Adding 0 servers from blacklist 03-12-2014 01:40:27.701 UTC Debug baseresolver.cpp:511: Attempt to parse 192.168.1.214 as IP address 03-12-2014 01:40:27.702 UTC Debug httpconnection.cpp:540: Sending HTTP request : http://hs.synlabs.com:8888/impu/sip%3A95200000000%40synlabs.com/location (trying 192.168.1.214) 03-12-2014 01:40:27.709 UTC Debug httpconnection.cpp:553: Received HTTP response : {"result-code":2001,"scscf":"sip:sprout.synlabs.com:5054;transport=TCP"} 03-12-2014 01:40:27.709 UTC Debug statistic.cpp:103: Send new value for statistic hss_location_latency_us, size 5 03-12-2014 01:40:27.709 UTC Debug icscfrouter.cpp:197: HSS returned S-CSCF sip:sprout.synlabs.com:5054;transport=TCP as target 03-12-2014 01:40:27.709 UTC Debug acr.cpp:638: Storing Server-Capabilities 03-12-2014 01:40:27.709 UTC Verbose acr.cpp:646: Sending BGCF Ralf ACR (0x7f64283d1580) 03-12-2014 01:40:27.709 UTC Debug acr.cpp:662: Building message 03-12-2014 01:40:27.709 UTC Debug acr.cpp:677: Adding peers meta-data, 1 ccfs, 0 ecfs 03-12-2014 01:40:27.709 UTC Debug acr.cpp:694: Building event From: Eleanor Merry [mailto:[email protected]] Sent: Wednesday, December 03, 2014 2:53 AM To: Paul Sun; [email protected]<mailto:[email protected]> Subject: RE: [Clearwater] 489 Event Package Not supported Hi Paul, That's not quite right. If Clearwater proxies the SUBSCRIBE, then there will be a LIR for the terminating user (if I-CSCF function is enabled). Clearwater will process the SUBSCRIBE if has Event type 'reg', and it's targeted at the home domain/local node. In this case no LIRs will be made. Ellie From: Paul Sun [mailto:[email protected]] Sent: 02 December 2014 17:51 To: Eleanor Merry; [email protected]<mailto:[email protected]> Subject: RE: [Clearwater] 489 Event Package Not supported So it meant whatever a SUBSCRIBE is received in sprout, it will trigger a LIR at homestead, although sprout will check whether event header is reg or not, rite? Ps -------- Original message -------- From: Eleanor Merry Date:2014/12/03 01:38 (GMT+08:00) To: Paul Sun ,[email protected] Subject: RE: [Clearwater] 489 Event Package Not supported Hi Paul, You are correct, the SUBSCRIBE does trigger a LIR. The lookup for the originating subscriber doesn't trigger an LIR - the S-CSCF is known from the Service-Route on a previous register. The lookup for the terminating subscribee does trigger an LIR though - the S-CSCF for this subscriber is not yet known. Hope this helps, Ellie From: Paul Sun [mailto:[email protected]] Sent: 02 December 2014 01:43 To: Eleanor Merry; [email protected]<mailto:[email protected]> Subject: RE: [Clearwater] 489 Event Package Not supported Hi Ellie I double checked through the packet trace captured on homestead, and I found that SPROUT sends http://<hss-mirror>:8888/impu/sip%3A123456789%40domain1.com/location<http://%3chss-mirror%3e:8888/impu/sip%3A123456789%40domain1.com/location> to request the name of the server currently serving the specified user. It maps to a Location-Info-Request to the HSS. So, I would like to make a clear understanding why sprout still sends the HTTP request to homestead even those the event package is not supported. Thanks - paul From: Paul Sun Sent: Monday, December 01, 2014 4:34 PM To: 'Eleanor Merry'; [email protected]<mailto:[email protected]> Subject: RE: [Clearwater] 489 Event Package Not supported Hi Ellie That's strange, I actually observe there is a LIR generated from homestead when a SUBSCRIBE message arrived in S-CSCF. Any idea? - PS -----Original Message----- From: Eleanor Merry [mailto:[email protected]] Sent: Saturday, November 29, 2014 3:50 AM To: Paul Sun; [email protected]<mailto:[email protected]> Subject: RE: [Clearwater] 489 Event Package Not supported Hi Paul, A SIP SUBSCRIBE will not trigger a LIR. A client has to be registered to send a SUSCRIBE (otherwise the P-CSCF will reject the SUBSCRIBE as untrusted). When the client successfully registers, the 200 OK they receive from the P-CSCF will include a Service-Route header, which is set to the subscriber's S-CSCF. When the client then makes a new request, they are meant to include this value as a route header (and if they don't, the P-CSCF will add it). As the subscriber's S-CSCF is known, there is no need to do an LIR. Ellie -----Original Message----- From: Paul Sun [mailto:[email protected]] Sent: 28 November 2014 03:45 To: Eleanor Merry; [email protected]<mailto:[email protected]> Subject: RE: [Clearwater] 489 Event Package Not supported Hi Ellie Will a SIP SUBSCRIBE message trigger a LIR between homestead and HSS? - PS -----Original Message----- From: Eleanor Merry [mailto:[email protected]] Sent: Friday, November 28, 2014 3:07 AM To: Paul Sun; [email protected]<mailto:[email protected]> Subject: RE: [Clearwater] 489 Event Package Not supported Hi, Clearwater only supports processing and creating a subscription for a SUBSCRIBE that has the Event type 'reg'. If Clearwater receives a SUBSCRIBE with any other Event type (or a SUBSCRIBE that isn't targeted at the home domain/the local node, or a SUBSCRIBE that doesn't accept 'application/reginfo+xml') then it will simply proxy it on - I presume that in this case it's back to the XLite client which then rejects it with a 489. If it's Clearwater generating the 489 (rather than the subscribee), then can you please send me the Sprout debug logs for this? Thanks, Ellie -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Paul Sun Sent: 27 November 2014 10:34 To: [email protected]<mailto:[email protected]> Subject: [Clearwater] 489 Event Package Not supported Hi While testing with X-lite on Clearwater, I noticed that when client send SIP SUBSCRIBE, a 489 Event Package Not supported is returned, is it normal? - PS _______________________________________________ Clearwater mailing list [email protected]<mailto:[email protected]> http://lists.projectclearwater.org/listinfo/clearwater _______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
