Re: [reSIProcate] Not using Dum but Stack Apis for the Cancel
Yah I guess you are right saying that the via headers are not proper but
on sending on the IP side and capturing the packets found the relevant
fields in the packet to be fine.
About getting the transaction id can you let me know exactly what are
the fields that are dependent on the same.
And about the stack getting the 200 response before the test that does
not seem possible as I am using kphone as the receiving end and till I
accept the call 200 wont be sent.
I am using resiprocate-0.9.0-5019.
However there is yet another problem which I have mentioned earlier and
is although not very relevant to this context and that is the presence
of the tag in the TO field in the Invite message which should not be
there but nothing is handled about the same in the Helper::makeInvite
routine.
Thanks for all the help and suggestions to everyone
Regards
Sumit
Dennis Dupont wrote:
Your Via headers don't look correct, but it may be that way for all
messages before they are sent as the transport has not been selected.
I assume the stack can still pull out the transaction ID.
Is it possible the stack is getting the 200 response before the test
program issues the cancel? Perhaps the 200 has been processed by the
transaction layer and is in the TU FIFO?
BTW, what version of resip are you using?