sr-users

sr-users@lists.kamailio.org

42 participants
37519 discussions

[Serusers] SER 0.10.99 (Carpo) - Cancel from CP-7912G not recognized
by Theodor Meier 16 Jan '07

16 Jan '07

Hello, the VoIP Provider Carpo (www.carpo.com) uses Sip EXpress router (0.10.99-iptelorg/tekelec-SOPv2 (i386/linux)). When using the CP-7912G with this server, the CANCEL reuqests aren't processed. When testing myself, has the openser (it was easier to set up with deb-packages) the same behaviour like the SER? Following a log from the Cisco CP-7912G with the 4 CANCEL that SER doesn't recognize. Is it due to configuration or aren't the SIP-Messages from 7912g not right? This log was recorded without the CP-7912G ConnectMode Parameter set to 0×00400000 (set bit 22 to use the received ip address for NAT) Before the 2 INVITE: ---- to SER INVITE sip:01608438483@sip.carpo.de;user=phone SIP/2.0 ---- from SER SIP/2.0 407 Proxy Authentifikation erforderlich ---- To SER ACK sip:01608438483@sip.carpo.de;user=phone SIP/2.0 ---- [0:0] Tx Msg to 80.95.252.5:5060 INVITE sip:01608438483@sip.carpo.de;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.178.41:5062;branch=z9hG4bKa96c7242c55a1bc From: Use of a Display Name <sip:wa.mayer@sip.carpo.de>;tag=3931549548 To: <sip:01608438483@sip.carpo.de;user=phone> Call-ID: 3762823499(a)192.168.178.41 CSeq: 2 INVITE Contact: Use of a Display Name <sip:wa.mayer@192.168.178.41:5062;transport=udp> User-Agent: Cisco-CP7912/8.0.0-060111A Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, UPDATE Supported: replaces, 100rel Proxy-Authorization: Digest username="wa.mayer",realm="carpo",nonce="45961c6006af8c7d88236d8de4aa44b64d504738",uri="sip:01608438483@sip. carpo.de",response="77323afc4bea0fb5e2cceb50bff9e404" Expires: 300 Content-Length: 285 Content-Type: application/sdp v=0 o=wa.mayer 2928 2928 IN IP4 192.168.178.41 s=Cisco 7912 SIP Call c=IN IP4 192.168.178.41 t=0 0 m=audio 30004 RTP/AVP 0 18 8 101 a=rtpmap:0 PCMU/8000/1 a=rtpmap:18 G729/8000/1 a=fmtp:18 annexb=yes a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 ---- [0]Rx Msg from 80.95.252.5:5060 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 192.168.178.41:5062;rport=5062;received=84.150.194.222;branch=z9hG4bKa96c7242c55a1bc From: Use of a Display Name <sip:wa.mayer@sip.carpo.de>;tag=3931549548 To: <sip:01608438483@sip.carpo.de;user=phone> Call-ID: 3762823499(a)192.168.178.41 CSeq: 2 INVITE P-Nat: Yes Server: Sip EXpress router (0.10.99-iptelorg/tekelec-SOPv2 (i386/linux)) Content-Length: 0 Warning: 392 80.95.252.14:5070 "Noisy feedback tells: pid=22183 req_src_ip=80.95.252.5 req_src_port=5060 in_uri=sip:01608438483@sip.carpo.de;user=phone out_uri=sip:491608438483@217.188.44.79 via_cnt==2" Response=100; Trying 0:30;2,0,0,0, ---- [0]Rx Msg from 80.95.252.5:5060 SIP/2.0 183 Sitzungsfortschritt Record-Route: <sip:80.95.252.14:5070;avp=B50DCABydHBwcm94eQMAeWVz;lr=on> Record-Route: <sip:80.95.252.5;lr=on> Via: SIP/2.0/UDP 192.168.178.41:5062;rport=5062;received=84.150.194.222;branch=z9hG4bKa96c7242c55a1bc From: Use of a Display Name <sip:wa.mayer@sip.carpo.de>;tag=3931549548 To: <sip:01608438483@sip.carpo.de;user=phone>;tag=e0aef7928df800c0a39d563783d2a332 Call-ID: 3762823499(a)192.168.178.41 CSeq: 2 INVITE Contact: <sip:aa+wa.mayer@80.95.252.29:5090> Content-Type: application/sdp Server: Sip EXpress router (0.10.99-iptelorg/tekelec-SOPv2 (i386/linux)) Content-Length: 382 Warning: 392 80.95.252.29:5090 "Noisy feedback tells: pid=5490 req_src_ip=80.95.252.14 req_src_port=5070 in_uri=sip:491608438483@217.188.44.79 out_uri=sip:491608438483@217.188.44.79 via_cnt==0" v=0 o=- 4067017 0 IN IP4 62.53.226.18 s=Cisco SDP 0 c=IN IP4 80.95.247.69 t=0 0 m=audio 2544 RTP/AVP 0 101 100 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194,200-202 a=X-sqn:0 a=X-cap: 1 audio RTP/AVP 100 a=X-cpar: a=rtpmap:100 X-NSE/8000 a=X-cpar: a=fmtp:100 192-194,200-202 a=X-cap: 2 image udptl t38 a=nortpproxy:yes AVT: payload=101 Response=183; Session Progress 18x Response has SDP Frames per packet=2 SetG723Mode: 2 0 [0]Enable encoder 0 RTP TX[0]:SSRC_ID = 9e8b6574 RTP Tx Init: 0, 0 [0]Enable encoder 0 [0]Start/Resume Media-> 80.95.247.69:2544 (pt=0) ---- [0]Rx Msg from 80.95.252.5:5060 SIP/2.0 180 Klingelt Record-Route: <sip:80.95.252.14:5070;avp=B50DCABydHBwcm94eQMAeWVz;lr=on> Record-Route: <sip:80.95.252.5;lr=on> Via: SIP/2.0/UDP 192.168.178.41:5062;rport=5062;received=84.150.194.222;branch=z9hG4bKa96c7242c55a1bc From: Use of a Display Name <sip:wa.mayer@sip.carpo.de>;tag=3931549548 To: <sip:01608438483@sip.carpo.de;user=phone>;tag=e0aef7928df800c0a39d563783d2a332 Call-ID: 3762823499(a)192.168.178.41 CSeq: 2 INVITE Content-Type: application/sdp Server: Sip EXpress router (0.10.99-iptelorg/tekelec-SOPv2 (i386/linux)) Content-Length: 0 Warning: 392 80.95.252.29:5090 "Noisy feedback tells: pid=5490 req_src_ip=80.95.252.14 req_src_port=5070 in_uri=sip:491608438483@217.188.44.79 out_uri=sip:491608438483@217.188.44.79 via_cnt==0" Response=180; Ringing ---- [0]DPKT 1st: 91375780 91375620, pt 0 SCC Cmd[0:0]CANCEL [0:0]Cancel INVITE [0]CANCEL Retry 0 [0:0] Tx Msg to 80.95.252.5:5060 CANCEL sip::80.95.252.14:5070;avp=B50DCA SIP/2.0 Route: <sip:80.95.252.5;lr=on> Via: SIP/2.0/UDP 192.168.178.41:5062;branch=z9hG4bKa96c7242c55a1bc From: Use of a Display Name <sip:wa.mayer@sip.carpo.de>;tag=3931549548 To: <sip:01608438483@sip.carpo.de;user=phone> Call-ID: 3762823499(a)192.168.178.41 CSeq: 2 CANCEL User-Agent: Cisco-CP7912/8.0.0-060111A Supported: replaces, 100rel Proxy-Authorization: Digest username="wa.mayer",realm="carpo",nonce="45961c6006af8c7d88236d8de4aa44b64d504738",uri="sip:01608438483@sip. carpo.de",response="31b050a88b23b31a915df6f6ef8cff28" Content-Length: 0 [0]CANCEL Retry 1 ----- [0:0] Tx Msg to 80.95.252.5:5060 CANCEL sip::80.95.252.14:5070;avp=B50DCA SIP/2.0 Route: <sip:80.95.252.5;lr=on> Via: SIP/2.0/UDP 192.168.178.41:5062;branch=z9hG4bKa96c7242c55a1bc From: Use of a Display Name <sip:wa.mayer@sip.carpo.de>;tag=3931549548 To: <sip:01608438483@sip.carpo.de;user=phone> Call-ID: 3762823499(a)192.168.178.41 CSeq: 2 CANCEL User-Agent: Cisco-CP7912/8.0.0-060111A Supported: replaces, 100rel Proxy-Authorization: Digest username="wa.mayer",realm="carpo",nonce="45961c6006af8c7d88236d8de4aa44b64d504738",uri="sip:01608438483@sip. carpo.de",response="31b050a88b23b31a915df6f6ef8cff28" Content-Length: 0 [0]CANCEL Retry 2 [0:0] Tx Msg to 80.95.252.5:5060 CANCEL sip::80.95.252.14:5070;avp=B50DCA SIP/2.0 Route: <sip:80.95.252.5;lr=on> Via: SIP/2.0/UDP 192.168.178.41:5062;branch=z9hG4bKa96c7242c55a1bc From: Use of a Display Name <sip:wa.mayer@sip.carpo.de>;tag=3931549548 To: <sip:01608438483@sip.carpo.de;user=phone> Call-ID: 3762823499(a)192.168.178.41 CSeq: 2 CANCEL User-Agent: Cisco-CP7912/8.0.0-060111A Supported: replaces, 100rel Proxy-Authorization: Digest username="wa.mayer",realm="carpo",nonce="45961c6006af8c7d88236d8de4aa44b64d504738",uri="sip:01608438483@sip. carpo.de",response="31b050a88b23b31a915df6f6ef8cff28" Content-Length: 0 [0]CANCEL Retry 3 ----- [0:0] Tx Msg to 80.95.252.5:5060 CANCEL sip::80.95.252.14:5070;avp=B50DCA SIP/2.0 Route: <sip:80.95.252.5;lr=on> Via: SIP/2.0/UDP 192.168.178.41:5062;branch=z9hG4bKa96c7242c55a1bc From: Use of a Display Name <sip:wa.mayer@sip.carpo.de>;tag=3931549548 To: <sip:01608438483@sip.carpo.de;user=phone> Call-ID: 3762823499(a)192.168.178.41 CSeq: 2 CANCEL User-Agent: Cisco-CP7912/8.0.0-060111A Supported: replaces, 100rel Proxy-Authorization: Digest username="wa.mayer",realm="carpo",nonce="45961c6006af8c7d88236d8de4aa44b64d504738",uri="sip:01608438483@sip. carpo.de",response="31b050a88b23b31a915df6f6ef8cff28" Content-Length: 0 [0]CANCEL Retry 4 ---- [0:0] Tx Msg to 80.95.252.5:5060 CANCEL sip::80.95.252.14:5070;avp=B50DCA SIP/2.0 Route: <sip:80.95.252.5;lr=on> Via: SIP/2.0/UDP 192.168.178.41:5062;branch=z9hG4bKa96c7242c55a1bc From: Use of a Display Name <sip:wa.mayer@sip.carpo.de>;tag=3931549548 To: <sip:01608438483@sip.carpo.de;user=phone> Call-ID: 3762823499(a)192.168.178.41 CSeq: 2 CANCEL User-Agent: Cisco-CP7912/8.0.0-060111A Supported: replaces, 100rel Proxy-Authorization: Digest username="wa.mayer",realm="carpo",nonce="45961c6006af8c7d88236d8de4aa44b64d504738",uri="sip:01608438483@sip. carpo.de",response="31b050a88b23b31a915df6f6ef8cff28" Content-Length: 0 BYE/CAN Failed (Proxy No Resp) SCC Cmd[0:0]RELEASE >>> SIP Soft Reset [0:0] <<< ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

