[Sip-implementors] A Question about INVITE Server Transaction in RFC 6026

[Caixia Liu]

In section "7.1 Server Transaction Impacts, RFC 6026", it has statements
like this.

A server transaction MUST NOT discard transaction state based only on
encountering a non-recoverable transport error when sending a
response. Instead, the associated INVITE server transaction state
machine MUST remain in its current state. (Timers will eventually
cause it to transition to the "Terminated" state). This allows
retransmissions of the INVITE to be absorbed instead of being
processed as a new request.


Which timer will eventually cause the server transaction to
transition to the "Terminated" state?

For example, if the current state is "Proceeding", due to transport error
we fail

to send response, the state will remain in "Proceeding" state. There is no
timer in

current Server Transaction, so how we eventually make the state transition
to

"Terminated" state?

Best Regards,

Caixia

[Brett Tate]

Good question. If within Accepted, it would be Timer L. However if
within Proceeding, I'm not completely sure what was expected to occur.

The following are a few situations to consider:
1) RFC 3262 sending first reliable 18x.
2) RFC 3262 sending second reliable 18x.
3) Same as 1 however already sent 100.
4) Sending 100.
5) Sending first 18x without having sent prior 100.
6) Sending first 18x after having sent prior 100.
7) Sending periodic non reliable 18x for Timer C reasons.
8) Sending periodic reliable 18x for Timer C reasons.
9) Sending 2xx.

The following was the motivation for the changed behavior.

"This allows retransmissions of the INVITE to be absorbed instead of being
processed as a new request."

Thus from an implementation perspective, that is the goal. However if you
don't get a better answer here, you might want to ask the sipcore working
group.

-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-
implementors-bounces at lists.cs.columbia.edu] On Behalf Of Caixia Liu
Sent: Wednesday, June 18, 2014 1:08 AM
To: Sip-implementors at lists.cs.columbia.edu
Subject: [Sip-implementors] A Question about INVITE Server Transaction
in RFC 6026
In section "7.1 Server Transaction Impacts, RFC 6026", it has
statements
like this.
A server transaction MUST NOT discard transaction state based only on
encountering a non-recoverable transport error when sending a
response. Instead, the associated INVITE server transaction state
machine MUST remain in its current state. (Timers will eventually
cause it to transition to the "Terminated" state). This allows
retransmissions of the INVITE to be absorbed instead of being
processed as a new request.
Which timer will eventually cause the server transaction to
transition to the "Terminated" state?
For example, if the current state is "Proceeding", due to transport error
we fail
to send response, the state will remain in "Proceeding" state. There is no
timer in
current Server Transaction, so how we eventually make the state transition
to
"Terminated" state?
Best Regards,
Caixia
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Caixia Liu]

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

Post by Brett Tate
Good question. If within Accepted, it would be Timer L. However if
within Proceeding, I'm not completely sure what was expected to occur.
1) RFC 3262 sending first reliable 18x.
2) RFC 3262 sending second reliable 18x.
3) Same as 1 however already sent 100.
4) Sending 100.
5) Sending first 18x without having sent prior 100.
6) Sending first 18x after having sent prior 100.
7) Sending periodic non reliable 18x for Timer C reasons.
8) Sending periodic reliable 18x for Timer C reasons.
9) Sending 2xx.
The following was the motivation for the changed behavior.
"This allows retransmissions of the INVITE to be absorbed instead of being
processed as a new request."
Thus from an implementation perspective, that is the goal. However if you
don't get a better answer here, you might want to ask the sipcore working
group.

-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-
implementors-bounces at lists.cs.columbia.edu] On Behalf Of Caixia Liu
Sent: Wednesday, June 18, 2014 1:08 AM
To: Sip-implementors at lists.cs.columbia.edu
Subject: [Sip-implementors] A Question about INVITE Server Transaction
in RFC 6026
In section "7.1 Server Transaction Impacts, RFC 6026", it has statements
like this.
A server transaction MUST NOT discard transaction state based only on
encountering a non-recoverable transport error when sending a
response. Instead, the associated INVITE server transaction state
machine MUST remain in its current state. (Timers will eventually
cause it to transition to the "Terminated" state). This allows
retransmissions of the INVITE to be absorbed instead of being
processed as a new request.
Which timer will eventually cause the server transaction to
transition to the "Terminated" state?
For example, if the current state is "Proceeding", due to transport error
we fail
to send response, the state will remain in "Proceeding" state. There is no
timer in
current Server Transaction, so how we eventually make the state transition
to
"Terminated" state?
Best Regards,
Caixia
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Roman Shpount]

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
application specific and does not need to be defined in the SIP spec. For
instance you can define that dial timeout when placing the call is 1 minute
and that will limit the duration of the proceeding state. Or you can set
the dial timeout at 10 minutes. Or you can set this to be unlimited and let
the caller hang up when they are done waiting for the call to connect. This
is really up to you. The same way you can put maximum call duration at 24
hours and limit calls this way or you can let the caller hang up when they
are done talking.
_____________
Roman Shpount

