[Spce-user] retries of INVITES for session timers

[Matthew Ogden]

Hmmm... here it comes then.

Its asterisk who sent the 100, so its their responsibility to keep sending
the 200 until they get an Ack.

Would anyone else like to comment?

Would there be a way without disabling timers to get SEMS to workaround
this? (to go back to retrying the reINVITE?)


> -----Original Message-----
> From: spce-user-bounces at lists.sipwise.com [mailto:spce-user-
> bounces at lists.sipwise.com] On Behalf Of Jon Bonilla (Manwe)
> Sent: 05 April 2013 06:15 PM
> To: spce-user at lists.sipwise.com
> Subject: Re: [Spce-user] retries of INVITES for session timers
>
> El Fri, 5 Apr 2013 14:54:00 +0200
> Matthew Ogden <matthew at tenacit.net> escribió:
>
> > HI Ivan,
> >
> >
> >
> > Sorry I have already deleted it (and our server only keeps it for 1
> > day).
> >
> >
> >
> > But as mentioned, the issue is SEMS no reINVITING after client sends
> > 100.
> >
> >
> >
> > This is the issue I’m trying to investigate, and no one out there
> > seems bothered that SEMS is broken.
> >
> >
> >
> > SEMS should do this:
> >
> >
> >
> > Client sends initial authenticated INVITE
> >
> > SEMS Accept initial authenticated INVITE
> >
> > SEMS Wait for timer period
> >
> > SEMS Send reinvite
> >
> > Client sends initial 100 – trying
> >
> > Client sends initial 200 – OK
> >
> > SEMS Wait for timer period
> >
> > SEMS Send reinvite
> >
> > Client sends initial 100 – trying
> >
> > ---No 200???
> >
> > SEMS Send reinvite  RETRY (BUT this is not happening…  after a 100 is
> > received, no subsequent retry occurs. In my opionion SEMS is broken?
> > But I don’t know how to prove/check this)
> >
> > Client sends initial 100 – trying
> >
> > Client sends initial 200 – OK
> >
> >
>
> Well, I'm not sure about this but I would say that's what I would expect.
> Provisional responses avoid retransmissions. If I send a request and don't
> receive any answer, then I retransmit it (suposing not reliable transport
> like
> UDP). If I receive a 100 or any other 1XX I know that my request has been
> received so there no reason to send retransmissions. I do know that the
> request has been received. What I will do is wait until the transaction
> expires and generate a 408 if no answer is received.