5 5

[Serusers] SER 0.10.99 (Carpo) - Cancel from CP-7912G not recognized - second
by Theodor Meier 15 Jan '07

15 Jan '07

I found another CANCEL problem where the Request-URI has not two double dots (sip:: ..) The call goes from Carpo to Carpo, wheras in my previous mail the call went to a gateway. What I found in the log is, that the branch Parameter is Via: SIP/2.0/UDP 192.168.178.42:5066;rport=5066;received=84.150.187.204;branch=z9hG4bK68fec26c25c87141 till PRACK, there and in the OK from the server this changes. Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK4abf1bf17596f52 the CANCEL request from the phone has the initial branch value. Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK68fec26c25c87141 finally the CANCEL is rejected SIP/2.0 404 Not Found Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK68fec26c25c87141;rport=5066;received=84.150.187.204 What is the reason for the rejection of the CANCEL? Is this a server or a phone problem? --------------------------- calling 23200302 SCC Cmd[0:0]CLIP SCC Cmd[0:0]CALL proxy = sip.carpo.de:5060 [0]INVITE Retry 0 [0:0] Tx Msg to 80.95.252.5:5060 INVITE sip:23200302@sip.carpo.de;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK56e50100b962975c From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone> Call-ID: 2749835686(a)84.150.187.204 CSeq: 1 INVITE Contact: <sip:paula.mayer@84.150.187.204:5066;transport=udp> User-Agent: Cisco-CP7912/8.0.0-060111A Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, UPDATE Supported: replaces, 100rel Expires: 300 Content-Length: 289 Content-Type: application/sdp v=0 o=paula.mayer 17339 17339 IN IP4 192.168.178.42 s=Cisco 7912 SIP Call c=IN IP4 84.150.187.204 t=0 0 m=audio 30006 RTP/AVP 0 18 8 101 a=rtpmap:0 PCMU/8000/1 a=rtpmap:18 G729/8000/1 a=fmtp:18 annexb=yes a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 [0]Rx Msg from 80.95.252.5:5060 SIP/2.0 407 Proxy Authentifikation erforderlich Via: SIP/2.0/UDP 192.168.178.42:5066;rport=5066;received=84.150.187.204;branch=z9hG4bK56e50100b962975c From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone>;tag=68e836eb5e2cffe6b7aefb548a3e0a9b.43de Call-ID: 2749835686(a)84.150.187.204 CSeq: 1 INVITE P-Nat: Yes Proxy-Authenticate: Digest realm="carpo", nonce="45abcd5aa631dd0be187ade4e8203010f5fb9de8" Server: Sip EXpress router (0.10.99-iptelorg/tekelec-SOPv2 (i386/linux)) Content-Length: 0 Warning: 392 80.95.252.14:5070 "Noisy feedback tells: pid=22174 req_src_ip=80.95.252.5 req_src_port=5060 in_uri=sip:23200302@sip.carpo.de;user=phone out_uri=sip:23200302@sip.carpo.de;user=phone via_cnt==2" Response=407; Proxy Authentication Required [0]TxMsg to 80.95.252.5:5060 ACK sip:23200302@sip.carpo.de;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK56e50100b962975c From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone>;tag=68e836eb5e2cffe6b7aefb548a3e0a9b.43de Call-ID: 2749835686(a)84.150.187.204 CSeq: 1 ACK User-Agent: Cisco-CP7912/8.0.0-060111A Content-Length: 0 [0]INVITE Retry 0 [0:0] Tx Msg to 80.95.252.5:5060 INVITE sip:23200302@sip.carpo.de;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK68fec26c25c87141 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone> Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 INVITE Contact: <sip:paula.mayer@84.150.187.204:5066;transport=udp> User-Agent: Cisco-CP7912/8.0.0-060111A Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, UPDATE Supported: replaces, 100rel Proxy-Authorization: Digest username="paula.mayer",realm="carpo",nonce="45abcd5aa631dd0be187ade4e8203010f5fb9de8",uri="sip:23200302@sip.carpo.de",response="271e020ff6474a1304077083c9beca99" Expires: 300 Content-Length: 289 Content-Type: application/sdp v=0 o=paula.mayer 17358 17358 IN IP4 192.168.178.42 s=Cisco 7912 SIP Call c=IN IP4 84.150.187.204 t=0 0 m=audio 30006 RTP/AVP 0 18 8 101 a=rtpmap:0 PCMU/8000/1 a=rtpmap:18 G729/8000/1 a=fmtp:18 annexb=yes a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 [0]Rx Msg from 80.95.252.5:5060 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 192.168.178.42:5066;rport=5066;received=84.150.187.204;branch=z9hG4bK68fec26c25c87141 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone> Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 INVITE P-Nat: Yes Server: Sip EXpress router (0.10.99-iptelorg/tekelec-SOPv2 (i386/linux)) Content-Length: 0 Response=100; Trying [0]Rx Msg from 80.95.252.5:5060 SIP/2.0 180 Klingelt Via: SIP/2.0/UDP 192.168.178.42:5066;rport=5066;received=84.150.187.204;branch=z9hG4bK68fec26c25c87141 Record-Route: <sip:80.95.252.5;lr=on> Record-Route: <sip:80.95.252.11:5070;avp=B50DCABydHBwcm94eQMAeWVz;lr=on> Record-Route: <sip:80.95.252.5;lr=on> From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone>;tag=3015611499 Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 INVITE Require: 100rel RSeq: 1 Contact: <sip:wa.mayer@84.150.187.204:5062;transport=udp> Server: Cisco-CP7912/8.0.0-060111A Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, UPDATE Content-Length: 0 Response=180; Ringing [0]PRACK Retry 0 [0:0] Tx Msg to 80.95.252.5:5060 PRACK sip:wa.mayer@84.150.187.204:5062 SIP/2.0 Route: <sip:80.95.252.5;lr=on>,<sip:80.95.252.11:5070;avp=B50DCABydHBwcm94eQMAeWVz;lr=on>,<sip:80.95.252.5;lr=on> Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK4abf1bf17596f52 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone>;tag=3015611499 Call-ID: 2749835686(a)84.150.187.204 CSeq: 3 PRACK RAck: 1 2 INVITE User-Agent: Cisco-CP7912/8.0.0-060111A Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, UPDATE Supported: replaces, 100rel Proxy-Authorization: Digest username="paula.mayer",realm="carpo",nonce="45abcd5aa631dd0be187ade4e8203010f5fb9de8",uri="sip:23200302@sip.carpo.de",response="34b5d81e9d984c39b09f586b09b12f04" Content-Length: 0 [0]Rx Msg from 80.95.252.5:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.178.42:5066;rport=5066;received=84.150.187.204;branch=z9hG4bK4abf1bf17596f52 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone>;tag=3015611499 Call-ID: 2749835686(a)84.150.187.204 CSeq: 3 PRACK Server: Cisco-CP7912/8.0.0-060111A Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, UPDATE Supported: replaces Content-Length: 0 SCC Cmd[0:0]CANCEL [0:0]Cancel INVITE [0]CANCEL Retry 0 [0:0] Tx Msg to 80.95.252.5:5060 CANCEL sip:wa.mayer@84.150.187.204:5062 SIP/2.0 Route: <sip:80.95.252.5;lr=on>,<sip:80.95.252.11:5070;avp=B50DCABydHBwcm94eQMAeWVz;lr=on>,<sip:80.95.252.5;lr=on> Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK68fec26c25c87141 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone> Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 CANCEL User-Agent: Cisco-CP7912/8.0.0-060111A Supported: replaces, 100rel Proxy-Authorization: Digest username="paula.mayer",realm="carpo",nonce="45abcd5aa631dd0be187ade4e8203010f5fb9de8",uri="sip:23200302@sip.carpo.de",response="5a04c4c23e034a4192e964fa468c9461" Content-Length: 0 [0]Rx Msg from 80.95.252.5:5060 SIP/2.0 404 Not Found Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK68fec26c25c87141;rport=5066;received=84.150.187.204 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone>;tag=a8c29d96e482b9ddbb33ac37669b77b1.da3a Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 CANCEL Server: Sip EXpress router (0.10.99-iptelorg/tekelec-SOPv2 (i386/linux)) Content-Length: 0 Warning: 392 80.95.252.5:5060 "Noisy feedback tells: pid=16875 req_src_ip=84.150.187.204 req_src_port=5066 in_uri=sip:wa.mayer@84.150.187.204:5062 out_uri=sip:wa.mayer@84.150.187.204:5062 via_cnt==1" [0]CANCEL Retry 1 [0:0] Tx Msg to 80.95.252.5:5060 CANCEL sip:wa.mayer@84.150.187.204:5062 SIP/2.0 Route: <sip:80.95.252.5;lr=on>,<sip:80.95.252.11:5070;avp=B50DCABydHBwcm94eQMAeWVz;lr=on>,<sip:80.95.252.5;lr=on> Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK68fec26c25c87141 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone> Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 CANCEL User-Agent: Cisco-CP7912/8.0.0-060111A Supported: replaces, 100rel Proxy-Authorization: Digest username="paula.mayer",realm="carpo",nonce="45abcd5aa631dd0be187ade4e8203010f5fb9de8",uri="sip:23200302@sip.carpo.de",response="5a04c4c23e034a4192e964fa468c9461" Content-Length: 0 [0]Rx Msg from 80.95.252.5:5060 SIP/2.0 404 Not Found Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK68fec26c25c87141;rport=5066;received=84.150.187.204 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone>;tag=a8c29d96e482b9ddbb33ac37669b77b1.da3a Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 CANCEL Server: Sip EXpress router (0.10.99-iptelorg/tekelec-SOPv2 (i386/linux)) Content-Length: 0 Warning: 392 80.95.252.5:5060 "Noisy feedback tells: pid=16872 req_src_ip=84.150.187.204 req_src_port=5066 in_uri=sip:wa.mayer@84.150.187.204:5062 out_uri=sip:wa.mayer@84.150.187.204:5062 via_cnt==1" [0]CANCEL Retry 2 [0:0] Tx Msg to 80.95.252.5:5060 CANCEL sip:wa.mayer@84.150.187.204:5062 SIP/2.0 Route: <sip:80.95.252.5;lr=on>,<sip:80.95.252.11:5070;avp=B50DCABydHBwcm94eQMAeWVz;lr=on>,<sip:80.95.252.5;lr=on> Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK68fec26c25c87141 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone> Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 CANCEL User-Agent: Cisco-CP7912/8.0.0-060111A Supported: replaces, 100rel Proxy-Authorization: Digest username="paula.mayer",realm="carpo",nonce="45abcd5aa631dd0be187ade4e8203010f5fb9de8",uri="sip:23200302@sip.carpo.de",response="5a04c4c23e034a4192e964fa468c9461" Content-Length: 0 [0]Rx Msg from 80.95.252.5:5060 SIP/2.0 404 Not Found Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK68fec26c25c87141;rport=5066;received=84.150.187.204 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone>;tag=a8c29d96e482b9ddbb33ac37669b77b1.da3a Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 CANCEL Server: Sip EXpress router (0.10.99-iptelorg/tekelec-SOPv2 (i386/linux)) Content-Length: 0 Warning: 392 80.95.252.5:5060 "Noisy feedback tells: pid=16874 req_src_ip=84.150.187.204 req_src_port=5066 in_uri=sip:wa.mayer@84.150.187.204:5062 out_uri=sip:wa.mayer@84.150.187.204:5062 via_cnt==1" [0]CANCEL Retry 3 [0:0] Tx Msg to 80.95.252.5:5060 CANCEL sip:wa.mayer@84.150.187.204:5062 SIP/2.0 Route: <sip:80.95.252.5;lr=on>,<sip:80.95.252.11:5070;avp=B50DCABydHBwcm94eQMAeWVz;lr=on>,<sip:80.95.252.5;lr=on> Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK68fec26c25c87141 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone> Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 CANCEL User-Agent: Cisco-CP7912/8.0.0-060111A Supported: replaces, 100rel Proxy-Authorization: Digest username="paula.mayer",realm="carpo",nonce="45abcd5aa631dd0be187ade4e8203010f5fb9de8",uri="sip:23200302@sip.carpo.de",response="5a04c4c23e034a4192e964fa468c9461" Content-Length: 0 [0]Rx Msg from 80.95.252.5:5060 SIP/2.0 404 Not Found Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK68fec26c25c87141;rport=5066;received=84.150.187.204 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone>;tag=a8c29d96e482b9ddbb33ac37669b77b1.da3a Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 CANCEL Server: Sip EXpress router (0.10.99-iptelorg/tekelec-SOPv2 (i386/linux3:00;2,0,0,0, )) Content-Length: 0 Warning: 392 80.95.252.5:5060 "Noisy feedback tells: pid=16871 req_src_ip=84.150.187.204 req_src_port=5066 in_uri=sip:wa.mayer@84.150.187.204:5062 out_uri=sip:wa.mayer@84.150.187.204:5062 via_cnt==1" [0]CANCEL Retry 4 [0:0] Tx Msg to 80.95.252.5:5060 CANCEL sip:wa.mayer@84.150.187.204:5062 SIP/2.0 Route: <sip:80.95.252.5;lr=on>,<sip:80.95.252.11:5070;avp=B50DCABydHBwcm94eQMAeWVz;lr=on>,<sip:80.95.252.5;lr=on> Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK68fec26c25c87141 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone> Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 CANCEL User-Agent: Cisco-CP7912/8.0.0-060111A Supported: replaces, 100rel Proxy-Authorization: Digest username="paula.mayer",realm="carpo",nonce="45abcd5aa631dd0be187ade4e8203010f5fb9de8",uri="sip:23200302@sip.carpo.de",response="5a04c4c23e034a4192e964fa468c9461" Content-Length: 0 [0]Rx Msg from 80.95.252.5:5060 SIP/2.0 404 Not Found Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK68fec26c25c87141;rport=5066;received=84.150.187.204 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone>;tag=a8c29d96e482b9ddbb33ac37669b77b1.da3a Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 CANCEL Server: Sip EXpress router (0.10.99-iptelorg/tekelec-SOPv2 (i386/linux)) Content-Length: 0 Warning: 392 80.95.252.5:5060 "Noisy feedback tells: pid=16868 req_src_ip=84.150.187.204 req_src_port=5066 in_uri=sip:wa.mayer@84.150.187.204:5062 out_uri=sip:wa.mayer@84.150.187.204:5062 via_cnt==1" BYE/CAN Failed (Proxy No Resp) SCC Cmd[0:0]RELEASE >>> SIP Soft Reset [0:0] <<< 3:30;2,0,0,0, [0]Rx Msg from 80.95.252.5:5060 SIP/2.0 480 Temporarily Not Available Via: SIP/2.0/UDP 192.168.178.42:5066;rport=5066;received=84.150.187.204;branch=z9hG4bK68fec26c25c87141 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone>;tag=3015611499 Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 INVITE Server: Cisco-CP7912/8.0.0-060111A Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, UPDATE Content-Length: 0 [0]TxMsg to 80.95.252.5:5060 ACK sip:23200302@sip.carpo.de;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.178.42:5066;branch=z9hG4bK68fec26c25c87141 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone>;tag=3015611499 Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 ACK User-Agent: Cisco-CP7912/8.0.0-060111A Content-Length: 0 [0]Rx Msg from 80.95.252.5:5060 SIP/2.0 480 Temporarily Not Available Via: SIP/2.0/UDP 192.168.178.42:5066;rport=5066;received=84.150.187.204;branch=z9hG4bK68fec26c25c87141 From: sip:paula.mayer@sip.carpo.de;tag=168806121 To: <sip:23200302@sip.carpo.de;user=phone>;tag=3015611499 Call-ID: 2749835686(a)84.150.187.204 CSeq: 2 INVITE Server: Cisco-CP7912/8.0.0-060111A Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER, PRACK, UPDATE Content-Length: 0 ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

