8 Feb
2006
8 Feb
'06
2:38 p.m.
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.
8 Feb
8 Feb
4:04 p.m.
New subject: [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:
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.
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
>>>
>>>
>>>
>>>
6866
days inactive
6866
days old
1 comments
2 participants
participants (2)
-
Bogdan-Andrei Iancu -
Papadopoulos Georgios