| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
Opps – my mistake – apparently
the response to the subsequent requests has not been received – (what
threw me off was my server does what was requested of it). As to the decision to only support one
outstanding NICT seems to stray from the RFC – is this correct? Thanks for your patience and help. Stephen From: Derek MacDonald
[mailto:derek@xxxxxxxx] What revision of duma re you using?
I have that exception being at line 505 in my sandbox. If you look at the
code, the important thing is that mNitState must be NitComplete, and will
transition there when a response to the current NIT is received. --Derek CONFIDENTIALITY NOTICE This email and any files transmitted with it contains
proprietary information and, unless expressly stated otherwise, all contents
and attachments are confidential. This email is intended for the addressee(s)
only and access by anyone else is unauthorized. If you are not an addressee,
any disclosure, distribution, printing or copying of the contents of this email
or its attachments, or any action taken in reliance on it, is unauthorized and
may be unlawful. If you are not an addressee, please inform the sender
immediately and then delete this email and any copies of it. Thank you for your
co-operation. From:
resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keohane, Stephen 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 |