[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