HI
I did the trace using ngrep: ngrep -T -W byline -d any port 5060
And I am confused with tm retran.
(1) case one tm module, the| retr_timer1| default is 500 ms.
#U +0.001824 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
#U +0.000012 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
the ngrep show the delta between packet, the second invite is only 12 ms behind? is my understanding correct?
(2) change retr_timer1 to 2000 ms
modparam("tm", "retr_timer1", 1000)
#U +0.001936 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
#U +0.000013 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
the delta still 13 ms behind, so similar to the case 1,
The question is: is the second invite the re-trans by tm? If so why it is around 12/13 ms? not the 500 ms or as configured 2000 ms?
thanks.
Kind regards / Mit freundlichen Grüßen
Min Wang
Does ngrep really show the difference to the previous captured packet which mathces the filter, or to any previous packet?
Further, you have to inspect the Via branch parameter. Maybe the second INVITE is not a retransmission (same branch parameter) but a second branch (different branch parameter)
regards klaus
Am 28.03.2011 17:43, schrieb Min Wang:
HI
I did the trace using ngrep: ngrep -T -W byline -d any port 5060
And I am confused with tm retran.
(1) case one tm module, the|retr_timer1| default is 500 ms.
#U +0.001824 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
#U +0.000012 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
the ngrep show the delta between packet, the second invite is only 12 ms behind? is my understanding correct?
(2) change retr_timer1 to 2000 ms
modparam("tm", "retr_timer1", 1000)
#U +0.001936 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
#U +0.000013 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
the delta still 13 ms behind, so similar to the case 1,
The question is: is the second invite the re-trans by tm? If so why it is around 12/13 ms? not the 500 ms or as configured 2000 ms?
thanks.
Kind regards / Mit freundlichen Grüßen
Min Wang
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Klaus:
thanks.
On 03/28/2011 12:15 PM, Klaus Darilion wrote:
Does ngrep really show the difference to the previous captured packet which mathces the filter, or to any previous packet?
the ngrep man page shows:
-T Print a timestamp in the form of +S.UUUUUU, indicating the delta between packet matches.
If I understand it correctly, it is the delta between two packets?
Further, you have to inspect the Via branch parameter. Maybe the second INVITE is not a retransmission (same branch parameter) but a second branch (different branch parameter)
the compelete two invites are here, I did not see the difference of these two via branch.
(xxx is some ip address.)
# U +0.001936 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0. Record-Route: sip:xxx.17;lr;ftag=kj456jkt2b;did=907.bb779af2;rqu=WkNGWWUlHxdHS0RDaEpNJxtOWlotaUR0UkFcFjl/TA--. Record-Route: sip:xxx.16;lr;ftag=kj456jkt2b;n=2. Via: SIP/2.0/UDP xxx.17;branch=z9hG4bKd37a.2a8e7037.0. Route: sip:xxx.16;lr;received="sip:xxx.3:2057". Via: SIP/2.0/UDP xxx.16;branch=z9hG4bKd37a.db97e707.0. Via: SIP/2.0/UDP 172.16.8.48:2048;received=xxx.3;branch=z9hG4bK-arncrc8u5vji;rport=2048. From: "Anonymous" sip:anonymous@anonymous.invalid;tag=kj456jkt2b. To: sip:%23224@demo-sip.centercall.com;user=phone. Call-ID: 3c2e31dee22b-yl0mwzs6z9ij. CSeq: 2 INVITE. Max-Forwards: 20. Contact: sip:225@xxx.3:2048;line=27vlv3wh;flow-id=1. P-Key-Flags: resolution="31x13", keys="4". User-Agent: snom360/7.1.33. Accept: application/sdp. Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO. Allow-Events: talk, hold, refer, call-info. Supported: timer, 100rel, replaces, from-change. Session-Expires: 3600;refresher=uas. Min-SE: 90. Content-Type: application/sdp. Content-Length: 426. X-Remote-IP: xxx.3:2048. X-NAT: Yes. X-NAT: Yes. X-RTP-PROXY-SET: 0. . v=0. o=root 1879428310 1879428310 IN IP4 xxx.3. s=call. c=IN IP4 xxx.3. t=0 0. m=audio 62730 RTP/AVP 0 8 101. a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:Z3ntA6fyR4ZPiFURrxuZL/WEBoDWPorK3uKc1SCb. a=rtpmap:0 pcmu/8000. a=rtpmap:8 pcm # U +0.000013 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0. Record-Route: sip:xxx.17;lr;ftag=kj456jkt2b;did=907.bb779af2;rqu=WkNGWWUlHxdHS0RDaEpNJxtOWlotaUR0UkFcFjl/TA--. Record-Route: sip:xxx.16;lr;ftag=kj456jkt2b;n=2. Via: SIP/2.0/UDP xxx.17;branch=z9hG4bKd37a.2a8e7037.0. Route: sip:xxx.16;lr;received="sip:xxx.3:2057". Via: SIP/2.0/UDP xxx.16;branch=z9hG4bKd37a.db97e707.0. Via: SIP/2.0/UDP 172.16.8.48:2048;received=xxx.3;branch=z9hG4bK-arncrc8u5vji;rport=2048. From: "Anonymous" sip:anonymous@anonymous.invalid;tag=kj456jkt2b. To: sip:%23224@demo-sip.centercall.com;user=phone. Call-ID: 3c2e31dee22b-yl0mwzs6z9ij. CSeq: 2 INVITE. Max-Forwards: 20. Contact: sip:225@xxx.3:2048;line=27vlv3wh;flow-id=1. P-Key-Flags: resolution="31x13", keys="4". User-Agent: snom360/7.1.33. Accept: application/sdp. Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO. Allow-Events: talk, hold, refer, call-info. Supported: timer, 100rel, replaces, from-change. Session-Expires: 3600;refresher=uas. Min-SE: 90. Content-Type: application/sdp. Content-Length: 426. X-Remote-IP: xxx.3:2048. X-NAT: Yes. X-NAT: Yes. X-RTP-PROXY-SET: 0. . v=0. o=root 1879428310 1879428310 IN IP4 xxx.3. s=call. c=IN IP4 xxx.3. t=0 0. m=audio 62730 RTP/AVP 0 8 101. a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:Z3ntA6fyR4ZPiFURrxuZL/WEBoDWPorK3uKc1SCb. a=rtpmap:0 pcmu/8000. a=rtpmap:8 pcm
Kind regards / Mit freundlichen Grüßen
Min Wang
regards klaus
Am 28.03.2011 17:43, schrieb Min Wang:
HI
I did the trace using ngrep: ngrep -T -W byline -d any port 5060
And I am confused with tm retran.
(1) case one tm module, the|retr_timer1| default is 500 ms.
#U +0.001824 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
#U +0.000012 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
the ngrep show the delta between packet, the second invite is only 12 ms behind? is my understanding correct?
(2) change retr_timer1 to 2000 ms
modparam("tm", "retr_timer1", 1000)
#U +0.001936 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
#U +0.000013 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
the delta still 13 ms behind, so similar to the case 1,
The question is: is the second invite the re-trans by tm? If so why it is around 12/13 ms? not the 500 ms or as configured 2000 ms?
thanks.
Kind regards / Mit freundlichen Grüßen
Min Wang
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
HI I guess I found the reason:
I have a bond interface (eth0_eth1), where -d any means any interface, so I guess the ngrep will capture the traffic both from the eth0 and bond0.
thx
min
Am 28.03.2011 17:43, schrieb Min Wang:
HI
I did the trace using ngrep: ngrep -T -W byline -d any port 5060
And I am confused with tm retran.
(1) case one tm module, the|retr_timer1| default is 500 ms.
#U +0.001824 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
#U +0.000012 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
the ngrep show the delta between packet, the second invite is only 12 ms behind? is my understanding correct?
(2) change retr_timer1 to 2000 ms
modparam("tm", "retr_timer1", 1000)
#U +0.001936 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
#U +0.000013 xxx.17:5060 -> xxx.16:5060 INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
the delta still 13 ms behind, so similar to the case 1,
The question is: is the second invite the re-trans by tm? If so why it is around 12/13 ms? not the 500 ms or as configured 2000 ms?
thanks.
Kind regards / Mit freundlichen Grüßen
Min Wang
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On Monday 28 March 2011, Min Wang wrote:
I have a bond interface (eth0_eth1), where -d any means any
interface, so I guess the ngrep will capture the traffic both from the eth0 and bond0.
Hi Min,
yes, it will capture from all (bonding) interfaces if you not specify only one.
Cheers,
Henning
Hi Henning
thanks.
min
On 03/30/2011 08:00 AM, Henning Westerholt wrote:
On Monday 28 March 2011, Min Wang wrote:
I have a bond interface (eth0_eth1), where -d any means any
interface, so I guess the ngrep will capture the traffic both from the eth0 and bond0.
Hi Min,
yes, it will capture from all (bonding) interfaces if you not specify only one.
Cheers,
Henning
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users