2 1

[Serusers] Re: Users presence status
by Vaclav Kubart 15 Jan '07

15 Jan '07

According to PIDF RFC there MUST be <basic> with value "open" or "closed". I guess, that this PUBLISH request should be rejected with non-2xx response. Is it? BTW, PA is not able to handle "partial PIDF" - you have to use PIDF. Presence status can be stored into database if you set "use_db" module parameter to 1. You can publish document like this: <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" entity="pres:venkat@10.187.83.218"> <tuple id="000s3"> <status> <basic>open</basic> </status> <contact>venkat(a)10.187.83.218</contact> </tuple> <dm:person id="p1"> <rpid:activities> <busy/> </rpid:activities> </dm:person> </presence> I'm not sure if it is strictly according to RPID specification, but might be. Much simpler it could be like this: <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" entity="pres:venkat@10.187.83.218"> <tuple id="000s3"> <status> <basic>open</basic> </status> <contact>venkat(a)10.187.83.218</contact> <note>busy</note> </tuple> </presence> Vaclav On Mon, Jan 15, 2007 at 01:34:04PM +0530, raj gopal wrote: > Thanks for reply, > > I am sending PUBLISH method with following simplified PIDF content. > > <pidf-part:presence xmlns:pidf-part="urn:ietf:params:xml:ns:pidf-partial" > xmlns="urn:ietf:params:xml:ns:pidf" > xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple" > xmlns:ep="urn:ietf:params:xml:ns:pidf:status:rpid-status" > xmlns:dc="urn:ietf:params:xml:ns:pidf:status:devcaps" entity=" > venkat(a)10.187.83.218" version="1" state="full"> > <tuple id="000s3"> > <status> > <basic>busy</basic> > </status> > <contact>venkat(a)10.187.83.218</contact> > </tuple> > > But, server sends following NOTIFY msg > > <?xml version="1.0" encoding="UTF-8"?> > <presence xmlns="urn:ietf:params:xml:ns:pidf" entity=" > pres:venkat@10.187.83.218"> > <tuple id="0xb626fba4x52c779c5x45ab1b6d"> > <status><basic>open</basic></status> > <contact priority="0.00">sip:10.187.83.222:5060</contact> > </tuple> > </presence> > > The server sends either closed/open. But it dont send busy status. > > Am i doing something wrong? is status is stored in database?? > > -venkat > > > On 1/15/07, Vaclav Kubart <vaclav.kubart(a)iptel.org> wrote: > > > >Hello, > >SER understands only basic status what means open/closed, but it allows > >clients to publish other info in extension elements (look into PIDF > >specification - RFC 3863). Such elements are not parsed by SER, but they > >are sent in NOTIFY to watchers. > > > >If you don't want to use PIDF extension elements, you can send > >additional status info in <note> elements - many clients do it in this > >way. > > > > Vaclav > > > >On Mon, Jan 15, 2007 at 12:11:31PM +0530, raj gopal wrote: > >> Hi Vaclav, > >> > >> I am using SER as sip and presence server. According to my understanding > >SER > >> supports "open" and "close" presence status. But, my application > >required > >> presence status like busy, tolunch etc.. When client sends PUBLISH with > >his > >> presence status , how does SER process it? while server sending NOTIFY, > >does > >> it consider the status published by client?? > >> > >> Please suggest me to achieve above requirement. > >> > >> -Venkat > >

