Re: [Sip] WGLC on draft-ietf-sip-location-conveyance

["James M. Polk" <[e-mail]>]

See comments in-line

At 11:13 PM 4/1/2007, [e-mail] wrote:

>Some comments/questions on the draft.
>
>
>1) Multiple Locations:
>- Section 5.3.1
>A server/proxy can add gelocation value to the existing geolocation
>header provided by UAC. In that case the messsage would look like this:
>
>Geolocation: <cid:[e-mail]>; inserted-by=endpoint,
>                     <sips:[e-mail]>;
>                     inserted-by=server;
>
>=>How the location recipient will decide which location is to
>be referred to? Either the one provided in the Sip message (CID URI)
>or he has to subscribe to the location provided in SIPS URI?

This is a local policy decision - when there is more than one 
location (either by-value or by-reference or one or more of both) in 
a SIP message.  This is the complication of allowing more than one 
location in a SIP message.


>2) Location by reference overhead:
>Look at the following scenario (P - is also a location recipient):
>
>              LIS                                     LIS
>             ^  |                                      ^  |
>SUBSCRIBE |  | NOTIFY          SUBSCRIBE |  |NOTIFY
>             |  |                                 |  |
>UA ------->  P1 ------------------>  P2  ----------->
>    INIVITE           INVITE                   INVITE
>
>In order to take action based on "retransmission-allowed" or not,
>P1 has to subscribe to the LIS (Location Information Server),
>obtain the location and then take the action. The same has to be
>done by all the intermediate proxies. So is this not a overhead?

this is location conveyed indirectly.  If location is not *in* the 
message, it MAY have to be retrieved from an external source.

We have concluded that LbyR (Location-by-Reference) does not violate 
the retransmission flag in an LbyR dereference.

BTW - both P1 and P2 will likely SUB/NOT to the same LIS for the same 
location-by-reference.


>3) "retransmission-allowed"
>Even if "retransmission-allowed" value is set to "no", can the
>proxy remove the PIDF location object from the message?

no, per 3261 (as you state)

>RFC 3261
>does not allow any proxy to add or delete the message body. So what
>is the use of "retransmission-allowed" with value "yes" or "no"?

I believe this is discussing whether or not the proxy can copy the 
location and send it somewhere else (i.e. not in this transaction).


>4) What is the behavior in following case:
>
>Retransmission-allowed Routing-query-allowed Transmission for Query
>---------------------- --------------------- ----------------------
>         "no"                  not present           ?????

Transmission for Query is "not allowed"



>5) "message-routed-on-this-uri" tells the downstream entity that
>is was routed based on location once. In section  5.3.1 it is
>mentioned that in case multiple times if routing is done based on
>location still only one latest entry of "message-routed-on-this-uri"
>is sufficient.

This will be corrected to keep the "message-routed-on-this-uri" for 
each location URI the message was routed on, in times where more than 
one proxy routed the message from different URIs (locations in the message).


>Why downstrem entity need to know that only one routing has
>happened (if at all it needs to know)?

The goal of this is to give routing information to the PSAP for their 
consumption, and after the call forensics (if the call was misrouted 
or something went wrong). PSAPs want to have the ability to go to 
where the problem was and request a correction so it doesn't happen again.

>Why it need not find out
>multiple location based routing was done?

again, this will be corrected. And, hopefully, if there is routing 
done more than once, any subsequent routing would correct any error done.


>6) Section 3.2: Use of the header in BYE, INFO and REFER
>Methods are allowed, although no purpose is known.  Conveying
>location in a CANCEL, BYE, ACK or PRACK is not defined.
>
>Conveying location in "BYE" is defined or not?

this is an error, and Location is should not be in a BYE (unless 
someone has a use case indicating a reason for it to be?)


>7) <sips: [e-mail]> or <sips:server.com/username>
>are these same? Is the second form a valid SIP URI?

I believe so. My co-author put this in.  Because you're questioning 
this, we will check.  Thanks!



>8) Why only PIDF format is selected.

because the IETF and the emergency services community (to date) has 
requested the least amount of errors possible, and limiting Location 
to be only in one format (which the IETF is pushing into IEEE, ATIS, 
TIA and other SDOs) means there is hopefully no information lost in 
any translation when converting location formats.

>
>9) Assume the case that UAC has sent his identity in the first INVITE.

this is likely

>Callee would have subscribed to that identity and would get the
>caller's location.

right now, one UA(1) Subscribing to another UA(2) for UA2's location 
is a pull mechanism and is not defined in this document.  That's 
being left for a future ID.

>Now if caller's identity is changed and caller
>sent a new RE-INVITE message. Should callee then stop subscription
>with first location and should subscribe to the new location?
>There is no behaviour with respect to this is mentioned in UAS scope?

correct, see just above to read that this is out-of-scope for the 
Location Conveyance ID.

Thanks for the detailed review, and sorry for the late response.



>regards
>Rishu
>
>
>
>
>
>"Drage, Keith \(Keith\)" <[e-mail]>
>
>03/05/2007 01:05 AM
>To
><[e-mail]>
>cc
>[e-mail], [e-mail], [e-mail]
>Subject
>[Sip] WGLC on draft-ietf-sip-location-conveyance
>
>
>
>
>(As WG chair)
>
>This is to announce a working group last call of
>
>http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-07.txt
>
>Due to the presence of IETF#68 in Prague, this is an extended last 
>call (for four weeks), and comments should be provided by start of 
>business on Monday 2nd April 2007.
>
>However if you think there are significant technical issues that 
>should be raised in IETF#68, please review the document well before 
>that time to make your comment to the list, so that such discussion 
>in the IETF meeting can occur.
>
>Please provide all comments to the SIP mailing list, and also to the 
>document authors listed (and mailing addresses) listed at the end of 
>the document. For each comment, it is ideal to provide the copy the 
>specific part of the text the comment is against, in order to 
>provide context of the comment, as well as identifying the 
>section/page and the comment itself.
>
>Please also clearly indicate whether the comment is 
>editorial/technical, and if technical the degree of the comment, 
>e.g. minor, major flaw, wrong solution, or whatever. This helps in 
>assessing the order in which comments get addressed when they are reviewed.
>
>In parallel with WGLC, a review team has also been set up to review 
>the document, and this review team will review at least the 
>significant comments for implementation. I will be addressing them 
>in a separate mail.
>
>As the document is a location supporting protocol, the document will 
>also be reviewed by the GEOPRIV group. However it is appropriate for 
>all readers to review the document against the GEOPRIV requirements 
>for such protocols, which may be found in RFC 3963.
>
>The above document however does not cover location by reference. 
>There is a preliminary set or requirements in
>
>http://www.ietf.org/internet-drafts/draft-marshall-geopriv-lbyr-requirements-00.txt
>
>For which we would like to align with whatever that document 
>develops into. Therefore it is appropriate to review against this 
>document, and identify differences. These could either be taken as 
>comments against the draft-ietf-sip-location-conveyance, or against 
>the location by reference requirements.
>
>
>Regards
>
>Keith
>
>Keith Drage
>[phone]
>[e-mail]
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [e-mail] for questions on current sip
>Use [e-mail] for new developments on the application of sip
>
>
>***********************  Aricent-Unclassified   ***********************
>
>"DISCLAIMER: This message is proprietary to Aricent and is intended 
>solely for the use of
>the individual to whom it is addressed. It may contain privileged or 
>confidential information and should not be
>circulated or used for any purpose other than for what it is 
>intended. If you have received this message in error,
>please notify the originator immediately. If you are not the 
>intended recipient, you are notified that you are strictly
>prohibited from using, copying, altering, or disclosing the contents 
>of this message. Aricent accepts no responsibility for
>loss or damage arising from the use of the information transmitted 
>by this email including damage from virus."
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [e-mail] for questions on current sip
>Use [e-mail] for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip