[Sip-implementors] Difference Between SIP registration & reregistration

[Sourav Dhar Chaudhuri]

Hi,
? ? How can be determined that whether SIP REGISTER is for new registration or reregistration by seeing the request.

? It seems that in case if the CSeq header value is considered then we can found something. ?So please find my question

i) First Scenario
? ?a) Consider an UE very first time sent REGISTER request with CSeq value as : 55 with one contact. Call-ID: 123 with expires 60
? ?b) ?It got successfully registered.
? ?c) Now with 50 ?seconds ?UE sends second REGISTER request with CSeq value as 40 with same contact . different Call ID 456 [Whether CSeq value has to be increased since call ID is different]

? ?but still with this behavior whether Second Register will be entertained?

ii) Second Scenario:
? ? ?a)?UE very first time sent REGISTER request with CSeq value as : 55 with Expiry = 60 and Call-Id: 345 with one contact
? ? ?b) ?It got successfully registered. This registration will be over after 60 seconds?
? ? ?
? ? c) ?After 120 seconds?UE sends second ?REGISTER request with CSeq value as 70 and different Call-Id: 789 with same contact . How second REGISTER will be differentiated with new registration or reregistration.



iii)?Second Scenario:
? ? ?a)?UE very first time sent REGISTER request with CSeq value as : 55 with Expiry = 60 and Call-Id: 876 with one contact
? ? ?b) ?It got successfully registered.?
? ? ?
? ? c) within 50 seconds?UE sends second ?REGISTER request with CSeq value as 70 and different Call-Id: 321 with same contact with Expiry = 0 . Whether UE will be deregistered?
? ? ?

Thanks & Regards,

Sourav Dhar Chaudhuri

[Paul Kyzivat]

Post by Sourav Dhar Chaudhuri
Hi,
How can be determined that whether SIP REGISTER is for new registration or reregistration by seeing the request.

You *can't* tell by examining the REGISTER.
And for the most part it doesn't matter.

Post by Sourav Dhar Chaudhuri
It seems that in case if the CSeq header value is considered then we can found something. So please find my question

The sender of REGISTER is required to increment the CSeq for each
REGISTER with the same Call-ID. The registrar is required to retain the
call-id and cseq used to establish each binding. Look at bullet 6 of
section 10.3 of 3261.

Post by Sourav Dhar Chaudhuri
i) First Scenario
a) Consider an UE very first time sent REGISTER request with CSeq value as : 55 with one contact. Call-ID: 123 with expires 60
b) It got successfully registered.
c) Now with 50 seconds UE sends second REGISTER request with CSeq value as 40 with same contact . different Call ID 456 [Whether CSeq value has to be increased since call ID is different]
but still with this behavior whether Second Register will be entertained?

Above is valid. The binding is replaced.

Post by Sourav Dhar Chaudhuri
a) UE very first time sent REGISTER request with CSeq value as : 55 with Expiry = 60 and Call-Id: 345 with one contact
b) It got successfully registered. This registration will be over after 60 seconds
c) After 120 seconds

So binding has expired.

UE sends second REGISTER request with CSeq value as 70 and
different Call-Id: 789 with same contact . How second REGISTER will be
differentiated with new registration or reregistration.

This is valid as a new registration. So the binding was present, then
absent, then present again.
*Third*

Post by Sourav Dhar Chaudhuri
a) UE very first time sent REGISTER request with CSeq value as : 55 with Expiry = 60 and Call-Id: 876 with one contact
b) It got successfully registered.
c) within 50 seconds UE sends second REGISTER request with CSeq value as 70 and different Call-Id: 321 with same contact with Expiry = 0 . Whether UE will be deregistered?

Yes. The new registration is valid, replacing the old one, and then
immediately expiring.

In the normal case where you establish a registration and then attempt
to maintain it by refreshing before it expires, it may be possible that
your refresh will be "late". If it arrives on time then it is a refresh,
and if it arrives late then it is a new registration.

And you can do that using the same call-id or different ones. You SHOULD
do it using the same call-id. If you use the same call-id then you must
use increasing cseq values. That helps to detect screw ups, because they
will be rejected.

