close
ENUM and Skype
Rao Aswath is raising an interesting point regarding my post on +43780 ENUM-based number range."I am curious to know Skype’s reaction regarding the URI requirement. I suppose Skype can allocate a SIP URI and then map it to Skype address. But then this scheme allows for easy porting from one service provider to another; probably the anticipated Skype “lock-in” is not so assured."
Rao is as usual on the point and we already thought about this. The solution he proposes is of course valid and workable, if Skype decides to provide SIP-URIs and SIP-Skype Gateways. But has basically nothing to do with ENUM, beside the fact that you may use these SIP-URIs e.g. sip:skypename@skype.com in ENUM. But the implementation is up to Niklas or eventually third parties providing such gateways. For a full sulution (to call back) one may also need to query ENUM from Skype and set-up calls to SIP users.
But ENUM is not providing interworking (it does also not solve the problem of interworking between H.323 and SIP. The basic requirements for Skype to be used in ENUM is to have a URI for Skype and an appropriate "enumservice".
Now the first half of this is already there: Skype "hi-jacked" the callto: URI from Microsoft to be used with the SkypeMe button. If one installes Skype on Windows or Mac, the callto: URI gets registered and if you click a SkypeMe button, Sykpe launches with callto://skypename.
So there IS a URI to be used in ENUM, all what is needed in addition is an "enumservice". I have no idea what the reaction of the IETFwould be if I propose skype:callto to be registered with IANA, but there is a way-out: if one reads RFC3761 very carefully, he may detect in section 2.4.2.1 ENUM Services the following statement:
The only exception to the registration rule is for Types and Subtypes used for experimental purposes, and those are to start with the faces"X-". These elements are unregistered, experimental, and should be used only with the active agreement of the parties exchanging them.
And in Section 3.1.2 Naming requirement:
An Enumservice MUST be unique in order to be useful as a selectioncriteria. Since an Enumservice is made up of a type and a type-dependent subtype, it is sufficient to require that the 'type' itself be unique. The 'type' MUST be unique, conform to the ABNF specified in Section 2.4.2, and MUST NOT start with the facet "X-" which is reserved for experimental, private use.
So we propose to use the experimental Enumservice x-skype:callto, e.g.
IN NAPTR 100 100 "u" "E2U+x-skype:callto" "!^.*$!callto://detlev!" .
This solution would at least allow all ENUM clients running on the end-users device to use this feature. Ideal for a first implementation would be an ENUM client running on top of the Pulver Communicator:
If you enter an E.164 number, the Communicator is querying ENUM and either setting up a call via SIP or via Skype, depending in the result of the query. If no entry is found, it may use SkypeOut or LibreTel, depending on configuation. An add-on on Skype directly may work at least for all x-skype enumservices.
But what about the ENUM queries via SIP-servers or via the +43 780 gateways? Here we are back to the proposal from Rao: if a SIP-Skype gateway exists, this could be used.
The decision on this is up to Skype: do they want to sell only their SkypeIn numbers or do they want in addition +43 780 users to point to their Skypenames, getting in more users with this functionality?
So I am also curious on Skype's reaction ;-)
http://voipandenum.blogspot.com/2005/04/enum-and-skype.html
全站熱搜
留言列表