Re: [Sip-implementors] Sending deRegister request just after sending REGISTER request

2017-06-28 Thread Dale R. Worley
Paul Kyzivat  writes:
> Another consideration is whether these are done using the same Call-ID. 
> (In the same pseudo-dialog.) I don't think it will generally make any 
> difference, but it may present issues if you are also requesting a 
> temporary gruu with the registration.

I haven't dug through the specifications.  But if they have the same
Call-ID, then the CSeq tells the order the REGISTERs are to have
effect.  If the network reorders them, the de-REGISTER will prevail
because it has a higher CSeq.

   A UA SHOULD use the same Call-ID for all registrations during a
   single boot cycle.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


Re: [Sip-implementors] Sending deRegister request just after sending REGISTER request

2017-06-28 Thread Paul Kyzivat

On 6/28/17 1:11 AM, Parveen Aggarwal wrote:

Dear Expert,

Is it valid to send deRegister request i.e. REGISTER with expires=0 before
receiving final response for previous registration request i.e. REGISTER
with expires >0  ?

As per RFC 3261,
It is mentioned for new REGISTER request only

UAs MUST NOT send a new registration (that is, containing new Contact
header field values, as opposed to a retransmission) until they have
received a final response from the registrar for the previous one or
the previous REGISTER request has timed out.


I see no particular reason why this should be considered an error. 
However it might not be wise. It would be possible for the two requests 
to get reordered, so that the unregister is processed before the 
register. Both would appear to succeed, but the end state of the 
registrar would be different.


Another consideration is whether these are done using the same Call-ID. 
(In the same pseudo-dialog.) I don't think it will generally make any 
difference, but it may present issues if you are also requesting a 
temporary gruu with the registration.


Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors