See comments in-line
At 11:13 PM 4/1/2007, [EMAIL PROTECTED] 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:[email protected]>; inserted-by=endpoint,
<sips:[EMAIL PROTECTED]>;
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: [EMAIL PROTECTED]> 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\)" <[EMAIL PROTECTED]>
03/05/2007 01:05 AM
To
<[email protected]>
cc
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
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
+44 1793 776249
[EMAIL PROTECTED]
_______________________________________________
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
*********************** 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
