[Serusers] CANCEL handling

[Ranga Rao Vutukuru]

Hi Bogdan,Martin

    I have an ser and asterisk combo. I was routing the call to
asterisk and after asterisk plays Ivr, it forwards it back to ser with
the desired extension/phone number. Then ser does parellel fork. when
I pick up one phone, other phones go down, thats normal.

The issue:
   
   487 generated by UA's is forwarded upstream to asterisk. AFAIK, 487
received by ser for parellel fork, should not be sent upstream. As a
result of this, asteriks is stopping rtp stream and sending  a BYE and
also ACK as it sees a 4xx for established call. This generated ACK is
creating race condition at ser. I see this  ACK when in debug mode.

23(7572) Sending:
ACK sip:ranga at 192.168.1.10 SIP/2.0
Max-Forwards: 10
Via: SIP/2.0/UDP 192.168.1.10;branch=0
Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK4817.b91e5341.1
(rest of headers except Route header follow )


after some debug lines, I see this message

17(7566) Sending:
ACK sip:ranga at 192.168.1.10 SIP/2.0
Max-Forwards: 9
Via: SIP/2.0/UDP 192.168.1.10;branch=0
Via: SIP/2.0/UDP 192.168.1.10;branch=0
Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK4817.b91e5341.1
(rest of headers except Route header follow )


This continues to add Via's till Max-Forwards is 0. Then I see the
famous message "Warning: sl_send_reply: I won't send a reply for
ACK!!"


IMO, when the parallel fork is not invloved, UA receiving 487 is perfect.

Any ideas abt what is going wrong here?

TIA,
-Ranga

On Fri, 15 Oct 2004 17:39:32 +0200, Bogdan-Andrei IANCU
<iancu at fokus.fraunhofer.de> wrote:
> Martin Koenig wrote:
> 
> >Hello,
> >
> >I just noticed that SER is not generating a 200 OK as reply for a CANCEL but
> >rather a 200 cancelling.
> >
> >
> yes...the rfc doesn't impose the reason phrase, just the code
> 
> >Then it is also generating a 487 Request cancelled what is supposed to be
> >generated by the other end device reveiving the CANCEL.
> >
> >
> SER does a hop-by-hop cancellation of the INVITE.
> 
> >How is this possible? Is this according to RFC3261?
> >
> >
> yes, but this approach can generate race conditions (cancelling before
> the INVITE get to target UAS); on the other hand solves the problem with
> UASs that don't generate 487 for Cancels.
> 
> 
> bogdan
> 
> 
> 
> >Regards,
> >Martin
> >
> >_______________________________________________
> >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
>