Thank everybody!
Especially thank Brett very much for forwarding this to sipcore!
This issue has been clarified in sipcore forum.
Actually this is my misunderstanding.
If a server transaction is in proceeding state, and TU hands a 2xx response
to server transaction, server transaction should tra
Brett,
This can probably be handled by timer C. The problem is that very few
clients actually resend the last provisional response every minute to keep
the transaction from expiring on timer C. In practice, application call
timeouts are set to be much less then 3 minutes so that the entire cal get
Hi Roman,
Transaction state and call state are separate things. However since I'm not
sure what timer (proprietary or RFC defined) sipcore was expecting to be
used while stuck within Proceeding because of the RFC 6026 requirement, I
posted the question to sipcore.
It will eventually show up in t
Caixia,
I do not think specification missed anything. This is quite intentional.
There is no limit of how long the caller can be dialing the number (as
there is no limit on how long the caller can stay connected on a SIP call).
If you need to put a limit on this duration, this will have to be
appl
Hi Brett,
Thanks a lot for your detailed analysis.
Yes, the proceeding state is big issue to me. It seems spec missed this
scenario, I have to retreat to an implementation specific behavior.
Best Regards,
Caixia
On Wed, Jun 18, 2014 at 7:39 PM, Brett Tate wrote:
> Good question. If within A
