sr-users

sr-users@lists.kamailio.org

18 participants
37468 discussions

[Serusers] Is there a way to force the added Via: to contain a specific IP addr != send socket
by Frank Durda IV 15 Jun '09

15 Jun '09

I have a configuration where SER sits immediately adjacent to a NAT translation between 10.x.x.x on the SER side and public Internet on the other side of the NAT. This a PSTN gateway that has only handled inbound SIP traffic, but now I am trying to send outbound and have run into issues. I am able to fix Contact: and SDP payload IP addresses and such with various force commands, but I have not found a way to alter Via:, and that is causing problems. To get the INVITE to forward out the right interface, we have to do a force_send_socket of say 10.2.4.6 which does get the packet out on the right interface headed toward the NAT router, but that same value also gets put in the Via: header and so none of the public IP address destinations (eg 208.22.33.44) can send SIP messages back to our public IP address gateway (205.66.77.88). So the INVITE that reaches 208.22.33.44 has packet source of 205.66.77.88), but the Via: is 10.2.4.6 and 208.22.33.44 replies to the Via: address, so we don't get any of the responses. So, is there a way to force the Via: to put out the needed value so that things will come out right?

2 1

[Kamailio-Users] Problem with PRACK
by Uriel Rozenbaum 12 Jun '09

12 Jun '09