1 0

[Serusers] Users presence status
by raj gopal 15 Jan '07

15 Jan '07

Hi, Does presence module supports user presence status other than closed/open. -venkat

2 1

Re: [Users] Multi Call Legs Accounting
by Daniel-Constantin Mierla 14 Jan '07

14 Jan '07

Hello, are you proxying the media stream all the time now? Or just when the one of the party is behind the nat? I have in mynd the sceanrio when the initial callee is behind nat, it sends back redirect, and the new destination is public... Cheers, Daniel On 01/12/07 14:36, Howard Tang wrote: > Hi Daniel, > > Thank you very much, the problem fixed. > > Regards, > Howard > > On 1/11/07, Daniel-Constantin Mierla <daniel(a)voice-system.ro> wrote: >> Hello, >> >> as i see in your failure route you close mediaproxy nat handling -- try >> to keep it on. ALso, the contacts in redirect message might be natted >> even when initial destination wasn't -- you have to deal with this case >> as well (start nat handling). >> >> Cheers, >> Daniel >> >> >> On 01/09/07 14:23, Howard Tang wrote: >> > Hi Daniel, >> > >> > by using the following code in the failure_route block, i am able to >> > have a better accounting record for billing. However, i am having one >> > way audio problem which i believe it is related to NAT. I have tested >> > forward a call on a UA which is on public ip, which works prefectly. >> > However, when i tested it with UA which is behind NAT, one way audio >> > happen when the UA send 302 reply to forward a call.. >> > >> > failure_route[1] >> > { >> > end_media_session(); >> > # Handle 302 Redirects >> > if (t_check_status("302")) { >> > get_redirects("*"); >> > t_relay(); >> > }; >> > } >> > >> > Anyone has an idea on how i can fix this? >> > >> > Regards, >> > Howard >> > >> > >> > On 1/9/07, Daniel-Constantin Mierla <daniel(a)voice-system.ro> wrote: >> >> Hello, >> >> >> >> when the call A -> B is forwarded to C, then you need to have in your >> >> script: >> >> >> >> avp_write("A", "$avp(i:110)"); >> >> avp_write("B", "$avp(i:111)"); >> >> avp_write("B", "$avp(i:110)"); >> >> avp_write("C", "$avp(i:111)"); >> >> >> >> A, B, C are the SIP addresses of the parties involved in this call. >> >> >> >> Cheers, >> >> Daniel >> >> >> >> On 01/08/07 23:14, Howard Tang wrote: >> >> > Hi, >> >> > >> >> > Did anyone successfully setup call accounting for call forward? >> I have >> >> > been searching for a working example for few days on google, I >> still >> >> > couldn't find any working example. >> >> > >> >> > The config I have at the moment is >> >> > >> >> > modparam("acc", "multi_leg_enabled", 1) >> >> > modparam("acc", "src_leg_avp_id", 110) >> >> > modparam("acc", "dst_leg_avp_id", 111) >> >> > >> >> > In the main route, >> >> > if (!method=="REGISTER" && !method=="NOTIFY") { >> >> > avp_write("$from/username", "$avp(i:110)"); >> >> > avp_write("$ruri/username", "$avp(i:111)"); >> >> > }; >> >> > >> >> > Let say A call B and B forward call to C, the record in the acc >> table >> >> > is all >> >> > A to C without B in any one of the record for billing purpose. The >> >> > Call forward was set on the UA. >> >> > >> >> > Can anyone give me a hand on this please? >> >> > >> >> >> > >> >

