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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Cc: users openser.org <[email protected]> >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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >> To: Bogdan-Andrei Iancu <[EMAIL PROTECTED]> >> Cc: users openser.org <[email protected]> >> 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 >> >> [email protected] >> >> http://openser.org/cgi-bin/mailman/listinfo/users >> >> >> >> >> >> >> > >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://openser.org/cgi-bin/mailman/listinfo/users >> >> >> >> -- >> ******************************************* >> Mahesh Paolini-Subramanya (703) 386-1500 x9100 >> CTO [EMAIL PROTECTED] >> Aptela, Inc. http://www.aptela.com >> "Aptela: How Business Answers The Call" >> ******************************************* >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://openser.org/cgi-bin/mailman/listinfo/users >> > > > >-- >***********************
_______________________________________________ Users mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/users
