I would not send a subscribe for tel+ URI, this would open pandora's box with a multitude of possibilities that end in the same wrong place every time.
Keep SIP simple. In you case the best way is to perform an ENUM lookup before subscribing, resolve the number into a SIP URI and subscribe to that one. The later you translate the tel URI into a SIP URI the more complicated (read close to impossible) becomes for each intermediate SIP device to take the correct routing decision. Adrian On Oct 24, 2008, at 6:21 PM, Iñaki Baz Castillo wrote: > El Viernes, 24 de Octubre de 2008, Vikram Chhibber escribió: >> I think we are digressing from the original query. The question is >> not >> about routing of tel url. The query is why the public identities in >> From and To header can not be tel for SUBSCRIBE. A better explanation >> only the RFC authors can provide. > > The question is: > > When I send a SUBSCRIBE to sip:[EMAIL PROTECTED], I send it to the proxy > responsible for domain.org (even if I use an outbound proxy). > > But if I send a SUBSCRIBE to tel:+12345678, I just can send it to a > configured > outbound proxy (or doing ENUM in the UA), but who is the responsible > for a > tel URI? > > For example: > > - Two users [EMAIL PROTECTED] and [EMAIL PROTECTED] using two > different > outbound proxies PA and PB. > > - When alice calls "tel:+12345678" the request arrives to PA and it > decides to > forward it to a PSTN carrier CA. > > - When bob calls "tel:+12345678" the request arrives to PB and it > decides to > forward it to a PSTN carrier CB. > > - There are not relationship between PA, PB, CA and CB, so how could > alice > subscribe to dialog status for +12345678 PSTN number and receive > notification > when bob, using a different proxy/carrier, dials that number? > > This is, there should be just a host/proxy responsible for > domain.org, but any > proxy/gateway can make itself "responsible" for a TEL uri, so... > > With this, I think it doesn't make sense to subscribe to a TEL uri > in an > *open* environment, but it could be useful for clients using the same > proxies. > > > -- > Iñaki Baz Castillo > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