Hi guys, I'm facing an awkward issue with a Kamailio (1.4.3-notls (i386/linux)) regarding PRACK messages. I'm migrating an old OpenSER (1.2.2-notls (i386/linux)) to this new Kamailio that is connected to some customer GWs. The GWs we use are Huawei AR2810 and Cisco AS5350. Both GWs support 100rel and for some signalling they send PRACK messages that are forwarded by OpenSER but consumed by Kamailio. What I was able to troubleshoot shown that Kamailio is not recognizing the lr=on on the header. I tested for PRACK messages within the following segment: # subsequent messages within a dialog should take the # path determined by record-routing if (is_method("PRACK")) { xlog("L_ERR", "PRACK: Outside LR...\n"); }; if (loose_route()) { if (is_method("PRACK")) { xlog("L_ERR", "PRACK: Inside LR...\n"); }; # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); }; Did anyone have a similar issue with this version of Kamailio? I captured the signalling for both proxies as follows: KAMAILIO(192.168.200.130) AS5350(192.168.200.40) AR2810(192.168.216.4) # U 192.168.200.40:49395 -> 192.168.200.130:5060 INVITE sip:3516380070@192.168.200.130:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK6107AA91..From: < sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40>>; tag=D41203B4-1763..To: <sip:3516380070@192.168.200.130<sip%3A3516380070(a)192.168.200.130>>..Date: Wed, 10 Jun 2009 14:26:12 GMT..Call-ID: 7BE3750B-550111DE-86AD96C1-6209D7B9(a)192.168.200.4 0..Supported: 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid: 2078424251-1426133470-2747138075-1395155982..User-Agent: Cisco-SIPGateway/IOS-12.x..Allo w: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101 INVITE..Max-Forwards: 70..Remote-Party-I D: <sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40>>;party=calling;screen=yes;privacy=off..Timestamp: 1244643972..Contact: <sip:1143314808@192.168.200.40:5060>..Expires: 180..Allow-Events: telephone-event..Content-Type: application/sdp..Content-Length: 302....v=0..o=CiscoSystemsSIP-GW-UserAgent 8434 7851 IN IP4 192.168.2 00.40..s=SIP Call..c=IN IP4 192.168.200.40..t=0 0..m=audio 16836 RTP/AVP 18 8 100..c=IN IP4 192.168.200.40..a=rtpmap:18 G729/8000..a=fmtp:18 annexb=no.. a=rtpmap:8 PCMA/8000..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=direction:passive.. # U 192.168.200.130:5060 -> 192.168.216.4:5060 INVITE sip:3516380070@192.168.216.4 <sip%3A3516380070(a)192.168.216.4>SIP/2.0..Record-Route: <sip:192.168.200.130;lr=on;ftag=D41203B4-1763>..Via: SIP/2.0/UDP 192.168.200.130;branch=z9hG4 bKf574.3149a801.0..Via: SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK6107AA91..From: <sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40>>;tag=D41203B4-1763..To: <sip:35163 80070(a)192.168.200.130>..Date: Wed, 10 Jun 2009 14:26:12 GMT..Call-ID: 7BE3750B-550111DE-86AD96C1-6209D7B9@192.168.200.40..Supported: 100rel,timer,replac es..Min-SE: 1800..Cisco-Guid: 2078424251-1426133470-2747138075-1395155982..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101 INVITE..Max-Forwards: 69..Remote-Party-ID: < sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40> >;party=calling;screen=yes;privacy=off..Timestamp: 1244643972..Contact: < sip:1143314808@192.168.200.40:5060>..Expires: 180..Allow-Events: telephone-even t..Content-Type: application/sdp..Content-Length: 302....v=0..o=CiscoSystemsSIP-GW-UserAgent 8434 7851 IN IP4 192.168.200.40..s=SIP Call..c=IN IP4 192.1 68.200.40..t=0 0..m=audio 16836 RTP/AVP 18 8 100..c=IN IP4 192.168.200.40..a=rtpmap:18 G729/8000..a=fmtp:18 annexb=no..a=rtpmap:8 PCMA/8000..a=rtpmap:10 0 X-NSE/8000..a=fmtp:100 192-194..a=direction:passive.. # U 192.168.200.130:5060 -> 192.168.200.40:5060 SIP/2.0 100 Giving a try..Via: SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK6107AA91..From: <sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40>>;tag=D41203B4-1763..To: <si p:3516380070@192.168.200.130 <p%3A3516380070(a)192.168.200.130>>..Call-ID: 7BE3750B-550111DE-86AD96C1-6209D7B9@192.168.200.40..CSeq: 101 INVITE..Server: Kamailio (1.4.3-notls (i386/linux) )..Content-Length: 0.... # U 192.168.216.4:5060 -> 192.168.200.130:5060 SIP/2.0 100 Trying..Call-ID:7BE3750B-550111DE-86AD96C1-6209D7B9@192.168.200.40..CSeq:101 INVITE..From:<sip:1143314808@192.168.200.40<sip%3A1143314808(a)192.168.200.40> >;tag=D41203B4-1763. .To:<sip:3516380070@192.168.200.130 <sip%3A3516380070(a)192.168.200.130>>..Via:SIP/2.0/UDP 192.168.200.130;branch=z9hG4bKf574.3149a801.0..Via:SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK6 107AA91..Content-Length:0.... # U 192.168.216.4:5060 -> 192.168.200.130:5060 SIP/2.0 180 Ringing..Require:100rel..Supported:100rel..Record-Route:<sip:192.168.200.130;lr=on;ftag=D41203B4-1763>..Via:SIP/2.0/UDP 192.168.200.130;bran ch=z9hG4bKf574.3149a801.0..Via:SIP/2.0/UDP 192.168.200.40:5060 ;branch=z9hG4bK6107AA91..Call-ID:7BE3750B-550111DE-86AD96C1-6209D7B9@192.168.200.40. .CSeq: 101 INVITE..From:<sip:1143314808@192.168.200.40<sip%3A1143314808(a)192.168.200.40> >;tag=D41203B4-1763..To:<sip:3516380070@192.168.200.130<sip%3A3516380070(a)192.168.200.130> >;tag=5358336B534F02B30582AFF0..RSeq:717562865..Co ntact:<sip:3516380070@192.168.200.130:5060>..Content-Length:0.... # U 192.168.200.130:5060 -> 192.168.200.40:5060 SIP/2.0 180 Ringing..Require:100rel..Supported:100rel..Record-Route:<sip:192.168.200.130;lr=on;ftag=D41203B4-1763>..Via:SIP/2.0/UDP 192.168.200.40:5060; branch=z9hG4bK6107AA91..Call-ID:7BE3750B-550111DE-86AD96C1-6209D7B9@192.168.200.40..CSeq:101 INVITE..From:<sip:1143314808@192.168.200.40<sip%3A1143314808(a)192.168.200.40> >;tag=D41203B4-1 763..To:<sip:3516380070@192.168.200.130 <sip%3A3516380070(a)192.168.200.130> >;tag=5358336B534F02B30582AFF0..RSeq:717562865..Contact:< sip:3516380070@192.168.200.130:5060>..Content-Length:0.. .. # U 192.168.200.40:49395 -> 192.168.200.130:5060 PRACK sip:3516380070@192.168.200.130:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK6107D249F..From: < sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40>>; tag=D41203B4-1763..To: <sip:3516380070@192.168.200.130<sip%3A3516380070(a)192.168.200.130>>;tag=5358336B534F02B30582AFF0..Date: Wed, 10 Jun 2009 14:26:12 GMT..Call-ID: 7BE3750B-550111DE-86 AD96C1-6209D7B9@192.168.200.40..CSeq: 102 PRACK..RAck: 717562865 101 INVITE..Route: <sip:192.168.200.130;lr=on;ftag=D41203B4-1763>..Max-Forwards: 70..Co ntent-Length: 0.... # U 192.168.216.4:5060 -> 192.168.200.130:5060 SIP/2.0 180 Ringing..Require:100rel..Supported:100rel..Record-Route:<sip:192.168.200.130;lr=on;ftag=D41203B4-1763>..Via:SIP/2.0/UDP 192.168.200.130;bran ch=z9hG4bKf574.3149a801.0..Via:SIP/2.0/UDP 192.168.200.40:5060 ;branch=z9hG4bK6107AA91..Call-ID:7BE3750B-550111DE-86AD96C1-6209D7B9@192.168.200.40. .CSeq: 101 INVITE..From:<sip:1143314808@192.168.200.40<sip%3A1143314808(a)192.168.200.40> >;tag=D41203B4-1763..To:<sip:3516380070@192.168.200.130<sip%3A3516380070(a)192.168.200.130> >;tag=5358336B534F02B30582AFF0..RSeq:717562865..Co ntact:<sip:3516380070@192.168.200.130:5060>..Content-Length:0.... # U 192.168.200.130:5060 -> 192.168.200.40:5060 SIP/2.0 180 Ringing..Require:100rel..Supported:100rel..Record-Route:<sip:192.168.200.130;lr=on;ftag=D41203B4-1763>..Via:SIP/2.0/UDP 192.168.200.40:5060; branch=z9hG4bK6107AA91..Call-ID:7BE3750B-550111DE-86AD96C1-6209D7B9@192.168.200.40..CSeq:101 INVITE..From:<sip:1143314808@192.168.200.40<sip%3A1143314808(a)192.168.200.40> >;tag=D41203B4-1 763..To:<sip:3516380070@192.168.200.130 <sip%3A3516380070(a)192.168.200.130> >;tag=5358336B534F02B30582AFF0..RSeq:717562865..Contact:< sip:3516380070@192.168.200.130:5060>..Content-Length:0.. .. # U 192.168.200.40:49395 -> 192.168.200.130:5060 PRACK sip:3516380070@192.168.200.130:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK6107D249F..From: < sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40>>; tag=D41203B4-1763..To: <sip:3516380070@192.168.200.130<sip%3A3516380070(a)192.168.200.130>>;tag=5358336B534F02B30582AFF0..Date: Wed, 10 Jun 2009 14:26:12 GMT..Call-ID: 7BE3750B-550111DE-86 AD96C1-6209D7B9@192.168.200.40..CSeq: 102 PRACK..RAck: 717562865 101 INVITE..Route: <sip:192.168.200.130;lr=on;ftag=D41203B4-1763>..Max-Forwards: 70..Co ntent-Length: 0.... And then for OPENSER(192.168.200.10) AS5350(192.168.200.40) AR2810(192.168.216.4) # U 192.168.200.40:50112 -> 192.168.200.10:5060 INVITE sip:3516380070@192.168.200.10:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK60D741D2C..From: < sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40>>; tag=D3E4E024-AA5..To: <sip:3516380070@192.168.200.10<sip%3A3516380070(a)192.168.200.10>>..Date: Wed, 10 Jun 2009 13:36:54 GMT..Call-ID: 98989BF6-54FA11DE-818396C1-6209D7B9(a)192.168.200.40. .Supported: 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid: 2560098254-1425674718-2728198171-1395155982..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101 INVITE..Max-Forwards: 70..Remote-Party-ID: <sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40>>;party=calling;screen=yes;privacy=off..Timestamp: 1244641014..Contact: <sip:1143314808@192.168.200.40:5060>..Expires: 18 0..Allow-Events: telephone-event..Content-Type: application/sdp..Content-Length: 302....v=0..o=CiscoSystemsSIP-GW-UserAgent 2319 3741 IN IP4 192.168.200 .40..s=SIP Call..c=IN IP4 192.168.200.40..t=0 0..m=audio 17416 RTP/AVP 18 8 100..c=IN IP4 192.168.200.40..a=rtpmap:18 G729/8000..a=fmtp:18 annexb=no..a= rtpmap:8 PCMA/8000..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=direction:passive.. # U 192.168.200.10:5060 -> 192.168.200.40:5060 SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK60D741D2C..From: < sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40>>;tag=D3E4 E024-AA5..To: <sip:3516380070@192.168.200.10<sip%3A3516380070(a)192.168.200.10>>;tag=329cfeaa6ded039da25ff8cbb8668bd2.941d..Call-ID: 98989BF6-54FA11DE-818396C1-6209D7B9@192.168.200.40..CS eq: 101 INVITE..Proxy-Authenticate: Digest realm="metrotel", nonce="4a2fb81ca554f5ff9ab57d058348ca3a20e35893"..Server: OpenSER (1.2.2-notls (i386/linux) )..Content-Length: 0.... # U 192.168.200.40:5060 -> 192.168.200.10:5060 ACK sip:3516380070@192.168.200.10:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK60D741D2C..From: < sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40>>;tag =D3E4E024-AA5..To: <sip:3516380070@192.168.200.10<sip%3A3516380070(a)192.168.200.10>>;tag=329cfeaa6ded039da25ff8cbb8668bd2.941d..Date: Wed, 10 Jun 2009 13:36:54 GMT..Call-ID: 98989BF6-54F A11DE-818396C1-6209D7B9@192.168.200.40..Max-Forwards: 70..CSeq: 101 ACK..Content-Length: 0.... # U 192.168.200.40:50112 -> 192.168.200.10:5060 INVITE sip:3516380070@192.168.200.10:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK60D751268..From: < sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40>>; tag=D3E4E024-AA5..To: <sip:3516380070@192.168.200.10<sip%3A3516380070(a)192.168.200.10>>..Date: Wed, 10 Jun 2009 13:36:54 GMT..Call-ID: 98989BF6-54FA11DE-818396C1-6209D7B9(a)192.168.200.40. .Supported: 100rel,timer,replaces..Min-SE: 1800..Cisco-Guid: 2560098254-1425674718-2728198171-1395155982..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 102 INVITE..Max-Forwards: 70..Remote-Party-ID: <sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40>>;party=calling;screen=yes;privacy=off..Timestamp: 1244641014..Contact: <sip:1143314808@192.168.200.40:5060>..Expires: 18 0..Allow-Events: telephone-event..Proxy-Authorization: Digest username="as5350",realm="metrotel",uri="sip:3516380070@192.168.200.10:5060 ",response="6a51 a32e9f21dadc67db011ab81af3f6",nonce="4a2fb81ca554f5ff9ab57d058348ca3a20e35893",algorithm=md5..Content-Type: application/sdp..Content-Length: 302....v=0. .o=CiscoSystemsSIP-GW-UserAgent 2319 3741 IN IP4 192.168.200.40..s=SIP Call..c=IN IP4 192.168.200.40..t=0 0..m=audio 17416 RTP/AVP 18 8 100..c=IN IP4 19 2.168.200.40..a=rtpmap:18 G729/8000..a=fmtp:18 annexb=no..a=rtpmap:8 PCMA/8000..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=direction:passive.. # U 192.168.200.10:5060 -> 192.168.200.40:5060 SIP/2.0 100 Giving a try..Via: SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK60D751268..From: <sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40>>;tag=D3E4E024-AA5..To: <si p:3516380070@192.168.200.10 <p%3A3516380070(a)192.168.200.10>>..Call-ID: 98989BF6-54FA11DE-818396C1-6209D7B9@192.168.200.40..CSeq: 102 INVITE..Server: OpenSER (1.2.2-notls (i386/linux)). .Content-Length: 0.... # U 192.168.200.10:5060 -> 192.168.216.4:5060 INVITE sip:3516380070@192.168.216.4:5060;transport=udp SIP/2.0..Record-Route: <sip:192.168.200.10;lr=on;ftag=D3E4E024-AA5>..Via: SIP/2.0/UDP 192.168.200 .10;branch=z9hG4bK831b.861b9286.0..Via: SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK60D751268..From: <sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40> >;tag=D3E4E024-AA5 ..To: <sip:3516380070@192.168.200.10 <sip%3A3516380070(a)192.168.200.10>>..Date: Wed, 10 Jun 2009 13:36:54 GMT..Call-ID: 98989BF6-54FA11DE-818396C1-6209D7B9@192.168.200.40..Supported: 100r el,timer,replaces..Min-SE: 1800..Cisco-Guid: 2560098254-1425674718-2728198171-1395155982..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS , BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 102 INVITE..Max-Forwards: 70..Remote-Party-ID: <sip:1143314808 @192.168.200.40>;party=calling;screen=yes;privacy=off..Timestamp: 1244641014..Contact: <sip:1143314808@192.168.200.40:5060>..Expires: 180..Allow-Events: telephone-event..Content-Type: application/sdp..Content-Length: 302..P-hint: outbound....v=0..o=CiscoSystemsSIP-GW-UserAgent 2319 3741 IN IP4 192.168.2 00.40..s=SIP Call..c=IN IP4 192.168.200.40..t=0 0..m=audio 17416 RTP/AVP 18 8 100..c=IN IP4 192.168.200.40..a=rtpmap:18 G729/8000..a=fmtp:18 annexb=no.. a=rtpmap:8 PCMA/8000..a=rtpmap:100 X-NSE/8000..a=fmtp:100 192-194..a=direction:passive.. # U 192.168.216.4:5060 -> 192.168.200.10:5060 SIP/2.0 100 Trying..Call-ID:98989BF6-54FA11DE-818396C1-6209D7B9@192.168.200.40..CSeq:102 INVITE..From:<sip:1143314808@192.168.200.40<sip%3A1143314808(a)192.168.200.40> >;tag=D3E4E024-AA5.. To:<sip:3516380070@192.168.200.10 <sip%3A3516380070(a)192.168.200.10>>..Via:SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK831b.861b9286.0..Via:SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK60D7 51268..Content-Length:0.... # U 192.168.216.4:5060 -> 192.168.200.10:5060 SIP/2.0 180 Ringing..Require:100rel..Supported:100rel..Record-Route:<sip:192.168.200.10;lr=on;ftag=D3E4E024-AA5>..Via:SIP/2.0/UDP 192.168.200.10;branch= z9hG4bK831b.861b9286.0..Via:SIP/2.0/UDP 192.168.200.40:5060 ;branch=z9hG4bK60D751268..Call-ID:98989BF6-54FA11DE-818396C1-6209D7B9@192.168.200.40. .CSeq:10 2 INVITE..From:<sip:1143314808@192.168.200.40<sip%3A1143314808(a)192.168.200.40> >;tag=D3E4E024-AA5..To:<sip:3516380070@192.168.200.10<sip%3A3516380070(a)192.168.200.10> >;tag=5358336B534F54210582B350..RSeq:900097065..Contac t:<sip:3516380070@192.168.200.10:5060>..Content-Length:0.... # U 192.168.200.10:5060 -> 192.168.200.40:5060 SIP/2.0 180 Ringing..Require:100rel..Supported:100rel..Record-Route:<sip:192.168.200.10;lr=on;ftag=D3E4E024-AA5>..Via:SIP/2.0/UDP 192.168.200.40:5060;br anch=z9hG4bK60D751268..Call-ID:98989BF6-54FA11DE-818396C1-6209D7B9@192.168.200.40..CSeq:102 INVITE..From:<sip:1143314808@192.168.200.40<sip%3A1143314808(a)192.168.200.40> >;tag=D3E4E024-AA 5..To:<sip:3516380070@192.168.200.10 <sip%3A3516380070(a)192.168.200.10> >;tag=5358336B534F54210582B350..RSeq:900097065..Contact:< sip:3516380070@192.168.200.10:5060>..Content-Length:0.... # U 192.168.200.40:50112 -> 192.168.200.10:5060 PRACK sip:3516380070@192.168.200.10:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK60D77201C..From: < sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40>>;t ag=D3E4E024-AA5..To: <sip:3516380070@192.168.200.10<sip%3A3516380070(a)192.168.200.10>>;tag=5358336B534F54210582B350..Date: Wed, 10 Jun 2009 13:36:54 GMT..Call-ID: 98989BF6-54FA11DE-81839 6C1-6209D7B9@192.168.200.40..CSeq: 103 PRACK..RAck: 900097065 102 INVITE..Route: <sip:192.168.200.10;lr=on;ftag=D3E4E024-AA5>..Proxy-Authorization: Dige st username="as5350",realm="metrotel",uri=" sip:3516380070@192.168.200.10:5060 ",response="df4f26f89f7a4eebb397266d31e71b38",nonce="4a2fb81ca554f5ff9ab57d 058348ca3a20e35893",algorithm=md5..Max-Forwards: 70..Content-Length: 0.... # U 192.168.200.10:5060 -> 192.168.216.4:5060 PRACK sip:3516380070@192.168.216.4:5060;transport=udp SIP/2.0..Record-Route: <sip:192.168.200.10;lr=on;ftag=D3E4E024-AA5>..Via: SIP/2.0/UDP 192.168.200. 10;branch=z9hG4bK931b.4afe556.0..Via: SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK60D77201C..From: <sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40> >;tag=D3E4E024-AA5.. To: <sip:3516380070@192.168.200.10 <sip%3A3516380070(a)192.168.200.10>>;tag=5358336B534F54210582B350..Date: Wed, 10 Jun 2009 13:36:54 GMT..Call-ID: 98989BF6-54FA11DE-818396C1-6209D7B9@192. 168.200.40..CSeq: 103 PRACK..RAck: 900097065 102 INVITE..Proxy-Authorization: Digest username="as5350",realm="metrotel",uri=" sip:3516380070@192.168.200. <sip%3A3516380070(a)192.168.200.> 10:5060",response="df4f26f89f7a4eebb397266d31e71b38",nonce="4a2fb81ca554f5ff9ab57d058348ca3a20e35893",algorithm=md5..Max-Forwards: 70..Content-Length: 0 ..P-hint: rr-enforced.... # U 192.168.216.4:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK..Call-ID:98989BF6-54FA11DE-818396C1-6209D7B9@192.168.200.40..CSeq:103 PRACK..From:<sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40> >;tag=D3E4E024-AA5..To:<s ip:3516380070@192.168.200.10 <ip%3A3516380070(a)192.168.200.10>>;tag=5358336B534F54210582B350..Via:SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK931b.4afe556.0..Via:SIP/2.0/UDP 192.168.200.40: 5060;branch=z9hG4bK60D77201C..Content-Length:0.... # U 192.168.200.10:5060 -> 192.168.200.40:5060 SIP/2.0 200 OK..Call-ID:98989BF6-54FA11DE-818396C1-6209D7B9@192.168.200.40..CSeq:103 PRACK..From:<sip:1143314808@192.168.200.40 <sip%3A1143314808(a)192.168.200.40> >;tag=D3E4E024-AA5..To:<s ip:3516380070@192.168.200.10 <ip%3A3516380070(a)192.168.200.10>>;tag=5358336B534F54210582B350..Via:SIP/2.0/UDP 192.168.200.40:5060;branch=z9hG4bK60D77201C..Content-Length:0....

