Hey,
I have setup two Kamailio servers, my INVITEs will go through server A, which forwards to server B which forwards it back to server A.
This is intential, the trouble is when the packet comes back through server B, nothing has changed so TM sees it as a retransmission.
The difference between the first time through and the second time is the port 5061 instead of 5060.
How can I tell tm that these are not the same transactions ? Would it be easier to have a seperate instance of Kamailio for 5061 ?
Thanks,
David
Hi,
David wrote:
I have setup two Kamailio servers, my INVITEs will go through server A, which forwards to server B which forwards it back to server A.
This is intential, the trouble is when the packet comes back through server B, nothing has changed so TM sees it as a retransmission.
The difference between the first time through and the second time is the port 5061 instead of 5060.
If you forward the INVITE from B to A SIP-wise (e.g., by calling forward()) a new Via header should be added which prevents the spiraled INVITE message from being considered a retransmission on A.
Do you perform forwarding on a lower level, like IP?
Cheers,
--Timo
Hey,
I do not do anything IP level forwarding. All my forwarding is done using Kamailio. It looks like what I am doing is called hairpin routing.
Thanks,
David
On 2010-07-07 18:48, Timo Reimann wrote:
Hi,
David wrote:
I have setup two Kamailio servers, my INVITEs will go through server A, which forwards to server B which forwards it back to server A.
This is intential, the trouble is when the packet comes back through server B, nothing has changed so TM sees it as a retransmission.
The difference between the first time through and the second time is the port 5061 instead of 5060.
If you forward the INVITE from B to A SIP-wise (e.g., by calling forward()) a new Via header should be added which prevents the spiraled INVITE message from being considered a retransmission on A.
Do you perform forwarding on a lower level, like IP?
Cheers,
--Timo
Hello,
post the sip trace (e.g., ngrep) with such invites.
Cheers, Daniel
On 7/8/10 12:53 AM, David wrote:
Hey,
I do not do anything IP level forwarding. All my forwarding is done using Kamailio. It looks like what I am doing is called hairpin routing.
Thanks,
David
On 2010-07-07 18:48, Timo Reimann wrote:
Hi,
David wrote:
I have setup two Kamailio servers, my INVITEs will go through server A, which forwards to server B which forwards it back to server A.
This is intential, the trouble is when the packet comes back through server B, nothing has changed so TM sees it as a retransmission.
The difference between the first time through and the second time is the port 5061 instead of 5060.
If you forward the INVITE from B to A SIP-wise (e.g., by calling forward()) a new Via header should be added which prevents the spiraled INVITE message from being considered a retransmission on A.
Do you perform forwarding on a lower level, like IP?
Cheers,
--Timo
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Am 08.07.2010 00:53, schrieb David:
Hey,
I do not do anything IP level forwarding. All my forwarding is done using Kamailio. It looks like what I am doing is called hairpin routing.
I think the correct term is "spiral" - at least the RFC uses this term.
How do you forward the request - t_relay()? If yes, then tm module should treat the request as a new transaction.
Post a trace (you can rewrite IP addresses): ngrep -t -q -W byline -d any -P "" port 5060 or 5061
regards Klaus
Thanks,
David
On 2010-07-07 18:48, Timo Reimann wrote:
Hi,
David wrote:
I have setup two Kamailio servers, my INVITEs will go through server A, which forwards to server B which forwards it back to server A.
This is intential, the trouble is when the packet comes back through server B, nothing has changed so TM sees it as a retransmission.
The difference between the first time through and the second time is the port 5061 instead of 5060.
If you forward the INVITE from B to A SIP-wise (e.g., by calling forward()) a new Via header should be added which prevents the spiraled INVITE message from being considered a retransmission on A.
Do you perform forwarding on a lower level, like IP?
Cheers,
--Timo
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hey,
OK, so after further research, I found that the trouble was not in fact in the transaction, the trouble was with fix_nated_contact();
So I setup a spiral SIP path. I have a public server that is used by a bunch of different phones, and I have a alg server ( one public and one private).
The public server often handles NATed users and the private alg server handles NAT for a particular user set ( the users on that particular network) .
The trouble is that the ALG does not rewrite the contact, rather it adds a Route: header with Record-Route. The trouble was the public server was calling fix_nated_contact on these users' requests, so when it came back and the last route header was parsed, the packet could not be delivered because the fix_nated_contact was changing the contact to the alg proxy server.
I added a custom header called "X-Ignore-NAT", and when I do the nat tests ( nac_uac_test ), I also check that the X-Ignore-NAT header was not present.
So I misdiagnosed the problem that I described in my message. I did my traces on the end point, so when I did not see the final packet arrive to the device, I thought it was being reabsorbed.
Is the custom header I used a good solution?
David
On 10-07-08 07:04 AM, Klaus Darilion wrote:
Am 08.07.2010 00:53, schrieb David:
Hey,
I do not do anything IP level forwarding. All my forwarding is done using Kamailio. It looks like what I am doing is called hairpin routing.
I think the correct term is "spiral" - at least the RFC uses this term.
How do you forward the request - t_relay()? If yes, then tm module should treat the request as a new transaction.
Post a trace (you can rewrite IP addresses): ngrep -t -q -W byline -d any -P "" port 5060 or 5061
regards Klaus
Thanks,
David
On 2010-07-07 18:48, Timo Reimann wrote:
Hi,
David wrote:
I have setup two Kamailio servers, my INVITEs will go through server A, which forwards to server B which forwards it back to server A.
This is intential, the trouble is when the packet comes back through server B, nothing has changed so TM sees it as a retransmission.
The difference between the first time through and the second time is the port 5061 instead of 5060.
If you forward the INVITE from B to A SIP-wise (e.g., by calling forward()) a new Via header should be added which prevents the spiraled INVITE message from being considered a retransmission on A.
Do you perform forwarding on a lower level, like IP?
Cheers,
--Timo
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Am 08.07.2010 15:09, schrieb David:
Hey,
OK, so after further research, I found that the trouble was not in fact in the transaction, the trouble was with fix_nated_contact();
So I setup a spiral SIP path. I have a public server that is used by a bunch of different phones, and I have a alg server ( one public and one private).
The public server often handles NATed users and the private alg server handles NAT for a particular user set ( the users on that particular network) .
The trouble is that the ALG does not rewrite the contact, rather it adds a Route: header with Record-Route. The trouble was the public server was calling fix_nated_contact on these users' requests, so when it came back and the last route header was parsed, the packet could not be delivered because the fix_nated_contact was changing the contact to the alg proxy server.
I added a custom header called "X-Ignore-NAT", and when I do the nat tests ( nac_uac_test ), I also check that the X-Ignore-NAT header was not present.
So I misdiagnosed the problem that I described in my message. I did my traces on the end point, so when I did not see the final packet arrive to the device, I thought it was being reabsorbed.
Is the custom header I used a good solution?
If it works then it is a good solution. Custom headers are often used provider internally to signal arbitrary data. Just make sure if a user fakes the internal headers, that they are not able to exploit something in your setup - e.g. you should screen incoming messages for the existence of header names which will be used internally in your network - and if you found such headers, just remove them.
regards klaus
David
On 10-07-08 07:04 AM, Klaus Darilion wrote:
Am 08.07.2010 00:53, schrieb David:
Hey,
I do not do anything IP level forwarding. All my forwarding is done using Kamailio. It looks like what I am doing is called hairpin routing.
I think the correct term is "spiral" - at least the RFC uses this term.
How do you forward the request - t_relay()? If yes, then tm module should treat the request as a new transaction.
Post a trace (you can rewrite IP addresses): ngrep -t -q -W byline -d any -P "" port 5060 or 5061
regards Klaus
Thanks,
David
On 2010-07-07 18:48, Timo Reimann wrote:
Hi,
David wrote:
I have setup two Kamailio servers, my INVITEs will go through server A, which forwards to server B which forwards it back to server A.
This is intential, the trouble is when the packet comes back through server B, nothing has changed so TM sees it as a retransmission.
The difference between the first time through and the second time is the port 5061 instead of 5060.
If you forward the INVITE from B to A SIP-wise (e.g., by calling forward()) a new Via header should be added which prevents the spiraled INVITE message from being considered a retransmission on A.
Do you perform forwarding on a lower level, like IP?
Cheers,
--Timo
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
"Just make sure if a user fakes the internal headers, that they are not able to exploit something in your setup"
Hey,
I am using a few custom headers. All the custom headers , except the NAT one, are authenticated using IP, if the IP doesn't match, the packet is rejected ( or dropped ). ( I check the IPs using "ds_is_from_list()" )
The NAT related header is checked like this :
if ( nat_uac_test('19') && !is_present_hf('X-Cool-Header') ) { fix_nated_contact(); # Set flags for NAT fixing such as RTP Proxy. }
I am pretty sure this is safe.
Thanks,
David
On 2010-07-08 10:33, Klaus Darilion wrote:
Am 08.07.2010 15:09, schrieb David:
Hey,
OK, so after further research, I found that the trouble was not in fact in the transaction, the trouble was with fix_nated_contact();
So I setup a spiral SIP path. I have a public server that is used by a bunch of different phones, and I have a alg server ( one public and one private).
The public server often handles NATed users and the private alg server handles NAT for a particular user set ( the users on that particular network) .
The trouble is that the ALG does not rewrite the contact, rather it adds a Route: header with Record-Route. The trouble was the public server was calling fix_nated_contact on these users' requests, so when it came back and the last route header was parsed, the packet could not be delivered because the fix_nated_contact was changing the contact to the alg proxy server.
I added a custom header called "X-Ignore-NAT", and when I do the nat tests ( nac_uac_test ), I also check that the X-Ignore-NAT header was not present.
So I misdiagnosed the problem that I described in my message. I did my traces on the end point, so when I did not see the final packet arrive to the device, I thought it was being reabsorbed.
Is the custom header I used a good solution?
If it works then it is a good solution. Custom headers are often used provider internally to signal arbitrary data. Just make sure if a user fakes the internal headers, that they are not able to exploit something in your setup - e.g. you should screen incoming messages for the existence of header names which will be used internally in your network - and if you found such headers, just remove them.
regards klaus
David
On 10-07-08 07:04 AM, Klaus Darilion wrote:
Am 08.07.2010 00:53, schrieb David:
Hey,
I do not do anything IP level forwarding. All my forwarding is done using Kamailio. It looks like what I am doing is called hairpin routing.
I think the correct term is "spiral" - at least the RFC uses this term.
How do you forward the request - t_relay()? If yes, then tm module should treat the request as a new transaction.
Post a trace (you can rewrite IP addresses): ngrep -t -q -W byline -d any -P "" port 5060 or 5061
regards Klaus
Thanks,
David
On 2010-07-07 18:48, Timo Reimann wrote:
Hi,
David wrote:
I have setup two Kamailio servers, my INVITEs will go through server A, which forwards to server B which forwards it back to server A.
This is intential, the trouble is when the packet comes back through server B, nothing has changed so TM sees it as a retransmission.
The difference between the first time through and the second time is the port 5061 instead of 5060.
If you forward the INVITE from B to A SIP-wise (e.g., by calling forward()) a new Via header should be added which prevents the spiraled INVITE message from being considered a retransmission on A.
Do you perform forwarding on a lower level, like IP?
Cheers,
--Timo
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel-Constantin Mierla -
David -
Klaus Darilion -
Timo Reimann