[Serusers] Another Looping Question

Fri Apr 15 20:19:22 CEST 2005

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 at 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 at gmail.com] 
> *Sent:* Friday, April 15, 2005 2:12 PM
> *To:* Alex Vishnev
> *Cc:* serusers at 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 at 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 at iptel.org [mailto: serusers-bounces at lists.iptel.org] *On 
> Behalf Of *Java Rockx
> *Sent:* Friday, April 15, 2005 10:46 AM
> *To:* serusers at 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 at 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 at sipdev.mycompany.net>;tag=1465261089.
> To: <sip:8187768080 at sipdev.mycompany.net>.
> Call-ID: 2671219156 at 192.168.1.102.
> CSeq: 101 INVITE.
> Contact: <sip:3215591439 at 192.168.1.102:5060>.
> Proxy-Authorization: Digest username="3215591439", realm="
> sipdev.mycompany.net <http://sipdev.mycompany.net>", 
> nonce="425f5e0de25efdb3f5a6125dcf2147bf30fe9177", uri="sip:8187768080 at 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.178<http://69.35.46.178>
> .
> From: Test User <sip:3215591439 at sipdev.mycompany.net>;tag=1465261089.
> To: <sip:8187768080 at sipdev.myvox.net>.
> Call-ID: 2671219156 at 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 at 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 at sipdev.mycompany.net>;tag=1465261089.
> To: <sip:8187768080 at sipdev.mycompany.net>;tag=
> cdbfe46960d7566fcbe09f199f2b328d.c2bb.
> Call-ID: 2671219156 at 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 at 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 at sipdev.mycompany.net>;tag=1465261089.
> To: <sip:8187768080 at sipdev.mycompany.net>;tag=
> cdbfe46960d7566fcbe09f199f2b328d.c2bb.
> Call-ID: 2671219156 at 192.168.1.102.
> CSeq: 100 ACK.
> Content-Length: 0.
> P-hint: Local Destination.
>  
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
>    
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050415/dc4d8799/attachment.htm>