Hi Klaus, Alex et al.
I was thinking about the same problem.
My setup has two redundant SIP Proxy/Registrar (OpenSER 1.1) Servers (P1 and P2), no additonal edge proxies. It uses either MySQL cluster or Master-Master Replication to exchange the state of the location table.
For NAT Processing of REGISTER I use the Nathelper module, which writes the original (inside NAT) address to the 'contact' column and the information, where the REGISTER request was received from (outside NAT socket) goes to 'received' column of the location table.
e.g.: contact column: sip:behoe@192.168.1.56:2051 received column: sip:130.56.88.20:5432
When an INVITE arrives at P1 (or P2), the 'contact' column will go to the R-URI and the 'received' value will be used as the next target of the INVITE request.
INVITE requests that do not arrive at the proxy, where the UA has registered, have (depending on the NAT type) some likelihood to fail.
Appart from that and as long as there is no path value saved in the location table, this work fine. If there is a path value, its content will go to the Route header field and the the request is sent to the topmost Route entry. Therefore it looses the information that was stored in the 'received' column....:-(
The preserve this information and to make sure that LL requests are routed via the proxy, the UA has registered to, I have some idea, that uses path. (Unfortunately not all of my UAs support 'outbound'...:-( ):
When the REGISTER arrives at the Proxy P1, I would insert a Path header field with the address of P1 (i.e. the IP address and port of the proxy processing the request)
Furthermore I would add a new header field parameter to the contact header field (let's call it "extsock" for the time being) containing the external NAT socket (i.e. the same information that also goes to 'received' column)
e.g. Path: sip:136.59.10.85:5060;lr, Contact: sip:behoe@192.168.1.56:2051;extsock=sip:130.56.88.20:5432;lr
This will then be stored in the 'path' / 'contact' columns of the location table at save().
When the INVITE arrives e.g. at P2, it does the location lookup: The Route header field will be populated with the content of the 'path' column and the R-URI will be rewritten with the 'contact' column. This means the request will be normally forwarded to P1 (topmost Route).
The SIP INVITE looks e.g. as follows:
INVITE sip:behoe@192.168.1.56:2051;extsock=sip:130.56.88.20:5432 SIP/2.0 Route:sip:136.59.10.85:5060;lr [...]
After the request arrives at P1, it checks, whether there is an extsock parameter in the R-URI, and if yes, it uses its values as the next target of the request i.e. sip:130.56.88.20:5432 (Maybe P1 could even remove the extsock parameter from the R-URI at this stage to make some Nokia E-Series' phones happier...)
My questions: - Is this idea feasible? Does it work in any case? Any issues with forking? - Could it easily be configured to OpenSER, or is there a change in the source code necessairy? - How much does it break SIP standards? ;-)
Looking forward to your feedback.
Have a nice weekend!
cheers, Bernie
On Wednesday 02 May 2007 08:33, Klaus Darilion wrote:
Hi Alex!
Without having done this: You can configure the SIP proxies as load balancers too which distribute the load over all the proxy/registrars (including itself).
I thought of that, but then every REGISTER needs to be forwarded to another proxy to get the path info right. This result in a great amount of traffic between the proxies and extra processing power. I want the REGISTER request to be handled on the first host it arrives on. Then only some INVITE's need to create inter-proxy traffic.
Bernie Hoeneisen wrote:
Hi Klaus, Alex et al.
I was thinking about the same problem.
My setup has two redundant SIP Proxy/Registrar (OpenSER 1.1) Servers (P1 and P2), no additonal edge proxies. It uses either MySQL cluster or Master-Master Replication to exchange the state of the location table.
For NAT Processing of REGISTER I use the Nathelper module, which writes the original (inside NAT) address to the 'contact' column and the information, where the REGISTER request was received from (outside NAT socket) goes to 'received' column of the location table.
e.g.: contact column: sip:behoe@192.168.1.56:2051 received column: sip:130.56.88.20:5432
When an INVITE arrives at P1 (or P2), the 'contact' column will go to the R-URI and the 'received' value will be used as the next target of the INVITE request.
INVITE requests that do not arrive at the proxy, where the UA has registered, have (depending on the NAT type) some likelihood to fail.
Appart from that and as long as there is no path value saved in the location table, this work fine. If there is a path value, its content will go to the Route header field and the the request is sent to the topmost Route entry. Therefore it looses the information that was stored in the 'received' column....:-(
Hi Bernie!
Do you use the "received" features of path module? I think this should solve your problems.
http://www.openser.org/docs/modules/1.2.x/path#AEN82 and http://www.openser.org/docs/modules/1.2.x/path#AEN123
regards klaus
The preserve this information and to make sure that LL requests are routed via the proxy, the UA has registered to, I have some idea, that uses path. (Unfortunately not all of my UAs support 'outbound'...:-( ):
When the REGISTER arrives at the Proxy P1, I would insert a Path header field with the address of P1 (i.e. the IP address and port of the proxy processing the request)
Furthermore I would add a new header field parameter to the contact header field (let's call it "extsock" for the time being) containing the external NAT socket (i.e. the same information that also goes to 'received' column)
e.g. Path: sip:136.59.10.85:5060;lr, Contact: sip:behoe@192.168.1.56:2051;extsock=sip:130.56.88.20:5432;lr
This will then be stored in the 'path' / 'contact' columns of the location table at save().
When the INVITE arrives e.g. at P2, it does the location lookup: The Route header field will be populated with the content of the 'path' column and the R-URI will be rewritten with the 'contact' column. This means the request will be normally forwarded to P1 (topmost Route).
The SIP INVITE looks e.g. as follows:
INVITE sip:behoe@192.168.1.56:2051;extsock=sip:130.56.88.20:5432 SIP/2.0 Route:sip:136.59.10.85:5060;lr [...]
After the request arrives at P1, it checks, whether there is an extsock parameter in the R-URI, and if yes, it uses its values as the next target of the request i.e. sip:130.56.88.20:5432 (Maybe P1 could even remove the extsock parameter from the R-URI at this stage to make some Nokia E-Series' phones happier...)
My questions:
- Is this idea feasible? Does it work in any case? Any issues with forking?
- Could it easily be configured to OpenSER, or is there a change in the
source code necessairy?
- How much does it break SIP standards? ;-)
Looking forward to your feedback.
Have a nice weekend!
cheers, Bernie
On Wednesday 02 May 2007 08:33, Klaus Darilion wrote:
Hi Alex!
Without having done this: You can configure the SIP proxies as load balancers too which distribute the load over all the proxy/registrars (including itself).
I thought of that, but then every REGISTER needs to be forwarded to another proxy to get the path info right. This result in a great amount of traffic between the proxies and extra processing power. I want the REGISTER request to be handled on the first host it arrives on. Then only some INVITE's need to create inter-proxy traffic.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Klaus
Thanks for you answer!
The solution with Path/received really works for my setup, however to me it looks kind of unlogical as the information about the external NAT address IMHO should rather go to the URI containing the internal NAT address. However, the solution works and looks like it is interoperable, as the one inserting the Path (and later removing the Route) is the only one that needs to understand its semantics.
I have another question:
How to get the Path header field into the location table, when it has been added on the same proxy that saves the location. I'd like to use something like this:
[...] add_path_received(); [...] save("location");
But the save function doesn't care, that I have just inserted the Path. To get the Path inserted into the location table at save, I have to relay the request around localhost interface e.g. using t_relay("localhost");
Is there some better way to accomplish this?
This looks like a general OpenSER thing, that changes do not affect the current request processing, until the request is sent forward. Could someone provide me with some insight into this matter?
cheers, Bernie
On Mon, 7 May 2007, Klaus Darilion wrote:
Bernie Hoeneisen wrote:
Hi Klaus, Alex et al.
I was thinking about the same problem.
My setup has two redundant SIP Proxy/Registrar (OpenSER 1.1) Servers (P1 and P2), no additonal edge proxies. It uses either MySQL cluster or Master-Master Replication to exchange the state of the location table.
For NAT Processing of REGISTER I use the Nathelper module, which writes the original (inside NAT) address to the 'contact' column and the information, where the REGISTER request was received from (outside NAT socket) goes to 'received' column of the location table.
e.g.: contact column: sip:behoe@192.168.1.56:2051 received column: sip:130.56.88.20:5432
When an INVITE arrives at P1 (or P2), the 'contact' column will go to the R-URI and the 'received' value will be used as the next target of the INVITE request.
INVITE requests that do not arrive at the proxy, where the UA has registered, have (depending on the NAT type) some likelihood to fail.
Appart from that and as long as there is no path value saved in the location table, this work fine. If there is a path value, its content will go to the Route header field and the the request is sent to the topmost Route entry. Therefore it looses the information that was stored in the 'received' column....:-(
Hi Bernie!
Do you use the "received" features of path module? I think this should solve your problems.
http://www.openser.org/docs/modules/1.2.x/path#AEN82 and http://www.openser.org/docs/modules/1.2.x/path#AEN123
regards klaus
The preserve this information and to make sure that LL requests are routed via the proxy, the UA has registered to, I have some idea, that uses path. (Unfortunately not all of my UAs support 'outbound'...:-( ):
When the REGISTER arrives at the Proxy P1, I would insert a Path header field with the address of P1 (i.e. the IP address and port of the proxy processing the request)
Furthermore I would add a new header field parameter to the contact header field (let's call it "extsock" for the time being) containing the external NAT socket (i.e. the same information that also goes to 'received' column)
e.g. Path: sip:136.59.10.85:5060;lr, Contact: sip:behoe@192.168.1.56:2051;extsock=sip:130.56.88.20:5432;lr
This will then be stored in the 'path' / 'contact' columns of the location table at save().
When the INVITE arrives e.g. at P2, it does the location lookup: The Route header field will be populated with the content of the 'path' column and the R-URI will be rewritten with the 'contact' column. This means the request will be normally forwarded to P1 (topmost Route).
The SIP INVITE looks e.g. as follows:
INVITE sip:behoe@192.168.1.56:2051;extsock=sip:130.56.88.20:5432 SIP/2.0 Route:sip:136.59.10.85:5060;lr [...]
After the request arrives at P1, it checks, whether there is an extsock parameter in the R-URI, and if yes, it uses its values as the next target of the request i.e. sip:130.56.88.20:5432 (Maybe P1 could even remove the extsock parameter from the R-URI at this stage to make some Nokia E-Series' phones happier...)
My questions:
- Is this idea feasible? Does it work in any case? Any issues with forking?
- Could it easily be configured to OpenSER, or is there a change in the
source code necessairy?
- How much does it break SIP standards? ;-)
Looking forward to your feedback.
Have a nice weekend!
cheers, Bernie
On Wednesday 02 May 2007 08:33, Klaus Darilion wrote:
Hi Alex!
Without having done this: You can configure the SIP proxies as load balancers too which distribute the load over all the proxy/registrars (including itself).
I thought of that, but then every REGISTER needs to be forwarded to another proxy to get the path info right. This result in a great amount of traffic between the proxies and extra processing power. I want the REGISTER request to be handled on the first host it arrives on. Then only some INVITE's need to create inter-proxy traffic.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Bernie!
But the save function doesn't care, that I have just inserted the Path. To get the Path inserted into the location table at save, I have to relay the request around localhost interface e.g. using t_relay("localhost");
Yes. That's a common workaround.
Is there some better way to accomplish this?
AFAIK no.
This looks like a general OpenSER thing, that changes do not affect the current request processing, until the request is sent forward. Could someone provide me with some insight into this matter?
If you make manipulations to a SIP message, in (open)ser this manipulations are not immediately applied to the message. But a "lump" is generated for later processing. Finally, when the message will be forwarded (e.g. during t_relay()), the lumps will be applied to the message.
Thus, allthough you add the path, the path module does not see the new Path header. Looping the request is a common workaround.
Another workaround would be a new function which applies all the lumps to the message instantly. But I do not know enough of openser's internals if this is possible.
I've just read the path module's source. The lump which add the Path header can't be applied instantly because it references to the socket on which the message will be sent out - and this is not know unless sending the request.
Another solution would be to write the Path header into an AVP and extend the registrar module to store the AVP as path if there is no Path header present.
regards klaus
cheers, Bernie
On Mon, 7 May 2007, Klaus Darilion wrote:
Bernie Hoeneisen wrote:
Hi Klaus, Alex et al.
I was thinking about the same problem.
My setup has two redundant SIP Proxy/Registrar (OpenSER 1.1) Servers (P1 and P2), no additonal edge proxies. It uses either MySQL cluster or Master-Master Replication to exchange the state of the location table.
For NAT Processing of REGISTER I use the Nathelper module, which writes the original (inside NAT) address to the 'contact' column and the information, where the REGISTER request was received from (outside NAT socket) goes to 'received' column of the location table.
e.g.: contact column: sip:behoe@192.168.1.56:2051 received column: sip:130.56.88.20:5432
When an INVITE arrives at P1 (or P2), the 'contact' column will go to the R-URI and the 'received' value will be used as the next target of the INVITE request.
INVITE requests that do not arrive at the proxy, where the UA has registered, have (depending on the NAT type) some likelihood to fail.
Appart from that and as long as there is no path value saved in the location table, this work fine. If there is a path value, its content will go to the Route header field and the the request is sent to the topmost Route entry. Therefore it looses the information that was stored in the 'received' column....:-(
Hi Bernie!
Do you use the "received" features of path module? I think this should solve your problems.
http://www.openser.org/docs/modules/1.2.x/path#AEN82 and http://www.openser.org/docs/modules/1.2.x/path#AEN123
regards klaus
The preserve this information and to make sure that LL requests are routed via the proxy, the UA has registered to, I have some idea, that uses path. (Unfortunately not all of my UAs support 'outbound'...:-( ):
When the REGISTER arrives at the Proxy P1, I would insert a Path header field with the address of P1 (i.e. the IP address and port of the proxy processing the request)
Furthermore I would add a new header field parameter to the contact header field (let's call it "extsock" for the time being) containing the external NAT socket (i.e. the same information that also goes to 'received' column)
e.g. Path: sip:136.59.10.85:5060;lr, Contact: sip:behoe@192.168.1.56:2051;extsock=sip:130.56.88.20:5432;lr
This will then be stored in the 'path' / 'contact' columns of the location table at save().
When the INVITE arrives e.g. at P2, it does the location lookup: The Route header field will be populated with the content of the 'path' column and the R-URI will be rewritten with the 'contact' column. This means the request will be normally forwarded to P1 (topmost Route).
The SIP INVITE looks e.g. as follows:
INVITE sip:behoe@192.168.1.56:2051;extsock=sip:130.56.88.20:5432 SIP/2.0 Route:sip:136.59.10.85:5060;lr [...]
After the request arrives at P1, it checks, whether there is an extsock parameter in the R-URI, and if yes, it uses its values as the next target of the request i.e. sip:130.56.88.20:5432 (Maybe P1 could even remove the extsock parameter from the R-URI at this stage to make some Nokia E-Series' phones happier...)
My questions:
- Is this idea feasible? Does it work in any case? Any issues with
forking?
- Could it easily be configured to OpenSER, or is there a change in
the source code necessairy?
- How much does it break SIP standards? ;-)
Looking forward to your feedback.
Have a nice weekend!
cheers, Bernie
On Wednesday 02 May 2007 08:33, Klaus Darilion wrote:
Hi Alex!
Without having done this: You can configure the SIP proxies as load balancers too which distribute the load over all the proxy/registrars (including itself).
I thought of that, but then every REGISTER needs to be forwarded to another proxy to get the path info right. This result in a great amount of traffic between the proxies and extra processing power. I want the REGISTER request to be handled on the first host it arrives on. Then only some INVITE's need to create inter-proxy traffic.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-
Bernie Hoeneisen -
Klaus Darilion