Subject: RE: [Sip] Simple question about NOTIFY

From: "Brett Tate" <[email-masked]>
Date: Thu, 26 Jun 2003 16:56:28 -0400

> If a NOTIFY can fork, then it should be 
> possible to fork a re-INVITE also. 
> Should not it? 

Yes most requests can fork within a dialog.

> Assuming the same reasoning as you provided 
> for NOTIFY in a dialog. In which case the 
> following text in RFC 3261 is not really true. 
>
> ****
> Section 14.1, Pg 87 in RFC 3261.
> 
> Unlike an INVITE, which can fork, a re-INVITE 
> will never fork, and
> therefore, only ever generate a single final 
> response. The reason a
> re-INVITE will never fork is that the 
> Request-URI identifies the
> target as the UA instance it established the 
> dialog with, rather than
> identifying an address-of-record for the user.
> ****

I agree; the text does not appear to be true.

> Regards
> - Ajay
> 
> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]] 
> Sent: Thursday, June 26, 2003 2:27 PM
> To: [email-masked]
> Subject: RE: [Sip] Simple question about NOTIFY
> 
> > As I am reading through the two RFCs 3261, 
> > and 3265, I am just wondering if a 
> > SIP NOTIFY can be forked? 
> 
> Yes a NOTIFY can be forked.
> 
> > Also if it can be forked, can someone please 
> > explain how will that work, since NOTIFY 
> > would be sent in a dialog, and according to 
> > the rules set in section 12 of RFC 3261, 
> > the Request-URI would need to be set to the 
> > remote target (which is the contact address 
> > of the subscriber), and a Proxy is just 
> > supposed to forward to that target.
> 
> Requests can fork within a dialog during
> fault-tolerant/redundancy situations where
> a device's added Contact or Record-Route entry
> resolves to multiple address.  ICMP errors
> or retry exhaustion can trigger the target
> advancing.
> 
> The NOTIFY can also fork outside of dialog
> when the "subscription" was not established
> through the typical SIP mechanisms.  RFC 3265 
> section 3.2 discusses subscriptions created 
> by not using a SUBSCRIBE.
> 
> 
> _______________________________________________
> 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: Idnani Ajaykumar-AIDNANI1 <[email-masked]>
Date: Thu, 26 Jun 2003 14:59:47 -0500

If a NOTIFY can fork, then it should be possible to fork a re-INVITE also. Should not it? Assuming the same reasoning as you provided for NOTIFY in a dialog. In which case the following text in RFC 3261 is not really true. 

****

Unlike an INVITE, which can fork, a re-INVITE will never fork, and
therefore, only ever generate a single final response. The reason a
re-INVITE will never fork is that the Request-URI identifies the
target as the UA instance it established the dialog with, rather than
identifying an address-of-record for the user.
****

Regards
- Ajay