Pcap is at: https://drive.google.com/open?id=0B9DgmCf1HtSbVlFRUkdnLV90cHM
Only Scenario 23 (using the uac.xml) captured packets to/from the proxy. Robert Remsik ACNS Desk Phone: 970 491 7120 robert.rem...@colostate.edu ________________________________ From: Remsik,Robert <robert.rem...@colostate.edu> Sent: Friday, August 5, 2016 11:09 AM To: sindelka; sipp-users@lists.sourceforge.net Subject: Re: [Sipp-users] Troubleshooting a basic call Scenario A - Correct; the switch feeds one vlan untagged and one vlan tagged (with PoE and lldp media) towards the phone. From there the phone registers and uses the tagged vlan for itself while passing the other vlan on towards the sipp computer. They are not on the same subnet. I'll look into the ACLs again. Scenario B - Yes the phone does respond to the proxy. Let me gather the pcap again with the proper test case#. Scenario C - Office365 does not support SIP over UDP, they are TLS or nothing. If I can't make sipp work over TLS there are still applications I can use it for inside work without TLS. For example scripting a monthly 'test all of our use-cases to make sure nothing broke when we weren't looking'. UDP/TCP - Removing the transport=tcp didn't seem to have much effect - tcpdump still showed the packets as UDP. Testing has gotten complex enough that I've created a spread-sheet to track what calls/configurations did what. ( https://docs.google.com/spreadsheets/d/1HJi8zI684knz7VI7Fws1rrdMZZbfJ_H4-wItgV9d_Xs/edit?usp=sharing ) My version of sipp is: SIPp v3.3-TLS-SCTP-PCAP, built Aug 18 2014, 18:09:56. compiled from source on Fedora Core 21. Should I look into updating to the latest from dnf? Robert Remsik ACNS Desk Phone: 970 491 7120 robert.rem...@colostate.edu ________________________________ From: sindelka <sinde...@ttc.cz> Sent: Thursday, August 4, 2016 3:27 PM To: Remsik,Robert; sipp-users@lists.sourceforge.net Subject: Re: [Sipp-users] Troubleshooting a basic call Scenario A - "fed off phone" means that the phone has two LAN ports, one towards the switch and to the other one your SIPp-running machine is connected? (sorry, tongue mother my not is English ;-) ) If so, are the IPs of the phone and of your SIPp machine in the same subnet? Basic question, I know, but I don't get why the phone should react on the INVITE but send nothing back. It is not a case of firewall on the SIPp machine because tcpdump would show you the packet even if the firewall wouldn't let it through to SIPp. So I can only imagine some misrouting, causing the packets for 129.82.3.26 to be sent to a blackhole somewhere between the phone and the SIPp machine. Scenario B - you haven't explicitly stated whether the phone sends the responses to the proxy. If it does and only the proxy does not forward these responses to the SIPp machine, can you attach the pcap? Scenario C - here, an "office365 SBC" makes me cautious, as Microsoft's Lync only supports SIP over TCP, so are you sure the office365 SBC supports SIP over UDP as well? P. Dne 4.8.2016 v 23:08 Remsik,Robert napsal(a): Thank you again for your help! 1. :D 2. Ah! Sorry, I was tinkering on a second test.xml(based on uac.xml) and checking to see if that had the same issue & I copied+pasted from the wrong screen. Here is the test-case I'm working on again below. 3. ... goes back to verify protocol validation is enabled... Yup, TCP and UDP are enabled and they are valid packets so it may be my tcpdump is being funky. My topology/test-cases for reference. All of them are returning the same SIPp results. Having typed out the scenarios I'm wondering if sipp is doing it's job right but I don't understand how to format the options for the xml. [-s who-I'm-calling] [-au myPhoneNumber(for authentication)] [-ap myPhonePassword(for authentication)] and that's it? Scenario A: Computer running sipp to my desk phone (Test case only) - my computer is fed off phone so I can't simplify this test-case any further(at least not that I know of). Having sipp directly call the phone I can get the phone to ring, appear to answer(as far as the phone's UI shows) but sipp doesn't see the 100 or anything beyond. Scenario B: Computer running sipp to production proxy to my desk phone (Test case only) - I needed to do this so I could capture packets via wireshark. I see the traffic from sipp to the proxy, and then the proxy to the phones; but no traffic from the proxy back to sipp. According to the phone UI it rings and appears to pick up(and will even forward to my cell if I let it ring) but again sipp doesn't see any of this. Scenario C: Computer running sipp to production proxy to voicemail(which is routed through office365 SBC) - This is the test-case I'm trying to work on, the others are to help reduce variables. I see the 100 invite from sipp to the proxy; and that's it wireshark doesn't see anything more(it's positioned reading data to/from my phone). --- 100 Invite from Scenario C --- 15:03:29.894306 IP (tos 0x0, ttl 64, id 45171, offset 0, flags [DF], proto UDP (17), length 893) 129.82.3.26.sip > 129.82.254.250.sip: [bad udp cksum 0x0834 -> 0x3a2e!] SIP, length: 865 INVITE sip:15500@129.82.254.250;user=phone;transport=tcp SIP/2.0 Via: SIP/2.0/UDP 129.82.3.26;branch=z9hG4bK-28277-1-0 From: "Robert Remsik" <sip:17...@otc.colostate.edu><sip:17...@otc.colostate.edu>;tag=1 To: <sip:15500@129.82.254.250;user=phone><sip:15500@129.82.254.250;user=phone> CSeq: 1 INVITE Call-ID: 1-28277@129.82.3.26<mailto:1-28277@129.82.3.26> Contact: <sip:17120@129.82.3.26;transport=UDP><sip:17120@129.82.3.26;transport=UDP> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER User-Agent: PolycomVVX-VVX_410-UA/4.1.8.0628 Accept-Language: en Supported: 100rel,replaces Allow-Events: conference,talk,hold Max-Forwards: 70 Content-Type: application/sdp Content-Length: 245 v=0 o=- 1470166919 1470166919 IN IP4 129.82.3.26 s=Polycom IP Phone c=IN IP4 129.82.3.26 t=0 0 a=sendrecv m=audio 6000 RTP/AVP 9 0 8 101 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 --- 100 Invite from Scenario C --- My TCPdump version for reference to future generations: root@localhost:~ $ yum list | grep tcpdump tcpdump.x86_64 14:4.7.4-2.fc21 @updates Messages Retrans Timeout Unexpected-Msg INVITE ----------> 1 0 100 <---------- 0 0 0 0 401 <---------- 0 0 0 0 407 <---------- 0 0 0 0 ACK ----------> 0 0 INVITE ----------> 0 0 100 <---------- 0 0 0 0 ---- test1.xml ---- <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE scenario SYSTEM "sipp.dtd"> <scenario name="Default scenario"> <send> <![CDATA[ INVITE sip:[service]@[remote_ip];user=phone;transport=tcp SIP/2.0 Via: SIP/2.0/[transport] [local_ip];branch=[branch] From: "Robert Remsik" <sip:17...@otc.colostate.edu><sip:17...@otc.colostate.edu>;tag=[call_number] To: <sip:[service]@[remote_ip];user=phone><sip:[service]@[remote_ip];user=phone> CSeq: [cseq] INVITE Call-ID: [call_id] Contact: <sip:17120@[local_ip];transport=[transport]><sip:17120@[local_ip];transport=[transport]> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER User-Agent: PolycomVVX-VVX_410-UA/4.1.8.0628 Accept-Language: en Supported: 100rel,replaces Allow-Events: conference,talk,hold Max-Forwards: 70 Content-Type: application/sdp Content-Length: [len] v=0 o=- 1470166919 1470166919 IN IP[local_ip_type] [local_ip] s=Polycom IP Phone c=IN IP[media_ip_type] [media_ip] t=0 0 a=sendrecv m=audio [media_port] RTP/AVP 9 0 8 101 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 ]]> </send> <recv response="100" optional="true"/> <recv response="401" optional="true" auth="true" next="auth_challenge_received"/> <recv response="407" auth="true"/> <label id="auth_challenge_received"/> <send> <![CDATA[ ACK sip:[service]@[remote_ip];user=phone;transport=tcp SIP/2.0 Via: SIP/2.0/[transport] [local_ip];branch=[branch] From: "Robert Remsik" <sip:17...@otc.colostate.edu><sip:17...@otc.colostate.edu>;tag=[call_number] To: <sip:[service]@[remote_ip];user=phone><sip:[service]@[remote_ip];user=phone>;[peer_tag_param] CSeq: [cseq] ACK Call-ID: [call_id] Contact: <sip:17120@[local_ip];transport=[transport]><sip:17120@[local_ip];transport=[transport]> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER User-Agent: PolycomVVX-VVX_410-UA/4.1.8.0628 Accept-Language: en Max-Forwards: 70 Content-Length: 0 ]]> </send> <send> <![CDATA[ INVITE sip:[service]@[remote_ip];user=phone;transport=tcp SIP/2.0 Via: SIP/2.0/[transport] [local_ip];branch=[branch] From: "Robert Remsik" <sip:17...@otc.colostate.edu><sip:17...@otc.colostate.edu>;tag=[call_number] To: <sip:[service]@[remote_ip];user=phone><sip:[service]@[remote_ip];user=phone> CSeq: [cseq] INVITE Call-ID: [call_id] Contact: <sip:17120@[local_ip];transport=[transport]><sip:17120@[local_ip];transport=[transport]> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER User-Agent: PolycomVVX-VVX_410-UA/4.1.8.0628 Accept-Language: en Supported: 100rel,replaces Allow-Events: conference,talk,hold [authentication username="abc" password="abc"] Max-Forwards: 70 Content-Type: application/sdp Content-Length: [len] v=0 o=- 1470166919 1470166919 IN IP[local_ip_type] [local_ip] s=Polycom IP Phone c=IN IP[media_ip_type] [media_ip] t=0 0 a=sendrecv m=audio [media_port] RTP/AVP 9 0 8 101 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 ]]> </send> <recv response="100" optional="true"/> </recv> <recv response="180" optional="true"/> </recv> <recv response="183" optional="true"/> </recv> <recv response="200" /> </recv> <send> <![CDATA[ ACK sip:e4PGFkEVw6krpgtHyWyvFNr4mi60DsxLQcG4Err5hfzg.@[remote_ip];transport=tcp SIP/2.0 Via: SIP/2.0/[transport] [local_ip];branch=[branch] From: "Robert Remsik" <sip:17...@otc.colostate.edu><sip:17...@otc.colostate.edu>;tag=[call_number] To: <sip:[service]@[remote_ip];user=phone><sip:[service]@[remote_ip];user=phone>;[peer_tag_param] Route: <sip:129.82.254.250:5060;lr;sipXecs-CallDest=VM;sipXecs-rs=%2Aauth%7E.%2Afrom%7EODEyRjdFOTMtNzY4ODg1Rjk%60.900_ntap%2Aid%7ENDE4OS04Mjg0%21ea26a124f1f3352fdb0bcb790663f8a6;x-sipX-done><sip:129.82.254.250:5060;lr;sipXecs-CallDest=VM;sipXecs-rs=%2Aauth%7E.%2Afrom%7EODEyRjdFOTMtNzY4ODg1Rjk%60.900_ntap%2Aid%7ENDE4OS04Mjg0%21ea26a124f1f3352fdb0bcb790663f8a6;x-sipX-done> CSeq: [cseq] ACK Call-ID: [call_id] Contact: <sip:17120@[local_ip];transport=[transport]><sip:17120@[local_ip];transport=[transport]> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER User-Agent: PolycomVVX-VVX_410-UA/4.1.8.0628 Accept-Language: en Max-Forwards: 70 Content-Length: 0 ]]> </send> <send> <![CDATA[ BYE sip:e4PGFkEVw6krpgtHyWyvFNr4mi60DsxLQcG4Err5hfzg.@[remote_ip];transport=tcp SIP/2.0 Via: SIP/2.0/[transport] [local_ip];branch=[branch] From: "Robert Remsik" <sip:17...@otc.colostate.edu><sip:17...@otc.colostate.edu>;tag=[call_number] To: <sip:[service]@[remote_ip];user=phone><sip:[service]@[remote_ip];user=phone>;[peer_tag_param] Route: <sip:129.82.254.250:5060;lr;sipXecs-CallDest=VM;sipXecs-rs=%2Aauth%7E.%2Afrom%7EODEyRjdFOTMtNzY4ODg1Rjk%60.900_ntap%2Aid%7ENDE4OS04Mjg0%21ea26a124f1f3352fdb0bcb790663f8a6;x-sipX-done><sip:129.82.254.250:5060;lr;sipXecs-CallDest=VM;sipXecs-rs=%2Aauth%7E.%2Afrom%7EODEyRjdFOTMtNzY4ODg1Rjk%60.900_ntap%2Aid%7ENDE4OS04Mjg0%21ea26a124f1f3352fdb0bcb790663f8a6;x-sipX-done> CSeq: [cseq] BYE Call-ID: [call_id] Contact: <sip:17120@[local_ip]><sip:17120@[local_ip]> User-Agent: PolycomVVX-VVX_410-UA/4.1.8.0628 Accept-Language: en Max-Forwards: 70 Content-Length: 0 ]]> </send> </scenario> ---- test1.xml ---- Robert Remsik ACNS Desk Phone: 970 491 7120 robert.rem...@colostate.edu<mailto:robert.rem...@colostate.edu> ________________________________ From: sindelka <sinde...@ttc.cz><mailto:sinde...@ttc.cz> Sent: Thursday, August 4, 2016 2:28 PM To: Remsik,Robert; sipp-users@lists.sourceforge.net<mailto:sipp-users@lists.sourceforge.net> Subject: Re: [Sipp-users] Troubleshooting a basic call Hi Robert, 1. as written - the long form is the only one possible in many cases; where both can be used, the short one is often preferred by keyboard-savvy (or lazy, like me) people. 2. where has the authentication part (INVITE, 100, 401, 407) gone? Not that its absence would explain why there is no response from the VM, it just differs from the scenario as you've shown it initially. 3. if Wireshark explicitly says that the UDP checksum is correct in the packet dissection pane (not just that it doesn't show the packet in red), then it is possible that your version of tcpdump has an issue with UDP checksum calculation. Otherwise, UDP checksum evaluation is often switched off by default in Wireshark. Go Edit->Preferences->Protocols->UDP and check whether the "validate UDP checksum if possible" is ticked. 4. looking at your /etc/hosts, I don't get how your tcpdump translates 129.82.3.26 to localhost.localdomain, but the source address of the packets seems to be OK, so the UDP checksum is more likely to be the reason why the voicemail does not respond (I suppose that there is no firewall and that the voicemail does listen at UDP/5060). P. Dne 4.8.2016 v 22:03 Remsik,Robert napsal(a): 1. Ah, that helps explain it! Thank you. [??] Is the long form or short form generally preferred? 2. Thank you, that did the trick. It now sees the entire scenario. Messages Retrans Timeout Unexpected-Msg INVITE ----------> 1 5 1 100 <---------- 0 0 0 0 180 <---------- 0 0 0 0 183 <---------- 0 0 0 0 200 <---------- E-RTD1 0 0 0 0 ACK ----------> 0 0 Pause [ 0ms] 0 0 BYE ----------> 0 0 0 200 <---------- 0 0 0 0 3. Interesting... I'll sniff traffic as it exits towards voicemail and verify if it detects a checksum error.... No checksum errors showing up in Wireshark. I'll try to comb through some more logs to see if I can turn anything up. 4. $ grep localhost /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 13:40:50.338851 IP (tos 0x0, ttl 64, id 14685, offset 0, flags [DF], proto UDP (17), length 551) 129.82.3.26.sip > 10.20.128.149.sip: [bad udp cksum 0x113a -> 0x15d2!] SIP, length: 523 INVITE sip:15500@10.20.128.149:5060 SIP/2.0 Via: SIP/2.0/UDP 129.82.3.26:5060;branch=z9hG4bK-21667-1-0 From: sipp <sip:sipp@129.82.3.26:5060><sip:sipp@129.82.3.26:5060>;tag=21667SIPpTag001 To: 15500 <sip:15500@10.20.128.149:5060><sip:15500@10.20.128.149:5060> Call-ID: 1-21667@129.82.3.26<mailto:1-21667@129.82.3.26> CSeq: 1 INVITE Contact: sip:sipp@129.82.3.26:5060 Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: 133 v=0 o=user1 53655765 2353687637 IN IP4 129.82.3.26 s=- c=IN IP4 129.82.3.26 t=0 0 m=audio 6000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Robert Remsik ACNS Desk Phone: 970 491 7120 robert.rem...@colostate.edu<mailto:robert.rem...@colostate.edu> ________________________________ From: sindelka <sinde...@ttc.cz><mailto:sinde...@ttc.cz> Sent: Thursday, August 4, 2016 1:09 PM To: Remsik,Robert; sipp-users@lists.sourceforge.net<mailto:sipp-users@lists.sourceforge.net> Subject: Re: [Sipp-users] Troubleshooting a basic call Robert, 1. adding </recv> after my recv tags which have already been closed by the / right before the closing > was not the right thing to do. SIPp is not really good in detecting wrong syntax in the scenario file, which explains why only the initial INVITE and 100 are displayed on the runtime screen now after your modification. In fact, <recv attribute1="value1" attribute2="value2"/> is equivalent to <recv attribute1="value1" attribute2="value2"> </recv> but shorter. Of course, the longer variant is the only possible one for tags which contain a body, like all cases of send or if the recv contains some action, like ereg. 2. the actual mistake causing SIPp to complain about an undefined label was a typo: a "-" (dash) instead of "_" (underscore) in the label name (after the <recv response="407"/>) 3. the bad UDP checksum is likely to cause the voicemail server not to answer, but I'm not sure it is a SIPp issue - normally, an application sends only the payload to a protocol socket, and the calculation of checksums is a job of the protocol stack in the kernel. If your network card eventually supports UDP checksum offloading, it may be that the error doesn't actually exist, although in such case I would expect the wrong value shown by tcpdump to be 0. To check that, you'll need to capture the packets anywhere else at their way from the sender to the recipient but at the sending machine (because there, the capturing point is before the UDP checksum is calculated if the offloading is used). If you can see the UDP checksum error after the packet has left the sending machine, it is really there and likely to cause the receiving machine's IP stack to drop the packet rather than deliver it to the application. 4. can you please run the tcpdump with -n option added, or place the output of grep localhost /etc/hosts here? It seems strange to me that the packet would have 127.0.0.1 as source address as the localhost.localdomain fqdn suggests, but if it does, the voicemail might to send the responses to itself if it looks at the source address of the request packet rather than at the address given in the Via header. P. Dne 4.8.2016 v 20:34 Remsik,Robert napsal(a): Thank you for the help! This is indeed my base case copy+pasted, just calling into voicemail and then either voicemail hangs up or I hang up. I added the modifications you suggested but I had to add </recv> after each recv tag to have the program not throw an error of: (The label 'auth_challenge_received' was not defined (index 2, next attribute)). However now the scenario only lists an invite and 100 message, not the full scenario that I was expecting. Interestingly the INVITE lists a bad UDP checksum. That might help explain why I'm not getting a response back from anything. 12:35:17.894298 IP (tos 0x0, ttl 64, id 62100, offset 0, flags [DF], proto UDP (17), length 891) localhost.localdomain.sip > 10.20.128.149.sip: [bad udp cksum 0x128e -> 0xb0db!] SIP, length: 863 INVITE sip:17120@10.20.128.149;user=phone;transport=tcp SIP/2.0 Via: SIP/2.0/UDP 129.82.3.26;branch=z9hG4bK-17371-1-0 From: "Robert Remsik" <sip:17...@otc.colostate.edu><sip:17...@otc.colostate.edu>;tag=1 To: <sip:17120@10.20.128.149;user=phone><sip:17120@10.20.128.149;user=phone> CSeq: 1 INVITE Call-ID: 1-17371@129.82.3.26<mailto:1-17371@129.82.3.26> Contact: <sip:17120@129.82.3.26;transport=UDP><sip:17120@129.82.3.26;transport=UDP> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER User-Agent: PolycomVVX-VVX_410-UA/4.1.8.0628 Accept-Language: en Supported: 100rel,replaces Allow-Events: conference,talk,hold Max-Forwards: 70 Content-Type: application/sdp Content-Length: 245 v=0 o=- 1470166919 1470166919 IN IP4 129.82.3.26 s=Polycom IP Phone c=IN IP4 129.82.3.26 t=0 0 a=sendrecv m=audio 6000 RTP/AVP 9 0 8 101 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 Messages Retrans Timeout Unexpected-Msg INVITE ----------> 1 0 100 <---------- 0 0 0 0 <recv response="100" optional="true"/> </recv> <recv response="401" optional="true" auth="true" next="auth_challenge_received"/> </recv> <recv response="407" auth="true"/> </recv> <label id="auth_challenge-received"/> </recv> Robert Remsik ACNS Desk Phone: 970 491 7120 robert.rem...@colostate.edu<mailto:robert.rem...@colostate.edu> ________________________________ From: sindelka <sinde...@ttc.cz><mailto:sinde...@ttc.cz> Sent: Tuesday, August 2, 2016 9:12 PM To: sipp-users@lists.sourceforge.net<mailto:sipp-users@lists.sourceforge.net> Subject: Re: [Sipp-users] Troubleshooting a basic call Hi Robert, if the scenario you've provided is a verbatim copy of the one you actually use, not an edited version for illustration purposes, the trouble is that you blindly fire a series of requests without waiting for any response from the server. Normally, the authentication challenge comes in a 401 or 407 response to the first INVITE, and the generation of the authentication response as requested by the [authentication] keyword depends on the information from the authentication challenge. So you must insert some optional and mandatory <recv> statements between the first INVITE and first ACK - namely, <recv response="100" optional="true"/> <recv response="401" optional="true" auth="true" next="auth_challenge_received"/> <recv response="407" auth="true"/> <label id="auth_challenge-received"/> This ensures that regardless whether the sipx device sends the 100 or not, and regardless whether it uses 401 or 407 to send the authentication challenge, you'll handle it properly. Also, remove the auth="true" AVPs from all the <send> blocks, they are useless there. On top of that, please <recv> optionally a 100, a 180, a 183 and then compulsorily a 200 between sending the second INVITE (with the authentication response) and sending the second ACK, otherwise you may run into some other issues. And the last point, if you specify user and password inside the scenario, SIPp does not use the -au and -ap specified on the command line. Pavel ------------------------------------------------------------------------------ _______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net<mailto:Sipp-users@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/sipp-users Sipp-users Info Page - SourceForge<https://lists.sourceforge.net/lists/listinfo/sipp-users> lists.sourceforge.net This is the sipp users mailing list. Use it to get support for sipp or ask for features or even post your own features to be included in sipp!
------------------------------------------------------------------------------
_______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users
