Hi,
I have the following SIP scenario:
UA_A -> SER_A -> other SIP Proxy -> SER_A -> UA_B
I want to force SER_A instance to forward the received request to other SIP proxy element and ensure that that request will return to SER_A afterwards. To do that I use an insert_hf() function from textops module inside ser.cfg to insert a double Route header field - first value the sip uri of the 'other SIP proxy' and second one the SER_A sip uri to assure that the forwarded request will return to SER_A.
Whenever request enters the ser.cfg script logic my SER code performs the loose_route() check in general. In my situation when request initialy enters the logic it doesn't have any Route headers. When request enters a particular route block responsible for handling this request there is an lookup_user() invocation to check if the user should be serviced by this SER. If lookup_user() returns true and this particular user has a flag set which indicates routing through the extra SIP proxy I add the Route headers and pass the request to the 'FORWARD' route block where I do the t_relay(). My problem is that when I do t_relay() after inserting the Route headers into the request it is not forwarded according to the topmost Route header field value??
Is it bug in ser?? Please point me what do I missed. Thank you in advance. Tomasz
Your mixing up route with the request uri. The Route headers that SER receive will be processed appropriately through the loose route handling. Adding your own is only for downstream processing. Thus, add an extra Route header for your SER and either rewrite the request uri to the next proxy or use t_forward* commands. g-)
tzieleniewski wrote:
Hi,
I have the following SIP scenario:
UA_A -> SER_A -> other SIP Proxy -> SER_A -> UA_B
I want to force SER_A instance to forward the received request to other SIP proxy element and ensure that that request will return to SER_A afterwards. To do that I use an insert_hf() function from textops module inside ser.cfg to insert a double Route header field - first value the sip uri of the 'other SIP proxy' and second one the SER_A sip uri to assure that the forwarded request will return to SER_A.
Whenever request enters the ser.cfg script logic my SER code performs the loose_route() check in general. In my situation when request initialy enters the logic it doesn't have any Route headers. When request enters a particular route block responsible for handling this request there is an lookup_user() invocation to check if the user should be serviced by this SER. If lookup_user() returns true and this particular user has a flag set which indicates routing through the extra SIP proxy I add the Route headers and pass the request to the 'FORWARD' route block where I do the t_relay(). My problem is that when I do t_relay() after inserting the Route headers into the request it is not forwarded according to the topmost Route header field value??
Is it bug in ser?? Please point me what do I missed. Thank you in advance. Tomasz
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Your mixing up route with the request uri. The Route headers that SER receive will be processed appropriately through the loose route handling. Adding your own is only for downstream processing. Thus, add an extra Route header for your SER and either rewrite the request uri to the next proxy or use t_forward* commands. g-)
And that is what I want to achive. In some particular scenarios I want to include an extra SIP proxy node in the path. But I want to make sure that the massage received by SER will be forwarded in the unchanged form to the extra node so that the initial recipient will be know to the extra node (like in IMS when AS acts as SIP Proxy). So I was wondering if make sense to add this extra Route headers in the SER logic, make loose_route() check again so it will influence the signaling path by adding an extra node.
Tomasz
tzieleniewski wrote:
Hi,
I have the following SIP scenario:
UA_A -> SER_A -> other SIP Proxy -> SER_A -> UA_B
I want to force SER_A instance to forward the received request to other SIP proxy element and ensure that that request will return to SER_A afterwards. To do that I use an insert_hf() function from textops module inside ser.cfg to insert a double Route header field - first value the sip uri of the 'other SIP proxy' and second one the SER_A sip uri to assure that the forwarded request will return to SER_A.
Whenever request enters the ser.cfg script logic my SER code performs the loose_route() check in general. In my situation when request initialy enters the logic it doesn't have any Route headers. When request enters a particular route block responsible for handling this request there is an lookup_user() invocation to check if the user should be serviced by this SER. If lookup_user() returns true and this particular user has a flag set which indicates routing through the extra SIP proxy I add the Route headers and pass the request to the 'FORWARD' route block where I do the t_relay(). My problem is that when I do t_relay() after inserting the Route headers into the request it is not forwarded according to the topmost Route header field value??
Is it bug in ser?? Please point me what do I missed. Thank you in advance. Tomasz
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On Ne, 2007-07-08 at 14:21 +0200, tzieleniewski wrote:
Hi,
I have the following SIP scenario:
UA_A -> SER_A -> other SIP Proxy -> SER_A -> UA_B
I want to force SER_A instance to forward the received request to other SIP proxy element and ensure that that request will return to SER_A afterwards. To do that I use an insert_hf() function from textops module inside ser.cfg to insert a double Route header field - first value the sip uri of the 'other SIP proxy' and second one the SER_A sip uri to assure that the forwarded request will return to SER_A.
Well it looks quite strange (yes I know that IMS AS use the Route headers for scenario like that one above, OTOH they usually are B2BUAs, so in reality you see two "independent" calls on SER_A :), if you insert the two Route headers into the request (and assuming the other SIP proxy is RFC compliant) it should work.
Whenever request enters the ser.cfg script logic my SER code performs the loose_route() check in general. In my situation when request initialy enters the logic it doesn't have any Route headers. When request enters a particular route block responsible for handling this request there is an lookup_user() invocation to check if the user should be serviced by this SER. If lookup_user() returns true and this particular user has a flag set which indicates routing through the extra SIP proxy I add the Route headers and pass the request to the 'FORWARD' route block where I do the t_relay(). My problem is that when I do t_relay() after inserting the Route headers into the request it is not forwarded according to the topmost Route header field value??
Yes, inserting Route header does not affect the destination for the request (which was already computed), so you can either use t_forward_to, which has the destination as parameter or change it using attr_destination or xlset_destination (near the code where you add the Route header).
Is it bug in ser??
No, it's know behaviour.
Michal
On Ne, 2007-07-08 at 14:21 +0200, tzieleniewski wrote:
Hi,
I have the following SIP scenario:
UA_A -> SER_A -> other SIP Proxy -> SER_A -> UA_B
I want to force SER_A instance to forward the received request to other SIP proxy element and ensure that that request will return to SER_A afterwards. To do that I use an insert_hf() function from textops module inside ser.cfg to insert a double Route header field - first value the sip uri of the 'other SIP proxy' and second one the SER_A sip uri to assure that the forwarded request will return to SER_A.
Well it looks quite strange (yes I know that IMS AS use the Route headers for scenario like that one above, OTOH they usually are B2BUAs, so in reality you see two "independent" calls on SER_A :), if you insert the two Route headers into the request (and assuming the other SIP proxy is RFC compliant) it should work.
That is exactly what I am trying to achive. In IMS whenever SCSCF passes the signaling to AS it inserts those two Route headers. This ofcourse is not important if AS acts as UA or B2BUA but in the case of AS in the SIP Proxy mode makes a difference:)
Whenever request enters the ser.cfg script logic my SER code performs the loose_route() check in general. In my situation when request initialy enters the logic it doesn't have any Route headers. When request enters a particular route block responsible for handling this request there is an lookup_user() invocation to check if the user should be serviced by this SER. If lookup_user() returns true and this particular user has a flag set which indicates routing through the extra SIP proxy I add the Route headers and pass the request to the 'FORWARD' route block where I do the t_relay(). My problem is that when I do t_relay() after inserting the Route headers into the request it is not forwarded according to the topmost Route header field value??
Yes, inserting Route header does not affect the destination for the request (which was already computed), so you can either use t_forward_to, which has the destination as parameter or change it using attr_destination or xlset_destination (near the code where you add the Route header).
Is it bug in ser??
When is the actual destination computed, is it during the first invocation of the loose_route() function??
tomasz
No, it's know behaviour.
Michal
-
Greger V. Teigre -
Michal Matyska -
tzieleniewski