2 1

[Serusers] proxy_challenge and E60
by Stefan Tichy 14 Jan '07

14 Jan '07

Hi, a nokia E60 is registered to SER 0.9.6. The response to a INVITE by the E60 is not a proper 407 response but just a small UDP paket (46 bytes). I cannot be shure that it is really the response and not some data send from time to time, but there is no other response. Ethereal does not identify this paket as SIP if (!proxy_authorize("domain","subscriber")) { log(3,"proxy_challenge"); proxy_challenge("domain","0"); break; } The phone is registered and can be called. Just INVITE does not work. Compression and security flags in phones config are set to off. The firmware of the phone is somewhat old, but probably I am not the only one using E60 with old firmware. The INVITE itself looks not bad and does work for asterisk 1.4 server and other systems. Even if the INVITE would contain garbage SER should send some SIP response with 5XX code. It is strange. Any help appreciated -- Stefan Tichy <seruser(a)pi4tel.de>

4 4

[Users] prevent double registration
by Howard Tang 14 Jan '07

14 Jan '07

Hi, What do i need to do if i want to prevent same user using two different UAs to register to openser in different location? e.g. A has 2 ATA, one at 222.222.222.222 and one in 111.111.111.111, he has put same login detials in the ATA, and try to register openser on 123.123.123.123 Both ATA will successfully register to the proxy, i want to prevent this, what can be done? Regards, Howard

