sr-users February 2006

sr-users@lists.kamailio.org

189 participants
373 discussions

RE: [Users] Receiving different VIA in INVITE and CANCEL

by Papadopoulos Georgios

Aaah, I see... So how does TM work? Does it try first the pre-RFC3261 and then the RFC3261? Thank you George > -----Original Message----- > From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] > Sent: Wednesday, February 08, 2006 4:05 PM > To: Papadopoulos Georgios > Cc: users(a)openser.org > Subject: Re: [Users] Receiving different VIA in INVITE and CANCEL > > George, > > there are two algs for transaction matching: > - the pre-RFC3261 one - a set of hdrs and RURI are used > to match the CANCEL to the original INVITE > - the RFC3261 alg - the cookies and ID from the branch > VIA param is used. > > via1_matching and ruri_matching are options only for the > pre-RFC3261 alg. > > regards, > bogdan > > Papadopoulos Georgios wrote: > > >Hi Bogdan, > > > >I will try the force_rport(). > > > >Meanwhile I am confused by what you wrote. Can you please clarify? > > > > > >>The problem is the different port in via. The "via1_matching" > >>param has no effect on RFC3261 transaction matching algorithm since > >>this is entirely based on via :). > >> > >> > > > >thanks a lot > > > >George > > > > > > > >>-----Original Message----- > >>From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] > >>Sent: Wednesday, February 08, 2006 11:43 AM > >>To: Papadopoulos Georgios > >>Cc: users(a)openser.org > >>Subject: Re: [Users] Receiving different VIA in INVITE and CANCEL > >> > >>Hi Geroge, > >> > >>it looks like your device uses STUN to perform nat traversal (the > >>callid has a private IP). The improper nat traversal via > STUN is the > >>reason for the different port in VIA; to fix this, call > >>"force_rport()" > >>in the beginning of your script for all requests. > >> > >>now, going back to the CANCEL matching....SIPURA uses the > >>RFC3261 transaction matching algorithm (based on some > cookie and ids > >>stored in branch VIA param. These are matching in your case, but > >>openser uses as additional checkings the via host, port and proto > >>(just to be sure that the originator matches too to avoid confusion > >>with different senders generating the same cookie/id). > >>The problem is the different port in via. The "via1_matching" > >>param has no effect on RFC3261 transaction matching algorithm since > >>this is entirely based on via :). > >> > >>my suggestion is to fix the nat traversal part. > >> > >>regards, > >>bogdan > >> > >>Papadopoulos Georgios wrote: > >> > >> > >> > >>>Hi Bogdan, > >>> > >>>Thank you for your reply. > >>> > >>>I used > >>>modparam("tm", "via1_matching", 0) > >>>modparam("tm", "ruri_matching", 0) > >>>and I got the following trace. You can see that the ACK to > the Proxy > >>>Authentication Required and the CANCEL have different Via than the > >>>INVITE. I know that this breaks the specs but I thought that > >>> > >>> > >>these two > >> > >> > >>>modparams should take care of these broken UAs. > >>> > >>>Also, any ideas what makes the UA switch ports? Is it a NAT > >>> > >>> > >>issue? Only > >> > >> > >>>a very small percentage of the same UA behave this way. > >>> > >>>thank you for any help > >>> > >>>George > >>> > >>> > >>># > >>>U 2006/02/07 12:05:29.756686 195.167.60.21:1231 -> > 213.5.43.134:5060 > >>>INVITE sip:2116872933@sip.i-call.gr SIP/2.0. > >>>Via: SIP/2.0/UDP 195.167.60.21:1327;branch=z9hG4bK-cc55e25. > >>>From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >>>To: <sip:2116872933@sip.i-call.gr>. > >>>Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >>>CSeq: 101 INVITE. > >>>Contact: tester <sip:tester@195.167.60.21:1327>. > >>>Remote-Party-ID: tester > >>><sip:tester@sip.i-call.gr>;screen=yes;party=calling. > >>>Max-Forwards: 70. > >>>Expires: 240. > >>>User-Agent: Sipura/SPA3000-3.1.7(GWg). > >>>Supported: x-sipura. > >>>Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. > >>>Content-Type: application/sdp. > >>>Content-Length: 423 . > >>>. > >>>v=0. > >>>o=- 33757 33757 IN IP4 195.167.60.21. > >>>s=-.. > >>>c=IN IP4 195.167.60.21. > >>>t=0 0. > >>>m=audio 10200 RTP/AVP 18 0 2 4 8 96 97 98 100 101. > >>>a=rtpmap:18 G729a/8000. > >>>a=rtpmap:0 PCMU/8000. > >>>a=rtpmap:2 G726-32/8000. > >>>a=rtpmap:4 G723/8000. > >>>a=rtpmap:8 PCMA/8000. > >>>a=rtpmap:96 G726-40/8000. > >>>a=rtpmap:97 G726-24/8000. > >>>a=rtpmap:98 G726-16/8000. > >>>a=rtpmap:100 NSE/8000. > >>>a=rtpmap:101 telephone-event/8000. > >>>a=fmtp:101 0-15. > >>>a=ptime:30. > >>>a=sendrecv. > >>> > >>># > >>>U 2006/02/07 12:05:29.757360 213.5.43.134:5060 -> > 195.167.60.21:1327 > >>>SIP/2.0 407 Proxy Authentication Required. > >>>Via: SIP/2.0/UDP 195.167.60.21:1327;branch=z9hG4bK-cc55e25. > >>>From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >>>To: > >>><sip:2116872933@sip.i-call.gr>;tag=97e44c910458bd56beb40ca402 > >>> > >>> > >>8d7cc8.0f0 > >> > >> > >>>e > >>>. > >>>Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >>>CSeq: 101 INVITE. > >>>Proxy-Authenticate: Digest realm="i-call.gr", > >>>nonce="43e87215b69f85cf82f231965df4ad938a65d43f". > >>>Server: OpenSer (1.0.0-tls (x86_64/linux)). > >>>Content-Length: 0. > >>>Warning: 392 213.5.43.134:5060 "Noisy feedback tells: pid=10474 > >>>req_src_ip=195.167.60.21 req_src_port=1231 > >>>in_uri=sip:2116872933@sip.i-call.gr > >>>out_uri=sip:2116872933@sip.i-call.gr > >>>via_cnt==1". > >>>. > >>> > >>># > >>>U 2006/02/07 12:05:29.865886 195.167.60.21:1327 -> > 213.5.43.134:5060 > >>>ACK sip:2116872933@sip.i-call.gr SIP/2.0. > >>>Via: SIP/2.0/UDP 195.167.60.21:1328;branch=z9hG4bK-cc55e25. > >>>From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >>>To: > >>><sip:2116872933@sip.i-call.gr>;tag=97e44c910458bd56beb40ca402 > >>> > >>> > >>8d7cc8.0f0 > >> > >> > >>>e > >>>. > >>>Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >>>CSeq: 101 ACK. > >>>Contact: tester <sip:tester@195.167.60.21:1328>. > >>>Max-Forwards: 70. > >>>User-Agent: Sipura/SPA3000-3.1.7(GWg). > >>>Content-Length: 0. > >>>. > >>>************************************************************* > >>> > >>> > >>********** > >> > >> > >>>* > >>>************** > >>>*** The Via in the ACK is different than in the INVITE and Openser > >>>sends it > >>>*** to the wrong server > >>>************************************************************* > >>> > >>> > >>********** > >> > >> > >>>* > >>>************** > >>># > >>>U 2006/02/07 12:05:29.866660 213.5.43.134:5060 -> > 213.5.xxx.xxx:5060 > >>>ACK sip:401#2116872933@213.5.xxx.xxx:5060 SIP/2.0. > >>>Record-Route: <sip:213.5.43.134;ftag=a75dbec37247ce75o0;lr=on>. > >>>Via: SIP/2.0/UDP 213.5.43.134;branch=0. > >>>Via: SIP/2.0/UDP 195.167.60.21:1328;branch=z9hG4bK-cc55e25. > >>>From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >>>To: > >>><sip:2116872933@sip.i-call.gr>;tag=97e44c910458bd56beb40ca402 > >>> > >>> > >>8d7cc8.0f0 > >> > >> > >>>e > >>>. > >>>Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >>>CSeq: 101 ACK. > >>>Contact: tester <sip:tester@195.167.60.21:1328>. > >>>Max-Forwards: 69. > >>>User-Agent: Sipura/SPA3000-3.1.7(GWg). > >>>Content-Length: 0. > >>>. > >>> > >>># > >>>U 2006/02/07 12:05:29.959041 195.167.60.21:1327 -> > 213.5.43.134:5060 > >>>INVITE sip:2116872933@sip.i-call.gr SIP/2.0. > >>>Via: SIP/2.0/UDP 195.167.60.21:1328;branch=z9hG4bK-bf20b945. > >>>From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >>>To: <sip:2116872933@sip.i-call.gr>. > >>>Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >>>CSeq: 102 INVITE. > >>>Contact: tester <sip:tester@195.167.60.21:1328>. > >>>Proxy-Authorization: Digest username="tester", realm="i-call.gr", > >>>nonce="43e87215b69f85cf82f231965df4ad938a65d43f", > >>>uri="sip:2116872933@sip.i-call.gr", > >>>response="da850791f85d3e882d384d96e4aff30e", algorithm=MD5. > >>>Remote-Party-ID: tester > >>><sip:tester@sip.i-call.gr>;screen=yes;party=calling. > >>>Max-Forwards: 70. > >>>Expires: 240. > >>>User-Agent: Sipura/SPA3000-3.1.7(GWg). > >>>Supported: x-sipura. > >>>Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. > >>>Content-Type: application/sdp. > >>>Content-Length: 423 . > >>>. > >>>v=0. > >>>o=- 33757 33757 IN IP4 195.167.60.21. > >>>s=-.. > >>>c=IN IP4 195.167.60.21. > >>>t=0 0. > >>>m=audio 10200 RTP/AVP 18 0 2 4 8 96 97 98 100 101. > >>>a=rtpmap:18 G729a/8000. > >>>a=rtpmap:0 PCMU/8000. > >>>a=rtpmap:2 G726-32/8000. > >>>a=rtpmap:4 G723/8000. > >>>a=rtpmap:8 PCMA/8000. > >>>a=rtpmap:96 G726-40/8000. > >>>a=rtpmap:97 G726-24/8000. > >>>a=rtpmap:98 G726-16/8000. > >>>a=rtpmap:100 NSE/8000. > >>>a=rtpmap:101 telephone-event/8000. > >>>a=fmtp:101 0-15. > >>>a=ptime:30. > >>>a=sendrecv. > >>> > >>># > >>>U 2006/02/07 12:05:29.960454 213.5.43.134:5060 -> > 195.167.60.21:1328 > >>>SIP/2.0 100 trying -- your call is important to us. > >>>Via: SIP/2.0/UDP 195.167.60.21:1328;branch=z9hG4bK-bf20b945. > >>>From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >>>To: <sip:2116872933@sip.i-call.gr>. > >>>Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >>>CSeq: 102 INVITE. > >>>Server: OpenSer (1.0.0-tls (x86_64/linux)). > >>>Content-Length: 0. > >>>Warning: 392 213.5.43.134:5060 "Noisy feedback tells: pid=10473 > >>>req_src_ip=195.167.60.21 req_src_port=1327 > >>>in_uri=sip:2116872933@sip.i-call.gr > >>>out_uri=sip:400#2116872933@213.5.yyy.yyy:5060 via_cnt==1". > >>>. > >>> > >>>************************************************************* > >>> > >>> > >>********** > >> > >> > >>>* > >>>*** Openser forwards the request to PSTN gateway > >>>************************************************************* > >>> > >>> > >>********** > >> > >> > >>>* > >>> > >>># > >>>U 2006/02/07 12:05:29.960516 213.5.43.134:5060 -> > 213.5.yyy.yyy:5060 > >>>INVITE sip:400#2116872933@213.5.yyy.yyy:5060 SIP/2.0. > >>>Record-Route: <sip:213.5.43.134;ftag=a75dbec37247ce75o0;lr=on>. > >>>Via: SIP/2.0/UDP 213.5.43.134;branch=z9hG4bK53cd.4e18cee6.0. > >>>Via: SIP/2.0/UDP 195.167.60.21:1328;branch=z9hG4bK-bf20b945. > >>>From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >>>To: <sip:2116872933@sip.i-call.gr>. > >>>Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >>>CSeq: 102 INVITE. > >>>Contact: tester <sip:tester@195.167.60.21:1328>. > >>>Max-Forwards: 69. > >>>Expires: 240. > >>>User-Agent: Sipura/SPA3000-3.1.7(GWg). > >>>Supported: x-sipura. > >>>Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. > >>>Content-Type: application/sdp. > >>>Content-Length: 423 . > >>>. > >>>v=0. > >>>o=- 33757 33757 IN IP4 195.167.60.21. > >>>s=-.. > >>>c=IN IP4 195.167.60.21. > >>>t=0 0. > >>>m=audio 10200 RTP/AVP 18 0 2 4 8 96 97 98 100 101. > >>>a=rtpmap:18 G729a/8000. > >>>a=rtpmap:0 PCMU/8000. > >>>a=rtpmap:2 G726-32/8000. > >>>a=rtpmap:4 G723/8000. > >>>a=rtpmap:8 PCMA/8000. > >>>a=rtpmap:96 G726-40/8000. > >>>a=rtpmap:97 G726-24/8000. > >>>a=rtpmap:98 G726-16/8000. > >>>a=rtpmap:100 NSE/8000. > >>>a=rtpmap:101 telephone-event/8000. > >>>a=fmtp:101 0-15. > >>>a=ptime:30. > >>>a=sendrecv. > >>> > >>># > >>>U 2006/02/07 12:05:29.975762 213.5.yyy.yyy:57918 -> > >>> > >>> > >>213.5.43.134:5060 > >> > >> > >>>SIP/2.0 100 Trying. > >>>Via: SIP/2.0/UDP > >>> > >>> > >>213.5.43.134;branch=z9hG4bK53cd.4e18cee6.0,SIP/2.0/UDP > >> > >> > >>>195.167.60.21:1328;branch=z9hG4bK-bf20b945. > >>>From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >>>To: <sip:2116872933@sip.i-call.gr>;tag=329C938C-7DF. > >>>Date: Tue, 07 Feb 2006 10:06:34 GMT. > >>>Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >>>Server: Cisco-SIPGateway/IOS-12.x. > >>>CSeq: 102 INVITE. > >>>Allow-Events: telephone-event. > >>>Content-Length: 0. > >>>. > >>> > >>> > >>># > >>>U 2006/02/07 12:05:30.149177 213.5.yyy.yyy:57918 -> > >>> > >>> > >>213.5.43.134:5060 > >> > >> > >>>SIP/2.0 183 Session Progress. > >>>Via: SIP/2.0/UDP > >>> > >>> > >>213.5.43.134;branch=z9hG4bK53cd.4e18cee6.0,SIP/2.0/UDP > >> > >> > >>>195.167.60.21:1328;branch=z9hG4bK-bf20b945. > >>>From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >>>To: <sip:2116872933@sip.i-call.gr>;tag=329C938C-7DF. > >>>Date: Tue, 07 Feb 2006 10:06:34 GMT. > >>>Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >>>Server: Cisco-SIPGateway/IOS-12.x. > >>>CSeq: 102 INVITE. > >>>Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, > >>>SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER. > >>>Allow-Events: telephone-event. > >>>Contact: <sip:400#2116872933@213.5.yyy.yyy:5060>. > >>>Record-Route: <sip:213.5.43.134;ftag=a75dbec37247ce75o0;lr=on>. > >>>Content-Disposition: session;handling=required. > >>>Content-Type: application/sdp. > >>>Content-Length: 288. > >>>. > >>>v=0. > >>>o=CiscoSystemsSIP-GW-UserAgent 9560 6985 IN IP4 213.5.yyy.yyy. > >>>s=SIP Call. > >>>c=IN IP4 213.5.yyy.yyy. > >>>t=0 0. > >>>m=audio 17868 RTP/AVP 18 101. > >>>c=IN IP4 213.5.yyy.yyy. > >>>a=rtpmap:18 G729/8000. > >>>a=fmtp:18 annexb=no. > >>>a=rtpmap:101 telephone-event/8000. > >>>a=fmtp:101 0-15. > >>>a=ptime:20. > >>>a=silenceSupp:off - - - -. > >>> > >>># > >>>U 2006/02/07 12:05:30.149263 213.5.43.134:5060 -> > 195.167.60.21:1328 > >>>SIP/2.0 183 Session Progress. > >>>Via: SIP/2.0/UDP 195.167.60.21:1328;branch=z9hG4bK-bf20b945. > >>>From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >>>To: <sip:2116872933@sip.i-call.gr>;tag=329C938C-7DF. > >>>Date: Tue, 07 Feb 2006 10:06:34 GMT. > >>>Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >>>Server: Cisco-SIPGateway/IOS-12.x. > >>>CSeq: 102 INVITE. > >>>Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, > >>>SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER. > >>>Allow-Events: telephone-event. > >>>Contact: <sip:400#2116872933@213.5.yyy.yyy:5060>. > >>>Record-Route: <sip:213.5.43.134;ftag=a75dbec37247ce75o0;lr=on>. > >>>Content-Disposition: session;handling=required. > >>>Content-Type: application/sdp. > >>>Content-Length: 288. > >>>. > >>>v=0. > >>>o=CiscoSystemsSIP-GW-UserAgent 9560 6985 IN IP4 213.5.yyy.yyy. > >>>s=SIP Call. > >>>c=IN IP4 213.5.yyy.yyy. > >>>t=0 0. > >>>m=audio 17868 RTP/AVP 18 101. > >>>c=IN IP4 213.5.yyy.yyy. > >>>a=rtpmap:18 G729/8000. > >>>a=fmtp:18 annexb=no. > >>>a=rtpmap:101 telephone-event/8000. > >>>a=fmtp:101 0-15. > >>>a=ptime:20. > >>>a=silenceSupp:off - - - -. > >>> > >>>************************************************************* > >>> > >>> > >>********** > >> > >> > >>>* > >>>**** > >>>*** User Agents sends CANCEL with different Via than in INVITE > >>>*** and Openser send it to the wrong server > >>>************************************************************* > >>> > >>> > >>********** > >> > >> > >>>* > >>>**** > >>> > >>># > >>>U 2006/02/07 12:05:37.859125 195.167.60.21:1328 -> > 213.5.43.134:5060 > >>>CANCEL sip:2116872933@sip.i-call.gr SIP/2.0. > >>>Via: SIP/2.0/UDP 195.167.60.21:1375;branch=z9hG4bK-bf20b945. > >>>From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >>>To: <sip:2116872933@sip.i-call.gr>. > >>>Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >>>CSeq: 102 CANCEL. > >>>Proxy-Authorization: Digest username="tester", realm="i-call.gr", > >>>nonce="43e87215b69f85cf82f231965df4ad938a65d43f", > >>>uri="sip:2116872933@sip.i-call.gr", > >>>response="0c4bcac79619588b61993a5ea407f520", algorithm=MD5. > >>>Max-Forwards: 70. > >>>User-Agent: Sipura/SPA3000-3.1.7(GWg). > >>>Content-Length: 0. > >>>. > >>> > >>># > >>>U 2006/02/07 12:05:37.859999 213.5.43.134:5060 -> > 213.5.xxx.xxx:5060 > >>>CANCEL sip:401#2116872933@213.5.xxx.xxx:5060 SIP/2.0. > >>>Record-Route: <sip:213.5.43.134;ftag=a75dbec37247ce75o0;lr=on>. > >>>Via: SIP/2.0/UDP 213.5.43.134;branch=z9hG4bK53cd.5e18cee6.0. > >>>Via: SIP/2.0/UDP 195.167.60.21:1375;branch=z9hG4bK-bf20b945. > >>>From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >>>To: <sip:2116872933@sip.i-call.gr>. > >>>Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >>>CSeq: 102 CANCEL. > >>>Proxy-Authorization: Digest username="tester", realm="i-call.gr", > >>>nonce="43e87215b69f85cf82f231965df4ad938a65d43f", > >>>uri="sip:2116872933@sip.i-call.gr", > >>>response="0c4bcac79619588b61993a5ea407f520", algorithm=MD5. > >>>Max-Forwards: 69. > >>>User-Agent: Sipura/SPA3000-3.1.7(GWg). > >>>Content-Length: 0. > >>>. > >>> > >>># > >>>U 2006/02/07 12:05:37.860901 213.5.xxx.xxx:5060 -> > 213.5.43.134:5060 > >>>SIP/2.0 481 Call Leg Does Not Exist. > >>>Via: SIP/2.0/UDP > >>>213.5.43.134;branch=z9hG4bK53cd.5e18cee6.0;received=213.5.43.134. > >>>Via: SIP/2.0/UDP 195.167.60.21:1375;branch=z9hG4bK-bf20b945. > >>>From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >>>To: <sip:2116872933@sip.i-call.gr>;tag=as3061dfb6. > >>>Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >>>CSeq: 102 CANCEL. > >>>User-Agent: i-Call Service. > >>>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. > >>>Max-Forwards: 70. > >>>Content-Length: 0. > >>>. > >>> > >>># > >>>U 2006/02/07 12:05:37.860998 213.5.43.134:5060 -> > 195.167.60.21:1375 > >>>SIP/2.0 481 Call Leg Does Not Exist. > >>>Via: SIP/2.0/UDP 195.167.60.21:1375;branch=z9hG4bK-bf20b945. > >>>From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >>>To: <sip:2116872933@sip.i-call.gr>;tag=as3061dfb6. > >>>Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >>>CSeq: 102 CANCEL. > >>>User-Agent: i-Call Service. > >>>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. > >>>Max-Forwards: 70. > >>>Content-Length: 0. > >>>. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] > >>>>Sent: Friday, February 03, 2006 10:43 PM > >>>>To: Papadopoulos Georgios > >>>>Cc: users(a)openser.org > >>>>Subject: Re: [Users] Receiving different VIA in INVITE and CANCEL > >>>> > >>>>Hi George, > >>>> > >>>>different VIA in INVITE and CANCEL brakes the specs of RFC > >>>> > >>>> > >>3261. The > >> > >> > >>>>"via1_matching" is a kind of a trick to make un-compliant > >>>> > >>>> > >>clients to > >> > >> > >>>>work. The trick is functional. I suspect that maybe not > >>>> > >>>> > >>only the VIA > >> > >> > >>>>is the problem. Can you please post the INVITE and CANCEL > to have a > >>>>look on them? > >>>> > >>>>regards, > >>>>bogdan > >>>> > >>>>Papadopoulos Georgios wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Hello, > >>>>> > >>>>>I have an issue with some user agents, (Linksys PAP2 and > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Sipura 3000) > >>>> > >>>> > >>>> > >>>> > >>>>>sending different Via in CANCEL than in INVITE. > >>>>>Of course the result is that the caller hangs up and the > >>>>> > >>>>> > >>>>> > >>>>> > >>>>callee keeps > >>>> > >>>> > >>>> > >>>> > >>>>>ringing. > >>>>>I tried to use > >>>>> modparam("tm", "via1_matching", 0) but it did not solve the > >>>>>problem. > >>>>> > >>>>>I have two questions: > >>>>>1. Is the via1_matching in TM working as described or is > it broken? > >>>>> > >>>>>2. What can be causing this behavior of the user agent? > >>>>> > >>>>> > >>Not all our > >> > >> > >>>>>users who have these user agents report this problem > >>>>> > >>>>> > >>>>> > >>>>> > >>>>(actually very few > >>>> > >>>> > >>>> > >>>> > >>>>>have the problem). In our lab we tried same user agent, same > >>>>> > >>>>> > >>>>> > >>>>> > >>>>firmware > >>>> > >>>> > >>>> > >>>> > >>>>>but could never reproduce this behavior no matter how bad we > >>>>> > >>>>> > >>>>> > >>>>> > >>>>tried to > >>>> > >>>> > >>>> > >>>> > >>>>>mess up their configuration. > >>>>> > >>>>>Any help will be greatly appreciated. Thanks. > >>>>> > >>>>>George > >>>>> > >>>>> > >>>>> > >>>>> > > > >Disclaimer > >The information in this e-mail and any attachments is > confidential. It is intended solely for the attention and use > of the named addressee(s). If you are not the intended > recipient, or person responsible for delivering this > information to the intended recipient, please notify the > sender immediately. Unless you are the intended recipient or > his/her representative you are not authorized to, and must > not, read, copy, distribute, use or retain this message or > any part of it. E-mail transmission cannot be guaranteed to > be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or > contain viruses. > > > > > > > > > > Disclaimer The information in this e-mail and any attachments is confidential. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.

