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 Tel: +1 647 342 6183, Mobile: +1 416 662 4490 On 10 March 2016 at 09:28, Chris Elford <[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]] > *Sent:* 09 March 2016 14:42 > *To:* Chris Elford <[email protected]> > *Cc:* [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 > > 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
