< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Sip Responses being buffered. How do i get at them when they arrive?


If the stack is retransmitting the INVITE, that means it is not seeing the 200. A few things can cause this, including:

1) 200 is going to the wrong place.
2) 200 is malformed enough to cause the pre-parse to fail.
3) 200 has the wrong transaction id.

Breaking out ethereal will help determine whether any of these is true. Also, looking through the logging might reveal something.

One thing worth noting; you are not calling select on that fdset after you build it. This will cause pretty nasty CPU spin (since everything will think their fd is ready for every iteration of the loop). It is possible that this is triggering some weirdness in one of the transports (which transport are you using here?), but a casual glance doesn't reveal anything that would be falling apart completely.

Best regards,
Byron Campen


Hi guys,

I've been using resiprocate for very basic purposes. I've been trying to
avoid using any of the higher level functionality, and simply have an
event loop which basically does this:

while (true) {

        sipStack->buildFdSet(fdset);

        sipStack->process(fdset);
        if ((SipMessage * msg=sipStack->receive())) {
                messageProcessor->onSipMessage(msg);
        }
        processOutgoingMessages(); // this simply reads off a list of           
                                   // SipMessage*s and sipStack(send)s          
                                   // each one of them.
}

This was all working fine when i was only answering sip requests, ie
sending back responses to INVITEs using, for example,
Helper::makeResponse(*origMsg,200,myAddress). The responses were being
sent back as soon as I called sipStack->send(). Similarly, the INVITE
was being passed to my messageProcessor->onSipMessage(msg) as soon as it
arrived on the wire.

However, now I've been trying to send out INVITE requests. I'm sending
out offerless invites created using
Helper::makeInvite(targetAddress,myAddress), and then sent using
sipStack->send(). The INVITE appears on the wire as soon as it is pushed
into the sipStack, which is all great.

The problem is, that when the 200-OK comes back from the other end, it
seems to be getting stuck in a fifo *somewhere*. I cannot for the life
of me figure out where this is! The INVITE i've pushed into the stack
gets resent 5 or 6 times, before the Timer B which is set to 32 seconds
(again, i don't know where from) times out, and only then does the
SipMessage get received by the sipStack->receive(msg) method.

I'm aware that SipStack::receive() is actually deprecated, but I've only
been using that because I was copying the simple examples in
resiprocate/resip/stack/test/*. I can see that this is something to do
with a TransactionUser registering itself with the sipstack and
associating itself with that INVITE request. But I don't know where this transaction user is being created, or how to get at its incoming queue...

Ideally, i'd like to (presumably) create my own subclass of
TransactionUser which registers itself with the SipStack for ALL
incoming requests AND responses, and just deal with all of the state of
the dialogs myself. But for now I could just do with being told when a
message arrives on the wire! There seems to be pretty much no
documentation that I can find which tells me how I might do this, so any
pointers would be very helpful.

I've been trying to figure this one out for almost a day now, and I
figured it's about time to ask around. Can anyone help me out?

Thanks in advance, and sorry for the length of the email!

Rob

--
Robert Wyrobek <robert@xxxxxxxxxxxxx>
Software Developer
Tel: +44 (0) 845 666 7778
Fax: +44 (0) 870 163 4694
http://www.mxtelecom.com
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel

Attachment: smime.p7s
Description: S/MIME cryptographic signature