18 years, 9 months

[Users] NEW FEATURE: NAPTR lookup

by Bogdan-Andrei Iancu

Hi, A new feature is available in openser, devel version : NAPTR lookup. Overview ========= OpenSER is now RFC3263 (Locating SIP Server) compliant. See http://www.ietf.org/rfc/rfc3263.txt NAPTR queries are used to discovered the transport protocols for SIP that are supported (and a preference order) by a SIP server. Combining the protocols that are supported by the remote server and the protocols that re locally implemented, the local server will choose the protocol to be used (if an explicit one is not provided). One the protocol is selected, SRV queries are used to discover the port to be used; after that A record query is made to get the IP address. This will make possible for a proxy to advertise its preferred protocols. Like : if supported, use TLS, otherwise try TCP and if not UDP. Establishing relationships/connections via TLS will be much simpler to configure and it would be dynamically done - if both proxies supports TLS they will use TLS, but this will not exclude UDP and TCP to be used as alternatives.... How it works ============ If NAPTR / SRV lookup is used depends if the proto and port are known. Here is a small diagram: if port specify then -> do just A record lookup and use defaults protos (UDP for SIP and TLS for SIPS) if not specified; done # no port if no proto then -> do NAPTR to get proto; if no results, use defaults protos (UDP for SIP and TLS for SIPS); continue # we have proto now do SRV to get port; if no results, use defaults ports (5060 for SIP and 5061 for SIPS); continue # we have proto and port do A record lookup to get IP The resolver will sequentially try all NAPTR and SRV results until it successfully gets an IP address. NAPTR / SRV records which cannot be completely followed (resolved) will be skipped. If the TLS / TCP support is compiled and enabled, the proxy will consider this protos to use; otherwise it will skip them. How to use ========== NAPTR will be used only if proto is not specify neither via the relaying function nor via the RURI. Ex: t_relay("openser.org"); # send to openser.org and use NAPTR and SRV to resolve the address t_relay(); # RURI=sip:user@domain.org forward(uri:host,uri:port); # RURI=sip:user@domain.org NOTE: these will not use NAPTR t_relay("tcp:openser.org"); t_relay(); # RURI=sip:user@domain.org;transport=udp NOTE: these will not use NAPTR/SRV t_relay("openser.org:5060"); t_relay(); # RURI=sip:user@domain.org:5060 Still under discussion ====================== According to the RFC, for a SIPS uri, the only protocol to be used is TLS. My question is : if SIPS is found force TLS as proto and do SRV lookup or perform NAPTR lookup and look for TLS entries. The difference may be: one extra query (from NAPTR) versus the fact that the NAPTR query may lead to a SRV into another domain. Ex: for sips:user@domainA If forcing TLS -> do SRV for "_sips._tcp.domainA." -> port server1.domainA:5061 If using first NAPTR -> do NAPTR on "domainA" and get "_sips._tcp.domainB." which will lead somewhere else than using directly SRV. According the RFC this is possible. What I'm not sure about is if this cross domain NAPTR records are allowed for TLS: see chapter 4.1 : For NAPTR records with SIPS protocol fields, (if the server is using a site certificate), the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior or the result of an attack. for the moment, NAPTR and SRV are used for SIPS....but any other opinions on this TLS matter are welcomed... regards, Bogdan PS: feedback is welcomed :D

