El Martes, 21 de Abril de 2009, Brett Tate escribió: > My specific questions are how to interpret the following upon receipt of > SUBSCRIBE at example.com (notifier) where user1, group1, and known-user are > known and unknown-user is unknown at example.com. > > 1) To: [email protected] and request-uri is example.com? > > 2) To: example.com and request-uri is [email protected]? > > 3) To: [email protected] and request-uri is [email protected]? > > 4) To: [email protected] and request-uri is [email protected]? > > 5) To: [email protected] and request-uri is [email protected]? > > 6) To: [email protected] and request-uri is [email protected]?
This is really annoying for me and I would simplify it a lot: IMHO, even if this RFC talks about To uri (not too much in fact), the SUBSCRIBE must be created according to the same rules of INVITE, MESSAGE..., this is, the UAC creating the request must copy the RURI into the To header. Period. Said that, if a server receives a message-summary SUBSCRIBE with RURI being different from To, it could reject/drop it, or it could ignore the To uri. But the important uri is the RURI. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
