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) Second Scenario:
*Third*
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
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
