krishna chaitanya wrote:
> Hi All,
>
> I have question regarding implicit de-registration.
This isn't the ideal place to ask this question.
Implicit registration is not part of any ietf standard,
its a creation of IMS.
> 2 IMPUs belonging to same IRS( Implicit registration set) are registered
> from two end points.
I'm not certain I understand. Is the following what you mean?
- IMPU is a UA? Or an AOR? Since you mention end points too, I'll assume
an IMPU is an AOR.
- AORs X, Y, and Z are part of the same IRS, so that
if X is registered then Y and Z are implicitly registered;
if Y is registered then X and Z are implicitly registered.
- You have one UA that registers X
- You have another UA that also registers X (or Y or Z)
> when first IMPU is registered all the IMPU's belonging to IRS are
> implcitly registered.
ok. So AOR X was registered by UA-A, and Y and Z are also implicitly
registered to UA-A.
You don't mention it, but I will also assume that then UA-B registers
AOR-X and so Y and Z are also implicitly registered for it.
At that point there are effectively *six* registrations active.
I would see all six in a notification by the reg event package.
> and then the second IMPU is involved in a active session
OK, lets assume that somebody called AOR Y and it was answered by UA-A.
> and finally when the first IMPU is de-registered then the second IMPU
> is still registered and the is still ongoing without any call release.
Now, why is it that any deregistration is going on?
Is it an active request? Or just an expiration of a registration that
hasn't been refreshed? If so, why wasn't it refreshed?
And is it a deregistration by UA-A or UA-B?
AFAIK IMS doesn't allow a session to continue after deregistration.
It will terminate it.
> Observation 1: In 200 OK message for the second register request I see 2
> contact headers belonging to 2 IMPU's.
By 2nd register request you mean the one by UA-B?
The response to a register request will contain all the Contact
addresses that have been registered for the same AOR. Assuming an IMPU
is an AOR. In your scenario these should be for the two different UAs
that have registered.
> Observation 2: when the first IMPU is de-registered from one end point. then
> i see a 200OK for that de-register message along with the contact header
> related to the second IMPU.
I guess you are talking about explicit deregistration - something
sending an explicit register request to an AOR with a Contact that was
previously registered and and expiration time of 0.
In that case, the response to that request should contain any other
contacts for the same AOR that are still registered. So if both UA-A and
UA-B had registered X, and now UA-A is deregistering X, then the
response should include a Contact containing the URI of UA-B.
> Here the implicit de-registration is not happening and as per 3GPP 24228
> 5.2.1a
> When one of the Public User Identities within the set is de-registered, all
> Public User Identities that have been implicitly registered are de-registered
> at
> the same time.
It sounds to me like you are mixing up AORs and UA identities / Contact
addresses.
> But In this case below here is what happening due to the same 3GPP 24228
> 5.2.1a para
>
> Registration and de-registration always relates to a particular contact
> address
> and a particular Private User Identity. A Public user identity that has been
> registered (including when implicitly registered) with different contact
> addresses remains registered in relation to those contact
> addresses that have not
> been de-registered.
> So when first IMPU is registered all the IMPU's belonging to IRS are
> implcitly registerd. when the second IMPU is involved in a active session and
> when the first IMPU is de-registered then the second IMPU is still registered
> and the is still ongoing without any call release.
I don't understand the point you are trying to make.
> Is this a conflict within 3GPP ??
> what should be behaviour in this case when one IMPU belonging to an IRS set
> is deregistered??
>
> Should the de-registration of second IMPU or all other IMPU's be not
> de-regisrered??
> Any reference to 3GPP or ETSI is available to resolve this issue??
I think the conflict is probably in your understanding, not the spec.
You will have much better luck talking about this *here* if you
translate everything from IMS terminology to SIP terminology.
It may also help you to understand it.
Thanks,
Paul
> Does anybody aware of the real implemention regarding this??
>
> I highly appreciate for your comments and suggestions.
>
> Kind Regards,
> Krishna.
>
>
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