18 years, 9 months

RE: [Users] Receiving different VIA in INVITE and CANCEL

by Papadopoulos Georgios

Hi Bogdan, I will try the force_rport(). Meanwhile I am confused by what you wrote. Can you please clarify? > The problem is the different port in via. The "via1_matching" > param has no effect on RFC3261 transaction matching algorithm > since this is entirely based on via :). thanks a lot George > -----Original Message----- > From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] > Sent: Wednesday, February 08, 2006 11:43 AM > To: Papadopoulos Georgios > Cc: users(a)openser.org > Subject: Re: [Users] Receiving different VIA in INVITE and CANCEL > > Hi Geroge, > > it looks like your device uses STUN to perform nat traversal > (the callid has a private IP). The improper nat traversal via > STUN is the reason for the different port in VIA; to fix > this, call "force_rport()" > in the beginning of your script for all requests. > > now, going back to the CANCEL matching....SIPURA uses the > RFC3261 transaction matching algorithm (based on some cookie > and ids stored in branch VIA param. These are matching in > your case, but openser uses as additional checkings the via > host, port and proto (just to be sure that the originator > matches too to avoid confusion with different senders > generating the same cookie/id). > The problem is the different port in via. The "via1_matching" > param has no effect on RFC3261 transaction matching algorithm > since this is entirely based on via :). > > my suggestion is to fix the nat traversal part. > > regards, > bogdan > > Papadopoulos Georgios wrote: > > >Hi Bogdan, > > > >Thank you for your reply. > > > >I used > >modparam("tm", "via1_matching", 0) > >modparam("tm", "ruri_matching", 0) > >and I got the following trace. You can see that the ACK to the Proxy > >Authentication Required and the CANCEL have different Via than the > >INVITE. I know that this breaks the specs but I thought that > these two > >modparams should take care of these broken UAs. > > > >Also, any ideas what makes the UA switch ports? Is it a NAT > issue? Only > >a very small percentage of the same UA behave this way. > > > >thank you for any help > > > >George > > > > > ># > >U 2006/02/07 12:05:29.756686 195.167.60.21:1231 -> 213.5.43.134:5060 > >INVITE sip:2116872933@sip.i-call.gr SIP/2.0. > >Via: SIP/2.0/UDP 195.167.60.21:1327;branch=z9hG4bK-cc55e25. > >From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >To: <sip:2116872933@sip.i-call.gr>. > >Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >CSeq: 101 INVITE. > >Contact: tester <sip:tester@195.167.60.21:1327>. > >Remote-Party-ID: tester > ><sip:tester@sip.i-call.gr>;screen=yes;party=calling. > >Max-Forwards: 70. > >Expires: 240. > >User-Agent: Sipura/SPA3000-3.1.7(GWg). > >Supported: x-sipura. > >Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. > >Content-Type: application/sdp. > >Content-Length: 423 . > >. > >v=0. > >o=- 33757 33757 IN IP4 195.167.60.21. > >s=-.. > >c=IN IP4 195.167.60.21. > >t=0 0. > >m=audio 10200 RTP/AVP 18 0 2 4 8 96 97 98 100 101. > >a=rtpmap:18 G729a/8000. > >a=rtpmap:0 PCMU/8000. > >a=rtpmap:2 G726-32/8000. > >a=rtpmap:4 G723/8000. > >a=rtpmap:8 PCMA/8000. > >a=rtpmap:96 G726-40/8000. > >a=rtpmap:97 G726-24/8000. > >a=rtpmap:98 G726-16/8000. > >a=rtpmap:100 NSE/8000. > >a=rtpmap:101 telephone-event/8000. > >a=fmtp:101 0-15. > >a=ptime:30. > >a=sendrecv. > > > ># > >U 2006/02/07 12:05:29.757360 213.5.43.134:5060 -> 195.167.60.21:1327 > >SIP/2.0 407 Proxy Authentication Required. > >Via: SIP/2.0/UDP 195.167.60.21:1327;branch=z9hG4bK-cc55e25. > >From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >To: > ><sip:2116872933@sip.i-call.gr>;tag=97e44c910458bd56beb40ca402 > 8d7cc8.0f0 > >e > >. > >Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >CSeq: 101 INVITE. > >Proxy-Authenticate: Digest realm="i-call.gr", > >nonce="43e87215b69f85cf82f231965df4ad938a65d43f". > >Server: OpenSer (1.0.0-tls (x86_64/linux)). > >Content-Length: 0. > >Warning: 392 213.5.43.134:5060 "Noisy feedback tells: pid=10474 > >req_src_ip=195.167.60.21 req_src_port=1231 > >in_uri=sip:2116872933@sip.i-call.gr > >out_uri=sip:2116872933@sip.i-call.gr > >via_cnt==1". > >. > > > ># > >U 2006/02/07 12:05:29.865886 195.167.60.21:1327 -> 213.5.43.134:5060 > >ACK sip:2116872933@sip.i-call.gr SIP/2.0. > >Via: SIP/2.0/UDP 195.167.60.21:1328;branch=z9hG4bK-cc55e25. > >From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >To: > ><sip:2116872933@sip.i-call.gr>;tag=97e44c910458bd56beb40ca402 > 8d7cc8.0f0 > >e > >. > >Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >CSeq: 101 ACK. > >Contact: tester <sip:tester@195.167.60.21:1328>. > >Max-Forwards: 70. > >User-Agent: Sipura/SPA3000-3.1.7(GWg). > >Content-Length: 0. > >. > >************************************************************* > ********** > >* > >************** > >*** The Via in the ACK is different than in the INVITE and Openser > >sends it > >*** to the wrong server > >************************************************************* > ********** > >* > >************** > ># > >U 2006/02/07 12:05:29.866660 213.5.43.134:5060 -> 213.5.xxx.xxx:5060 > >ACK sip:401#2116872933@213.5.xxx.xxx:5060 SIP/2.0. > >Record-Route: <sip:213.5.43.134;ftag=a75dbec37247ce75o0;lr=on>. > >Via: SIP/2.0/UDP 213.5.43.134;branch=0. > >Via: SIP/2.0/UDP 195.167.60.21:1328;branch=z9hG4bK-cc55e25. > >From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >To: > ><sip:2116872933@sip.i-call.gr>;tag=97e44c910458bd56beb40ca402 > 8d7cc8.0f0 > >e > >. > >Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >CSeq: 101 ACK. > >Contact: tester <sip:tester@195.167.60.21:1328>. > >Max-Forwards: 69. > >User-Agent: Sipura/SPA3000-3.1.7(GWg). > >Content-Length: 0. > >. > > > ># > >U 2006/02/07 12:05:29.959041 195.167.60.21:1327 -> 213.5.43.134:5060 > >INVITE sip:2116872933@sip.i-call.gr SIP/2.0. > >Via: SIP/2.0/UDP 195.167.60.21:1328;branch=z9hG4bK-bf20b945. > >From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >To: <sip:2116872933@sip.i-call.gr>. > >Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >CSeq: 102 INVITE. > >Contact: tester <sip:tester@195.167.60.21:1328>. > >Proxy-Authorization: Digest username="tester", realm="i-call.gr", > >nonce="43e87215b69f85cf82f231965df4ad938a65d43f", > >uri="sip:2116872933@sip.i-call.gr", > >response="da850791f85d3e882d384d96e4aff30e", algorithm=MD5. > >Remote-Party-ID: tester > ><sip:tester@sip.i-call.gr>;screen=yes;party=calling. > >Max-Forwards: 70. > >Expires: 240. > >User-Agent: Sipura/SPA3000-3.1.7(GWg). > >Supported: x-sipura. > >Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. > >Content-Type: application/sdp. > >Content-Length: 423 . > >. > >v=0. > >o=- 33757 33757 IN IP4 195.167.60.21. > >s=-.. > >c=IN IP4 195.167.60.21. > >t=0 0. > >m=audio 10200 RTP/AVP 18 0 2 4 8 96 97 98 100 101. > >a=rtpmap:18 G729a/8000. > >a=rtpmap:0 PCMU/8000. > >a=rtpmap:2 G726-32/8000. > >a=rtpmap:4 G723/8000. > >a=rtpmap:8 PCMA/8000. > >a=rtpmap:96 G726-40/8000. > >a=rtpmap:97 G726-24/8000. > >a=rtpmap:98 G726-16/8000. > >a=rtpmap:100 NSE/8000. > >a=rtpmap:101 telephone-event/8000. > >a=fmtp:101 0-15. > >a=ptime:30. > >a=sendrecv. > > > ># > >U 2006/02/07 12:05:29.960454 213.5.43.134:5060 -> 195.167.60.21:1328 > >SIP/2.0 100 trying -- your call is important to us. > >Via: SIP/2.0/UDP 195.167.60.21:1328;branch=z9hG4bK-bf20b945. > >From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >To: <sip:2116872933@sip.i-call.gr>. > >Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >CSeq: 102 INVITE. > >Server: OpenSer (1.0.0-tls (x86_64/linux)). > >Content-Length: 0. > >Warning: 392 213.5.43.134:5060 "Noisy feedback tells: pid=10473 > >req_src_ip=195.167.60.21 req_src_port=1327 > >in_uri=sip:2116872933@sip.i-call.gr > >out_uri=sip:400#2116872933@213.5.yyy.yyy:5060 via_cnt==1". > >. > > > >************************************************************* > ********** > >* > >*** Openser forwards the request to PSTN gateway > >************************************************************* > ********** > >* > > > ># > >U 2006/02/07 12:05:29.960516 213.5.43.134:5060 -> 213.5.yyy.yyy:5060 > >INVITE sip:400#2116872933@213.5.yyy.yyy:5060 SIP/2.0. > >Record-Route: <sip:213.5.43.134;ftag=a75dbec37247ce75o0;lr=on>. > >Via: SIP/2.0/UDP 213.5.43.134;branch=z9hG4bK53cd.4e18cee6.0. > >Via: SIP/2.0/UDP 195.167.60.21:1328;branch=z9hG4bK-bf20b945. > >From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >To: <sip:2116872933@sip.i-call.gr>. > >Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >CSeq: 102 INVITE. > >Contact: tester <sip:tester@195.167.60.21:1328>. > >Max-Forwards: 69. > >Expires: 240. > >User-Agent: Sipura/SPA3000-3.1.7(GWg). > >Supported: x-sipura. > >Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. > >Content-Type: application/sdp. > >Content-Length: 423 . > >. > >v=0. > >o=- 33757 33757 IN IP4 195.167.60.21. > >s=-.. > >c=IN IP4 195.167.60.21. > >t=0 0. > >m=audio 10200 RTP/AVP 18 0 2 4 8 96 97 98 100 101. > >a=rtpmap:18 G729a/8000. > >a=rtpmap:0 PCMU/8000. > >a=rtpmap:2 G726-32/8000. > >a=rtpmap:4 G723/8000. > >a=rtpmap:8 PCMA/8000. > >a=rtpmap:96 G726-40/8000. > >a=rtpmap:97 G726-24/8000. > >a=rtpmap:98 G726-16/8000. > >a=rtpmap:100 NSE/8000. > >a=rtpmap:101 telephone-event/8000. > >a=fmtp:101 0-15. > >a=ptime:30. > >a=sendrecv. > > > ># > >U 2006/02/07 12:05:29.975762 213.5.yyy.yyy:57918 -> > 213.5.43.134:5060 > >SIP/2.0 100 Trying. > >Via: SIP/2.0/UDP > 213.5.43.134;branch=z9hG4bK53cd.4e18cee6.0,SIP/2.0/UDP > >195.167.60.21:1328;branch=z9hG4bK-bf20b945. > >From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >To: <sip:2116872933@sip.i-call.gr>;tag=329C938C-7DF. > >Date: Tue, 07 Feb 2006 10:06:34 GMT. > >Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >Server: Cisco-SIPGateway/IOS-12.x. > >CSeq: 102 INVITE. > >Allow-Events: telephone-event. > >Content-Length: 0. > >. > > > > > ># > >U 2006/02/07 12:05:30.149177 213.5.yyy.yyy:57918 -> > 213.5.43.134:5060 > >SIP/2.0 183 Session Progress. > >Via: SIP/2.0/UDP > 213.5.43.134;branch=z9hG4bK53cd.4e18cee6.0,SIP/2.0/UDP > >195.167.60.21:1328;branch=z9hG4bK-bf20b945. > >From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >To: <sip:2116872933@sip.i-call.gr>;tag=329C938C-7DF. > >Date: Tue, 07 Feb 2006 10:06:34 GMT. > >Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >Server: Cisco-SIPGateway/IOS-12.x. > >CSeq: 102 INVITE. > >Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, > >SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER. > >Allow-Events: telephone-event. > >Contact: <sip:400#2116872933@213.5.yyy.yyy:5060>. > >Record-Route: <sip:213.5.43.134;ftag=a75dbec37247ce75o0;lr=on>. > >Content-Disposition: session;handling=required. > >Content-Type: application/sdp. > >Content-Length: 288. > >. > >v=0. > >o=CiscoSystemsSIP-GW-UserAgent 9560 6985 IN IP4 213.5.yyy.yyy. > >s=SIP Call. > >c=IN IP4 213.5.yyy.yyy. > >t=0 0. > >m=audio 17868 RTP/AVP 18 101. > >c=IN IP4 213.5.yyy.yyy. > >a=rtpmap:18 G729/8000. > >a=fmtp:18 annexb=no. > >a=rtpmap:101 telephone-event/8000. > >a=fmtp:101 0-15. > >a=ptime:20. > >a=silenceSupp:off - - - -. > > > ># > >U 2006/02/07 12:05:30.149263 213.5.43.134:5060 -> 195.167.60.21:1328 > >SIP/2.0 183 Session Progress. > >Via: SIP/2.0/UDP 195.167.60.21:1328;branch=z9hG4bK-bf20b945. > >From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >To: <sip:2116872933@sip.i-call.gr>;tag=329C938C-7DF. > >Date: Tue, 07 Feb 2006 10:06:34 GMT. > >Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >Server: Cisco-SIPGateway/IOS-12.x. > >CSeq: 102 INVITE. > >Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, > >SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER. > >Allow-Events: telephone-event. > >Contact: <sip:400#2116872933@213.5.yyy.yyy:5060>. > >Record-Route: <sip:213.5.43.134;ftag=a75dbec37247ce75o0;lr=on>. > >Content-Disposition: session;handling=required. > >Content-Type: application/sdp. > >Content-Length: 288. > >. > >v=0. > >o=CiscoSystemsSIP-GW-UserAgent 9560 6985 IN IP4 213.5.yyy.yyy. > >s=SIP Call. > >c=IN IP4 213.5.yyy.yyy. > >t=0 0. > >m=audio 17868 RTP/AVP 18 101. > >c=IN IP4 213.5.yyy.yyy. > >a=rtpmap:18 G729/8000. > >a=fmtp:18 annexb=no. > >a=rtpmap:101 telephone-event/8000. > >a=fmtp:101 0-15. > >a=ptime:20. > >a=silenceSupp:off - - - -. > > > >************************************************************* > ********** > >* > >**** > >*** User Agents sends CANCEL with different Via than in INVITE > >*** and Openser send it to the wrong server > >************************************************************* > ********** > >* > >**** > > > ># > >U 2006/02/07 12:05:37.859125 195.167.60.21:1328 -> 213.5.43.134:5060 > >CANCEL sip:2116872933@sip.i-call.gr SIP/2.0. > >Via: SIP/2.0/UDP 195.167.60.21:1375;branch=z9hG4bK-bf20b945. > >From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >To: <sip:2116872933@sip.i-call.gr>. > >Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >CSeq: 102 CANCEL. > >Proxy-Authorization: Digest username="tester", realm="i-call.gr", > >nonce="43e87215b69f85cf82f231965df4ad938a65d43f", > >uri="sip:2116872933@sip.i-call.gr", > >response="0c4bcac79619588b61993a5ea407f520", algorithm=MD5. > >Max-Forwards: 70. > >User-Agent: Sipura/SPA3000-3.1.7(GWg). > >Content-Length: 0. > >. > > > ># > >U 2006/02/07 12:05:37.859999 213.5.43.134:5060 -> 213.5.xxx.xxx:5060 > >CANCEL sip:401#2116872933@213.5.xxx.xxx:5060 SIP/2.0. > >Record-Route: <sip:213.5.43.134;ftag=a75dbec37247ce75o0;lr=on>. > >Via: SIP/2.0/UDP 213.5.43.134;branch=z9hG4bK53cd.5e18cee6.0. > >Via: SIP/2.0/UDP 195.167.60.21:1375;branch=z9hG4bK-bf20b945. > >From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >To: <sip:2116872933@sip.i-call.gr>. > >Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >CSeq: 102 CANCEL. > >Proxy-Authorization: Digest username="tester", realm="i-call.gr", > >nonce="43e87215b69f85cf82f231965df4ad938a65d43f", > >uri="sip:2116872933@sip.i-call.gr", > >response="0c4bcac79619588b61993a5ea407f520", algorithm=MD5. > >Max-Forwards: 69. > >User-Agent: Sipura/SPA3000-3.1.7(GWg). > >Content-Length: 0. > >. > > > ># > >U 2006/02/07 12:05:37.860901 213.5.xxx.xxx:5060 -> 213.5.43.134:5060 > >SIP/2.0 481 Call Leg Does Not Exist. > >Via: SIP/2.0/UDP > >213.5.43.134;branch=z9hG4bK53cd.5e18cee6.0;received=213.5.43.134. > >Via: SIP/2.0/UDP 195.167.60.21:1375;branch=z9hG4bK-bf20b945. > >From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >To: <sip:2116872933@sip.i-call.gr>;tag=as3061dfb6. > >Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >CSeq: 102 CANCEL. > >User-Agent: i-Call Service. > >Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. > >Max-Forwards: 70. > >Content-Length: 0. > >. > > > ># > >U 2006/02/07 12:05:37.860998 213.5.43.134:5060 -> 195.167.60.21:1375 > >SIP/2.0 481 Call Leg Does Not Exist. > >Via: SIP/2.0/UDP 195.167.60.21:1375;branch=z9hG4bK-bf20b945. > >From: tester <sip:tester@sip.i-call.gr>;tag=a75dbec37247ce75o0. > >To: <sip:2116872933@sip.i-call.gr>;tag=as3061dfb6. > >Call-ID: 6d30a75b-c6343ebd(a)172.22.3.25. > >CSeq: 102 CANCEL. > >User-Agent: i-Call Service. > >Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. > >Max-Forwards: 70. > >Content-Length: 0. > >. > > > > > > > > > > > > > > > >>-----Original Message----- > >>From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] > >>Sent: Friday, February 03, 2006 10:43 PM > >>To: Papadopoulos Georgios > >>Cc: users(a)openser.org > >>Subject: Re: [Users] Receiving different VIA in INVITE and CANCEL > >> > >>Hi George, > >> > >>different VIA in INVITE and CANCEL brakes the specs of RFC > 3261. The > >>"via1_matching" is a kind of a trick to make un-compliant > clients to > >>work. The trick is functional. I suspect that maybe not > only the VIA > >>is the problem. Can you please post the INVITE and CANCEL to have a > >>look on them? > >> > >>regards, > >>bogdan > >> > >>Papadopoulos Georgios wrote: > >> > >> > >> > >>>Hello, > >>> > >>>I have an issue with some user agents, (Linksys PAP2 and > >>> > >>> > >>Sipura 3000) > >> > >> > >>>sending different Via in CANCEL than in INVITE. > >>>Of course the result is that the caller hangs up and the > >>> > >>> > >>callee keeps > >> > >> > >>>ringing. > >>>I tried to use > >>> modparam("tm", "via1_matching", 0) > >>>but it did not solve the problem. > >>> > >>>I have two questions: > >>>1. Is the via1_matching in TM working as described or is it broken? > >>> > >>>2. What can be causing this behavior of the user agent? > Not all our > >>>users who have these user agents report this problem > >>> > >>> > >>(actually very few > >> > >> > >>>have the problem). In our lab we tried same user agent, same > >>> > >>> > >>firmware > >> > >> > >>>but could never reproduce this behavior no matter how bad we > >>> > >>> > >>tried to > >> > >> > >>>mess up their configuration. > >>> > >>>Any help will be greatly appreciated. Thanks. > >>> > >>>George > >>> > >>> > Disclaimer The information in this e-mail and any attachments is confidential. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.

