Imsdroid issuing subscriber against a barred public user identity

[GoogleCodeExporter]

What steps will reproduce the problem?
1.
In the IMS core reate a private identity with two public identities, one of 
which is marked as barred.

2.
From imsdroid, register against the barred public identity.  The registration 
will succeed, however, in the 200 the barred public identity will not be 
included in the P-Associated-URI list.

3.
Following the registration, imsdroid will attempt to subscribe to the reg event 
package for the barred public identity, and receive back a 403 Forbidden 
response.

What is the expected output? What do you see instead?
TS 24.229 (Rel 9, ver 5), section 5.1.1.3, paragraph 3 begins:

"The UE shall use the default public user identity for subscription to the 
registration-state event package, if the public user identity that was used for 
initial registration is a barred public user identity."

In section 5.1.1.2.1, under actions to be taken after receiving the 200 ok, 
bullet b) states:

"store as the default public user identity the first URI on the list of URIs 
present in the P-Associated-URI header"

Therefore, I would expect imsdroid to issue a reg-event subscribe for the first 
identity in the first uri in the P-Assoicated-URI headers set in the 200 ok for 
the reg.

What version of the product are you using? On what operating system?
I'm using imsdroid v1.0.302 on an HTC Evo runing Adroid 2.2.

Please provide any additional information below.
Terrific tool!

Original issue reported on code.google.com by jemy...@gmail.com on 1 Nov 2010 at 3:51

[GoogleCodeExporter]

What do you mean by "marked as barred"?
To detect that the identity is barred, the client will check that the IMPU is 
not part of the P-Associated-URIs returned in initial "200 REGISTER". The new 
public identity will be the first P-Associated-URI.
Source code-> 
http://code.google.com/p/doubango/source/browse/trunk/tinySIP/src/dialogs/tsip_d
ialog_register.client.c (from line 401).

Original comment by boss...@yahoo.fr on 1 Nov 2010 at 7:01

• Changed state: Accepted

[GoogleCodeExporter]

My apologies, you are absolutely correct!

First, on the question of “marked as barred”, in our IMS core we have the 
capability of marking a public identity as “barred” and therefore not 
available for anything beyond registration.  I think this is much as you would 
expect.

Previously I had noted that on calls, the client is using the first IMPU in the 
P-Associated-UR list in the P-Preferred-Identity header.  Somehow when I looked 
at the Subscribe message, I managed to look right by the P-Preferred header.  
Clearly my AS is (correctly) paying attention P-header, while the S-CSCF is not 
doing the same for the Subscribe/Notify.

Again, my apologies for calling your implementation into doubt.  If you’ll 
excuse me, I’ll now go have a chat with my CSCF supplier.

Thanks again!

Original comment by jemy...@gmail.com on 1 Nov 2010 at 7:52

[GoogleCodeExporter]

In preparing to talk with my CSCF vendor, I've noticed that the cleint is 
creating a Subscribe transaction with the form:

SUBSCRIBE sip:{barred PUID} SIP/2.0
From: <sip:{barred PUID}>;...
To: <sip:{barred PUID}>
Contact: ...
Event: reg
P-Asserted-Identity: <sip:{Default PUID}>

However, I beleive for a subscribe method the Request-URI should be the uri for 
which the subscription is being made.  Therefore:

SUBSCRIBE sip:{Default PUID} SIP/2.0

I don't beleive the P-Asserted header can really help in the cases if for no 
other reason then it is providing information regarding the originator of the 
transaction not the target of the transaction.

Opinion?

Original comment by jemy...@gmail.com on 1 Nov 2010 at 9:41

[GoogleCodeExporter]

You are right, both SUBSCRIBE (reg, message-summary) and PUBLISH requests shall 
have the {Default PUID} as request-uri. From and To headers should not change.

Original comment by boss...@yahoo.fr on 2 Nov 2010 at 12:40

[GoogleCodeExporter]

Fixed in version 1.0.320.

Original comment by boss...@yahoo.fr on 4 Nov 2010 at 6:55

[GoogleCodeExporter]

Original comment by boss...@yahoo.fr on 4 Nov 2010 at 11:16

• Changed state: Fixed