| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
Hi, After re-reading my post, I see how
unclear my original post was Here is what I am seeing: UAC ---- invite à UAS UAC ß 200 ---- UAS UAC ---- ACK à UAS 2 seconds later: UAC -à info à UAS UAC <- 200 à UAS 2 seconds later UAC à info à UAS Log: DEBUG | 20050906-121810.812 | SipH |
RESIP:TRANSPORT | 2780 | Transport.cxx:329 | Adding message to tx buffer to: [
V4 10.1.17.70:5060 UDP received on: Transport: [ V4 0.0.0.0:12005 UDP
connectionId=0 ] connectionId=0 ] DEBUG | 20050906-121811.312 | SipH |
RESIP:TRANSPORT | 2780 | Transport.cxx:375 | incoming from: [ V4
10.1.17.70:5060 UDP received on: Transport: [ V4 0.0.0.0:12005 UDP
connectionId=0 ] connectionId=0 ] DEBUG | 20050906-121813.468 | SipH | RESIP
| 1320 | BaseException.cxx:20 | BaseException at .\InviteSession.cxx:666 Cannot
start a non-invite transaction until the previous one has completed INFO | 20050906-121813.468 | SipH |
RESIP:DUM | 1320 | ClientInviteSession.cxx:349 | ClientInviteSession::end,
Terminated/Connected/ReInviting) INFO | 20050906-121813.468 | SipH |
RESIP:DUM | 1320 | InviteSession.cxx:707 | InviteSession::end, state: 4 INFO | 20050906-121813.468 | SipH |
RESIP:DUM | 1320 | InviteSession.cxx:730 | InviteSession::end, Connected DEBUG | 20050906-121813.468 | SipH |
RESIP:DUM | 1320 | Dialog.cxx:843 | Dialog::makeRequest: BYE
sip:VoiceGenie@xxxxxxxxxx:5060 SIP/2.0 My assumption was that the Timer K which
moves the NICT from Competed to Terminated (and defaults to T4) had not fired. As
my usecase succeeds when I issue requests greater than 4 seconds apart. Sorry for the confusion. From: Keohane, Stephen
Hello, My usecase has multiple info request/response transactions
during a session. What I am finding is that the Timer K which moves the NICT
from the Completed to Terminated states has not fired. Questions: Is it possible to set Timer K to some other value other than
T4? If so, how? This seems to be allowed in RFC 3261 pg 258 “RFC 2543
was silent on whether a UA could initiate a new transaction to
a peer while another was in progress. That is now specified here.
It is allowed for non-INVITE requests, disallowed for
INVITE.” Is this an issue or has it been fixed in the latest release? Finally, here is the exception raised: UsageUseException::Cannot start a non-invite
transaction until the previous one has completed Thanks for all your help, I really appreciate it, and
I’m really sorry if this is covered in the archives or wiki – I
couldn’t find it. Stephen Keohane |