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?
You can/should route it the same way you would route an INVITE to the
same address.
> 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?
Well, in that case it isn't going to work.
Depending on the event you are subscribing to, perhaps the GW can handle
it for you in a useful way, and perhaps not.
But there are other cases where it can work. For instance, perhaps both
PA and PB do ENUM on the number and find a translation to a sip URI. In
that case subscribe can work as well as INVITE.
Thanks,
Paul
> 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.
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