3 4

[Users] Reduce Retry Time
by Arun Kumar 14 Jan '07

14 Jan '07

Hi, I've configured the ser with my lcr and its working fine. If first gateway fails after a wait of 30sec it loads another gw and passes the call to my asterisk server. Now I want to reduce this 30sec retry time to 5sec so in case my first gw is not reachable then after 5sec it should load the next gateway. thanks arun

4 5

[Serusers] Status of SER 2.0 (Ottendorf) documentation
by Greger V. Teigre 14 Jan '07

14 Jan '07

Just a quick summary of documentation status for SER 2.0 (Ottendorf): ------------------- * http://www.iptel.org/ser/doc/010whatsnew contains a set of book pages introducing new features * ser-basic.cfg and ser.cfg in etc/ directory of source package contains a non-database and mysql database example that should be a good basis for testing * http://www.iptel.org/new_major_ser_pre_release_ottendorf_is_out_for_testing provides and overview of new stuff and a step-wise guide to get started * Module documentation is available online at http://www.iptel.org/views/moduledocs (I personally prefer the table overview for quick browsing: http://www.iptel.org/views/tableofmodules). Most of the important modules are available online, but see below for module documentation status What's left? ---------------- * Overall review of all readme files in source tree, as well as review of completeness/correctness of module documentation * Completion of module documentation * Update SER - Getting Started document and configuration files * Complete What's New 0.10.x as a migration guide; evaluate what to extract in a separate manual for SER functionality (updated admin guide) * Make sure all new features have been documented properly either in module docs or migration guide If you want to contribute in some way, please volunteer! (ex. to review module documentation for your favorite module...) g-) ---------------------------------------------------------------------------- Most of the modules are documented online at iptel.org. The documentation is checked out every night (4am CET) from the cvs and generated, so any changes made the previous day will be available online the next day. The modules below are not yet available online and the following have no readme or docbook documentation in CVS (anybody with documentation for these, please make a sound!): acc_db acc_radius ctl dialog fifo xmlrpc These modules have README files available in CVS, but have not been converted to docbook format yet (in the works): db_ops diversion eval mediaproxy postgres timer tls

