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 ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,.
From: "Mike Tkachuk" mike@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
At 10:54 PM 9/23/2004, TSS Support wrote:
From: "Mike Tkachuk" mike@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'.
exactly. protocol violation threatens interoperability and gets you on a slippery slope.
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
--- Jiri Kuthan jiri@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@yahoo.com
_______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
http://www.iptel.org/info/trends/#b2bua
At 12:03 AM 9/24/2004, Girish wrote:
--- Jiri Kuthan jiri@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@yahoo.com
Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
From: "Jiri Kuthan" jiri@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
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@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 _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Greg Fausak www.AddaBrand.com (US) 469-546-1265
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@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.
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
From: "Greg Fausak" greg@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
-
Girish -
Greg Fausak -
Jiri Kuthan -
Mike Tkachuk -
TSS Support