hi giles,
    The role of the msgQueue is to give u all the requests and final responses to the message that came out of the SipTransceiverFilter::receive(). So, when u get a 200 OK, it should contain the INVITE for the transaction, an ACK message will contain the INVITE, 200 OK and ACK message and so on. An INVITE is available for a period of 3 minutes and all others for a period of 32 seconds. Hence, to return all the messages for the transaction, a queue is returned.
    Did this help?
gautham
 
 
----- Original Message -----
Sent: Thursday, June 07, 2001 6:59 AM
Subject: [Sip] Early experiments: proxy server, tagged To and matching Transaction Id problems.

I'm using sip 1.2.1 to further my understanding of  the SIP protocol in a hands on way.  That's the plan anyway.  To get my hands dirty I'm trying to build a non-forking proxy server but have come up with a couple of problems and wonder if anyone can point me in the right direction.

I've provided my own builder, feature, state and operator classes, each of which derives from the corresponding one in base.  All the work is done in myOperator::process.  The other bits just allow me to call the necessary addXXX()

myOperator::process() munges the request URI and adds the proxy server to the via list, then calls sendAsync to forward the request on.

So far so good, so I tested this with a couple of vovida UA's.  The INVITE is routed through OK and both 180 RINGING and 200 come back to the proxy server as far as SipTransceiver::receive().  Here's where the problems start.

1) The UA has correctly added a To: tag as the via list is >1.  This means that the transaction IDs for request & response do not match, so the UDP retransmission is not cancelled.  A crude hack to not compare tags solves this problem but is there a better way?

2) With the hacked transaction ID from 1, run the ProxyServer, and break on receiving the 200 status in SipTransceiver::receive().  The call to   udpConnection->cancel(*requestId) results in a log entry of "failed to cancel msg (id not found)" presumably because the msg was successfully cancelled by the returning 180 - there's a log entry of "cancelling request after <200 response".  I think I'm happy with that, my confusion is over the msgQueue - I don't seem to be entering the block of code:

   // xxx this is the fix for retrans
            if (msgQueue == 0) // etc

I don't understand the use of msgQueue here, but assume that I need to post the response to the queue to give myOperator::process a shot at it. 

Where am I going wrong?

Any help gratefully received!

----------
Giles Chamberlin

Reply via email to