Hi Everyone...
I'm looking for some advice. Let's say I have a To: header in an initial INVITE:
To: Bob sip:8005551212@sip.example.com
Due to carrier requirements, it really needs to be:
To: Bob sip:+18005551212@sip.example.com
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
Phil,
Why would you have to deal with the To tag?
I've had to do this very often and simply using textops to transform the headers precisely as you describe has always worked. Just use regex to conserve all the tags and other extended fields that appear in the To and From URIs.
-- Alex
On Thu, 29 Nov 2007, Phil D'Amore wrote:
Hi Everyone...
I'm looking for some advice. Let's say I have a To: header in an initial INVITE:
To: Bob sip:8005551212@sip.example.com
Due to carrier requirements, it really needs to be:
To: Bob sip:+18005551212@sip.example.com
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : +1-678-954-0670 Direct : +1-678-954-0671
Sorry, this reply didn't originally go to the whole list...
I was talking about the to tag only in the context of modifying the UAC module to do this like it does From. I realize now that it's only the URI being modified so you're right, the tags don't matter.
My original concern with just re-writing the To: URI is that, strictly speaking, it's not allowed by RFC3261. Specifically section 12.2.1.1, which requires reflection of the original To: and From: URIs in subsequent requests in a dialog. If a UA sends a re-invite back upstream, it will reflect my re-written URI to the original UA, which then might not be able to match the dialog because the URI is different.
I believe that is why uac_replace_from exists for the From header. The uac module catches such requests, and restores the original URI. I know of nothing that currently handles To that way.
In reality, UAs fully supporting 3261 shouldn't care about the URI, and the restriction I mentioned above is only for backward compatability. Perhaps I'm worrying about nothing, but uac_replace_from must exist for a reason.
Thanks, Phil
On Nov 29, 2007 12:51 PM, Alex Balashov abalashov@evaristesys.com wrote:
Phil,
Why would you have to deal with the To tag?
I've had to do this very often and simply using textops to transform the headers precisely as you describe has always worked. Just use regex to conserve all the tags and other extended fields that appear in the To and From URIs.
-- Alex
On Thu, 29 Nov 2007, Phil D'Amore wrote:
Hi Everyone...
I'm looking for some advice. Let's say I have a To: header in an initial INVITE:
To: Bob sip:8005551212@sip.example.com
Due to carrier requirements, it really needs to be:
To: Bob sip:+18005551212@sip.example.com
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : +1-678-954-0670 Direct : +1-678-954-0671
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@sip.example.com
Due to carrier requirements, it really needs to be:
To: Bob sip:+18005551212@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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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.
On Nov 30, 2007 2:10 AM, Klaus Darilion klaus.mailinglists@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@sip.example.com
Due to carrier requirements, it really needs to be:
To: Bob sip:+18005551212@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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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@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@sip.example.com
Due to carrier requirements, it really needs to be:
To: Bob sip:+18005551212@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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Alex Balashov -
Klaus Darilion -
Phil D'Amore