David Cunningham <dcunning...@voisonics.com> writes: > I must say RFC 6665 4.4.1 does seem to make it clear that the route set in > the NOTIFY should be used, and therefore it's incorrect that the > re-SUBSCRIBE sends directly to the Contact address rather than using the > Record-Routes in the NOTIFY. It's very helpful to have this knowledge as a > reference!
But don't overlook the 2nd paragraph of section 4.3: Proxies that did not add a "Record-Route" header field to the initial SUBSCRIBE request MUST NOT add a "Record-Route" header field to any of the associated NOTIFY requests. My vague memory is that while the passage of the first NOTIFY request of a subscription creates the subscription usage, the intermediate proxies are required to insert Record-Routes into it in exactly the same way they inserted Record-Routes into the SUBSCRIBE. In particular, when the subscriber receives a 2xx response, it can act as if that subscription usage has been created and be assured that it will handle the dialog correctly. Further NOTIFYs that it receives create other subscription usages based on their contents. If I understand your example correctly, it was taken at the subscriber. I see that the 200 response to the SUBSCRIBE contains no Record-Route headers, so none of the proxies in the path have chosen to insert themselves into dialog. However, the first NOTIFY contains two Record-Route headers, which violate section 4.3. It appears the subscriber has refreshed its remote target based on the Contact header of the NOTIFY, which it is required to do. But it has not recorded the Record-Route headers from the NOTIFY, which should not be there. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
