From: "Rosen, Brian" <[EMAIL PROTECTED]> An issue raised by reviewers for location-conveyance was how it works if the UAS tries to send its location to the UAC. There are several things that are problematic with this, including errors: the UAC can't tell the UAS about an error it finds in the location.
Ouch. That could be quite a problem. We propose to resolve this by specifying that location-conveyance sends the location of the UAC. The header can appear in a message from the UAS to the UAC, but it means that the UAS is looping back the location of the UAC. The other end can send its location with an UPDATE or ReINVITE, turning around the connection (i.e. becoming the UAC). This does seem to be the correct solution. I suppose you could even extend this mechanism to include sending an OPTIONS with a location-conveyance header. The loopback procedure is useful when proxies insert location. The UAC may not even be aware that it happened, and yet it gets an error or a result it doesn't understand. If the UAS echo's what it gets, the UAC can see it. Good point. From: Paul Kyzivat <[EMAIL PROTECTED]> Something that bears further discussion: is an intermediate node permitted to drop the location from a response? I think there are competing interests here - some intermediate nodes may want to drop it, while the UAC would prefer to have it retained. It seems best to require the intermediate node to retain the location-conveyance. At least, unless there is no error or warning referring to it. But assuming that locations aren't added to messages frivolously, why would intermediate nodes want to drop it? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
