< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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