Hello,
I just noticed that SER is not generating a 200 OK as reply for a CANCEL but rather a 200 cancelling.
Then it is also generating a 487 Request cancelled what is supposed to be generated by the other end device reveiving the CANCEL.
How is this possible? Is this according to RFC3261?
Regards, Martin
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Bogdan-Andrei IANCU -
Martin Koenig -
Ranga Rao Vutukuru