I am trying to use opensips to act as an outbound proxy to my SIP server/gateway. User clients register to my server through outbound proxy. The outbound proxy adds a path to the register and relays it to my server. Calls to and from my server gateway through the outbound proxy to the user clients are fine.
However if a client wishes to call another client the outbound proxy (opensips) does not relay the ACK to the target client.
So the scenario is:
U1 -> P1 -> p2 -> P1 ->U2
Where
U1 is user client 1123@10.0.0.102:5068
U2 is user client 1124@10.0.0.100:5062
P1 is opensips on 10.0.0.23:9000
P2 is SIP registrar/server on 10.0.0.22:5060
I am using the standard opensips configuration file with a modification to add path to register messages.
The Invite and responses are fine. When U1 sends the ACK it gets as far as the second call to P1:
U1 ACK -> P1 -> P2 -> P1
It is not relayed to U2.
The ACK as received by P1 looks like:
ACK sip:1124@10.0.0.100:5062 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.22:5060;branch=z9hG4bKdd5fc1bd535ca5995f0236f610d11873.ee6590f9
Via: SIP/2.0/UDP 10.0.0.23:9000;branch=z9hG4bKf7d.13d70813.2
Via: SIP/2.0/UDP 10.0.0.102:5068;branch=z9hG4bKcc549ef31247f06f
To: <sip:1124@10.0.0.22>;tag=dbb1b5e85ca8d514
From: "gxp2000" <sip:1123@10.0.0.22>;tag=386107ed18014fb8
Call-ID: 051ee3041aaf49b5@10.0.0.102
CSeq: 12565 ACK
Max-Forwards: 68
Route: <sip:10.0.0.23:9000;lr>
Record-Route: <sip:proxy@10.0.0.22>
Contact: <sip:1123@10.0.0.102:5068;transport=udp>
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Supported: path
User-Agent: net-voice PBX/2.1.37
Content-Length: 0
To my mind loose_route should remove the route and then t_relay should relay the ACK to the Request URI which is the correct destination. In fact if I force the ACK to be relayed with t_relay("10.0.0.100:5062") the call is successful.
The debug below shows what opensips is doing with the ACK. Any help with this would be gratefully received.
Thank you
Jonathan
Nov 30 13:20:07 DBG:core:parse_msg: SIP Request:
Nov 30 13:20:07 DBG:core:parse_msg: method: <ACK>
Nov 30 13:20:07 DBG:core:parse_msg: uri: <sip:1124@10.0.0.100:5062>
Nov 30 13:20:07 DBG:core:parse_msg: version: <SIP/2.0>
Nov 30 13:20:07 DBG:core:parse_headers: flags=2
Nov 30 13:20:07 DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bKdd5fc1bd535ca5995f0236f610d11873.ee6590f9>; state=16
Nov 30 13:20:07 DBG:core:parse_via: end of header reached, state=5
Nov 30 13:20:07 DBG:core:parse_headers: via found, flags=2
Nov 30 13:20:07 DBG:core:parse_headers: this is the first via
Nov 30 13:20:07 DBG:core:receive_msg: After parse_msg…
Nov 30 13:20:07 DBG:core:receive_msg: preparing to run routing scripts…
Nov 30 13:20:07 DBG:sl:sl_filter_ACK: to late to be a local ACK!
Nov 30 13:20:07 DBG:core:parse_headers: flags=100
Nov 30 13:20:07 DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bKf7d.13d70813.2>; state=16
Nov 30 13:20:07 DBG:core:parse_via: end of header reached, state=5
Nov 30 13:20:07 DBG:core:parse_headers: via found, flags=100
Nov 30 13:20:07 DBG:core:parse_headers: parse_headers: this is the second via
Nov 30 13:20:07 DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bKcc549ef31247f06f>; state=16
Nov 30 13:20:07 DBG:core:parse_via: end of header reached, state=5
Nov 30 13:20:07 DBG:core:parse_headers: via found, flags=100
Nov 30 13:20:07 DBG:core:parse_to_param: tag=dbb1b5e85ca8d514
Nov 30 13:20:07 DBG:core:parse_to: end of header reached, state=29
Nov 30 13:20:07 DBG:core:parse_to: display={}, ruri={sip:1124@10.0.0.22}
Nov 30 13:20:07 DBG:core:get_hdr_field: <To> ; uri=
Nov 30 13:20:07 DBG:core:get_hdr_field: to body
Nov 30 13:20:07 DBG:core:get_hdr_field: cseq <CSeq>: <12565> <ACK>
Nov 30 13:20:07 DBG:maxfwd:is_maxfwd_present: value = 68
Nov 30 13:20:07 DBG:uri:has_totag: totag found
Nov 30 13:20:07 DBG:core:parse_to_param: tag=386107ed18014fb8
Nov 30 13:20:07 DBG:core:parse_to: end of header reached, state=29
Nov 30 13:20:07 DBG:core:parse_to: display={"gxp2000"}, ruri={sip:1123@10.0.0.22}
TO TAG 1 TRACEPOINT
rm=<ACK>
ruri=<sip:1124@10.0.0.100:5062>
from=<sip:1123@10.0.0.22>
to=<sip:1124@10.0.0.22>
Nov 30 13:20:07 DBG:core:parse_headers: flags=200
Nov 30 13:20:07 DBG:rr:is_preloaded: is_preloaded: No
Nov 30 13:20:07 DBG:core:grep_sock_info: checking if host==us: 10==9 && ==
Nov 30 13:20:07 DBG:core:grep_sock_info: checking if port 9000 matches port 5062
Nov 30 13:20:07 DBG:core:check_self: host != me
Nov 30 13:20:07 DBG:core:grep_sock_info: checking if host==us: 9==9 && ==
Nov 30 13:20:07 DBG:core:grep_sock_info: checking if port 9000 matches port 9000
Nov 30 13:20:07 DBG:rr:after_loose: Topmost route URI: 'sip:10.0.0.23:9000;lr' is me
Nov 30 13:20:07 DBG:core:parse_headers: flags=200
Nov 30 13:20:07 DBG:core:get_hdr_field: content_length=0
Nov 30 13:20:07 DBG:core:get_hdr_field: found end of header
Nov 30 13:20:07 DBG:rr:find_next_route: No next Route HF found
Nov 30 13:20:07 DBG:rr:after_loose: No next URI found
Nov 30 13:20:07 DBG:rr:run_rr_callbacks: callback id 0 entered with <lr>
Nov 30 13:20:07 DBG:core:parse_params: Parsing params for:
LOOSE ROUTE 1 TRACEPOINT
rm=<ACK>
ruri=<sip:1124@10.0.0.100:5062>
from=<sip:1123@10.0.0.22>
to=<sip:1124@10.0.0.22>
Nov 30 13:20:07 DBG:core:pv_get_dsturi: no destination URI
has_totag - Routing to <null> Request URI sip:1124@10.0.0.100:5062Nov 30 13:20:07 DBG™️t_newtran: transaction on entrance=0xffffffff
Nov 30 13:20:07 DBG:core:parse_headers: flags=ffffffffffffffff
Nov 30 13:20:07 DBG:core:parse_headers: flags=78
Nov 30 13:20:07 DBG™️t_lookup_request: start searching: hash=3455, isACK=1
Nov 30 13:20:07 DBG:core:parse_headers: flags=38
Nov 30 13:20:07 DBG™️matching_3261: RFC3261 transaction matched, tid=dd5fc1bd535ca5995f0236f610d11873.ee6590f9
Nov 30 13:20:07 DBG™️t_lookup_request: REF_UNSAFE: after is 1
Nov 30 13:20:07 DBG™️t_lookup_request: transaction found (T=0xb6133a90)
Nov 30 13:20:07 DBG™️cleanup_uac_timers: RETR/FR timers reset
Nov 30 13:20:07 DBG™️t_unref: UNREF_UNSAFE: after is 0
Nov 30 13:20:07 DBG:core:destroy_avp_list: destroying list (nil)
Nov 30 13:20:07 DBG:core:receive_msg: cleaning up
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo
I have a similar issue. Using standard conf, try to call from SIP client to a public phone number via opensips and then pstn to an international number. The signalling and authentication works fine, but the ACK to the 200 OK message is never going to the pstn and the bye from the pstn never comes to the sip client. The rtp (voice) is connected.
Wondering if its the same issue.
thanks for any help
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi net-voice,
I guess you changed your sequential request section. Could you be so kind and copy that to me? It might be a solution for me as well. Thanks in advance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What does your opensips debug show when it receives the ACK?
I didn't need to change the standard config file. It was purely an error on my sip server. The only change I have made to the standard config is to insert the following code into line 303 and include the path module and modparam("path", "use_received", 1) statement:
if (is_method("REGISTER"))
{
log("INFO:Add Path\n");
if (!add_path_received()) {
log("INFO:Add Path - failed\n");
sl_send_reply("503", "Internal Path Error");
};
}
This allows my server to route calls back to the proxy (opensips) the registration came in on.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are so many entried when I set the debug mode to 4, so could you tell me, how a sequence is tight together?
Is it the number 7971 or what is the meaning of this number? I had never looking in debug level 4 before.
Dec 6 13:22:01 localhost /usr/sbin/opensips: DBG:nathelper:force_rtp_proxy: Forcing body: [v=0
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You would be best off running a separate instance of opensips to test with. You can then run it with output to stderr and capture that in a file. Then search the debug for <ACK> which is where the ACK processing starts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I am trying to use opensips to act as an outbound proxy to my SIP server/gateway. User clients register to my server through outbound proxy. The outbound proxy adds a path to the register and relays it to my server. Calls to and from my server gateway through the outbound proxy to the user clients are fine.
However if a client wishes to call another client the outbound proxy (opensips) does not relay the ACK to the target client.
So the scenario is:
U1 -> P1 -> p2 -> P1 ->U2
Where
U1 is user client 1123@10.0.0.102:5068
U2 is user client 1124@10.0.0.100:5062
P1 is opensips on 10.0.0.23:9000
P2 is SIP registrar/server on 10.0.0.22:5060
I am using the standard opensips configuration file with a modification to add path to register messages.
The Invite and responses are fine. When U1 sends the ACK it gets as far as the second call to P1:
U1 ACK -> P1 -> P2 -> P1
It is not relayed to U2.
The ACK as received by P1 looks like:
ACK sip:1124@10.0.0.100:5062 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.22:5060;branch=z9hG4bKdd5fc1bd535ca5995f0236f610d11873.ee6590f9
Via: SIP/2.0/UDP 10.0.0.23:9000;branch=z9hG4bKf7d.13d70813.2
Via: SIP/2.0/UDP 10.0.0.102:5068;branch=z9hG4bKcc549ef31247f06f
To: <sip:1124@10.0.0.22>;tag=dbb1b5e85ca8d514
From: "gxp2000" <sip:1123@10.0.0.22>;tag=386107ed18014fb8
Call-ID: 051ee3041aaf49b5@10.0.0.102
CSeq: 12565 ACK
Max-Forwards: 68
Route: <sip:10.0.0.23:9000;lr>
Record-Route: <sip:proxy@10.0.0.22>
Contact: <sip:1123@10.0.0.102:5068;transport=udp>
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
Supported: path
User-Agent: net-voice PBX/2.1.37
Content-Length: 0
To my mind loose_route should remove the route and then t_relay should relay the ACK to the Request URI which is the correct destination. In fact if I force the ACK to be relayed with t_relay("10.0.0.100:5062") the call is successful.
The debug below shows what opensips is doing with the ACK. Any help with this would be gratefully received.
Thank you
Jonathan
Nov 30 13:20:07 DBG:core:parse_msg: SIP Request:
Nov 30 13:20:07 DBG:core:parse_msg: method: <ACK>
Nov 30 13:20:07 DBG:core:parse_msg: uri: <sip:1124@10.0.0.100:5062>
Nov 30 13:20:07 DBG:core:parse_msg: version: <SIP/2.0>
Nov 30 13:20:07 DBG:core:parse_headers: flags=2
Nov 30 13:20:07 DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bKdd5fc1bd535ca5995f0236f610d11873.ee6590f9>; state=16
Nov 30 13:20:07 DBG:core:parse_via: end of header reached, state=5
Nov 30 13:20:07 DBG:core:parse_headers: via found, flags=2
Nov 30 13:20:07 DBG:core:parse_headers: this is the first via
Nov 30 13:20:07 DBG:core:receive_msg: After parse_msg…
Nov 30 13:20:07 DBG:core:receive_msg: preparing to run routing scripts…
Nov 30 13:20:07 DBG:sl:sl_filter_ACK: to late to be a local ACK!
Nov 30 13:20:07 DBG:core:parse_headers: flags=100
Nov 30 13:20:07 DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bKf7d.13d70813.2>; state=16
Nov 30 13:20:07 DBG:core:parse_via: end of header reached, state=5
Nov 30 13:20:07 DBG:core:parse_headers: via found, flags=100
Nov 30 13:20:07 DBG:core:parse_headers: parse_headers: this is the second via
Nov 30 13:20:07 DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bKcc549ef31247f06f>; state=16
Nov 30 13:20:07 DBG:core:parse_via: end of header reached, state=5
Nov 30 13:20:07 DBG:core:parse_headers: via found, flags=100
Nov 30 13:20:07 DBG:core:parse_to_param: tag=dbb1b5e85ca8d514
Nov 30 13:20:07 DBG:core:parse_to: end of header reached, state=29
Nov 30 13:20:07 DBG:core:parse_to: display={}, ruri={sip:1124@10.0.0.22}
Nov 30 13:20:07 DBG:core:get_hdr_field: <To> ; uri=
Nov 30 13:20:07 DBG:core:get_hdr_field: to body
Nov 30 13:20:07 DBG:core:get_hdr_field: cseq <CSeq>: <12565> <ACK>
Nov 30 13:20:07 DBG:maxfwd:is_maxfwd_present: value = 68
Nov 30 13:20:07 DBG:uri:has_totag: totag found
Nov 30 13:20:07 DBG:core:parse_to_param: tag=386107ed18014fb8
Nov 30 13:20:07 DBG:core:parse_to: end of header reached, state=29
Nov 30 13:20:07 DBG:core:parse_to: display={"gxp2000"}, ruri={sip:1123@10.0.0.22}
TO TAG 1 TRACEPOINT
rm=<ACK>
ruri=<sip:1124@10.0.0.100:5062>
from=<sip:1123@10.0.0.22>
to=<sip:1124@10.0.0.22>
Nov 30 13:20:07 DBG:core:parse_headers: flags=200
Nov 30 13:20:07 DBG:rr:is_preloaded: is_preloaded: No
Nov 30 13:20:07 DBG:core:grep_sock_info: checking if host==us: 10==9 && ==
Nov 30 13:20:07 DBG:core:grep_sock_info: checking if port 9000 matches port 5062
Nov 30 13:20:07 DBG:core:check_self: host != me
Nov 30 13:20:07 DBG:core:grep_sock_info: checking if host==us: 9==9 && ==
Nov 30 13:20:07 DBG:core:grep_sock_info: checking if port 9000 matches port 9000
Nov 30 13:20:07 DBG:rr:after_loose: Topmost route URI: 'sip:10.0.0.23:9000;lr' is me
Nov 30 13:20:07 DBG:core:parse_headers: flags=200
Nov 30 13:20:07 DBG:core:get_hdr_field: content_length=0
Nov 30 13:20:07 DBG:core:get_hdr_field: found end of header
Nov 30 13:20:07 DBG:rr:find_next_route: No next Route HF found
Nov 30 13:20:07 DBG:rr:after_loose: No next URI found
Nov 30 13:20:07 DBG:rr:run_rr_callbacks: callback id 0 entered with <lr>
Nov 30 13:20:07 DBG:core:parse_params: Parsing params for:
LOOSE ROUTE 1 TRACEPOINT
rm=<ACK>
ruri=<sip:1124@10.0.0.100:5062>
from=<sip:1123@10.0.0.22>
to=<sip:1124@10.0.0.22>
Nov 30 13:20:07 DBG:core:pv_get_dsturi: no destination URI
has_totag - Routing to <null> Request URI sip:1124@10.0.0.100:5062Nov 30 13:20:07 DBG™️t_newtran: transaction on entrance=0xffffffff
Nov 30 13:20:07 DBG:core:parse_headers: flags=ffffffffffffffff
Nov 30 13:20:07 DBG:core:parse_headers: flags=78
Nov 30 13:20:07 DBG™️t_lookup_request: start searching: hash=3455, isACK=1
Nov 30 13:20:07 DBG:core:parse_headers: flags=38
Nov 30 13:20:07 DBG™️matching_3261: RFC3261 transaction matched, tid=dd5fc1bd535ca5995f0236f610d11873.ee6590f9
Nov 30 13:20:07 DBG™️t_lookup_request: REF_UNSAFE: after is 1
Nov 30 13:20:07 DBG™️t_lookup_request: transaction found (T=0xb6133a90)
Nov 30 13:20:07 DBG™️cleanup_uac_timers: RETR/FR timers reset
Nov 30 13:20:07 DBG™️t_unref: UNREF_UNSAFE: after is 0
Nov 30 13:20:07 DBG:core:destroy_avp_list: destroying list (nil)
Nov 30 13:20:07 DBG:core:receive_msg: cleaning up
Hallo
I have a similar issue. Using standard conf, try to call from SIP client to a public phone number via opensips and then pstn to an international number. The signalling and authentication works fine, but the ACK to the 200 OK message is never going to the pstn and the bye from the pstn never comes to the sip client. The rtp (voice) is connected.
Wondering if its the same issue.
thanks for any help
Problem solved. I discovered my sip server was using the same via branch in the ACK as the INVITE. That has been fixed and now my scenario works.
Schaepper: that may not be the problem you are having but it could be worth checking.
Hi net-voice,
I guess you changed your sequential request section. Could you be so kind and copy that to me? It might be a solution for me as well. Thanks in advance.
What does your opensips debug show when it receives the ACK?
I didn't need to change the standard config file. It was purely an error on my sip server. The only change I have made to the standard config is to insert the following code into line 303 and include the path module and modparam("path", "use_received", 1) statement:
if (is_method("REGISTER"))
{
log("INFO:Add Path\n");
if (!add_path_received()) {
log("INFO:Add Path - failed\n");
sl_send_reply("503", "Internal Path Error");
};
}
This allows my server to route calls back to the proxy (opensips) the registration came in on.
There are so many entried when I set the debug mode to 4, so could you tell me, how a sequence is tight together?
Is it the number 7971 or what is the meaning of this number? I had never looking in debug level 4 before.
Dec 6 13:22:01 localhost /usr/sbin/opensips: DBG:nathelper:force_rtp_proxy: Forcing body: [v=0
Thanks
You would be best off running a separate instance of opensips to test with. You can then run it with output to stderr and capture that in a file. Then search the debug for <ACK> which is where the ACK processing starts.