18 years, 9 months

[Users] Dispatcher module: another question.

by Antoine Fressancourt

Hello, I followed with great interest the discussion about the use of the Dispatcher module that occured in the last few days. Yet, I have another question. For design issues, I wish to balance the incoming SIP messages according to the method they hold : for instance, I want to treat the REGISTER, SUBSCRBE and NOTIFY messages on some machines, and the INVITE, BYE, CANCEL on another set of machines. I know this may seem strange first, but I wonder if any mecanism allow to do that. Thank you in advance for your answers. Antoine Fressancourt

18 years, 9 months

[Users] avpops, duplicate key, empty username and domain

by JF

Hi, I'm trying to use avpops module, but I'm facing the following error: 0(8178) PG[367] submit_query query 'insert into usr_preferences (uuid,attribute,value,type,username,domain ) values ('test','avpname','test',0,'','')', result 'ERROR: duplicate key violates unique constraint "usr_preferences_pkey" It seems to be caused by the username and domain parameters being empty strings, since the usr_preferences table has this PK constraint: "usr_preferences_pkey" primary key, btree (attribute, username, "domain") The avpops module is configured like this: modparam("avpops", "avp_url", "postgres://xpto:xpto@127.0.0.1/xpto") modparam("avpops", "avp_table", "usr_preferences") modparam("avpops","use_domain",1) modparam("avpops", "avp_aliases", "avpalias=s:avpname") And I'm simply doing: avp_printf("s:avpname", "test"); avp_db_store("$avpalias/uuid", "s:avpname"); What may be missing? Maybe the usr_preferences table should not have this PK when using UUID-based AVP identification... JF

