[Users] Receiving different VIA in INVITE and CANCEL

Bogdan-Andrei Iancu bogdan at voice-system.ro
Wed Feb 8 10:42:53 CET 2006


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 at sip.i-call.gr SIP/2.0.
>Via: SIP/2.0/UDP 195.167.60.21:1327;branch=z9hG4bK-cc55e25.
>From: tester <sip:tester at sip.i-call.gr>;tag=a75dbec37247ce75o0.
>To: <sip:2116872933 at sip.i-call.gr>.
>Call-ID: 6d30a75b-c6343ebd at 172.22.3.25.
>CSeq: 101 INVITE.
>Contact: tester <sip:tester at 195.167.60.21:1327>.
>Remote-Party-ID: tester
><sip:tester at 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 at sip.i-call.gr>;tag=a75dbec37247ce75o0.
>To:
><sip:2116872933 at sip.i-call.gr>;tag=97e44c910458bd56beb40ca4028d7cc8.0f0e
>.
>Call-ID: 6d30a75b-c6343ebd at 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 at sip.i-call.gr out_uri=sip:2116872933 at 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 at sip.i-call.gr SIP/2.0.
>Via: SIP/2.0/UDP 195.167.60.21:1328;branch=z9hG4bK-cc55e25.
>From: tester <sip:tester at sip.i-call.gr>;tag=a75dbec37247ce75o0.
>To:
><sip:2116872933 at sip.i-call.gr>;tag=97e44c910458bd56beb40ca4028d7cc8.0f0e
>.
>Call-ID: 6d30a75b-c6343ebd at 172.22.3.25.
>CSeq: 101 ACK.
>Contact: tester <sip:tester at 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 at 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 at sip.i-call.gr>;tag=a75dbec37247ce75o0.
>To:
><sip:2116872933 at sip.i-call.gr>;tag=97e44c910458bd56beb40ca4028d7cc8.0f0e
>.
>Call-ID: 6d30a75b-c6343ebd at 172.22.3.25.
>CSeq: 101 ACK.
>Contact: tester <sip:tester at 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 at sip.i-call.gr SIP/2.0.
>Via: SIP/2.0/UDP 195.167.60.21:1328;branch=z9hG4bK-bf20b945.
>From: tester <sip:tester at sip.i-call.gr>;tag=a75dbec37247ce75o0.
>To: <sip:2116872933 at sip.i-call.gr>.
>Call-ID: 6d30a75b-c6343ebd at 172.22.3.25.
>CSeq: 102 INVITE.
>Contact: tester <sip:tester at 195.167.60.21:1328>.
>Proxy-Authorization: Digest username="tester", realm="i-call.gr",
>nonce="43e87215b69f85cf82f231965df4ad938a65d43f",
>uri="sip:2116872933 at sip.i-call.gr",
>response="da850791f85d3e882d384d96e4aff30e", algorithm=MD5.
>Remote-Party-ID: tester
><sip:tester at 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 at sip.i-call.gr>;tag=a75dbec37247ce75o0.
>To: <sip:2116872933 at sip.i-call.gr>.
>Call-ID: 6d30a75b-c6343ebd at 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 at sip.i-call.gr
>out_uri=sip:400#2116872933 at 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 at 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 at sip.i-call.gr>;tag=a75dbec37247ce75o0.
>To: <sip:2116872933 at sip.i-call.gr>.
>Call-ID: 6d30a75b-c6343ebd at 172.22.3.25.
>CSeq: 102 INVITE.
>Contact: tester <sip:tester at 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 at sip.i-call.gr>;tag=a75dbec37247ce75o0.
>To: <sip:2116872933 at sip.i-call.gr>;tag=329C938C-7DF.
>Date: Tue, 07 Feb 2006 10:06:34 GMT.
>Call-ID: 6d30a75b-c6343ebd at 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 at sip.i-call.gr>;tag=a75dbec37247ce75o0.
>To: <sip:2116872933 at sip.i-call.gr>;tag=329C938C-7DF.
>Date: Tue, 07 Feb 2006 10:06:34 GMT.
>Call-ID: 6d30a75b-c6343ebd at 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 at 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 at sip.i-call.gr>;tag=a75dbec37247ce75o0.
>To: <sip:2116872933 at sip.i-call.gr>;tag=329C938C-7DF.
>Date: Tue, 07 Feb 2006 10:06:34 GMT.
>Call-ID: 6d30a75b-c6343ebd at 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 at 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 at sip.i-call.gr SIP/2.0.
>Via: SIP/2.0/UDP 195.167.60.21:1375;branch=z9hG4bK-bf20b945.
>From: tester <sip:tester at sip.i-call.gr>;tag=a75dbec37247ce75o0.
>To: <sip:2116872933 at sip.i-call.gr>.
>Call-ID: 6d30a75b-c6343ebd at 172.22.3.25.
>CSeq: 102 CANCEL.
>Proxy-Authorization: Digest username="tester", realm="i-call.gr",
>nonce="43e87215b69f85cf82f231965df4ad938a65d43f",
>uri="sip:2116872933 at 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 at 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 at sip.i-call.gr>;tag=a75dbec37247ce75o0.
>To: <sip:2116872933 at sip.i-call.gr>.
>Call-ID: 6d30a75b-c6343ebd at 172.22.3.25.
>CSeq: 102 CANCEL.
>Proxy-Authorization: Digest username="tester", realm="i-call.gr",
>nonce="43e87215b69f85cf82f231965df4ad938a65d43f",
>uri="sip:2116872933 at 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 at sip.i-call.gr>;tag=a75dbec37247ce75o0.
>To: <sip:2116872933 at sip.i-call.gr>;tag=as3061dfb6.
>Call-ID: 6d30a75b-c6343ebd at 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 at sip.i-call.gr>;tag=a75dbec37247ce75o0.
>To: <sip:2116872933 at sip.i-call.gr>;tag=as3061dfb6.
>Call-ID: 6d30a75b-c6343ebd at 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 at voice-system.ro] 
>>Sent: Friday, February 03, 2006 10:43 PM
>>To: Papadopoulos Georgios
>>Cc: users at 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
>>>      
>>>




More information about the Users mailing list