On 7/1/14 11:11 AM, Sourav Dhar Chaudhuri wrote:
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.
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.
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
Thanks & Regards
Sourav Dhar Chaudhuri
.
On Tuesday, 1 July 2014 7:53 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:
On 7/1/14 9:37 AM, Sourav Dhar Chaudhuri wrote:
> 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.
> 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
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.
> iii) Third 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?
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@lists.cs.columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
