Hi James,
>
>- added a Geolocation header parameter "recipient=" to indication which SIP
>entity type a particular locationValue is intended for.
>
> OPEN ISSUE here: what does a Location Recipient
> do if more than one locationValue point to it? (i.e.,
> the case in which the UAS receives 2 locations
> and both state "recipient=endpoint")
First a couple of nits, then a question on the open issue.
Section 3.2 says:
the "recipient=" to allow recipients to infer what SIP element
type this locationValue was intended to be for. The types are
"endpoint", meaning the ultimate destination UAS;
"routing-entity", meaning SIP servers; and "both" meaning this
locationValue is to be viewed by both types of SIP entities.
The example in 4.2, though, has "recipient=server". That should
get shifted to "routing-entity", if I understand things correctly.
The document also points to 3261 for Absolute URI, which appears to
derive that from RFC 2396, Section 5. Would it be a problem to update
that to RFC 3986, Section 4.3, since 3986 is now a full standard?
So, the open issue you raise is what a routing-entity or endpoint
does when it receives multiple locationValues for which it is the
recipient. For the endpoint, I believe that the answer is
application specific. For some uses, the most recently added may
get used; for others, the first added; for others, all of them
may get evaluated and some other application-specific judgement call
made (an application might prefer the most precise, a specific
address type, or something else). I think, though, that this
document can stay silent about the endpoint's selection beyond the error
code text describing 424.
For the routing-entity, though, I think that silence is probably
not workable. I would personally say that a routing-entity receiving
multiple locationValues should always use the most recently
added unless that location would generate a 424; in that case, it
can examine the previously asserted locations in reverse order of
addition until it finds one that is valid or generates the 424.
Would that make sense to you?
regards,
Ted
_______________________________________________
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
