23 Sep
2004
23 Sep
'04
9:17 p.m.
Hello All,
Has somebody any idea how to rewrite the part of the 'To'
field (165) the same as the part of header field (700403)..?
in other words, how to make the 'user' field of this part
of both messages the same?
INVITE sip:123456@20.30.40.50 SIP/2.0
To: <sip:789@myserver.com;user=phone>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,.
Mike Tkachuk, ph:380-3433-47067
YES ISP, fx:380-3433-47067
Valova 17, mike|a|yes.net.ua
Kolomyia, www.yes.net.ua
Ukraine 78200 FWD: 66518
23.09.2004
ICQ# 57698805
MSN: mike_tkachuk|a|hotmail.com
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,.
23 Sep
23 Sep
10:54 p.m.
From: "Mike Tkachuk" <mike(a)yes.net.ua>
Has somebody any idea how to rewrite the part of the
'To'
field (165) the same as the part of header field (700403)..?
in other words, how to make the 'user' field of this part
of both messages the same?
INVITE sip:123456@20.30.40.50 SIP/2.0
To: <sip:789@myserver.com;user=phone>
I'm betting you'll find the answer is 'that's not a good thing to do'.
I'm
in the same spot right now, and have decided just to patch ser to make this
happen on our server. We need to interop with a provider who expects the To
to be in e.164 format, and since we can't expect our users to dial a + on
their phone, we have to rewrite it. Looking in the developer's guide, it
seems this has come up for discussion before. If you look under the
documentation for the transaction module you will see:
a.. Review whether there is not potential for to-tag rewriting and ACK
matching.
So this issue has obviously been visited before. However, when I asked, the
answer was 'don't rewrite to' and there's that answer several times in the
archives. Other SIP servers apparently do it as this provider says that they
are getting the proper messages from them. A sample exchange used an
Asterisk server, and some investigation turns up that Asterisk seems to have
no problems rewriting.
-Keith, TSS Support
11:53 p.m.
At 10:54 PM 9/23/2004, TSS Support wrote:
From: "Mike Tkachuk" <mike(a)yes.net.ua>
exactly. protocol violation threatens interoperability and gets you on
a slippery slope.
Has somebody any idea how to rewrite the part of
the 'To'
field (165) the same as the part of header field (700403)..?
in other words, how to make the 'user' field of this part
of both messages the same?
INVITE sip:123456@20.30.40.50 SIP/2.0
To: <sip:789@myserver.com;user=phone>
I'm betting you'll find the answer is 'that's not a good thing to do'.
I'm in the same spot right now, and have decided
just to patch ser to make this happen on our server. We need to interop with a provider
who expects the To to be in e.164 format, and since we can't expect our users to dial
a + on their phone, we have to rewrite it.
Then the provider is using VERY questionnable policy and ought to look only
at request-uri.
Looking in the developer's guide, it seems this has
come up for discussion before. If you look under the documentation for the transaction
module you will see:
a.. Review whether there is not potential for to-tag rewriting and ACK matching.
If you go for a light-weighted violation, this is something you need to look at.
So this issue has obviously been visited before.
However, when I asked, the answer was 'don't rewrite to' and there's that
answer several times in the archives. Other SIP servers apparently do it as this provider
says that they are getting the proper messages from them. A sample exchange used an
Asterisk server, and some investigation turns up that Asterisk seems to have no problems
rewriting.
* is a B2BUA -- it does not rewrite, it generates everything on its own.
I personally think B2BUA is in most cases very suboptimal technology.
Scalability is an example, even if it does not matter in baby-sized setups.
B2BUa security model is questionnable too.
-jiri
24 Sep
24 Sep
12:03 a.m.
--- Jiri Kuthan <jiri(a)iptel.org> wrote:
<snip>
I personally think B2BUA is in most cases very
suboptimal technology.
Scalability is an example, even if it does not matter in baby-sized setups.
B2BUa security model is questionnable too.
Jiri, can you please elaborate this a bit?
-jiri
Regards,
=====
Girish Gopinath <gr_sh2003(a)yahoo.com>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
1:07 a.m.
http://www.iptel.org/info/trends/#b2bua
At 12:03 AM 9/24/2004, Girish wrote:
--- Jiri Kuthan <jiri(a)iptel.org> wrote:
<snip>
--
Jiri Kuthan http://iptel.org/~jiri/
I personally think B2BUA is in most cases very
suboptimal technology.
Scalability is an example, even if it does not matter in baby-sized setups.
B2BUa security model is questionnable too.
Jiri, can you please elaborate this a bit?
-jiri
Regards,
=====
Girish Gopinath <gr_sh2003(a)yahoo.com>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6:13 p.m.
From: "Jiri Kuthan" <jiri(a)iptel.org>
Then the provider is using VERY questionnable policy
and ought to look
only
at request-uri.
* is a B2BUA -- it does not rewrite, it generates everything on its own.
I personally think B2BUA is in most cases very suboptimal technology.
Scalability is an example, even if it does not matter in baby-sized
setups.
B2BUa security model is questionnable too.
See, this is the problem. The provider is Level3. We are trying to use their
Enhanced Local service rather than provide all of the toll calling over our
trunks. They insist that there must be e.164 formatted addresses in all
header fields: From, To, and Request-URI. The first and last are easy. It
seems the only solution to fix the middle one is to add a B2BUA or go in and
patch SER. We don't want to add another point of failure, so it's likely
we'll end up adding t_relay_to_level3() or something like that.
-Keith, TSS
8:08 p.m.
Keith,
If I'm not mistaken, the From and To form part of the request's dialog
'key' along with the callid. To cannot be changed. If you did change
To
in the Level3 direction, when the request comes back you would have to
replace the
original 'To' from the UAC. I think this is, in effect, a psuedo b2bua.
I agree with Jiri, the request uri is what is important. However, you
know what they say about the 1000 pound gorilla :-)
-g
On Sep 24, 2004, at 11:13 AM, TSS Support wrote:
From: "Jiri Kuthan" <jiri(a)iptel.org>
Greg Fausak
www.AddaBrand.com
(US) 469-546-1265
Then the provider is using VERY questionnable
policy and ought to
look only
at request-uri.
* is a B2BUA -- it does not rewrite, it generates everything on its
own.
I personally think B2BUA is in most cases very suboptimal technology.
Scalability is an example, even if it does not matter in baby-sized
setups.
B2BUa security model is questionnable too.
See, this is the problem. The provider is Level3. We are trying to use
their Enhanced Local service rather than provide all of the toll
calling over our trunks. They insist that there must be e.164
formatted addresses in all header fields: From, To, and Request-URI.
The first and last are easy. It seems the only solution to fix the
middle one is to add a B2BUA or go in and patch SER. We don't want to
add another point of failure, so it's likely we'll end up adding
t_relay_to_level3() or something like that.
-Keith, TSS
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
8:39 p.m.
New subject: Re[2]: [Serusers] Header and To changing.
Hello Greg,
Friday, September 24, 2004, 9:08:33 PM, you wrote:
GF> Keith,
GF> If I'm not mistaken, the From and To form part of the request's dialog
GF> 'key' along with the callid. To cannot be changed. If you did change
GF> To
GF> in the Level3 direction, when the request comes back you would have to
GF> replace the
GF> original 'To' from the UAC. I think this is, in effect, a psuedo b2bua.
GF> I agree with Jiri, the request uri is what is important. However, you
GF> know what they say about the 1000 pound gorilla :-)
GF> -g
GF> On Sep 24, 2004, at 11:13 AM, TSS Support wrote:
>
> From: "Jiri Kuthan" <jiri(a)iptel.org>
>> Then the provider is using VERY questionnable policy and ought to
>> look only
>> at request-uri.
>> * is a B2BUA -- it does not rewrite, it generates everything on its
>> own.
>> I personally think B2BUA is in most cases very suboptimal technology.
>> Scalability is an example, even if it does not matter in baby-sized
>> setups.
>> B2BUa security model is questionnable too.
>
>
> See, this is the problem. The provider is Level3. We are trying to use
> their Enhanced Local service rather than provide all of the toll
> calling over our trunks. They insist that there must be e.164
> formatted addresses in all header fields: From, To, and Request-URI.
> The first and last are easy. It seems the only solution to fix the
> middle one is to add a B2BUA or go in and patch SER. We don't want to
> add another point of failure, so it's likely we'll end up adding
> t_relay_to_level3() or something like that.
>
> -Keith, TSS
I'm not sure 100%, I'm not SIP guru, but as I remember dialog should
be identified by totag, fromtag and callid.
--
Best regards,
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,.
Mike Tkachuk, ph:380-3433-47067
YES ISP, fx:380-3433-47067
Valova 17, mike|a|yes.net.ua
Kolomyia, www.yes.net.ua
Ukraine 78200 FWD: 66518
24.09.2004
ICQ# 57698805
MSN: mike_tkachuk|a|hotmail.com
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,.
10:35 p.m.
New subject: Re[2]: [Serusers] Header and To changing.
I think Greg's gotten the point -- 1000 pound gorillas frequently
overweight technology, interoeprability and common sense :)
At 08:39 PM 9/24/2004, Mike Tkachuk wrote:
I'm not sure 100%, I'm not SIP guru, but as I
remember dialog should
be identified by totag, fromtag and callid.
That's valid assumption for RFC3261-based dialog matching. It is not
valid for pre-RFC3261. I suspect there are quite some implementations
that will look at other message elements a la RFC2543.
-jiri
9:35 p.m.
From: "Greg Fausak" <greg(a)addabrand.com>
Keith,
If I'm not mistaken, the From and To form part of the request's dialog
'key' along with the callid. To cannot be changed. If you did change To
in the Level3 direction, when the request comes back you would have to
replace the
original 'To' from the UAC. I think this is, in effect, a psuedo b2bua.
I agree with Jiri, the request uri is what is important. However, you
know what they say about the 1000 pound gorilla :-)
-g
Bingo. It's about the gorilla.
Anyway, the following code snippet seems to be working with 0.8.14, though
it hasn't been extensively tested:
# replace To: with the current URI
if (subst('/^To:(.*)sip:[^@]*@[a-zA-Z0-9.]+(.*)$/To:\1\u\2/ig')) {
route(1);
} else {
sl_send_reply("500", "Server Internal Error 164");
};
Since this is in a route[] block which already has the request-URI written
in e.164, this does it for us.
-Keith, TSS Support
7176
days inactive
7177
days old
9 comments
5 participants
participants (5)
-
Girish -
Greg Fausak -
Jiri Kuthan -
Mike Tkachuk -
TSS Support