Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay
Răzvan Crainea wrote: The default uas scenario of sipp does not properly treat Record-Route. If you are using it, you should drop it and write your own scenario that does handle RR, just as Ben suggested. Thanks everyone for helping on this thread! I have replaced the SIPp UAS with FreeSWITCH () and that works now well; no config change in OpenSIPS necessary. And it gives me a bit more flexibility for future extensions. Thomas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay
Hi, Ben! The default uas scenario of sipp does not properly treat Record-Route. If you are using it, you should drop it and write your own scenario that does handle RR, just as Ben suggested. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 10/13/22 16:11, Ben Newlin wrote: Our servers also use double Record-Route headers and we have always used SIPp in our testing with no issues. There are no inherent faults in the most recent version of SIPp with Record-Route/Route handling as far as I know. As long as you are properly setting “rrs=true” on the received INVITE, and including the “” variable in your replies it all works perfectly. https://sipp.sourceforge.net/doc/reference.html#Actions <https://sipp.sourceforge.net/doc/reference.html#Actions> Ben Newlin *From: *Users on behalf of Thomas Pircher via Users *Date: *Thursday, October 13, 2022 at 4:26 AM *To: *users@lists.opensips.org *Cc: *John Quick *Subject: *Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay EXTERNAL EMAIL - Please use caution with links and attachments John Quick wrote: >The UAS at 10.30.9.11 has failed to process the two Record-Route headers >sent in the INVITE. It should send the Route Set back as part of the >Response - i.e. within the 200 OK. But it hasn't. It has just absorbed the >Record-Route headers and ignored them. I would say that is faulty UAS >behaviour, but maybe Bogdan could confirm. Hi John, thanks for the reply. Your explanation makes sense to me; I can see that in the packet capture file, in the replies from the UAS in packets 4 and 6. Also, your article explains why OpenSIPS adds two RR headers in this scenario. >Consequently, the ACK has no Route headers. That means OpenSIPS is treated >as the final destination - it doesn't know that it is meant to relay the ACK >to 10.30.9.11 Now I have the right keywords to search for some more information; it looks like there was an attempt to fix this in 2006: https://sourceforge.net/p/sipp/mailman/sipp-users/thread/200606071744.k57HiPJ4002550%40mail.zserv.tuwien.ac.at/#msg9012298 <https://sourceforge.net/p/sipp/mailman/sipp-users/thread/200606071744.k57HiPJ4002550%40mail.zserv.tuwien.ac.at/#msg9012298> But then there is http://yuminstallgit.blogspot.com/2011/03/record-route-and-route-fun-in-sipp.html <http://yuminstallgit.blogspot.com/2011/03/record-route-and-route-fun-in-sipp.html> and the comment from 2021 at the end suggests others have seen the same issue relatively recently. >If you can't fix the UAS, you could try using the Topology hiding module in >OpenSIPS. That would probably overcome the problem because Topology hiding >doesn't send Record-Route headers downstream. That gives me a few options; I'll try replacing the SIPp UAS with FreeSWITCH. This may sound a bit over-engineered, as all I need is a machine that automatically answers calls to a bunch of usernames and plays an audio file. But it gives me a scenario that vaguely resembles a real-world setup, to test against. Thanks, Thomas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users <http://lists.opensips.org/cgi-bin/mailman/listinfo/users> ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay
Our servers also use double Record-Route headers and we have always used SIPp in our testing with no issues. There are no inherent faults in the most recent version of SIPp with Record-Route/Route handling as far as I know. As long as you are properly setting “rrs=true” on the received INVITE, and including the “” variable in your replies it all works perfectly. https://sipp.sourceforge.net/doc/reference.html#Actions Ben Newlin From: Users on behalf of Thomas Pircher via Users Date: Thursday, October 13, 2022 at 4:26 AM To: users@lists.opensips.org Cc: John Quick Subject: Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay EXTERNAL EMAIL - Please use caution with links and attachments John Quick wrote: >The UAS at 10.30.9.11 has failed to process the two Record-Route headers >sent in the INVITE. It should send the Route Set back as part of the >Response - i.e. within the 200 OK. But it hasn't. It has just absorbed the >Record-Route headers and ignored them. I would say that is faulty UAS >behaviour, but maybe Bogdan could confirm. Hi John, thanks for the reply. Your explanation makes sense to me; I can see that in the packet capture file, in the replies from the UAS in packets 4 and 6. Also, your article explains why OpenSIPS adds two RR headers in this scenario. >Consequently, the ACK has no Route headers. That means OpenSIPS is treated >as the final destination - it doesn't know that it is meant to relay the ACK >to 10.30.9.11 Now I have the right keywords to search for some more information; it looks like there was an attempt to fix this in 2006: https://sourceforge.net/p/sipp/mailman/sipp-users/thread/200606071744.k57HiPJ4002550%40mail.zserv.tuwien.ac.at/#msg9012298 But then there is http://yuminstallgit.blogspot.com/2011/03/record-route-and-route-fun-in-sipp.html and the comment from 2021 at the end suggests others have seen the same issue relatively recently. >If you can't fix the UAS, you could try using the Topology hiding module in >OpenSIPS. That would probably overcome the problem because Topology hiding >doesn't send Record-Route headers downstream. That gives me a few options; I'll try replacing the SIPp UAS with FreeSWITCH. This may sound a bit over-engineered, as all I need is a machine that automatically answers calls to a bunch of usernames and plays an audio file. But it gives me a scenario that vaguely resembles a real-world setup, to test against. Thanks, Thomas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay
Bogdan-Andrei Iancu wrote: Sorry, my wireshark is not able to open that pcap :(, complains on a unknown command or so :(. Try exportting the pcap as SIP text only. HI Bogdam-Andrei, I think newer versions of libpcap appear to use some backwards-incompatible fields. The trace was captured with tcpdump version 4.99.0, using libpcap version 1.10.0. I have attached the same trace with only the UDP payload exported as text, using: tshark -r opensips-any.pcap -T fields -e udp.payload | while read payload; do echo $payload | xxd -r -p; echo ===; done John in the other sub-thread seems to be onto something: the SIPp UAS does not appear to send RR headers with its responses, which might be the cause of these problems. Thanks, Thomas INVITE sip:5678@10.30.8.201:5060 SIP/2.0 Via: SIP/2.0/UDP 10.30.8.204:5060;branch=z9hG4bK-8000-1-0 From: sipp ;tag=1 To: sut Call-ID: 1-8000@10.30.8.204 CSeq: 1 INVITE Contact: sip:sipp@10.30.8.204:5060 Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: 188 v=0 o=user1 53655765 2353687637 IN IP4 10.30.8.204 s=- c=IN IP4 10.30.8.204 t=0 0 m=audio 6000 RTP/AVP 8 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11,16 === SIP/2.0 100 Giving it a try Via: SIP/2.0/UDP 10.30.8.204:5060;branch=z9hG4bK-8000-1-0 To: sut From: sipp ;tag=1 Call-ID: 1-8000@10.30.8.204 CSeq: 1 INVITE Server: OpenSIPS (3.3.1 (x86_64/linux)) Content-Length: 0 === INVITE sip:5678@10.30.8.201:5060 SIP/2.0 Record-Route: Record-Route: Via: SIP/2.0/UDP 10.30.9.10:5060;branch=z9hG4bK659a.b3ed2224.0 Via: SIP/2.0/UDP 10.30.8.204:5060;branch=z9hG4bK-8000-1-0 From: sipp ;tag=1 To: sut Call-ID: 1-8000@10.30.8.204 CSeq: 1 INVITE Contact: sip:sipp@10.30.8.204:5060 Max-Forwards: 69 Subject: Performance Test Content-Type: application/sdp Content-Length: 205 v=0 o=user1 53655765 2353687637 IN IP4 10.30.9.10 s=- c=IN IP4 10.30.9.10 t=0 0 m=audio 42160 RTP/AVP 8 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11,16 a=nortpproxy:yes === SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.30.9.10:5060;branch=z9hG4bK659a.b3ed2224.0, SIP/2.0/UDP 10.30.8.204:5060;branch=z9hG4bK-8000-1-0 From: sipp ;tag=1 To: sut ;tag=5014SIPpTag0111 Call-ID: 1-8000@10.30.8.204 CSeq: 1 INVITE Contact: Content-Length: 0 === SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.30.8.204:5060;branch=z9hG4bK-8000-1-0 From: sipp ;tag=1 To: sut ;tag=5014SIPpTag0111 Call-ID: 1-8000@10.30.8.204 CSeq: 1 INVITE Contact: Content-Length: 0 === SIP/2.0 200 OK Via: SIP/2.0/UDP 10.30.9.10:5060;branch=z9hG4bK659a.b3ed2224.0, SIP/2.0/UDP 10.30.8.204:5060;branch=z9hG4bK-8000-1-0 From: sipp ;tag=1 To: sut ;tag=5014SIPpTag0111 Call-ID: 1-8000@10.30.8.204 CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 170 v=0 o=user1 53655765 2353687637 IN IP4 10.30.9.11 s=- c=IN IP4 10.30.9.11 t=0 0 m=audio 1222 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 === SIP/2.0 200 OK Via: SIP/2.0/UDP 10.30.8.204:5060;branch=z9hG4bK-8000-1-0 From: sipp ;tag=1 To: sut ;tag=5014SIPpTag0111 Call-ID: 1-8000@10.30.8.204 CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 191 v=0 o=user1 53655765 2353687637 IN IP4 10.30.8.201 s=- c=IN IP4 10.30.8.201 t=0 0 m=audio 42464 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=nortpproxy:yes === ACK sip:5678@10.30.8.201:5060 SIP/2.0 Via: SIP/2.0/UDP 10.30.8.204:5060;branch=z9hG4bK-8000-1-4 From: sipp ;tag=1 To: sut ;tag=5014SIPpTag0111 Call-ID: 1-8000@10.30.8.204 CSeq: 1 ACK Contact: sip:sipp@10.30.8.204:5060 Max-Forwards: 70 Subject: Performance Test Content-Length: 0 === SIP/2.0 200 OK Via: SIP/2.0/UDP 10.30.9.10:5060;branch=z9hG4bK659a.b3ed2224.0, SIP/2.0/UDP 10.30.8.204:5060;branch=z9hG4bK-8000-1-0 From: sipp ;tag=1 To: sut ;tag=5014SIPpTag0111 Call-ID: 1-8000@10.30.8.204 CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 170 v=0 o=user1 53655765 2353687637 IN IP4 10.30.9.11 s=- c=IN IP4 10.30.9.11 t=0 0 m=audio 1222 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 === SIP/2.0 200 OK Via: SIP/2.0/UDP 10.30.8.204:5060;branch=z9hG4bK-8000-1-0 From: sipp ;tag=1 To: sut ;tag=5014SIPpTag0111 Call-ID: 1-8000@10.30.8.204 CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 191 v=0 o=user1 53655765 2353687637 IN IP4 10.30.8.201 s=- c=IN IP4 10.30.8.201 t=0 0 m=audio 42464 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=nortpproxy:yes === ACK sip:5678@10.30.8.201:5060 SIP/2.0 Via: SIP/2.0/UDP 10.30.8.204:5060;branch=z9hG4bK-8000-1-4 From: sipp ;tag=1 To: sut ;tag=5014SIPpTag0111 Call-ID: 1-8000@10.30.8.204 CSeq: 1 ACK Contact: sip:sipp@10.30.8.204:5060 Max-Forwards: 70 Subject: Performance Test Content-Length: 0 === SIP/2.0 200 OK Via: SIP/2.0/UDP 10.30.9.10:5060;branch=z9hG4bK659a.b3ed2224.0, SIP/2.0/UDP 10.30.8.204:5060;branch=z9hG4bK-8000-1-0 From: sipp ;tag=1 To: sut ;tag=5014SIPpTag0111 Call-ID: 1-8000@10.30.8.204 CS
Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay
John Quick wrote: The UAS at 10.30.9.11 has failed to process the two Record-Route headers sent in the INVITE. It should send the Route Set back as part of the Response - i.e. within the 200 OK. But it hasn't. It has just absorbed the Record-Route headers and ignored them. I would say that is faulty UAS behaviour, but maybe Bogdan could confirm. Hi John, thanks for the reply. Your explanation makes sense to me; I can see that in the packet capture file, in the replies from the UAS in packets 4 and 6. Also, your article explains why OpenSIPS adds two RR headers in this scenario. Consequently, the ACK has no Route headers. That means OpenSIPS is treated as the final destination - it doesn't know that it is meant to relay the ACK to 10.30.9.11 Now I have the right keywords to search for some more information; it looks like there was an attempt to fix this in 2006: https://sourceforge.net/p/sipp/mailman/sipp-users/thread/200606071744.k57HiPJ4002550%40mail.zserv.tuwien.ac.at/#msg9012298 But then there is http://yuminstallgit.blogspot.com/2011/03/record-route-and-route-fun-in-sipp.html and the comment from 2021 at the end suggests others have seen the same issue relatively recently. If you can't fix the UAS, you could try using the Topology hiding module in OpenSIPS. That would probably overcome the problem because Topology hiding doesn't send Record-Route headers downstream. That gives me a few options; I'll try replacing the SIPp UAS with FreeSWITCH. This may sound a bit over-engineered, as all I need is a machine that automatically answers calls to a bunch of usernames and plays an audio file. But it gives me a scenario that vaguely resembles a real-world setup, to test against. Thanks, Thomas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay
Hi Thomas, Sorry, my wireshark is not able to open that pcap :(, complains on a unknown command or so :(. Try exportting the pcap as SIP text only. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 10/11/22 6:07 PM, Thomas Pircher via Users wrote: Thomas Pircher via Users wrote: sure, please find the trace attached. This was captured using sudo tcpdump -lnn -i any udp port 5060 -w opensips-any.pcap i.e. it contains both OpenSIPS interfaces in one file: - ens4, 10.30.8.201, external - ens5, 10.30.9.10, internal The other IPs are: - 10.30.8.204: sipp uac - 10.30.9.11: sipp uas This time with actual attachment; sorry... Thomas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay
++ John. On 12/10/2022 18:29, John Quick wrote: Thomas, The UAS at 10.30.9.11 has failed to process the two Record-Route headers sent in the INVITE. It should send the Route Set back as part of the Response - i.e. within the 200 OK. But it hasn't. It has just absorbed the Record-Route headers and ignored them. I would say that is faulty UAS behaviour, but maybe Bogdan could confirm. Consequently, the ACK has no Route headers. That means OpenSIPS is treated as the final destination - it doesn't know that it is meant to relay the ACK to 10.30.9.11 If you can't fix the UAS, you could try using the Topology hiding module in OpenSIPS. That would probably overcome the problem because Topology hiding doesn't send Record-Route headers downstream. John Quick Smartvox Limited Web: www.smartvox.co.uk ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay
Thomas, The UAS at 10.30.9.11 has failed to process the two Record-Route headers sent in the INVITE. It should send the Route Set back as part of the Response - i.e. within the 200 OK. But it hasn't. It has just absorbed the Record-Route headers and ignored them. I would say that is faulty UAS behaviour, but maybe Bogdan could confirm. Consequently, the ACK has no Route headers. That means OpenSIPS is treated as the final destination - it doesn't know that it is meant to relay the ACK to 10.30.9.11 If you can't fix the UAS, you could try using the Topology hiding module in OpenSIPS. That would probably overcome the problem because Topology hiding doesn't send Record-Route headers downstream. John Quick Smartvox Limited Web: www.smartvox.co.uk ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay
Thomas Pircher via Users wrote: sure, please find the trace attached. This was captured using sudo tcpdump -lnn -i any udp port 5060 -w opensips-any.pcap i.e. it contains both OpenSIPS interfaces in one file: - ens4, 10.30.8.201, external - ens5, 10.30.9.10, internal The other IPs are: - 10.30.8.204: sipp uac - 10.30.9.11: sipp uas This time with actual attachment; sorry... Thomas opensips-any.pcap Description: application/vnd.tcpdump.pcap ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay
Bogdan-Andrei Iancu wrote: Could you post a pcap or ngrep capture of the failing call (with the broken ACK) - PM me if info is too sensitive. Hi Bogdan-Andrei, sure, please find the trace attached. This was captured using sudo tcpdump -lnn -i any udp port 5060 -w opensips-any.pcap i.e. it contains both OpenSIPS interfaces in one file: - ens4, 10.30.8.201, external - ens5, 10.30.9.10, internal The other IPs are: - 10.30.8.204: sipp uac - 10.30.9.11: sipp uas Thanks, Thomas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay
Hi Thomas, Could you post a pcap or ngrep capture of the failing call (with the broken ACK) - PM me if info is too sensitive. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 10/11/22 12:06 PM, Thomas Pircher via Users wrote: Bogdan-Andrei Iancu wrote: Hi Thomas, Your handling of sequential requests is broken, see here for a correct sample: https://github.com/OpenSIPS/opensips/blob/master/etc/opensips.cfg#L109 Hi Bogdan-Andrei, thanks for your reply. I had a look at my config (both the config attached to the first mail, and the fragment in my second mail) and it does match -- modulo whitespace changes and one additional route[byNumber] -- the config in git. The bracket placement in the config fragment in my second mail was misleading, I made a copy&paste error, that might have created a confusion? Or is there something I continue missing when I read and compare the config files? Thanks, Thomas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay
Bogdan-Andrei Iancu wrote: Hi Thomas, Your handling of sequential requests is broken, see here for a correct sample: https://github.com/OpenSIPS/opensips/blob/master/etc/opensips.cfg#L109 Hi Bogdan-Andrei, thanks for your reply. I had a look at my config (both the config attached to the first mail, and the fragment in my second mail) and it does match -- modulo whitespace changes and one additional route[byNumber] -- the config in git. The bracket placement in the config fragment in my second mail was misleading, I made a copy&paste error, that might have created a confusion? Or is there something I continue missing when I read and compare the config files? Thanks, Thomas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay and rtpproxy
John Quick wrote: ACK messages are normally loose routed. Perhaps you need to call loose_route() before t_relay(). You could try reading my article here which may help explain things: https://kb.smartvox.co.uk/opensips/contact-and-record-route-headers-explained/ Hi John, thanks for the reply and sorry for the late response. Your articles are quite informative, they made a few bits clearer. I tried tracing the sequence diagram from your page on the opensips.cfg file attached in my first post, and I believe all the necessary bits are there -- I have taken the residential configuration from the config generator and added an additiona "route[byNumber]" in the flow. Unless I'm missing something when looking at the config file, I do believe my config does match the flow you described. However, I have not looked at the headers in the trace in detail, perhaps that's where my problem lies? Thanks, Thomas ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay and rtpproxy
Hi Thomas, Your handling of sequential requests is broken, see here for a correct sample: https://github.com/OpenSIPS/opensips/blob/master/etc/opensips.cfg#L109 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/30/22 11:07 AM, Thomas Pircher via Users wrote: Thomas Pircher wrote: The problem I am seeing is when I initiate a connection from the sipp client then I see RTP flowing only in one direction (sipp client to sipp server). I believe this is due to a missing ACK from OpenSIPS to the sipp server following the 200 OK. Hi, I no longer think the rtpproxy is part of the problem. I believe this is purely an issue with my t_relay configuration. I did some more tests, and I think the issue is that the ACK from the sipp client at 10.30.8.203 is discarded by OpenSIPS, and therefore the OpenSIPS does not send the ACK to the sipp server on the internal interface. This would also explain the "404 Not here" response to the BYE at the end of the connection: ┌───┐ ┌─┐ ┌─┐ ┌───┐ │sipp client│ │OpenSIPS external│ │OpenSIPS internal│ │sipp server│ │10.30.8.203│ │10.30.8.201 │ │10.30.9.10 │ │10.30.90.11│ └─┬─┘ └┬┘ └┬┘ └─┬─┘ │ INVITE SDP (g711A) │ │ │ │──>│ │ │ │ │ │ │ │ 100 Giving it a try │ │ │ │<──│ │ │ │ │ │ │ │ │ │ INVITE SDP (g711A) │ │ │ │──>│ │ │ │ │ │ │ │ 180 Ringing │ │ │ │<──│ │ │ │ │ │ 180 Ringing │ │ │ │<──│ │ │ │ │ │ │ │ │ │200 OK SDP (g711A telephone-event) │ │ │ │<──│ │ │ │ │ │200 OK SDP (g711A telephone-event) │ │ │ │<──│ │ │ │ │ │ │ │ ACK │ │ │ │──>│ │ │ │ │ │ │ │ │ │200 OK SDP (g711A telephone-event) │ │ │ │<──│ │ │ │ │ │200 OK SDP (g711A telephone-event) │ │ │ │<──│ │ │ │ │ │ │ │ ACK │ │ │ │──>│ │ │ │ │ │ │ │ │ │200 OK SDP (g711A telephone-event) │ │ │ │<──│ │ │ │ │ │200 OK SDP (g711A telephone-event) │ │ │ │<──│ │ │ │ │ │ │ │ ACK │ │ │ │──>│ │ │ │ │ │ │ │ │ │200 OK SDP (g711A telephone-event) │ │ │ │<──│ │ │ │ │ │200 OK SDP (g711A telephone-event) │ │ │ │<──│ │ │ │ │ │ │ │ ACK │ │ │ │──>│ │ │ │ │ │ │ │ │ │200 OK SDP (g711A telephone-event) │ │ │ │<──│ │ │ │ │ │ BYE │ │ │ │──>│ │ │ │ │ │ │ │ 404 Not here │
Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay and rtpproxy
Thomas, ACK messages are normally loose routed. Perhaps you need to call loose_route() before t_relay(). You could try reading my article here which may help explain things: https://kb.smartvox.co.uk/opensips/contact-and-record-route-headers-explaine d/ John Quick Smartvox Limited Web: www.smartvox.co.uk ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Problem proxying a SIP connection with t_relay and rtpproxy
Thomas Pircher wrote: The problem I am seeing is when I initiate a connection from the sipp client then I see RTP flowing only in one direction (sipp client to sipp server). I believe this is due to a missing ACK from OpenSIPS to the sipp server following the 200 OK. Hi, I no longer think the rtpproxy is part of the problem. I believe this is purely an issue with my t_relay configuration. I did some more tests, and I think the issue is that the ACK from the sipp client at 10.30.8.203 is discarded by OpenSIPS, and therefore the OpenSIPS does not send the ACK to the sipp server on the internal interface. This would also explain the "404 Not here" response to the BYE at the end of the connection: ┌───┐┌─┐ ┌─┐┌───┐ │sipp client││OpenSIPS external│ │OpenSIPS internal││sipp server│ │10.30.8.203││10.30.8.201 │ │10.30.9.10 ││10.30.90.11│ └─┬─┘└┬┘ └┬┘└─┬─┘ │INVITE SDP (g711A) ││ │ │──>││ │ │ ││ │ │ 100 Giving it a try ││ │ │<──││ │ │ ││ │ │ ││ INVITE SDP (g711A) │ │ │ │──>│ │ ││ │ │ ││ 180 Ringing │ │ │ │<──│ │ ││ │ │ 180 Ringing ││ │ │<──││ │ │ ││ │ │ ││200 OK SDP (g711A telephone-event) │ │ │ │<──│ │ ││ │ │200 OK SDP (g711A telephone-event) ││ │ │<──││ │ │ ││ │ │ ACK ││ │ │──>││ │ │ ││ │ │ ││200 OK SDP (g711A telephone-event) │ │ │ │<──│ │ ││ │ │200 OK SDP (g711A telephone-event) ││ │ │<──││ │ │ ││ │ │ ACK ││ │ │──>││ │ │ ││ │ │ ││200 OK SDP (g711A telephone-event) │ │ │
[OpenSIPS-Users] Problem proxying a SIP connection with t_relay and rtpproxy
Hi,
I'm trying to set up an OpenSIPS 3.2.6 server that is connected to two networks
and I'd like to proxy SIP and RTP through the OpenSIPS server.
The OpenSIPS server is sitting on these two networks:
- 10.30.8.0/24: network with the sipp client
- 10.30.9.0/24: network with the sipp server
A crude network diagram is here:
[ 10.30.8.203 (sipp client) ][ 10.30.8.201 (OpenSIPS) 10.30.9.10 ]---[
10.30.9.11 (sipp server) ]
The problem I am seeing is when I initiate a connection from the sipp
client then I see RTP flowing only in one direction (sipp client to sipp
server). I believe this is due to a missing ACK from OpenSIPS to the
sipp server following the 200 OK.
This is a tcpdump on the client side:
12:54:38.891222 IP 10.30.8.203.5060 > 10.30.8.201.5060: SIP: INVITE
sip:5678@10.30.8.201:5060 SIP/2.0
12:54:38.895104 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 100 Giving
it a try
12:54:38.896523 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 180 Ringing
12:54:38.898255 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 200 OK
12:54:38.899385 IP 10.30.8.203.5060 > 10.30.8.201.5060: SIP: ACK
sip:5678@10.30.8.201:5060 SIP/2.0
12:54:39.398922 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 200 OK
12:54:39.399489 IP 10.30.8.203.5060 > 10.30.8.201.5060: SIP: ACK
sip:5678@10.30.8.201:5060 SIP/2.0
12:54:40.403883 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 200 OK
12:54:40.404357 IP 10.30.8.203.5060 > 10.30.8.201.5060: SIP: ACK
sip:5678@10.30.8.201:5060 SIP/2.0
12:54:42.407114 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 200 OK
12:54:42.407652 IP 10.30.8.203.5060 > 10.30.8.201.5060: SIP: ACK
sip:5678@10.30.8.201:5060 SIP/2.0
12:54:47.910201 IP 10.30.8.203.5060 > 10.30.8.201.5060: SIP: BYE
sip:5678@10.30.8.201:5060 SIP/2.0
12:54:47.910373 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 404 Not
here
12:54:47.911090 IP 10.30.8.203.5060 > 10.30.8.201.5060: SIP: BYE
sip:5678@10.30.8.201:5060 SIP/2.0
12:54:47.911287 IP 10.30.8.201.5060 > 10.30.8.203.5060: SIP: SIP/2.0 404 Not
here
And on the network with the sipp server:
12:54:38.895726 IP 10.30.9.10.5060 > 10.30.9.11.5060: SIP: INVITE
sip:5678@10.30.8.201:5060 SIP/2.0
12:54:38.895931 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 180 Ringing
12:54:38.897219 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK
12:54:39.397731 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK
12:54:40.401824 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK
12:54:42.406023 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK
12:54:46.410604 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK
12:54:50.414512 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK
12:54:54.418603 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK
12:54:58.422011 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK
12:55:02.422177 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK
12:55:06.425519 IP 10.30.9.11.5060 > 10.30.9.10.5060: SIP: SIP/2.0 200 OK
I would expect an ACK from OpenSIPS to the sipp server, after the first
200 OK, right?
The full OpenSIPS config is attached. Some salient bits of the configuration
are:
/* The server is multi-homed */
mhomed=1
socket=udp:10.30.9.10:5060
socket=udp:10.30.8.201:5060
...
rtpproxy
loadmodule "dialog.so"
loadmodule "rtp_relay.so"
loadmodule "rtpproxy.so"
# RTP proxy to 10.30.8.0/24
modparam("rtpproxy", "rtpproxy_sock", "0 == udp:localhost:2")
...
route {
...
route(byNumber);
...
}
route[byNumber] {
xlog("L_NOTICE", "Routing by Numbers ru=$rU fu=$fU tu=$tU ou=$oU\n");
#Simulated VoIP phones: sipp
if ($tU =~ "^567[0-9]{1,5}$")
{
route(SimVoIP);
exit;
}
}
route[SimVoIP] {
xlog("SimVoIP $rm: $si:$sp -> $ru\n");
# If coming from the Chassis to the VoIP network.
if ($si =~ "^10.159.60." || $si =~ "^10.30.8.") {
if (is_method("INVITE") && !has_totag()) {
create_dialog();
$rtp_relay = "coeir"; # check the RTPProxy documentation for the
meaning of these (optional) flags
$rtp_relay_peer = "coier"; # do the same thing for the callee
rtp_relay_engage("rtpproxy", 0);
}
}
if (!t_relay(, "udp:10.30.9.11:5060")) {
sl_reply_error();
}
exit;
}
...
I have briefly experimented with B2Bua top hiding, but I must have
gotten things quite wrong, as every connection ended i a flood of error
messages (ERROR:b2b_entities:b2b_send_reply: Tm transaction not saved!).
So I went down the t_relay option, as it sounded simpler.
Any help to how to fix this is greatly appreciated. Be gentle, I'm
relatively new to OpenSIPS, so I might have gotten quite a few bits
wrong.
Thanks,
Thomas
#
# OpenSIPS residential configuration script
# by OpenSIPS Solutions
#
# This script was generated via "make menuconfig", from
# the "Residential" scenario.
# You can enable / disable more features / functionalities
