[Spce-user] retries of INVITES for session timers
Andreas Granig
agranig at sipwise.com
Wed Apr 10 10:36:12 EDT 2013
Hi,
On 04/10/2013 04:17 PM, Jon Bonilla (Manwe) wrote:
> At this point I think you should contact our sales team and talk to them
> regarding a new feature request in NGCP's session timer handling. Modifying
> sems, when it behaves correctly IMHO, is out of the scope of this mailing
> list.
Since the SPCE is using Sems for handling session timers, it's probably
best covered on the Sems mailing-list.
However, there is already a mechanism coping with lost 200. Sems sends
(re)INVITE to a client, waits for provisional or final responses and
retransmits the invite if it doesn't get one within the timers defined
in RFC3261. Once it gets a provisional response, it stops
retransmitting, which is according to the SIP standard.
Now it's the client's responsibility to retransmit the 200 for the
INVITE until an ACK is received (again within the defined timers).
So if no 200 ever reaches Sems (or the SPCE for that matter), this means
that there is complete packet loss for at least 30secs (that's the value
how long retransmission should be tried, iirc), and I don't see how
sending another re-INVITE would help in this case.
If retransmissions for UDP can't cope with the packet loss, the next
best thing to do is switching to tcp.
Andreas
More information about the Spce-user
mailing list