1 1

[Kamailio-Users] Problems in ACC with missing BYE
by David 11 Jun '09

11 Jun '09

Hi, I am using Kamailio as my ACC, Dispatcher, far end nat and presence server in front of a farm of asterisk boxes. Most calls are being properly added into my acc table and using a join between the INVITEs, CANCELs, and BYEs I am able to get what seems like accurate call detail records. The trouble is that every so often a BYE does not make it back to my server. In my simulation this morning, I simply unplugged ( electric ) the two phones that were having a pleasant conversation. Now I have asterisk that thinks the call is still running and I have Kamailio which has no ending 'BYE' message. For the most part this is not a big deal, but when I can a cellular phone in European countries, my provider thinks I am still talking. At 30 cents a minute, that's a lot. Here are some snippets from my code : loadmodule("dialog.so") loadmodule("acc.so") loadmodule("sst.so") modparam("acc", "early_media", 1) modparam("acc", "report_ack", 1) modparam("acc", "report_cancels", 1) modparam("acc", "failed_transaction_flag", 3) modparam("acc", "log_flag", 1) modparam("acc", "log_missed_flag", 2) modparam("acc", "db_flag", 1) modparam("acc", "db_missed_flag", 2) # There is also a parameter for the DB, but I can't give you my password modparam("acc", "db_url", "some://valid:url@to/db") # Note $avp(i:10) always ends up being 14400 ( less than the value on the help page ) modparam("dialog", "timeout_avp", "$avp(i:10)") modparam("sst", "timeout_avp", "$avp(i:10)") modparam("sst", "sst_flag", 5) Relevant snippets from my routing : if ( has_totag()) { if ( loose_route() ) { if ( is_method("CANCEL|BYE") { setflag(1); setflag(3); } } # Routing of INVITEs setflag(2) if ( !is_method("ACK")) { setflag(1); } setflag(4); setflag(5); For invites, I have a onreply_route and failure_route which I use only for RTP Stuff. On reply route checks if rtpproxy is needed, if it is it is activated. failure_route checks if rtpproxy was activated and if it was deactives it. The only other code in the failure route is this : if ( t_was_cancelled() ){ exit ; } So, the problem is, when phones do not send BYE, what do I do? I need resources freed up from Asterisk, RTP Proxy, and Kamailio Dialog, and I need the call to be canceled with my provider and I need for my ACC to recieve some indication as to when the call ended. Obviously it won't be exact to the second, but I kind of thought that the SIP Session Timers would notice the phone was gone and would generate a BYE or something? What do I do? Thanks, David