Of course, during the period when your registration was expired you may
have missed some calls, and without some other effort on your part you
will never know that.

The introduction of GRUU (RFC 5627) complicates things, because
temporary gruus expire when a binding expires. If you are using those
temporary bindings then it is important to know that.

Look at section 6.1 of RFC 5628 for some details on this.

Why are you asking these questions? Are you trying to figure out how to
implement a registrar? Or how to implement a UA that registers?

Thanks,
Paul

[Sourav Dhar Chaudhuri]

Hi Paul,
? ? ?At first thanks a lot for your very fast response. Actually I am verifying a Registrer behavior with those kinds of REGISTER request.

?As you mentioned for my first scenario that the Binding will be changed. Whether that will consider as New Registration request or reregistration?

? ? Also by reading your explanation, if a REGISTER request is having same call ID with previous any REGISTER request ?and also sent before the expiry of the that previous REGISTER request, moreover it has higher CSeq value than the previous REGISTER ?request. ?Then that second REGISTER request is considered as a reregistration.

In any other case is possible where any REGISTER request will be considered as ?reregistration ?

?Actual I am asking reregistration terminology ?specifically due to Authorization implementation for reregistration.

Thanks & Regards

Sourav Dhar Chaudhuri


.

Hi,
? ? ? How can be determined that whether SIP REGISTER is for new registration or reregistration by seeing the request.

You *can't* tell by examining the REGISTER.
And for the most part it doesn't matter.

? ? It seems that in case if the CSeq header value is considered then we can found something.? So please find my question

The sender of REGISTER is required to increment the CSeq for each
REGISTER with the same Call-ID. The registrar is required to retain the
call-id and cseq used to establish each binding. Look at bullet 6 of
section 10.3 of 3261.

i) First Scenario
? ? a) Consider an UE very first time sent REGISTER request with CSeq value as : 55 with one contact. Call-ID: 123 with expires 60
? ? b)? It got successfully registered.
? ? c) Now with 50? seconds? UE sends second REGISTER request with CSeq value as 40 with same contact . different Call ID 456 [Whether CSeq value has to be increased since call ID is different]
? ? but still with this behavior whether Second Register will be entertained?

Above is valid. The binding is replaced.

? ? ? a) UE very first time sent REGISTER request with CSeq value as : 55 with Expiry = 60 and Call-Id: 345 with one contact
? ? ? b)? It got successfully registered. This registration will be over after 60 seconds
? ? ? c)? After 120 seconds

So binding has expired.

? ? ? ? ? ? UE sends second? REGISTER request with CSeq value as 70 and
different Call-Id: 789 with same contact . How second REGISTER will be
differentiated with new registration or reregistration.

This is valid as a new registration. So the binding was present, then
absent, then present again.

? ? ? a) UE very first time sent REGISTER request with CSeq value as : 55 with Expiry = 60 and Call-Id: 876 with one contact
? ? ? b)? It got successfully registered.
? ? ? c) within 50 seconds UE sends second? REGISTER request with CSeq value as 70 and different Call-Id: 321 with same contact with Expiry = 0 . Whether UE will be deregistered?

Yes. The new registration is valid, replacing the old one, and then
immediately expiring.

In the normal case where you establish a registration and then attempt
to maintain it by refreshing before it expires, it may be possible that
your refresh will be "late". If it arrives on time then it is a refresh,
and if it arrives late then it is a new registration.

And you can do that using the same call-id or different ones. You SHOULD
do it using the same call-id. If you use the same call-id then you must
use increasing cseq values. That helps to detect screw ups, because they
will be rejected.

Of course, during the period when your registration was expired you may
have missed some calls, and without some other effort on your part you
will never know that.

The introduction of GRUU (RFC 5627) complicates things, because
temporary gruus expire when a binding expires. If you are using those
temporary bindings then it is important to know that.

Look at section 6.1 of RFC 5628 for some details on this.

Why are you asking these questions? Are you trying to figure out how to
implement a registrar? Or how to implement a UA that registers?


??? Thanks,
??? Paul

[Paul Kyzivat]

