On Sun, 2009-05-31 at 12:01 +0200, Alberto wrote: > Hi, > tested XX-5623 in 4.0.1-015694 with Internet calling not enabled. > I could perfectly complete a call to "[email protected]" both using > a Snom 320 and a Cisco 7960. > Again I could complete the call from both phone simply pressing redial > from my missed call list, where the missed call came from the outside > via sipxbridge. > > 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. > 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? > 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. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
