I can see several reasons for it. One is we use billing codes which we are
embedding in the URI and handling in the proxy (dial
97,1234567890,1-212-555-1212). No reason for ITSPs to see that. I guess
it's SBC-lite:)
/a
...... Original Message .......
On Wed, 29 Nov 2006 19:15:10 -0500 (EST) "Mahesh Paolini-Subramanya"
<mahesh(a)corp.aptela.com> wrote:
Good to know!
Strangely enuff, I got the same response from a handful of people too :-)
FWIW, I'm probably still going to mess around with getting uac_replace_to
operational, 'cos it does seem to be somewhat useful (especially with some
of the stranger carrier requirements that I'm starting to see out there)
cheers
----- Original MessagGe -----
From: T.R. Missner <tmissner(a)gmail.com>
To: mahesh(a)aptela.com
Cc: users
openser.org <users(a)openser.org>
Sent: Wednesday, November 29, 2006 3:35:47 PM GMT-0600
Subject: Re: [Users] modifying From/To headers with uac module?
as a former level3 engineer who wrote some of level3s voip platform
parts and current customer i can tell you with certainty that level3
only enforces the e.164 requirement on the from and to header during
interop. if you can mock up your headers long enough to pass interop
and production turn up you can then safely terminate traffic to l3
without e.164 formating. they will not refuse your calls once you
make it to production.
of course a better solution may be choosing a meta carrier like
bandwidth.com ( where i work )
hope this helps
tr
On 11/29/06, Mahesh Paolini-Subramanya <mahesh(a)corp.aptela.com> wrote:
> FWIW, i've been bemoaning the lack of 'To' rewriting for a while myself.
> Level3, in its infinite wisdom, has decided that they need the RURI,
From,
> and 'To' headers to be in a very specific
format (prepended '+', 10
digits,
> etc., etc.)
> I can get the RURI and 'From' exactly the way they need it, but the
'To'
is
> definitely beyond my ability.
>
> Do let me/us know if you intend to go ahead with 'uac_replace_to'. It
would
> be trememdously useful...
>
> cheers
> ----- Original Message -----
> From: Alan Crosswell <alan(a)columbia.edu>
> To: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro>
> Cc: users
openser.org <users(a)openser.org>
> Sent: Tuesday, November 28, 2006 3:35:22 PM GMT-0600
> Subject: Re: [Users] modifying From/To headers with uac module?
>
> Thanks Bogdan. I'll have to double-check with them; They may have only
> meant they wanted the From in E.164 so that Caller ID works correctly.
> /a
>
> Bogdan-Andrei Iancu wrote:
> > Hi Alan,
> >
> > my advice is to change the PSTN termination since their service is not
> > RFC compliant - TO header has no use in routing, only the RURI being
> > used (according to the RFC 3261 ~ 3 years old).
> >
> > but to answer to your question, yes that is the proper place and the
> > mechanism is 95% the same as for FROM hdr.
> >
> > regards,
> > bogdan
> >
> > Alan Crosswell wrote:
> >
> >> Hello,
> >>
> >> I see that UAC allows modifying the From header, but I would also like
> >> to modify the To. This is because an ITSP I will be testing with
wants
> >> the From and To to be written in E.164
form (rewriting the R-URI
appears
> >> not to be good enough) while my internal
registrations use a 5-digit
> >> extension. It looks like uac is the right module for this but it
> >> appears that it can only modify the From header with
uac_replace_from()
and
uac_restore_from(). Would this be the right place to add
uac_replace_to() and uac_resotre_to() as well?
/a
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
--
*******************************************
Mahesh Paolini-Subramanya (703) 386-1500 x9100
CTO mahesh(a)aptela.com
Aptela, Inc.
http://www.aptela.com
"Aptela: How Business Answers The Call"
*******************************************
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
--
***********************