Bug 35437

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.