Re: [reSIProcate] enum support in resip
On Wednesday 07 September 2005 03:11, Jason Fischl wrote:
> On 9/6/05, Jason Fischl <jason@xxxxxxxxxxx> wrote:
> > On 8/31/05, Jason Fischl <jason@xxxxxxxxxxx> wrote:
> > > I think what you are suggesting is what I meant. For example, the
> > > following examples would do an enum lookup in the e164.org suffix.
> > >
> > > tel:+14155551212;enumSuffix=e164.org
> > > sip:+14155551212@xxxxxxxxxxx;user=phone;enumSuffix=e164.org
Yes, I meant the same.
> > What is it that determines that an enum lookup should be done on a
> > target URI? For now, is it safe to assume that an enum lookup should
> > be done if the first character of the user portion of the URI is '+'?
> >
> > We could additionally only do enum lookups if user=phone or for tel
> > uris. Opinions?
Snom phones do enum lookups if the user=phone is present in the URI. But from
a stack perspective I think this should be highly configurable. I could
imagine two options:
- do enum lookups on leading +: on/off
- do enum lookups on user=phone: on/off
and if the enumSuffix is present it should be obvious to try a lookup.
> If the target URI is sips but the enum lookup produces a sip URI what
> should the application do? Should it continue to use sips or assume
> that the enum lookup failed?
It fails to same question, if you should switch to a sip URI if sips was
requested. I think the answer is no, because someone/somethink requested
secure signaling which isn't present then any more. Thus the enum lookup
should fail IMHO.
Although this leads to a funny question: is PSTN signaling secure? Or more
secure then a sip connection (compared to a sips connection)?
Because if the enum lookup fails (sips!=sip) the call gets probably routed to
a gateway then. Assume the signaling is secure up to the gateway it gets
converted into a (un-) secure PSTN call.... it gets even more funny if this
call wants to use SRTP... assuming no gateway can establish encrypted calls
on the PSTN side shouldn't be completed then.
Nils