3 4

[Kamailio-Users] Keep-alive implementation
by Ariadne Ramos 11 Jun '09

11 Jun '09

Im trying to implement Keep alive to maintain communication with nated clients. Enabling it in the terminals We eliminate OPTIONS natpings setbflag(7); We want to eliminate setbflag(6); because when this is setted openser send 4 bytes packages to maintain the communication with nated clients. But if we do that we have problems using mediaproxy. Can you help me with this issue? I hope to have explained correctly. Ariadne L. Ramos Solís Depto. Ingeniería Aprovisionamiento y Señalización VoIP Galaxy Communications Corp. Tel. 2000117 e-mail <mailto:aramos@clarocom.com> aramos(a)clarocom.com P BE CARBON CONSCIOUS. PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS E-MAIL

6 14

[Kamailio-Users] Kamailio + NAT Help
by Chandrakant Solanki 11 Jun '09

11 Jun '09

Hi I need help on NAT with Kamailio... My Network Details are as follows... SIP Phone Registration ADSL Router Kamailio Asterisk 172.18.100.73/255.255.0.0 192.168.1.1/255.255.255.0 192.168.1.68/255.255.255.0 192.168.1.70/255.255.255.0 172.18.100.72/255.255.0.0 GW: 172.18.100.72 (Virtual IP 172.18.100.68) (Virtual IP 172.18.100.70) Router Type: AirLink 101 802.11 Token Ring Where Virtual IP 172.18.100.68 and 172.18.100.70 set virtually on ADSL Router.. and set routing on it.. So when I ping 172.18.100.70 it will go through 192.168.1.1 I am able to call, receive means able to receive OK, INVITE and REGISTER method of kamailio ... but When i try to Hangup call, it can't hangup at both side.. I have to manually cut phone at the other end.. I have not set any rule on Router. *Scenario...* 1] I have two user. 1212(a)domain.com [172.18.100.73] and 2121(a)domain.com[172.18.100.72] and register successfully 2] Call from 1212(a)domain.com [172.18.100.73] to 2121(a)domain.com[172.18.100.72].. 3] Call is connected successfully 4] While hangup from 1212(a)domain.com [172.18.100.73] it will take time and at the other end, I have to manually hangup call.. Please help me out.. -- Regards, Chandrakant Solanki

