In that case we will try to extend PIDF-LO and add a cell-id tag under <location-info>.
Best wishes, Bartek -----Original Message----- From: Brian Rosen [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2008 7:04 PM To: Bartłomiej Kołakowski; [EMAIL PROTECTED]; [email protected] Subject: RE: draft-ietf-sip-location-conveyance - Question about potential usage of the Geolocation header There is no standard to include a cell-id in a PIDF-LO. It has been discussed 2-3 times and the consensus was that it's a bad idea. Brian > -----Original Message----- > From: Bartłomiej Kołakowski [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 28, 2008 10:32 AM > To: Brian Rosen; [EMAIL PROTECTED]; > [email protected] > Subject: RE: draft-ietf-sip-location-conveyance - Question about > potential usage of the Geolocation header > > Thanks for reply Brian. > Probably we'll go for the SUBSCRIBE/NOTIFY option. We'd rather keep > cell ids inside our network, but anyway it's not really possible (see > Google's My Location). So far we won't have any 3rd parties connected > to IMS though. > > Do you know if there is any standard to include a cell-id into PIDF-LO? > > Bartek > > > -----Original Message----- > From: Brian Rosen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 13, 2008 10:24 PM > To: Bartłomiej Kołakowski; draft-ietf-sip-location- > [EMAIL PROTECTED]; [email protected] > Subject: RE: draft-ietf-sip-location-conveyance - Question about > potential usage of the Geolocation header > > You can use the "HELD" protocol, rather than a SIP SUBSCRIBE/NOTIFY > for the dereference, if that makes it seem simpler to you. > SUBSCRIBE/NOTIFY is quite simple, and most devices and services > implement it for other reasons. > > We have discussed using cell-id as a representation mechanism, but > have been told, many times, that operators will not divulge location > of cell ids beyond the immediate network, which makes this form of > location entirely > unsuitable for the range of applications we envisioned. If you have > different information, please share it. > > On the other hand, even if we did allow cell id as a form of location, > it would be inside a PIDF-LO, and thus would need to be in a body. > > I don't think putting actual location in the header is a good idea, as > it cannot be protected against inadvertent disclosure. That would be > a problem in the IETF. > > Brian > ________________________________________ > From: Bartłomiej Kołakowski [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 13, 2008 10:04 AM > To: [EMAIL PROTECTED]; [email protected] > Subject: draft-ietf-sip-location-conveyance - Question about potential > usage of the Geolocation header > > Hello, > I have got such concern regarding location conveyance in SIP messages: > I am designing IMS Appilcation Server, acting as a proxy, that would > query network elements for location information. As you wrote proxies > cannot insert message body, so the only way is to provide location by > reference. > This requires appling SUBSCRIBE-NOTIFY mechanism, which makes the > architecture of the solution quit complex. > In order to make it simpler I thought about including location > information as locationValue inside the Geolocation header. In fact we > do not need location represented with coordinates, but with cell-id > (that's mobile network). PIDF-LO does not support it, but maybe inside > a header that would be possible? There would be also an issue in > indicating loaction target whose location is included (we plan to > include both A and B parties location). Geolocation header would look like > this: > Geolocation: {cell-id-3gpp} > ;location-target="[EMAIL PROTECTED]";inserted-by="[EMAIL PROTECTED]" > What do you think about souch a usage of Geolocation header, maybe you > could give us some other solution? > Thank you in advance, > Bartłomiej Kołakowski > Service Solutions Architect > Service Development Support Department Polkomtel S.A tel. 601131509 _______________________________________________ Sip mailing list https://www.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
