[OpenSER-Users] Changing From: and To: URIs...

[Klaus Darilion]

Phil D'Amore wrote:
> Yes, it's a real pain.  This particular carrier has a requirement that
> request, From, and To URIs are all in E.164 format for some reason.
> The other problem I have with the To header is RFC 3398 section
> 7.2.1.1, specifically the part that reads:
> 
> "If the primary telephone number in the Request-URI and that of the To
>    header are at variance, then the To header SHOULD be used to populate
>    an OCN parameter.  Otherwise the To header SHOULD be ignored."
> 
> That one sentence is a huge pain in my backside.  There are *much*
> better headers for that.  All sorts of unexpected things can happen
> when the gateway implements that, and the to uri != ruri :(.  Like the
> first time we noticed that mapping a speed dial to someone's cell
> phone, and it went to VM, and we got the voicemail box for the speed
> dial digits, *not* the actual number in the request uri!  I use
> redirects to implement speed dial and vertical service codes now
> because of that.
> 
> Oh well, I press on for a work-around.

Ok - for the workaround. Some clients do not care about To: URI and use 
only to/from tags for dialog matching. If you have homogeneous clients 
then you could try if changing to URI works.

If not, you can do it the hard way - in the initial INVITE put the 
original and the new To URI into a record route parameters and the 
original To URIinto an AVP. In the reply route undo the replacement 
using the AVP.

For in dialog requests use is_direction() to find out if the request if 
upstream or downstream and rewrite the To URI accordingly (retrieve URIs 
from record route). Again set up an AVP with the original To URI to undo 
the change in the reply route.

Other Workaround: Use a B2BUA (Asterisk, sippy, sems, freeswitch?....)
regards
klaus




> 
> On Nov 30, 2007 2:10 AM, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
>>
>> Phil D'Amore schrieb:
>>> Hi Everyone...
>>>
>>> I'm looking for some advice.  Let's say I have a To: header in an
>>> initial INVITE:
>>>
>>> To: Bob <sip:8005551212 at sip.example.com>
>>>
>>> Due to carrier requirements, it really needs to be:
>>>
>>> To: Bob <sip:+18005551212 at sip.example.com>
>> Although you do not want to hear this answer:
>> Tell your carrier to fix it's system! Routing on To-header is bullshit.
>>
>> regards
>> klaus
>>
>>
>>> I'm not asking how to do it.  I know I can use some textops functions
>>> to make this happen.  I also know that doing this might break
>>> something.
>>>
>>> The uac module already nicely handles the From: header in a way that
>>> doesn't break things.  I thought about extending this to handle To:,
>>> but I worried that the Record-Route header might get too long for some
>>> UAs if I wind up having to change both headers.  The To tag must also
>>> be dealt with somehow, which I think might make it harder to do than
>>> From.
>>>
>>> Using a 302 response is not an option for me, and I'm really trying to
>>> avoid getting a B2BUA involved with this right now.  Moving from
>>> openser 1.1.1 to 1.3 is enough for me without changing my architecture
>>> ;).  I'm wondering what would be the best way given what openser can
>>> do right now (1.3) to re-write that header that doesn't break
>>> anything.  I'm not adverse to writing some code to make it happen if
>>> that is what is needed.
>>>
>>> Any ideas?
>>>
>>> Thanks,
>>> Phil
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.openser.org
>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users