Post by Caixia Liu
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

[Brett Tate]

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 the archive.

http://www.ietf.org/mail-archive/web/sipcore/current/maillist.html


-----

From: Roman Shpount [mailto:roman at telurix.com]
Sent: Monday, June 23, 2014 6:06 AM
To: Caixia Liu
Cc: Brett Tate; Sip-implementors at lists.cs.columbia.edu
Subject: Re: [Sip-implementors] A Question about INVITE Server Transaction
in RFC 6026

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 application
specific and does not need to be defined in the SIP spec. For instance you
can define that dial timeout when placing the call is 1 minute and that will
limit the duration of the proceeding state. Or you can set the dial timeout
at 10 minutes. Or you can set this to be unlimited and let the caller hang
up when they are done waiting for the call to connect. This is really up to
you. The same way you can put maximum call duration at 24 hours and limit
calls this way or you can let the caller hang up when they are done talking.
_____________
Roman Shpount

[Roman Shpount]

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 gets
hanged up and the whole transaction gets cancelled before timer C ever
fires. My point is, there is a gap in SIP transaction state definition with
INVITE transactions never expiring when in proceeding state, but in
practice this is not a major problem since application call level timers
typically terminate the whole call if it is not answered within reasonable
time. So, this can be fixed but there is very little incentive for real
world implementation to worry or care about this specification change.

_____________
Roman Shpount

Post by Brett Tate
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 the archive.
http://www.ietf.org/mail-archive/web/sipcore/current/maillist.html
-----
From: Roman Shpount [mailto:roman at telurix.com]
Sent: Monday, June 23, 2014 6:06 AM
To: Caixia Liu
Cc: Brett Tate; Sip-implementors at lists.cs.columbia.edu
Subject: Re: [Sip-implementors] A Question about INVITE Server Transaction
in RFC 6026
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 application
specific and does not need to be defined in the SIP spec. For instance you
can define that dial timeout when placing the call is 1 minute and that will
limit the duration of the proceeding state. Or you can set the dial timeout
at 10 minutes. Or you can set this to be unlimited and let the caller hang
up when they are done waiting for the call to connect. This is really up to
you. The same way you can put maximum call duration at 24 hours and limit
calls this way or you can let the caller hang up when they are done talking.
_____________
Roman Shpount

[Caixia Liu]

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 transition to accepted
state no matter if there is transport error or not.

Best Regards,
Caixia

Post by Caixia Liu
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 gets
hanged up and the whole transaction gets cancelled before timer C ever
fires. My point is, there is a gap in SIP transaction state definition with
INVITE transactions never expiring when in proceeding state, but in
practice this is not a major problem since application call level timers
typically terminate the whole call if it is not answered within reasonable
time. So, this can be fixed but there is very little incentive for real
world implementation to worry or care about this specification change.
_____________
Roman Shpount

Post by Brett Tate
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 the archive.
http://www.ietf.org/mail-archive/web/sipcore/current/maillist.html
-----
From: Roman Shpount [mailto:roman at telurix.com]
Sent: Monday, June 23, 2014 6:06 AM
To: Caixia Liu
Cc: Brett Tate; Sip-implementors at lists.cs.columbia.edu
Subject: Re: [Sip-implementors] A Question about INVITE Server

Transaction

Post by Brett Tate
in RFC 6026
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 application
specific and does not need to be defined in the SIP spec. For instance

you

Post by Brett Tate
can define that dial timeout when placing the call is 1 minute and that will
limit the duration of the proceeding state. Or you can set the dial

timeout

Post by Brett Tate
at 10 minutes. Or you can set this to be unlimited and let the caller

hang

Post by Brett Tate
up when they are done waiting for the call to connect. This is really up

to

Post by Brett Tate
you. The same way you can put maximum call duration at 24 hours and limit
calls this way or you can let the caller hang up when they are done talking.
_____________
Roman Shpount

_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors