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 . On Tuesday, 1 July 2014 7:53 PM, Paul Kyzivat <[email protected]> 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 [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