2 2

[Kamailio-Users] perl module, "pv_sprintf: Memory exhausted!"
by Christian Koch 11 Jun '09

11 Jun '09

Hi all, we're using kamailio 1.5.1 with modules htable and perl to generate CDRs. Using htable we save some variables which are dumped to file using the perl module at the end of the call. We did a small stress test with 5 calls in parallel (each call about 20 seconds) and we got after about 6 hours the following error: ERROR:core:pv_sprintf: pv_sprintf: Memory exhausted! No CDRs were written anymore, the perl method was not called. Everything else seems to run fine. After stopping the stress test doing one simple call with a softphone worked and a CDR had been written (without restarting kamailio!). Perhaps the perl script is buggy? Any ideas how to fix this are greatly appreciated. We don't think extending the PKG_MEM_POOL_SIZE will solve the problem. This is currently 4MB and should be enough for 5 concurrent calls!?! Thanks, Christian Koch The perl script: use OpenSER; use OpenSER::Constants; use IO::Socket; sub write_cdr { my $m = shift; #my $v = $m->getVersion(); #my $t = $m->getType(); my $index = $m->pseudoVar("\$ci"); my $endTimeStamp = $m->pseudoVar("\$Ts"); my $startTimeStamp = $endTimeStamp - $m->pseudoVar("\$DLG_lifetime"); ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime($startTimeStamp); my $startTime = sprintf("%02d.%02d.%4d;%02d:%02d:%02d", $mday, $mon+1, $year+1900, $hour, $min, $sec); my $fileDate = sprintf("%02d%02d%02d", $mday, $mon+1, $year%100); ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime($endTimeStamp); my $endTime = sprintf("%02d.%02d.%4d;%02d:%02d:%02d", $mday, $mon+1, $year+1900, $hour, $min, $sec); ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime($m->pseudoVar("\$sht(a=>".$index."::invtrytime)")); my $InvTryingTime = sprintf("%02d.%02d.%4d;%02d:%02d:%02d", $mday, $mon+1, $year+1900, $hour, $min, $sec); $ReplyReason=$m->pseudoVar("\$rr"); $ReplyReason=~ s/;/_/g; $FromDisplayName = $m->pseudoVar("\$sht(a=>".$index."::fromdplname)"); $FromDisplayName=~ s/;/_/g; $ToUri = $m->pseudoVar("\$sht(a=>".$index."::touri)"); $ToUri=~s/;/_/g; $FromUri = $m->pseudoVar("\$sht(a=>".$index."::fromuri)"); $FromUri=~s/;/_/g; $UserAgent = $m->pseudoVar("\$sht(a=>".$index."::useragent)"); $UserAgent=~s/;/_/g; my $CDR = $startTime.";"; # 1 + 2 $CDR .= $endTime.";"; # 3 + 4 $CDR .= $m->pseudoVar("\$DLG_lifetime").";"; # 5 $CDR .= $index.";"; #6 CallID $CDR .= $m->pseudoVar("\$sht(a=>".$index."::srcip)").";"; # source-IP of INVITE $CDR .= $m->pseudoVar("\$si").";"; # source-IP of BYE/CANCEL $CDR .= $FromDisplayName.";"; # from display-name INVITE $CDR .= $InvTryingTime.";"; # Alerting time $CDR .= ($startTimeStamp - $m->pseudoVar("\$sht(a=>".$index."::invtrytime)")).";"; #Alerting period $CDR .= $m->pseudoVar("\$DLG_count").";"; # current amount of calls $CDR .= $ToUri.";"; # ToUri from Invite $CDR .= $FromUri.";"; # FromUri from Invite $CDR .= $UserAgent.";"; # UserAgent from Invite $CDR .= $m->pseudoVar("\$rm").";"; # Method (INVITE,BYE,CANCEL) $CDR .= $m->pseudoVar("\$rs").";"; # SIP reply status $CDR .= $ReplyReason.";"; #SIP Reply reason open(MYOUTFILE, ">>/home/sys/log/kamailio".$fileDate.".cdr.".$m->pseudoVar("\$pp")); print MYOUTFILE $CDR."\n"; close(MYOUTFILE); #delete(%sourceIp->{$index}); #delete(%fromDisplayName->{$index}); #delete(%InviteTryingTimestamp->{$index}); #delete(%ToUri->{$index}); #delete(%FromUri->{$index}); #delete(%UserAgent->{$index}); return 1; } 1;

4 28

[Kamailio-Users] Upgrade guide from 1.4.x to 1.5.x
by Uriel Rozenbaum 10 Jun '09

10 Jun '09

Hi gentlemen, Is there any upgrade guide to go from 1.4.3-notls to 1.5.1-notls? If not, is there something I need to keep in mind? some major change on the cfg or DB schema? Thanks in advance! Uriel

2 1

[Kamailio-Users] avp_db_query
by Bruno Machado 10 Jun '09

10 Jun '09

Hi I'm using Kamailio v1.5.1 and, I do not know why, the avp value is disappearing. Let me show you what is happening: #IT DOESN'T WORK avp_db_query("select count(1) as c from group_endpoint where num_ip='$si'","$avp(i:105)"); log(1,"Before AVP_PRINT\n"); avp_print(); log(1,"After AVP_PRINT\n"); if( avp_check("$avp(i:105)","eq/i:0") ) #Debug Jun 10 09:57:48 [4326] DBG:avpops:ops_dbquery_avps: query [select count(1) as c from group_endpoint where num_ip='192.168.0.194'] Jun 10 09:57:48 [4326] DBG:core:db_new_result: allocate 28 bytes for result set at 0x8180ea8 Jun 10 09:57:48 [4326] DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query Jun 10 09:57:48 [4326] DBG:core:db_allocate_columns: allocate 4 bytes for result names at 0x8180ed0 Jun 10 09:57:48 [4326] DBG:core:db_allocate_columns: allocate 4 bytes for result types at 0x8180ee0 Jun 10 09:57:48 [4326] DBG:db_mysql:db_mysql_get_columns: allocate 8 bytes for RES_NAMES[0] at 0x8180ef0 Jun 10 09:57:48 [4326] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8180ef0)[0]=[c] Jun 10 09:57:48 [4326] DBG:db_mysql:db_mysql_get_columns: use DB_BIGINT result type Jun 10 09:57:48 [4326] DBG:core:db_allocate_rows: allocate 8 bytes for rows at 0x8180f00 Jun 10 09:57:48 [4326] DBG:core:db_allocate_row: allocate 20 bytes for row values at 0x8180f10 Jun 10 09:57:48 [4326] DBG:core:db_str2val: converting BIGINT [0] Jun 10 09:57:48 [4326] DBG:avpops:db_query_avp: rows [1] Jun 10 09:57:48 [4326] DBG:avpops:db_query_avp: row [0] Jun 10 09:57:48 [4326] DBG:avpops:db_close_query: close avp query Jun 10 09:57:48 [4326] DBG:core:db_free_columns: freeing 1 columns Jun 10 09:57:48 [4326] DBG:core:db_free_columns: freeing RES_NAMES[0] at 0x8180ef0 Jun 10 09:57:48 [4326] DBG:core:db_free_columns: freeing result names at 0x8180ed0 Jun 10 09:57:48 [4326] DBG:core:db_free_columns: freeing result types at 0x8180ee0 Jun 10 09:57:48 [4326] DBG:core:db_free_rows: freeing 1 rows Jun 10 09:57:48 [4326] DBG:core:db_free_row: freeing row values at 0x8180f10 Jun 10 09:57:48 [4326] DBG:core:db_free_rows: freeing rows at 0x8180f00 Jun 10 09:57:48 [4326] DBG:core:db_free_result: freeing result set at 0x8180ea8 Before AVP_PRINT After AVP_PRINT Jun 10 09:57:48 [4326] DBG:avpops:ops_check_avp: no src avp found No src avp found! There isn't any avp. The avp value returned by mysql server is quickly dropped. So, to avoid this, I changed the query's result into a string. I'm using the mysql concat function. #IT WORKS! avp_db_query("select concat('',count(1)) from group_endpoint where num_ip='$si'","$avp(s:105)"); log(1,"Before AVP_PRINT\n"); avp_print(); log(1,"After AVP_PRINT\n"); if( avp_check("$avp(s:105)","eq/s:0/g") ) #Debug Jun 10 10:01:37 [4378] DBG:avpops:ops_dbquery_avps: query [select concat('',count(1)) from group_endpoint where num_ip='192.168.0.194'] Jun 10 10:01:37 [4378] DBG:core:db_new_result: allocate 28 bytes for result set at 0x8180ea8 Jun 10 10:01:37 [4378] DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query Jun 10 10:01:37 [4378] DBG:core:db_allocate_columns: allocate 4 bytes for result names at 0x8180ed0 Jun 10 10:01:37 [4378] DBG:core:db_allocate_columns: allocate 4 bytes for result types at 0x8180ee0 Jun 10 10:01:37 [4378] DBG:db_mysql:db_mysql_get_columns: allocate 8 bytes for RES_NAMES[0] at 0x8180ef0 Jun 10 10:01:37 [4378] DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x8180ef0)[0]=[concat('',count(1))] Jun 10 10:01:37 [4378] DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Jun 10 10:01:37 [4378] DBG:core:db_allocate_rows: allocate 8 bytes for rows at 0x8180f00 Jun 10 10:01:37 [4378] DBG:core:db_allocate_row: allocate 20 bytes for row values at 0x8180f10 Jun 10 10:01:37 [4378] DBG:core:db_str2val: converting STRING [0] Jun 10 10:01:37 [4378] DBG:avpops:db_query_avp: rows [1] Jun 10 10:01:37 [4378] DBG:avpops:db_query_avp: row [0] Jun 10 10:01:37 [4378] DBG:avpops:db_close_query: close avp query Jun 10 10:01:37 [4378] DBG:core:db_free_columns: freeing 1 columns Jun 10 10:01:37 [4378] DBG:core:db_free_columns: freeing RES_NAMES[0] at 0x8180ef0 Jun 10 10:01:37 [4378] DBG:core:db_free_columns: freeing result names at 0x8180ed0 Jun 10 10:01:37 [4378] DBG:core:db_free_columns: freeing result types at 0x8180ee0 Jun 10 10:01:37 [4378] DBG:core:db_free_rows: freeing 1 rows Jun 10 10:01:37 [4378] DBG:core:db_free_row: freeing row values at 0x8180f10 Jun 10 10:01:37 [4378] DBG:core:db_free_rows: freeing rows at 0x8180f00 Jun 10 10:01:37 [4378] DBG:core:db_free_result: freeing result set at 0x8180ea8 Before AVP_PRINT Jun 10 10:01:37 [4378] INFO:avpops:ops_print_avp: p=0xb5d3ef08, flags=0x0003 Jun 10 10:01:37 [4378] INFO:avpops:ops_print_avp: name=<105> Jun 10 10:01:37 [4378] INFO:avpops:ops_print_avp: val_str=<0 / 1> After AVP_PRINT Jun 10 10:01:37 [4378] DBG:avpops:ops_check_avp: check <0> against <0> as str /16777217 The avp value is there now! Why is it happening? Am I doing something wrong? I think the answer is a perfect 'yes'. Thanks for any advice. Bruno Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com

1 0

Re: [Kamailio-Users] Maintenance of Modules
by Cristhiano 10 Jun '09

10 Jun '09

>* How are made updates ? * Can you add a bit more details? Updates from one kamailio version to another are done just like in any other project. Check the release notes and the upgrade informations and then act appropriately. :-) Hi, Henning. My query is how one module is updated. The maintener for very modules are same in both projects (Kamailio and Opensips). But, don't have information if he work for one or two. If have bugs or new implementations/features in one module, this is updated in both plataforms ? In example of LCR module, maintener is same in both, but in Kamailio is more active than the Opensips. And status is "stable" in developer version of two plataforms. thanks

2 1

[Kamailio-Users] Maintenance of Modules
by Cristhiano Rovani 10 Jun '09

10 Jun '09

Hi, I would like to understand the maintenance of modules of Opensips and Kamailio. The developer is same for two plataforms ? How are made updates ? The modules are compatible between plataforms ? If I get one default module (eg. lcr/carrierroute) of kamailio and put in opensips, this work ? Have one list of developer/mainteiner of each modules ? Thanks

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users