23:38 < DocScrutinizer> Robot101: there's a problem with telepathy-sofiaSIP, contacts, and dialer. I got an account at sipgate.de, a german SIP provider. It has an associated landline number. Inbound call from e.g landline "+49 911 123456" are signalled and logged as origin:"SIP:0911123456@sipgate.de". This doesn't match to any contact that has tel:"0911123456" nor to "+49911123456". My question: is there a concept in telepathy to deal with this? 23:40 < Robot101> alas no, the address book code in the N900 has special-cases for doing suffix lookups on incoming PSTN calls, but the same isn't true of SIP URIs 23:40 < Robot101> it would need to have some heuristic to decompose them to pull out a telephone number 23:40 < Robot101> but it's always going to be a kinda lame hack 23:55 < DocScrutinizer> well, in twinklephone there's an option to check for "...;call=tel" parameter and in that case discard the domain part and display the user part as a plain simple phonenumber. Service "tel:" in any SIP addr should get handled same way. But yeah, basically I agree there has to be heuristics to deal with that, as there seems to be no consistent standard how carriers handle signalling of inbound calls via PSTN gateway 23:56 < Robot101> aha, call=tel sounds useful 23:56 < Robot101> want to send a wishlist bug to telepathy-rakia and say "expose tel: and ;call=tel numbers through a different namespace so that UIs can apply PSTN heuristics"? (... he didn't ... :D)
There's a general feeling that the Telepathy spec should have some way to (optionally) distinguish certain contact handles/identifiers as belonging to another namespace. This would be a perfect usecase for such functionality, as well as the MSN <-> Yahoo bridge, maybe XMPP transports, and other gateways.
(In reply to comment #1) > There's a general feeling that the Telepathy spec should have some way to > (optionally) distinguish certain contact handles/identifiers as belonging to > another namespace. This would be a perfect usecase for such functionality, as > well as the MSN <-> Yahoo bridge, maybe XMPP transports, and other gateways. You mean like Addressing is supposed to do it? :)
(In reply to comment #0) > 23:38 < DocScrutinizer> Robot101: there's a problem with telepathy-sofiaSIP, > contacts, and dialer. I got an account at sipgate.de, a german SIP provider. It > has an associated landline number. Inbound call from e.g landline "+49 911 > 123456" are signalled and logged as origin:"SIP:0911123456@sipgate.de". If this is how it looks in SIP messages, there is no way to tell it is actually a phone number. Heuristics are prone to guessing wrong and getting into bigger problems for unsuspecting users (faking a PSTN caller with a simply set up SIP proxy, anyone?).
(In reply to comment #3) > (In reply to comment #0) > > 23:38 < DocScrutinizer> Robot101: there's a problem with telepathy-sofiaSIP, > > contacts, and dialer. I got an account at sipgate.de, a german SIP provider. It > > has an associated landline number. Inbound call from e.g landline "+49 911 > > 123456" are signalled and logged as origin:"SIP:0911123456@sipgate.de". > > If this is how it looks in SIP messages, there is no way to tell it is actually > a phone number. This is how it looks when Maemo displays the info it gets from sofiaSIP. The real SIP INVITE definitely has better details. Please also note my odd worded comment about call=tell that AIUI actually should read ";user=phone" (http://de.wikipedia.org/wiki/Session_Initiation_Protocol). However take this with a grain of salt, as I never seen a provider supporting it yet, and I'm not sure it's even supposed to be used that way. > Heuristics are prone to guessing wrong given the fact most SIP providers don't even allow inbound direct SIP via IP, there's not much more guessing involved than just looking for a settings flag set for that particular SIP account that tells sofiaSIP about the properties of this account. > and getting into bigger > problems for unsuspecting users (faking a PSTN caller with a simply set up SIP > proxy, anyone?). For all I know it's not THAT easy to fake an inbound INVITE. Actually I'd think a properly implemented SIP stack should ignore such faked INVITE msgs (not to mention you'll have a hard time to get *any* fake thru a NAT, but that's unrelated and irrelevant here)
http://tools.ietf.org/html/rfc3261#section-19.1.6 might help
(In reply to comment #4) > The real SIP INVITE definitely has better details. Please also note my odd > worded comment about call=tell that AIUI actually should read ";user=phone" Yes, that would be a good clue. Besides, Telepathy-Rakia does not hide URI parameters, so if you do not see this in the contact ID, it was not in the INVITE. The display alias attribute (from Aliasing) omits the URI parameters for readability. > For all I know it's not THAT easy to fake an inbound INVITE. I mean sending an invite with a From header of your choice. Standard SIP has no ways of verifying senders' identity. In fact, in many network configurations anyone can send a request directly to our UA stack's listening socket. But all told, there could be an option to interpret "phone-like" user names in SIP URIs of the same domain as the account owner's; presumably SIP services use authentication to verify senders claiming to be from their domain. We could use Addressing to offer tel: interpretation of such URIs.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-rakia/issues/18.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.