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 Tel: +1 647 342 6183, Mobile: +1 416 662 4490 On 9 March 2016 at 08:42, Chris Elford <[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]] > *On Behalf Of *Steve Yeoman > *Sent:* 07 March 2016 14:48 > *To:* [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];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] > ;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]), 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