Post by Sourav Dhar Chaudhuri
Hi Paul,
At first thanks a lot for your very fast response. Actually I am
verifying a Registrer behavior with those kinds of REGISTER request.
As you mentioned for my first scenario that the Binding will be
changed. Whether that will consider as New Registration request or
reregistration?

What difference does it make?

The binding will remain. The callid and cseq associated with it will change.

Post by Sourav Dhar Chaudhuri
Also by reading your explanation, if a REGISTER request is having
same call ID with previous any REGISTER request and also sent before
the expiry of the that previous REGISTER request, moreover it has higher
CSeq value than the previous REGISTER request. Then that second
REGISTER request is considered as a reregistration.
In any other case is possible where any REGISTER request will be
considered as reregistration ?

Again, what distinction are you trying to draw?

All the matters are externally discernible changes in behavior.

Are you concerned with GRUUs, or with the "reg" event package?
If not, then there is no observable difference.

Post by Sourav Dhar Chaudhuri
Actual I am asking reregistration terminology specifically due to
Authorization implementation for reregistration.

I don't understand. Do you mean that there is some authorization policy
that is different for reregistration than for initial registration?

Thanks,
Paul

Post by Sourav Dhar Chaudhuri
Thanks & Regards
Sourav Dhar Chaudhuri
.

Post by Sourav Dhar Chaudhuri
Hi,
How can be determined that whether SIP REGISTER is for new

registration or reregistration by seeing the request.
You *can't* tell by examining the REGISTER.
And for the most part it doesn't matter.

Post by Sourav Dhar Chaudhuri
It seems that in case if the CSeq header value is considered then

we can found something. So please find my question
The sender of REGISTER is required to increment the CSeq for each
REGISTER with the same Call-ID. The registrar is required to retain the
call-id and cseq used to establish each binding. Look at bullet 6 of
section 10.3 of 3261.

Post by Sourav Dhar Chaudhuri
i) First Scenario
a) Consider an UE very first time sent REGISTER request with CSeq

value as : 55 with one contact. Call-ID: 123 with expires 60

Post by Sourav Dhar Chaudhuri
b) It got successfully registered.
c) Now with 50 seconds UE sends second REGISTER request with

CSeq value as 40 with same contact . different Call ID 456 [Whether CSeq
value has to be increased since call ID is different]

Post by Sourav Dhar Chaudhuri
but still with this behavior whether Second Register will be

entertained?
Above is valid. The binding is replaced.
55 with Expiry = 60 and Call-Id: 345 with one contact

Post by Sourav Dhar Chaudhuri
b) It got successfully registered. This registration will be

over after 60 seconds

Post by Sourav Dhar Chaudhuri
c) After 120 seconds

So binding has expired.
UE sends second REGISTER request with CSeq value as 70 and
different Call-Id: 789 with same contact . How second REGISTER will be
differentiated with new registration or reregistration.
This is valid as a new registration. So the binding was present, then
absent, then present again.
55 with Expiry = 60 and Call-Id: 876 with one contact

Post by Sourav Dhar Chaudhuri
b) It got successfully registered.
c) within 50 seconds UE sends second REGISTER request with CSeq

value as 70 and different Call-Id: 321 with same contact with Expiry = 0
. Whether UE will be deregistered?
Yes. The new registration is valid, replacing the old one, and then
immediately expiring.
In the normal case where you establish a registration and then attempt
to maintain it by refreshing before it expires, it may be possible that
your refresh will be "late". If it arrives on time then it is a refresh,
and if it arrives late then it is a new registration.
And you can do that using the same call-id or different ones. You SHOULD
do it using the same call-id. If you use the same call-id then you must
use increasing cseq values. That helps to detect screw ups, because they
will be rejected.
Of course, during the period when your registration was expired you may
have missed some calls, and without some other effort on your part you
will never know that.
The introduction of GRUU (RFC 5627) complicates things, because
temporary gruus expire when a binding expires. If you are using those
temporary bindings then it is important to know that.
Look at section 6.1 of RFC 5628 for some details on this.
Why are you asking these questions? Are you trying to figure out how to
implement a registrar? Or how to implement a UA that registers?
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
<mailto:Sip-implementors at lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors