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.
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?
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
