29 Nov
2007
29 Nov
'07
7:48 p.m.
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
29 Nov
29 Nov
7:51 p.m.
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(a)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
8:42 p.m.
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(a)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(a)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
30 Nov
30 Nov
9:10 a.m.
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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
5:32 p.m.
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(a)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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
8:31 p.m.
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(a)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(a)lists.openser.org
>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
6202
days inactive
6203
days old
5 comments
3 participants
participants (3)
-
Alex Balashov -
Klaus Darilion -
Phil D'Amore