Hi All.
Below is a snippet of an INVITE and you can see the usual "trying - your call is important to us" in the dialog. Anyhow, for some reason SER occasionally attempts to sent the ACK to itself, which causes a looping condition. The last ACK shown is the start of the looping condition.
It only happens on occasion. SER should have consumed the ACK rather than attempted to forward it.
Can anyone explain this?
Regards, Paul
IP Legend ------------------- 10.3.0.221 http://10.3.0.221 - SER (behind a Cisco 3600 so ALG rewrote the IPs) 69.36.46.178 http://69.36.46.178 - NATed SIP UA
U 2005/04/15 02:19:16.252614 69.35.46.178:5060 http://69.35.46.178:5060 -> 10.3.0.221:5060 http://10.3.0.221:5060 INVITE sip:8187768080@sipdev.mycompany.net SIP/2.0. Via: SIP/2.0/UDP 192.168.1.102:5060 http://192.168.1.102:5060 ;branch=z9hG4bK3915905414. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net. Call-ID: 2671219156@192.168.1.102. CSeq: 101 INVITE. Contact: sip:3215591439@192.168.1.102:5060. Proxy-Authorization: Digest username="3215591439", realm=" sipdev.mycompany.net http://sipdev.mycompany.net", nonce="425f5e0de25efdb3f5a6125dcf2147bf30fe9177", uri=" sip:8187768080@sipdev.mycompany.net", response="61996c3bdc10990fec7e245751777516", algorithm=MD5, cnonce="ae02e47a3355bada49ce344c92f48587", qop=auth, nc=00000002. max-forwards: 70. Allow: INVITE, ACK, CANCEL, BYE, REFER, NOTIFY. Content-Type: application/sdp. Content-Length: 180. . v=0. o=- 32014 3005 IN IP4 192.168.1.102 http://192.168.1.102. s=-. c=IN IP4 192.168.1.102 http://192.168.1.102. t=0 0. m=audio 13456 RTP/AVP 18 0 8 2 4 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. .
# U 2005/04/15 02:19:16.276216 10.3.0.221:5060 http://10.3.0.221:5060 -> 69.35.46.178:5060 http://69.35.46.178:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 192.168.1.102:5060 http://192.168.1.102:5060 ;branch=z9hG4bK3915905414;rport=5060;received=69.35.46.178http://69.35.46.178 . From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.myvox.net. Call-ID: 2671219156@192.168.1.102. CSeq: 101 INVITE. Content-Length: 0. .
# U 2005/04/15 02:19:16.792795 69.35.46.178:5060 http://69.35.46.178:5060 -> 10.3.0.221:5060 http://10.3.0.221:5060 ACK sip:8187768080@sipdev.mycompany.net SIP/2.0. Via: SIP/2.0/UDP 192.168.1.102:5060 http://192.168.1.102:5060 ;branch=z9hG4bK3499714875. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net;tag= cdbfe46960d7566fcbe09f199f2b328d.c2bb. Call-ID: 2671219156@192.168.1.102. CSeq: 100 ACK. Content-Length: 0. .
# U 2005/04/15 02:19:16.912146 10.3.0.221:5060 http://10.3.0.221:5060 -> 10.3.0.221:5060 http://10.3.0.221:5060 ACK sip:8187768080@sipdev.mycompany.net SIP/2.0. Max-Forwards: 10. Record-Route: <sip:10.3.0.221 http://10.3.0.221;ftag=1465261089;lr>. Via: SIP/2.0/UDP 10.3.0.221 http://10.3.0.221;branch=0. Via: SIP/2.0/UDP 192.168.1.102:5060 http://192.168.1.102:5060;received= 69.35.46.178 http://69.35.46.178;branch=z9hG4bK3499714875. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net;tag= cdbfe46960d7566fcbe09f199f2b328d.c2bb. Call-ID: 2671219156@192.168.1.102. CSeq: 100 ACK. Content-Length: 0. P-hint: Local Destination.
Paul,
It looks like UA ACK 100 Trying. First of all I don't believe this is needed. Second of all, it changes CSEQ from 101 INVITE to 100. I think that's not valid at all. HTH
Alex
_____
From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Friday, April 15, 2005 10:46 AM To: serusers@lists.iptel.org Subject: [Serusers] Another Looping Question
Hi All.
Below is a snippet of an INVITE and you can see the usual "trying - your call is important to us" in the dialog. Anyhow, for some reason SER occasionally attempts to sent the ACK to itself, which causes a looping condition. The last ACK shown is the start of the looping condition.
It only happens on occasion. SER should have consumed the ACK rather than attempted to forward it.
Can anyone explain this?
Regards, Paul
IP Legend ------------------- 10.3.0.221 - SER (behind a Cisco 3600 so ALG rewrote the IPs) 69.36.46.178 - NATed SIP UA
U 2005/04/15 02:19:16.252614 69.35.46.178:5060 -> 10.3.0.221:5060 INVITE sip:8187768080@sipdev.mycompany.net SIP/2.0. Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK3915905414. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net. Call-ID: 2671219156@192.168.1.102. CSeq: 101 INVITE. Contact: sip:3215591439@192.168.1.102:5060. Proxy-Authorization: Digest username="3215591439", realm="sipdev.mycompany.net", nonce="425f5e0de25efdb3f5a6125dcf2147bf30fe9177", uri="sip:8187768080@sipdev.mycompany.net", response="61996c3bdc10990fec7e245751777516", algorithm=MD5, cnonce="ae02e47a3355bada49ce344c92f48587", qop=auth, nc=00000002. max-forwards: 70. Allow: INVITE, ACK, CANCEL, BYE, REFER, NOTIFY. Content-Type: application/sdp. Content-Length: 180. . v=0. o=- 32014 3005 IN IP4 192.168.1.102. s=-. c=IN IP4 192.168.1.102. t=0 0. m=audio 13456 RTP/AVP 18 0 8 2 4 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. .
# U 2005/04/15 02:19:16.276216 10.3.0.221:5060 -> 69.35.46.178:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK3915905414;rport=5060;received=69.35.46.178 . From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.myvox.net. Call-ID: 2671219156@192.168.1.102. CSeq: 101 INVITE. Content-Length: 0. .
# U 2005/04/15 02:19:16.792795 69.35.46.178:5060 -> 10.3.0.221:5060 ACK sip:8187768080@sipdev.mycompany.net SIP/2.0. Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK3499714875. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net;tag=cdbfe46960d7566fcbe09f199f2b328d.c 2bb. Call-ID: 2671219156@192.168.1.102. CSeq: 100 ACK. Content-Length: 0. .
# U 2005/04/15 02:19:16.912146 10.3.0.221:5060 -> 10.3.0.221:5060 ACK sip:8187768080@sipdev.mycompany.net SIP/2.0. Max-Forwards: 10. Record-Route: sip:10.3.0.221;ftag=1465261089;lr. Via: SIP/2.0/UDP 10.3.0.221;branch=0. Via: SIP/2.0/UDP 192.168.1.102:5060;received=69.35.46.178;branch=z9hG4bK3499714875. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net;tag=cdbfe46960d7566fcbe09f199f2b328d.c 2bb. Call-ID: 2671219156@192.168.1.102. CSeq: 100 ACK. Content-Length: 0. P-hint: Local Destination.
Thanks Alex.
So just to be clear, are you saying this:
1) When ser receives an INVITE it does not need to reply with "100 Trying"
2) When the SER tm module sends back the 100 Trying, the SIP UA should not be changing the Cseq header?
Regards, Paul
On 4/15/05, Alex Vishnev avishnev@optonline.net wrote:
Paul,
It looks like UA ACK 100 Trying. First of all I don't believe this is needed. Second of all, it changes CSEQ from 101 INVITE to 100. I think that's not valid at all.
HTH
Alex
*From:* serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] *On Behalf Of *Java Rockx *Sent:* Friday, April 15, 2005 10:46 AM *To:* serusers@lists.iptel.org *Subject:* [Serusers] Another Looping Question
Hi All.
Below is a snippet of an INVITE and you can see the usual "trying - your call is important to us" in the dialog. Anyhow, for some reason SER occasionally attempts to sent the ACK to itself, which causes a looping condition. The last ACK shown is the start of the looping condition.
It only happens on occasion. SER should have consumed the ACK rather than attempted to forward it.
Can anyone explain this?
Regards, Paul
IP Legend
10.3.0.221 http://10.3.0.221 - SER (behind a Cisco 3600 so ALG rewrote the IPs) 69.36.46.178 http://69.36.46.178 - NATed SIP UA
U 2005/04/15 02:19:16.252614 69.35.46.178:5060 http://69.35.46.178:5060-> 10.3.0.221:5060 http://10.3.0.221:5060 INVITE sip:8187768080@sipdev.mycompany.net SIP/2.0. Via: SIP/2.0/UDP 192.168.1.102:5060 http://192.168.1.102:5060 ;branch=z9hG4bK3915905414. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net. Call-ID: 2671219156@192.168.1.102. CSeq: 101 INVITE. Contact: sip:3215591439@192.168.1.102:5060. Proxy-Authorization: Digest username="3215591439", realm=" sipdev.mycompany.net http://sipdev.mycompany.net", nonce="425f5e0de25efdb3f5a6125dcf2147bf30fe9177", uri=" sip:8187768080@sipdev.mycompany.net", response="61996c3bdc10990fec7e245751777516", algorithm=MD5, cnonce="ae02e47a3355bada49ce344c92f48587", qop=auth, nc=00000002. max-forwards: 70. Allow: INVITE, ACK, CANCEL, BYE, REFER, NOTIFY. Content-Type: application/sdp. Content-Length: 180. . v=0. o=- 32014 3005 IN IP4 192.168.1.102 http://192.168.1.102. s=-. c=IN IP4 192.168.1.102 http://192.168.1.102. t=0 0. m=audio 13456 RTP/AVP 18 0 8 2 4 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. .
# U 2005/04/15 02:19:16.276216 10.3.0.221:5060 http://10.3.0.221:5060 -> 69.35.46.178:5060 http://69.35.46.178:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 192.168.1.102:5060 http://192.168.1.102:5060 ;branch=z9hG4bK3915905414;rport=5060;received=69.35.46.178http://69.35.46.178 . From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.myvox.net. Call-ID: 2671219156@192.168.1.102. CSeq: 101 INVITE. Content-Length: 0. .
# U 2005/04/15 02:19:16.792795 69.35.46.178:5060 http://69.35.46.178:5060-> 10.3.0.221:5060 http://10.3.0.221:5060 ACK sip:8187768080@sipdev.mycompany.net SIP/2.0. Via: SIP/2.0/UDP 192.168.1.102:5060 http://192.168.1.102:5060 ;branch=z9hG4bK3499714875. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net;tag= cdbfe46960d7566fcbe09f199f2b328d.c2bb. Call-ID: 2671219156@192.168.1.102. CSeq: 100 ACK. Content-Length: 0. .
# U 2005/04/15 02:19:16.912146 10.3.0.221:5060 http://10.3.0.221:5060 -> 10.3.0.221:5060 http://10.3.0.221:5060 ACK sip:8187768080@sipdev.mycompany.net SIP/2.0. Max-Forwards: 10. Record-Route: <sip:10.3.0.221 http://10.3.0.221;ftag=1465261089;lr>. Via: SIP/2.0/UDP 10.3.0.221 http://10.3.0.221;branch=0. Via: SIP/2.0/UDP 192.168.1.102:5060 http://192.168.1.102:5060;received= 69.35.46.178 http://69.35.46.178;branch=z9hG4bK3499714875. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net;tag= cdbfe46960d7566fcbe09f199f2b328d.c2bb. Call-ID: 2671219156@192.168.1.102. CSeq: 100 ACK. Content-Length: 0. P-hint: Local Destination.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Paul,
Sorry it this was unclear. I meant to say that I don't think UA should respond with ACK to provisional response (i.e. 100 Trying). I just scanned through an RFC and did not see anywhere where it says provisional responses should be ACKed. Also, I am unclear on why UA changed CSEQ. Any ideas on that?
Alex
_____
From: Java Rockx [mailto:javarockx@gmail.com] Sent: Friday, April 15, 2005 2:12 PM To: Alex Vishnev Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Another Looping Question
Thanks Alex.
So just to be clear, are you saying this:
1) When ser receives an INVITE it does not need to reply with "100 Trying"
2) When the SER tm module sends back the 100 Trying, the SIP UA should not be changing the Cseq header?
Regards, Paul On 4/15/05, Alex Vishnev avishnev@optonline.net wrote: Paul,
It looks like UA ACK 100 Trying. First of all I don't believe this is needed. Second of all, it changes CSEQ from 101 INVITE to 100. I think that's not valid at all. HTH
Alex
_____
From: serusers-bounces@lists.iptel.org [mailto: mailto:serusers-bounces@iptel.org serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Friday, April 15, 2005 10:46 AM To: serusers@lists.iptel.org Subject: [Serusers] Another Looping Question
Hi All.
Below is a snippet of an INVITE and you can see the usual "trying - your call is important to us" in the dialog. Anyhow, for some reason SER occasionally attempts to sent the ACK to itself, which causes a looping condition. The last ACK shown is the start of the looping condition.
It only happens on occasion. SER should have consumed the ACK rather than attempted to forward it.
Can anyone explain this?
Regards, Paul
IP Legend ------------------- 10.3.0.221 - SER (behind a Cisco 3600 so ALG rewrote the IPs) 69.36.46.178 - NATed SIP UA
U 2005/04/15 02:19:16.252614 69.35.46.178:5060 -> 10.3.0.221:5060 INVITE sip:8187768080@sipdev.mycompany.net SIP/2.0. Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK3915905414. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net. Call-ID: 2671219156@192.168.1.102. CSeq: 101 INVITE. Contact: sip:3215591439@192.168.1.102:5060. Proxy-Authorization: Digest username="3215591439", realm="sipdev.mycompany.net", nonce="425f5e0de25efdb3f5a6125dcf2147bf30fe9177", uri="sip:8187768080@sipdev.mycompany.net ", response="61996c3bdc10990fec7e245751777516", algorithm=MD5, cnonce="ae02e47a3355bada49ce344c92f48587", qop=auth, nc=00000002. max-forwards: 70. Allow: INVITE, ACK, CANCEL, BYE, REFER, NOTIFY. Content-Type: application/sdp. Content-Length: 180. . v=0. o=- 32014 3005 IN IP4 192.168.1.102. s=-. c=IN IP4 192.168.1.102. t=0 0. m=audio 13456 RTP/AVP 18 0 8 2 4 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. .
# U 2005/04/15 02:19:16.276216 10.3.0.221:5060 -> 69.35.46.178:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK3915905414;rport=5060;received= 69.35.46.178 http://69.35.46.178 . From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.myvox.net. Call-ID: 2671219156@192.168.1.102. CSeq: 101 INVITE. Content-Length: 0. .
# U 2005/04/15 02:19:16.792795 69.35.46.178:5060 -> 10.3.0.221:5060 ACK sip:8187768080@sipdev.mycompany.net SIP/2.0. Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK3499714875. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net;tag=cdbfe46960d7566fcbe09f199f2b328d.c 2bb. Call-ID: 2671219156@192.168.1.102. CSeq: 100 ACK. Content-Length: 0. .
# U 2005/04/15 02:19:16.912146 10.3.0.221:5060 -> 10.3.0.221:5060 ACK sip:8187768080@sipdev.mycompany.net SIP/2.0. Max-Forwards: 10. Record-Route: sip:10.3.0.221;ftag=1465261089;lr. Via: SIP/2.0/UDP 10.3.0.221;branch=0. Via: SIP/2.0/UDP 192.168.1.102:5060;received= 69.35.46.178 http://69.35.46.178 ;branch=z9hG4bK3499714875. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net;tag=cdbfe46960d7566fcbe09f199f2b328d.c 2bb. Call-ID: 2671219156@192.168.1.102. CSeq: 100 ACK. Content-Length: 0. P-hint: Local Destination.
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Perhaps it is a firmware bug. I'm going to check with the manufacturer.
By the way, this ATA is a UTstarcom iAN-02EX in case you're wondering.
Regards, Paul
On 4/15/05, Alex Vishnev avishnev@optonline.net wrote:
Paul,
Sorry it this was unclear. I meant to say that I don't think UA should respond with ACK to provisional response (i.e. 100 Trying). I just scanned through an RFC and did not see anywhere where it says provisional responses should be ACKed. Also, I am unclear on why UA changed CSEQ. Any ideas on that?
Alex
*From:* Java Rockx [mailto:javarockx@gmail.com] *Sent:* Friday, April 15, 2005 2:12 PM *To:* Alex Vishnev *Cc:* serusers@lists.iptel.org *Subject:* Re: [Serusers] Another Looping Question
Thanks Alex.
So just to be clear, are you saying this:
When ser receives an INVITE it does not need to reply with "100 Trying"
When the SER tm module sends back the 100 Trying, the SIP UA should not
be changing the Cseq header?
Regards, Paul
On 4/15/05, *Alex Vishnev* avishnev@optonline.net wrote:
Paul,
It looks like UA ACK 100 Trying. First of all I don't believe this is needed. Second of all, it changes CSEQ from 101 INVITE to 100. I think that's not valid at all.
HTH
Alex
*From:* serusers-bounces@iptel.org [mailto: serusers-bounces@lists.iptel.org] *On Behalf Of *Java Rockx *Sent:* Friday, April 15, 2005 10:46 AM *To:* serusers@lists.iptel.org *Subject:* [Serusers] Another Looping Question
Hi All.
Below is a snippet of an INVITE and you can see the usual "trying - your call is important to us" in the dialog. Anyhow, for some reason SER occasionally attempts to sent the ACK to itself, which causes a looping condition. The last ACK shown is the start of the looping condition.
It only happens on occasion. SER should have consumed the ACK rather than attempted to forward it.
Can anyone explain this?
Regards, Paul
IP Legend
10.3.0.221 http://10.3.0.221 - SER (behind a Cisco 3600 so ALG rewrote the IPs) 69.36.46.178 http://69.36.46.178 - NATed SIP UA
U 2005/04/15 02:19:16.252614 69.35.46.178:5060 http://69.35.46.178:5060-> 10.3.0.221:5060 http://10.3.0.221:5060 INVITE sip:8187768080@sipdev.mycompany.net SIP/2.0. Via: SIP/2.0/UDP 192.168.1.102:5060 http://192.168.1.102:5060 ;branch=z9hG4bK3915905414. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net. Call-ID: 2671219156@192.168.1.102. CSeq: 101 INVITE. Contact: sip:3215591439@192.168.1.102:5060. Proxy-Authorization: Digest username="3215591439", realm=" sipdev.mycompany.net http://sipdev.mycompany.net", nonce="425f5e0de25efdb3f5a6125dcf2147bf30fe9177", uri="sip:8187768080@sipdev.mycompany.net ", response="61996c3bdc10990fec7e245751777516", algorithm=MD5, cnonce="ae02e47a3355bada49ce344c92f48587", qop=auth, nc=00000002. max-forwards: 70. Allow: INVITE, ACK, CANCEL, BYE, REFER, NOTIFY. Content-Type: application/sdp. Content-Length: 180. . v=0. o=- 32014 3005 IN IP4 192.168.1.102 http://192.168.1.102. s=-. c=IN IP4 192.168.1.102 http://192.168.1.102. t=0 0. m=audio 13456 RTP/AVP 18 0 8 2 4 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. .
# U 2005/04/15 02:19:16.276216 10.3.0.221:5060 http://10.3.0.221:5060 -> 69.35.46.178:5060 http://69.35.46.178:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 192.168.1.102:5060 http://192.168.1.102:5060 ;branch=z9hG4bK3915905414;rport=5060;received= 69.35.46.178http://69.35.46.178 . From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.myvox.net. Call-ID: 2671219156@192.168.1.102. CSeq: 101 INVITE. Content-Length: 0. .
# U 2005/04/15 02:19:16.792795 69.35.46.178:5060 http://69.35.46.178:5060-> 10.3.0.221:5060 http://10.3.0.221:5060 ACK sip:8187768080@sipdev.mycompany.net SIP/2.0. Via: SIP/2.0/UDP 192.168.1.102:5060 http://192.168.1.102:5060 ;branch=z9hG4bK3499714875. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net;tag= cdbfe46960d7566fcbe09f199f2b328d.c2bb. Call-ID: 2671219156@192.168.1.102. CSeq: 100 ACK. Content-Length: 0. .
# U 2005/04/15 02:19:16.912146 10.3.0.221:5060 http://10.3.0.221:5060 -> 10.3.0.221:5060 http://10.3.0.221:5060 ACK sip:8187768080@sipdev.mycompany.net SIP/2.0. Max-Forwards: 10. Record-Route: <sip:10.3.0.221 http://10.3.0.221;ftag=1465261089;lr>. Via: SIP/2.0/UDP 10.3.0.221 http://10.3.0.221;branch=0. Via: SIP/2.0/UDP 192.168.1.102:5060 http://192.168.1.102:5060;received=69.35.46.178http://69.35.46.178 ;branch=z9hG4bK3499714875. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net;tag= cdbfe46960d7566fcbe09f199f2b328d.c2bb. Call-ID: 2671219156@192.168.1.102. CSeq: 100 ACK. Content-Length: 0. P-hint: Local Destination.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi Paul,
I'm testing UTstarcom iAN-02EX but i'm not receiving this sort of PR'ACK' to the 100 Trying Response from SER....my firmware version is:
Firmware Version: V1.8.2.17a
I hope this help you...
Regards,
Verbal ----- Original Message ----- From: Java Rockx To: Alex Vishnev Cc: serusers@lists.iptel.org Sent: Friday, April 15, 2005 8:19 PM Subject: Re: [Serusers] Another Looping Question
Perhaps it is a firmware bug. I'm going to check with the manufacturer.
By the way, this ATA is a UTstarcom iAN-02EX in case you're wondering.
Regards, Paul
On 4/15/05, Alex Vishnev avishnev@optonline.net wrote: Paul,
Sorry it this was unclear. I meant to say that I don't think UA should respond with ACK to provisional response (i.e. 100 Trying). I just scanned through an RFC and did not see anywhere where it says provisional responses should be ACKed. Also, I am unclear on why UA changed CSEQ. Any ideas on that?
Alex
----------------------------------------------------------------------------
From: Java Rockx [mailto: javarockx@gmail.com] Sent: Friday, April 15, 2005 2:12 PM To: Alex Vishnev Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Another Looping Question
Thanks Alex.
So just to be clear, are you saying this:
1) When ser receives an INVITE it does not need to reply with "100 Trying"
2) When the SER tm module sends back the 100 Trying, the SIP UA should not be changing the Cseq header?
Regards, Paul
On 4/15/05, Alex Vishnev avishnev@optonline.net wrote:
Paul,
It looks like UA ACK 100 Trying. First of all I don't believe this is needed. Second of all, it changes CSEQ from 101 INVITE to 100. I think that's not valid at all.
HTH
Alex
----------------------------------------------------------------------------
From: serusers-bounces@lists.iptel.org [mailto: serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Friday, April 15, 2005 10:46 AM To: serusers@lists.iptel.org Subject: [Serusers] Another Looping Question
Hi All.
Below is a snippet of an INVITE and you can see the usual "trying - your call is important to us" in the dialog. Anyhow, for some reason SER occasionally attempts to sent the ACK to itself, which causes a looping condition. The last ACK shown is the start of the looping condition.
It only happens on occasion. SER should have consumed the ACK rather than attempted to forward it.
Can anyone explain this?
Regards, Paul
IP Legend ------------------- 10.3.0.221 - SER (behind a Cisco 3600 so ALG rewrote the IPs) 69.36.46.178 - NATed SIP UA
U 2005/04/15 02:19:16.252614 69.35.46.178:5060 -> 10.3.0.221:5060 INVITE sip:8187768080@sipdev.mycompany.net SIP/2.0. Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK3915905414. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net. Call-ID: 2671219156@192.168.1.102. CSeq: 101 INVITE. Contact: sip:3215591439@192.168.1.102:5060. Proxy-Authorization: Digest username="3215591439", realm="sipdev.mycompany.net", nonce="425f5e0de25efdb3f5a6125dcf2147bf30fe9177", uri="sip:8187768080@sipdev.mycompany.net ", response="61996c3bdc10990fec7e245751777516", algorithm=MD5, cnonce="ae02e47a3355bada49ce344c92f48587", qop=auth, nc=00000002. max-forwards: 70. Allow: INVITE, ACK, CANCEL, BYE, REFER, NOTIFY. Content-Type: application/sdp. Content-Length: 180. . v=0. o=- 32014 3005 IN IP4 192.168.1.102. s=-. c=IN IP4 192.168.1.102. t=0 0. m=audio 13456 RTP/AVP 18 0 8 2 4 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. .
# U 2005/04/15 02:19:16.276216 10.3.0.221:5060 -> 69.35.46.178:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK3915905414;rport=5060;received= 69.35.46.178. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.myvox.net. Call-ID: 2671219156@192.168.1.102. CSeq: 101 INVITE. Content-Length: 0. .
# U 2005/04/15 02:19:16.792795 69.35.46.178:5060 -> 10.3.0.221:5060 ACK sip:8187768080@sipdev.mycompany.net SIP/2.0. Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK3499714875. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net;tag=cdbfe46960d7566fcbe09f199f2b328d.c2bb. Call-ID: 2671219156@192.168.1.102. CSeq: 100 ACK. Content-Length: 0. .
# U 2005/04/15 02:19:16.912146 10.3.0.221:5060 -> 10.3.0.221:5060 ACK sip:8187768080@sipdev.mycompany.net SIP/2.0. Max-Forwards: 10. Record-Route: sip:10.3.0.221;ftag=1465261089;lr. Via: SIP/2.0/UDP 10.3.0.221;branch=0. Via: SIP/2.0/UDP 192.168.1.102:5060;received= 69.35.46.178;branch=z9hG4bK3499714875. From: Test User sip:3215591439@sipdev.mycompany.net;tag=1465261089. To: sip:8187768080@sipdev.mycompany.net;tag=cdbfe46960d7566fcbe09f199f2b328d.c2bb. Call-ID: 2671219156@192.168.1.102. CSeq: 100 ACK. Content-Length: 0. P-hint: Local Destination.
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
------------------------------------------------------------------------------
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Alex Vishnev -
Francesco Bottà -
Java Rockx