Hello, I noticed that the draft for explicit REFER subscriptions was mentioned on the list a couple of weeks ago. As someone who has implemented REFER relatively recently, I thought I could share some thoughts on the topic.
The draft lists avoiding dialog reuse for SUBSCRIBE while reusing the dialog for REFER as the main motivation behind explicit subscriptions, followed by enabling the negotiation of the duration and other parameters of the subscription, and the use of Supported and Required header fields. In my experience, dialog reuse is hardly the biggest issue with REFER. Sending the REFER outside of a dialog does not make all of the problems associated with dialog reuse to go away (so, my REFER with Target-Dialog got an error response, what to do with the INVITE dialog?), and RFC 5057 provides good guidance on this topic. If anything, dialog reuse must be supported by the UAC for interoperability purposes, given how many UAs do not support Target-Dialog and GRUU. As for negotiation of the duration, I am tempted to say that the vast majority of cases will fall into one of the two categories - either the sender does not want to create the subscription at all, or the subscription can be arbitrarily long, and will be terminated when the user gives up waiting for the final response. The negotiation of the duration generally *is* an issue, but that is because the sender of REFER has no way of knowing how long it will take for the UAS to process the request, and access the referred resource. In this aspect, REFER is much closer to an INVITE than a SUBSCRIBE request, and the proposal for explicit subscriptions does not address it. As a side note, why can't the relevant header fields be included in the REFER request itself? From the implementation perspective, there is nothing that would forbid user agents from processing the REFER as if it was a sort of SUBSCRIBE request. In my opinion, the main issue with REFER (and SUBSCRIBE, too, to some extent) is assigning multiple semantics to one request - NOTIFY. There is a multitude of ways a REFER can possibly fail: 1) The REFER is rejected immediately by sending an error response; 2) The request itself is accepted, but the reference is eventually rejected, eg. due to not being authorized; 3) The subscription is pending, but times out before authorization could be obtained; 4) Authorization is granted, but the subscription times out before the resource can be accessed; 5) The recipient of the REFER failed to access the resource; 6) The recipient is willing to access the referred resource, but does not want to create a subscription. Except for the first one, all others must be conveyed by a NOTIFY request with a message/sipfrag body. Different reason codes in the Subscription-State header could be used to distinguish between 2), 3) and 4), but in practice many user agents seem to interpret Section 2.4.7 of RFC 3515 literally - noresource and nothing else. The NOTIFY body itself is also a mess to deal with. For the most common case - REFER to another SIP address - dialog state event package is a better fit. The message/sipfrag type could be used to deliver the actual response to REFER, but that would require two event types in the same subscription. An explicit SUBSCRIBE does not change anything about this. It may seem that it addresses the point 6) above, but that does not take into account the processing of the REFER itself, ie. points 2) and 3), which in my opinion are especially important for out-of-call references that do not have an existing dialog associated with them. What could be useful, however, is creating two subscriptions for each REFER, an implicit one for the request itself, and an explicit one for status of the reference. The final NOTIFY of the first one could be used to provide an URI for the second, explicit subscription. Whether the same dialog is reused for all requests or not is orthogonal to that. Lastly, and on a completely unrelated note, the requirement to use the Require header for explicitsub, as opposed to Supported, and the prescribed use of 421 response code seems to be unnecessary, and at odds with RFC 3261, which states that "A UAS SHOULD NOT use [the 421 Extension Required] response unless it truly cannot provide any useful service to the client." I believe the same reasoning applies to the use of Require headers in requests sent by UAC. Besides that, the 421 response code is supposed to be used when the UAC has not listed the required extension in the Supported header, not when it has. These are my 2 cents. Thank you for your attention, and sorry about the wall of text. Best, Jānis _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
