14 Oct
2004
14 Oct
'04
3:37 p.m.
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
15 Oct
15 Oct
6:39 p.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
9:35 p.m.
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(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7347
days inactive
7348
days old
2 comments
3 participants
participants (3)
-
Bogdan-Andrei IANCU -
Martin Koenig -
Ranga Rao Vutukuru