hung up the call. Maybe someone more familar with the "RTC" stack drop a comment here.
From my point of view even the first call could not work. Maybe have a closer look at: rfc3261 / 17.1.1.3 Construction of the ACK Request.
Ok, rfc2543 does not point the use of request-uri values out like
rfc3261 does in this case, but even in rfc2543 i can only find examples like
these:
ACK sip:[EMAIL PROTECTED] SIP/2.0
Via: SIP/2.0/UDP north.east.isi.edu
From: Mark Handley <sip:[EMAIL PROTECTED]>
To: Eve Schooler <sip:[EMAIL PROTECTED]> ;tag=9883472
Call-ID: [EMAIL PROTECTED]
CSeq: 1 ACK
Regards,
Michael
On Dec 1, 2004, at 2:00 PM, mahesh akarapu wrote:
Hi Michael,
If you look at packets 1-11(this is the case where no 200 OK was sent
after ACK is recieved), there also the request line does not contain the
user part. I guess if it is because of the user part missing, then in
the first case also we should see 200 Ok after ACK.
What are your comments on this.
regards Mahesh
On Wed, 2004-12-01 at 17:02, michael koehler wrote:Seems that ACK is missing the userpart of the request line.
should be:
ACK sip:[EMAIL PROTECTED]
instead of
ACK sip:202.125.84.170...
my 5c
Michael
On Dec 1, 2004, at 8:00 AM, mahesh akarapu wrote:
Hi,
I am attaching the ethereal captures, so as to be clear on the problem.
I am using the following network setup.
HOST1---HOST2
HOST1(202.125.84.170) and HOST2(202.125.84.171) are windows-XP machines
with AOL instant messengers as the UAs. Now a sip call is initiated
from
HOST1. I am attaching the ethereal capture on HOST2 where the problem
behaviour is seen.
Packets (1-11) in the capture show the case where the SIP call was
established and terminated normally. Packets (12-27) show the case
where
i observed the problem behavior.
Please go through the capture and let me know your comments on this.
Regards Mahesh
On Tue, 2004-11-30 at 20:49, Nataraju A B wrote:If you can send the message details it would be easy to find out the actual problem...
Otherwise we could only find vague answer which may not be useful to your actual problem...
Best Regards, Nataraju A.B.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of michael
koehler
Sent: Tuesday, November 30, 2004 4:51 PM
To: mahesh akarapu
Cc: [EMAIL PROTECTED]
Subject: Re: [Sip-implementors] 200 OK after recieving ACK
Mahesh,
when UAS is sending 200 after ACK then it could be that UAS is not understaending your ACK request.
ensure that your ACK request is matching:
- request uri from INVITE (or record route) - to/from headers incl. TAGS (to-tag from 200) - call-id from INVITE - cseq from INVITE
Have in mind this could also be a proxy bug and without further details it is only possible to give hints. At least, maybe your ACK is never reaching the right destination.
Regards,
Michael
On Nov 30, 2004, at 6:17 AM, mahesh akarapu wrote:
Hi all, I have a doubt regarding how ACK requests are handled. I am trying to establish a SIP session. The following is the scenario. A------------B INV---------> <----------100 <----------180 <----------200 ACK---------> Till this point, it is OK.But after this there are repeated 200Ok from
possibleB as below. <----------200 ACK---------> <----------200 ACK--------->
I guess according to the RFC 3261, once ACK is received, the UA should stop sending the 200 OK.Could someone please tell me if this ascenario, that is under what circumstances 200 OK is sent after recieving ACK. I could not get the answer for this from the RFC.
Could someone answer this.
thanks Mahesh
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
<host2-capture>
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