18 years, 9 months

[Serusers] limit the cps-rate

by Thomas Balsfulland

hello list, i am searching for a way to limit the cps-rate with ser. our class-iv (cisco pgw) behind der ser has problems with too many sip-calls per second and will going to crash. is there any way to limit the cps to a rate i can define? there are no hints in the ser documentation i know. thanks for helping. regards thomas -- thomas balsfulland tbals(a)ctrl-c.de

18 years, 9 months

[Serusers] how to download the tls module

by Yi Zheng

Hi, How to download/checkout the experimental tls module? I plan to use it with the latest presence server snapshot (ser-0.10.99-dev30-tm-timers-pa-3]). Thanks, - ming

18 years, 9 months

[Users] how to add custom certificates to windows messenger 5.1

by Pjothi

Hello openser users, I am trying to connect windows messenger 5.1 with openser in TLS mode. OpenSER uses the custom created certificate and predictably windows msngr returns -------------- There was a problem in verfiying the certificate from the server. Please contact your network administrator. -------------- I do have my own client certificate and ca-list created with openser scripts and I would like to add it to windows messenger to verify the server certificate. Is it possible to add a ca-list to windows messenger so that it can verify the server certificate. If yes, kindly point me how ? thanks and regards, Pjothi

18 years, 9 months

