[Users] modifying From/To headers with uac module?

Alan Crosswell alan at columbia.edu
Thu Nov 30 01:51:29 CET 2006


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 at 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 at gmail.com>
>To: mahesh at aptela.com
>Cc: users openser.org <users at 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 at 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 at columbia.edu>
>> To: Bogdan-Andrei Iancu <bogdan at voice-system.ro>
>> Cc: users openser.org <users at 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 at openser.org
>> >> http://openser.org/cgi-bin/mailman/listinfo/users
>> >>
>> >>
>> >>
>> >
>>
>> _______________________________________________
>> Users mailing list
>> Users at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> --
>> *******************************************
>> Mahesh Paolini-Subramanya      (703) 386-1500 x9100
>> CTO                                         mahesh at aptela.com
>> Aptela, Inc.                               http://www.aptela.com
>> "Aptela: How Business Answers The Call"
>> *******************************************
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>>
>
>
>
>-- 
>***********************




More information about the Users mailing list