1 0

[Users] get_hdr_field: bad to header...
by Lars Sundqvist 14 Jan '07

14 Jan '07

Hello, We have a few hundred users registered to a openser we are running and everything works fine, however i get som error messages in the logs I would like to get rid of... //sbin/openser[28867]: ERROR: get_hdr_field: bad to header /sbin/openser[28867]: ERROR: bad header field /sbin/openser[28867]: ERROR: get_hdr_field: bad to header /sbin/openser[28867]: ERROR: bad header field /sbin/openser[28867]: ERROR:parse_from_header: bad from header /sbin/openser[28867]: xl_get_from: ERROR cannot parse FROM header /sbin/openser[28867]: ERROR: get_hdr_field: bad to header /sbin/openser[28867]: ERROR: bad header field /sbin/openser[28867]: xl_get_to: ERROR cannot parse TO header /sbin/openser[28867]: [REGISTER] from [<null>] to [<null>] /sbin/openser[28867]: ERROR: get_hdr_field: bad to header /sbin/openser[28867]: ERROR: bad header field /sbin/openser[28867]: ERROR:maxfwd:is_maxfwd_present : parsing MAX_FORWARD header failed! /sbin/openser[28867]: ERROR:parse_from_header: bad from header /sbin/openser[28867]: insert_RR(): From parsing failed /sbin/openser[28867]: record_route(): Error while inserting Record-Route line /sbin/openser[28867]: ERROR: get_hdr_field: bad to header /sbin/openser[28867]: ERROR: bad header field /sbin/openser[28867]: find_first_route: Error while parsing headers /sbin/openser[28867]: analyzing REGISTER request /sbin/openser[28867]: ERROR: get_hdr_field: bad to header /sbin/openser[28867]: ERROR: bad header field /sbin/openser[28867]: find_credentials(): Error while parsing headers /sbin/openser[28867]: pre_auth(): Error while looking for credentials /sbin/openser[28867]: ERROR: get_hdr_field: bad to header /sbin/openser[28867]: ERROR: bad header field /sbin/openser[28867]: ERROR: get_hdr_field: bad to header /sbin/openser[28867]: ERROR: bad header field /sbin/openser[28867]: ERROR: build_res_buf_from_sip_req: alas, parse_headers failed /sbin/openser[28867]: pre_auth(): Error while sending 400 reply / Anyone has a clue what I can do to debug this to find out where the request are coming from or what can be done to stop the invalid(?) requests from being processed and clutter my logs? Thanks Lars Sundqvist

6 9

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