Hi All,
I have question regarding implicit de-registration.
2 IMPUs belonging to same IRS( Implicit registration set) are registered from
two end points.
when first IMPU is registered all the IMPU's belonging to IRS are
implcitly registered. and then the second IMPU is involved in a active
session 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.
Observation 1: In 200 OK message for the second register request I see 2
contact headers belonging to 2 IMPU's.
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.
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.
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.
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??
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
