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

[Byron Campen]

	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 at mxtelecom.com>
> Software Developer
> Tel: +44 (0) 845 666 7778
> Fax: +44 (0) 870 163 4694
> http://www.mxtelecom.com
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2369 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060815/913bc157/attachment.bin>