Subject: RE: [Sip] Can INVITE overlap SUBSCRIBE

From: [email-masked]
Date: Mon, 13 Jan 2003 10:50:01 +0200

To avoid all this confusion, would it be a good idea to forbid overlapping of target refresh requests within a dialog? i.e. requests that create dialogs are not allowed to overlap. In this way, we avoid the 500 response and the confusion of the race condition of the responses as well that might carry different remote targets.

Regards,
Hisham

> -----Original Message-----
> From: ext Brett Tate [mailto:[email-masked]]
> Sent: Saturday, January 11, 2003 2:59 AM
> To: [email-masked]
> Subject: RE: [Sip] Can INVITE overlap SUBSCRIBE
> 
> 
> > If a dialog is already established with a 
> > SUBSCRIBE, that SUBSCRIBE is being refreshed 
> > (SUBSCRIBE in progress). Can an INVITE, within 
> > the same dialog, be sent while the SUBSCRIBE 
> > refresh is in progress?
> 
> Yes.  However the requests might be received
> out of order.  Thus it might lead to a 500 
> response for the subscribe.
> 
> However caution should be observed when 
> overlapping requests towards devices that
> authenticate each request with a new nonce
> and only remember the last nonce.  Such a
> situation can lead to a continual challenge
> situation where UAC appears to keep sending 
> non-latest nonce.
>  
> > Another question: Can SUBSCRIBEs overlap in
> >  the following 2 scenarios?
> > 
> > Scenario 1:
> > 
> >    (1) SUBSCRIBE event:presence
> > ---------------------------->
> > 
> >    (2) SUBSCRIBE event:presence
> > ---------------------------->
> > 
> > (1) and (2) are requests within the same dialog 
> > and are the same association with the dialog.
> > Can (2) be sent before (1) completes. This is 
> > like INVITEs overlapping.
> 
> Yes, assuming the dialog has already been establish.  
> However the requests might be received out of order.  
> Thus it might lead to a 500 response for 1.
> 
> > Scenario 2:
> > 
> >    (3) SUBSCRIBE event:presence
> > ---------------------------->
> > 
> >    (4) SUBSCRIBE event:winfo
> > ---------------------------->
> > 
> > (3) and (4) are requests within the same dialog 
> > but are in different associations with the dialog.
> > Can (4) be sent before (3) completes. This is like 
> > INVITE and SUBSCRIBE overlapping, I think.
> 
> I'm not positive about what you mean by different 
> associations.  Thus I'll assume you mean different 
> event types.
> 
> Assuming the dialog has already been establish,
> yes it is legal to send.  However the requests might 
> be received out of order.  Thus it might lead to a 
> 500 response for 3.
> 
> > A similar example of this is 2 SUBSCRIBEs with the 
> > same event package but different event ids.
> 
> Yes it is legal to send.  However the requests might 
> be received out of order.  Thus it might lead to a 
> 500 response for 3.
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 13 Jan 2003 11:59:02 -0500

> To avoid all this confusion, would it be a 
> good idea to forbid overlapping of target 
> refresh requests within a dialog? 
> i.e. requests that create dialogs are not 
> allowed to overlap. In this way, we avoid 
> the 500 response and the confusion of the 
> race condition of the responses as well that 
> might carry different remote targets.

RFC 3261 section 12.2.2 already defines what
must happen when requests are received out
of order; a 500 response MUST be sent.  
Thus retargeting requests from the same
direction are already accommodated.

There are numerous race conditions associated 
with devices using responses to re-target.
Device Y should not be confident that a
re-target response will be processed correctly
by device X when device Y is currently awaiting 
a response for request containing the Contact of
prior target.  Using a retarget sequence number 
or Date header potentially could help solve the 
problem; however it is likely not worth the
extra specification to define it.

Some issues with dialog sharing and retargeting
were captured within the following:

http://www.ietf.org/mail-archive/working-groups/sip/current/msg06767.html