Thanks Steve, I’ve raised this with our product owner, and he’s going to prioritise it against our other work. I’ll let you when I have an answer from him.
Chris From: Steve Yeoman [mailto:[email protected]] Sent: 10 March 2016 15:03 To: Chris Elford <[email protected]> Cc: [email protected] Subject: Re: [Project Clearwater] preserving user=phone parameter on 3rd-party registration Hi Chris, ok, thanks. The use-case for this is 3rd-party ATM registrations for IP-SM-GW scenarios. I am testing that the TAS can handle all the logical permutations of SIP identities that can come from the S-CSCF - SIP URIs, Tel URIs, combinations etc. Having a sip identity with the user=phone param is one possible permutation on the list. It's not a blocker issue. The S-CSCF and TAS work fine without the user=phone param. Once you add support for it, I can check the TAS handles it as expected. cheers Steve ------------------------------------------------------------------------------------------ Steve Yeoman, Software Engineer, http://www.opencloud.com<http://www.opencloud.com/> Tel: +1 647 342 6183, Mobile: +1 416 662 4490 On 10 March 2016 at 09:28, Chris Elford <[email protected]<mailto:[email protected]>> wrote: Thanks Steve, I agree that it is possible to read the specification in two ways, so it makes sense to support both interpretations. It will help us to prioritise this issue if we understand how this is affecting you, and what impact this has in your specific use case. As a result of this conversation, Rob has raised an issue<https://github.com/Metaswitch/sprout/issues/1343> against Sprout to make sure that we send addresses in the right format over Diameter. Yours, Chris From: Steve Yeoman [mailto:[email protected]<mailto:[email protected]>] Sent: 09 March 2016 14:42 To: Chris Elford <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [Project Clearwater] preserving user=phone parameter on 3rd-party registration Hi, Those are good points. I was looking at 3GPP 24.229 5.4.1.7.c: "the To header field, which shall contain a non-barred public user identity belonging to the service profile of the processed Filter Criteria. It may be either a public user identity as contained in the REGISTER request received from the UE or one of the implicitly registered public user identities in the service profile, as configured by the operator;" I read that as meaning there are 2 options for the SCSCF: 1. Populate the To header value with the value that came "as contained" in the registration (i.e. with user=phone) 2. Populate the To header with the value that came from the HSS (without user=phone) So I thought perhaps there should be a config toggle for both choices? Although if the spec says there are 2 options for the SCSCF with a "it may be either" statement that could also mean you only need to implement one of them, not a choice of either of them. cheers Steve ------------------------------------------------------------------------------------------ Steve Yeoman, Software Engineer, http://www.opencloud.com<http://www.opencloud.com/> Tel: +1 647 342 6183<tel:%2B1%20647%20342%206183>, Mobile: +1 416 662 4490<tel:%2B1%20416%20662%204490> On 9 March 2016 at 08:42, Chris Elford <[email protected]<mailto:[email protected]>> wrote: Hi Steve, Thank you for letting us know about this. I ran this past some of the other Project Clearwater developers. We based Project Clearwater’s behaviour on our interpretation of the 3GPP specs. In particular, 3GPP TS 23.003<http://www.3gpp.org/dynareport/23003.htm> contains the following paragraph: “The canonical form of a SIP URI for a Public User Identity shall take the form "sip:username@domain" as specified in IETF RFC 3261 [26], section 10.3. SIP URI comparisons shall be performed as defined in IETF RFC 3261 [26], section 19.1.4.” We interpreted this as meaning that we should be sending IMPUs in SIP messages in this form, with all URI parameters removed. Looking more closely, the spec states that the canonical form must be used over Diameter interfaces, but it does not specify the behaviour for SIP interfaces: “According to 3GPP TS 29.229 [95] and 3GPP TS 29.329 [96] the canonical forms of SIP URI and Tel URI shall be used over the corresponding Diameter interfaces.” Do you have a different interpretation of this part of the spec to the one we used? In any case, we may be able to help. What is the use-case that you are trying to address here? Yours, Chris From: Clearwater [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Steve Yeoman Sent: 07 March 2016 14:48 To: [email protected]<mailto:[email protected]> Subject: [Project Clearwater] preserving user=phone parameter on 3rd-party registration Hi, I am trying to register a subscriber with a user=phone parameter. I want the user=phone parameter to be passed to the TAS for the 3rd-party registration. It looks like sprout receives the To header as: To: <sip:[email protected]<mailto:sip%3a%[email protected]>;user=phone> But sends the HSS lookup to Homestead like this: 07-03-2016 14:35:53.552 UTC Debug httpconnection.cpp:623: Sending HTTP request : http://ec2-52-3-140-139.compute-1.amazonaws.com:8888/impi/%2B6505550202%40example.com/registration-status?impu=sip%3A%2B6505550202%40example.com&visited-network=example.com&auth-type=REG (trying 172.31.45.86) on new connection which fails to find my IMPU because I have sip:[email protected]<mailto:sip%3a%[email protected]>;user=phone in the HSS. So the registration fails. I tried adding a second IMPU in the HSS without user=phone (i.e. sip:[email protected]<mailto:sip%3a%[email protected]>), but then Homestead finds that entry and Sprout sends the 3rd-party reg to the TAS without user=phone. Is there a way to preserve the user=phone param throughout the whole registration? I tried adding enforce_user_phone=Y and enforce_global_only_lookups=Y to my /etc/cleawater/shared_config file but that didn't seem to help. cheers Steve Yeoman
_______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
