Hello,
Thanks for the analysis. Meaning that Cisco does not act properly if there is a port != 5060 set as communication port. Damn.
Regards, Martin
-----Original Message----- From: Marian Dumitru [mailto:marian.dumitru@voice-sistem.ro] Sent: Wednesday, November 17, 2004 6:48 PM To: Martin Koenig Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Cisco 7960 and 407 Proxy Auth Required
Hi Martin,
The problem is that you have different VIAs in INVITE and ACK
- the port
is different. SL module (used by auth) use the ip:port from VIA for ACK to INVITE matching.
Best regards, Marian
Martin Koenig wrote:
Hello,
we have (again) problems with a Cisco 7960 SIP phone.
# U 2004/11/17 13:18:55.664760 1.2.3.4:50520 -> 11.22.33.44:5060 INVITE sip:07216636445@testbed.de SIP/2.0. Via: SIP/2.0/UDP 1.2.3.4:5065;branch=z9hG4bK218ce466. From: "Koenig" sip:koenig@testbed.de;tag=0006283e0a68009a4d72450f-0d8cfd54. To: sip:07216636445@testbed.de. Call-ID: 0006283e-0a680093-034392eb-37bfeedf@1.2.3.4. CSeq: 101 INVITE. User-Agent: CSCO/7. Contact: sip:koenig@1.2.3.4:5065. Expires: 180. Content-Type: application/sdp. Content-Length: 246. Accept: application/sdp. Remote-Party-ID: "Koenig"
sip:koenig@1.2.3.4;party=calling;id-type=subscriber;privacy= off;screen=no.
. (sdp stripped)
# U 2004/11/17 13:18:55.665068 11.22.33.44:5060 -> 1.2.3.4:5065 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 1.2.3.4:5065;branch=z9hG4bK218ce466. From: "Koenig" sip:koenig@testbed.de;tag=0006283e0a68009a4d72450f-0d8cfd54. To:
sip:07216636445@testbed.de;tag=16ac3fc2258766c821c391b58b08d b64.371f.
Call-ID: 0006283e-0a680093-034392eb-37bfeedf@1.2.3.4. CSeq: 101 INVITE. Proxy-Authenticate: Digest realm="testbed.de", nonce="419b42db55c1a65dac6b825b8c2f8bfa62539beb", qop="auth". Server: Sip EXpress router (0.8.14-2 (i386/linux)). Content-Length: 0. Warning: 392 11.22.33.44:5060 "Noisy feedback tells: pid=2660 req_src_ip=1.2.3.4 req_src_port=50520
in_uri=sip:07216636445@testbed.de
out_uri=sip:07216636445@testbed.de via_cnt==1". .
# U 2004/11/17 13:18:55.764578 1.2.3.4:51368 -> 11.22.33.44:5060 ACK sip:07216636445@testbed.de SIP/2.0. Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK218ce466. From: "Koenig" sip:koenig@testbed.de;tag=0006283e0a68009a4d72450f-0d8cfd54. To:
sip:07216636445@testbed.de;tag=16ac3fc2258766c821c391b58b08d b64.371f.
Call-ID: 0006283e-0a680093-034392eb-37bfeedf@1.2.3.4. CSeq: 101 ACK. Content-Length: 0. .
# U 2004/11/17 13:18:55.764915 11.22.33.44:5060 -> 11.22.33.55:5060 ACK sip:+497216636445@213.218.10.130:5060 SIP/2.0. Max-Forwards: 10. Via: SIP/2.0/UDP 11.22.33.44;branch=0. Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK218ce466. From: "Koenig" sip:koenig@testbed.de;tag=0006283e0a68009a4d72450f-0d8cfd54. To:
sip:07216636445@testbed.de;tag=16ac3fc2258766c821c391b58b08d b64.371f.
Call-ID: 0006283e-0a680093-034392eb-37bfeedf@1.2.3.4. CSeq: 101 ACK. Content-Length: 0. .
As you can see, the ACK for the 407 gets forwarded by SER.
It does not match
the previous transaction. This should not be the case. Is
there anything we
can do about this, except flying to munich and beat on cisco?
Best regards, Martin
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Voice Sistem http://www.voice-sistem.ro