[Users] acc module db_extra accounting issue

by Marcello Lupo

Hi, i have a db_extra accounting rule like: modparam("acc", "db_extra", "customer_code=$avp(i:102)") The avp value is 12 and i checked it with avp_print() . DEBUG:avpops:print_avp: p=0x2a97a866e8, flags=0 DEBUG: id=<102> DEBUG: val_int=<12> When it is accounted in the table the value become 11 !!!!! the field in the table is type int(10) . How is it possible?? Thanks, Bye, MArcello

18 years, 9 months

[Users] Clarity on the DISPATCHER module

by Anders Brownworth

Hi, I am trying to get an OpenSER instance running with the dispatcher module spreading load amongst several other OpenSER servers. I'm having trouble understanding from the docs and practical application exactly what the dispatcher module does and how to make it do what I want. I want to accept requests and use the dispatcher module to send requests to one of a number of other servers. (I want this setup to scale so I don't want to use the tm module.) Each subsequent request with the same CallId should go back to the same server. Therefore using the hash over the CallId algorithm in the dispatcher module seems like the best choice. I'm running OpenSER 1.0.0 and working off of the configuration in the modules documentation: http://openser.org/docs/modules/1.0.x/dispatcher.html I fixed up a few things that didn't seem to work out of the box such as replacing forward( ) with forward( uri:host, uri:port ). I have several questions. 1. What exactly does ds_select_dst("1", "0") do? I understand the parameters but the module documentation says it "selects a destination from addresses set". OK, so does it return it somehow? How do I get my hands on what it picks? What is an example of a situation where this function would be useful? 2. What exactly ds_select_domain("1", "0") do? I gather it rewrites the host and port with what it gets from the addresses set (which seems more useful than ds_select_dst), but when I run this in practice, _if_ it rewrites the host / port, it always seems to pick the same destination. (in my tests I only get an outgoing INVITE about 10% of the time) It does seem like I want to be using ds_select_domain() though. Can someone point out where my misunderstanding is? I have my configuration copied below. Thanks. -Anders --------------------------------------------------------------------------------------- What I'm expecting: When the first INVITE comes from 10.1.50.30 (Asterisk) to 10.1.50.31, (OpenSER with dispatcher) I want to see an outgoing INVITE from 10.1.50.31 to one of the listed addresses. (10.1.50.[34-37]) What I'm seeing: A tcpdump shows that most of the time all I see is the incoming INVITE. Seemingly random INVITES produce an outgoing INVITE, even when calling the same number. Presumably the only substantive difference is the CallID. openser.cfg: ----------------------------------------------------------------------------- #debug=4 fork=yes log_stderror=no children=4 check_via=no dns=off rev_dns=off port=5060 mpath="/usr/local/lib/openser/modules" loadmodule "maxfwd.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "dispatcher.so" modparam( "dispatcher", "list_file", "/usr/local/etc/openser/dispatcher.list" ) route { if ( ! mf_process_maxfwd_header( "10" ) ) { sl_send_reply( "483", "To Many Hops" ); drop( ); }; ds_select_domain( "1", "0" ); forward( uri:host, uri:port ); } ----------------------------------------------------------------------- dispatcher.list: ----------------------------------------------------------------------- # gateways 1 sip:10.1.50.34:5060 1 sip:10.1.50.35:5060 1 sip:10.1.50.36:5060 1 sip:10.1.50.37:5060 ----------------------------------------------------------------------- tcpdump shows: ----------------------------------------------------------------------- 07:43:37.216888 IP 10.1.50.30.5060 > 10.1.50.31.5060: UDP, length: 685 .@.@... .2. .2.........INVITE sip:+18666775910@10.1.50.31 SIP/2.0 Via: SIP/2.0/UDP 10.1.50.30:5060;branch=z9hG4bK434da07b From: "+19195551212" <sip:+19195551212@10.1.50.30>;tag=as3a379ead To: <sip:+18666775910@10.1.50.31> Contact: <sip:+19195551212@10.1.50.30> Call-ID: 7dd7978262a876832fc69a4364f89f22(a)10.1.50.30 CSeq: 102 INVITE User-Agent: BandwidthVoice Date: Fri, 03 Feb 2006 12:41:35 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Content-Type: application/sdp Content-Length: 202 v=0 o=root 11014 11014 IN IP4 10.1.50.30 s=session c=IN IP4 10.1.50.30 t=0 0 m=audio 8360 RTP/AVP 0 3 8 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:8 PCMA/8000 a=silenceSupp:off - - - - ----------------------------------------------------------------------- with no outgoing INVITE. Things seem to be dead. Then I try the same call a few seconds later and I get the outgoing INVITE: ----------------------------------------------------------------------- 07:43:48.695958 IP 10.1.50.30.5060 > 10.1.50.31.5060: UDP, length: 686 .@.@... .2. .2.........INVITE sip:+18666775910@10.1.50.31 SIP/2.0 Via: SIP/2.0/UDP 10.1.50.30:5060;branch=z9hG4bK15490a4e From: "+19195551212" <sip:+19195551212@10.1.50.30>;tag=as302ac772 To: <sip:+18666775910@10.1.50.31> Contact: <sip:+19195551212@10.1.50.30> Call-ID: 531db3695f15035620baae890d555216(a)10.1.50.30 CSeq: 102 INVITE User-Agent: BandwidthVoice Date: Fri, 03 Feb 2006 12:41:46 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Content-Type: application/sdp Content-Length: 203 v=0 o=root 11015 11015 IN IP4 10.1.50.30 s=session c=IN IP4 10.1.50.30 t=0 0 m=audio 28484 RTP/AVP 0 3 8 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:8 PCMA/8000 a=silenceSupp:off - - - - 07:43:48.696191 IP 10.1.50.31.5060 > 10.1.50.36.5060: UDP, length: 747 E....*@.@..g .2. .2$......S.INVITE sip:+18666775910@10.1.50.36:5060 SIP/2.0 Max-Forwards: 10 Via: SIP/2.0/UDP 10.1.50.31;branch=0 Via: SIP/2.0/UDP 10.1.50.30:5060;branch=z9hG4bK15490a4e From: "+19195551212" <sip:+19195551212@10.1.50.30>;tag=as302ac772 To: <sip:+18666775910@10.1.50.31> Contact: <sip:+19195551212@10.1.50.30> Call-ID: 531db3695f15035620baae890d555216(a)10.1.50.30 CSeq: 102 INVITE User-Agent: BandwidthVoice Date: Fri, 03 Feb 2006 12:41:46 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Content-Type: application/sdp Content-Length: 203 v=0 o=root 11015 11015 IN IP4 10.1.50.30 s=session c=IN IP4 10.1.50.30 t=0 0 m=audio 28484 RTP/AVP 0 3 8 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:8 PCMA/8000 a=silenceSupp:off - - - - ----------------------------------------------------------------------- any help greatly appreciated.

18 years, 9 months

← Newer
1
...
24
25
26
27
28
29
30
...
38
Older →

Jump to page:

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 February 2006