On Mon, 2009-06-01 at 23:12 +0200, Alberto wrote:
> Scott Lawrence ha scritto:
> > On Sun, 2009-05-31 at 12:01 +0200, Alberto wrote:
> >
> > > The issue is resolved when I'm calling "[email protected]". The only
> > > exception I had is placing such call with Bria Pro 2.5. I receive a 407
> > > Proxy Authentication Required. I suspect this to be a Bria issue. What
> > > do you think? Should I open a new issue for further investigation?
> > >
> >
> > Is the 407 coming from sipXproxy? The phone should have the credentials
> > to respond to that challenge... it's certainly not the same issue.
> >
> >
> I will open a JIRA issue attaching a snapshot.
> > > After a deeper testing with my ITSP I found another range of call
> > > failing when pressing the redial. IP to IP incoming calls are recorded
> > > as "[email protected]" and they now work fine. PSTN to IP calls are
> > > recorded as "num...@ipaddress" where ipAddress is a ITSP host, I guess
> > > one of their PSTN gateway. Again should I open an issue?
> > >
> >
> > There's not going to be much we can reasonably do about that one in the
> > short term. Is the ITSP not consistent in how they send calls?
> >
> >
> It does not seems consistent. I'll make further investigations.
> > > Last thought: when recalling "[email protected]" we re-route a call
> > > to the originator ITSP account. If just the "number" part match some
> > > dial rule are we following that rule or simply routing it back the way
> > > it came? Suppose I'd like to route calls matching my dial plan (Simple
> > > example "number" of "[email protected]" is a mobile and I want to
> > > use a pstn gateway where I get better rates) would not be simple to have
> > > a configurable switch manipulating the incoming From URI like
> > > "[email protected]" and "num...@ipaddress" to simply "number"
> > > striping the "@.." part?
> > >
> >
> > That's not really a legal thing to do. The userpart (left of the '@')
> > in a SIP URI can only be interpreted at the domain on the right hand
> > side. Just because it 'looks like' a phone number doesn't mean that it
> > is, or that the number would work in the same way from somewhere else.
> >
> > In theory, a 'tel' scheme URL wouldn't have this problem, but at present
> > sipXecs doesn't support it.
> >
> I absolutely don't know what is a 'tel' scheme URL is. Basically I
> expect a SIP trunk to behave like any other gateway.
> Since today I felt it's perfectly possible to call back someone that
> called from the ISDN gateway through a for example a GSM gateway to
> archive better rates. Other thing I felt is sipXecs dial plan does it
> all. With sip trunks I feel I'm loosing this power if "number" with a
> "@" will take privileged or no routes.
> Again most "hard" gateway provide some form of number manipulation.
> Why a sip trunk should not have such a feature?
> I perfectly understand this is not legal, in fact I don't expect this
> to happen for all Sip trunks. Some sort of number manipulation should
> be a configurable option when it is appropriate for the ITSP
> configured in the trunk. For my ITSP it's always appropriate. I own a
> couple of cheap sip phones ... they're all capable of calling back all
> incoming number when registered directly to my ITSP. There must be
> something that could be done.
This is a subtle point - if the phone received a call from n...@itsp
(where 'NNNN' is a number), and then the user tries to call that back,
there are two ways the phone _could_ generate that call:
* It could just dial 'NNNN' as a dial string and send it to your
pbx.
If it did things that way, then we can manipulate the dial
string and use your dial plans to optimize routing.
* It could just send the sip address 'n...@itsp' back to the pbx
If the phone does this, then the pbx really can't be sure that
the number is really a PSTN number.
There are some hints available in addresses that we could exploit but
don't yet - unfortunately those hints are not always reliable.
> Last missing piece in a Sip Trunk, I'm a bit off topic I know but just
> cause I'm talking about trunks... , is a very basic QoS mechanism. A
> physical gateway will be limited to the number of channel. When they
> are all busy it will cause the next call to fall somewhere else or
> fail. Our sip trunk is always doing that? If my ITSP allows a max
> fixed number of calls and this number is larger than the capacity of
> my WAN we are in trouble. If my ITSP does not have max call limit, I'm
> sure they will charge a poor quality call like a good one, will the
> trunk eat up all calls without falling back in other gateway?
We do have an issue open for that:
http://track.sipfoundry.org/browse/XX-5871
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
