Hi, Concerning the 408, I assume that a transaction stateful middle box generated it upon re-INVITE transaction timeout (or similar issue) hitting the "best response" behavior of RFC 3261 section 16.7.
> -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat > Sent: Wednesday, July 22, 2015 1:52 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] No Session Expire Header in 200 OK > > I generally agree with what Tarun is saying, but have one clarification > > On 7/22/15 1:39 PM, Tarun2 Gupta wrote: > > Hi > > > > Please refer Section 7.2 of RFC 4028. > > > > If the UAS did not include a SE header in 200 OK response, it means that it > does not want / support session expiration. In this case, UAC can perform > refreshes but for its own benefit only. UAC should behave as if the 200 OK > response contained refresher as 'UAC'. > > > > However, UAC can also choose not to send any season refresh requests. > > > > Ideally the ReInvite sent by UAC should be processed as any ordinary > ReInvite. If the version number in the 'o' line in SDP did not change, the > UAS can effectively treat the ReInvite as a no-operation. > > There is *no* difference between reinvites triggered by session expiration > and other reinvites. They are all processed exactly the same way. The only > point of negotiating session timer is to ensure that a reinvite (or update) > will be sent. > > *Every* reinvite or update acts as a session timer refresh or a session timer > cancellation. > > > Not sure why the UAS is sending 408 in this case. Is the UAC sending BYE on > receipt of 408 for ReInvite? > > The 408 indicates that the UAS has no knowledge of the dialog. Normally a BYE > should have been sent in one direction or the other when terminating the > dialog. While it is possible that a BYE was sent and lost, it would then have > been retried several times. So it might be a sign of a bad network - lots of > loss. Or, it could be that the UAS rebooted and forgot its state. > > If none of those, then it points to bug in one end or the other: UAS could > have dropped dialog without sending BYE, or UAC could have a corrupted dialog > id. > > Thanks, > Paul > > > Regards > > Tarun Gupta > > > > On Wed, Jul 22, 2015 at 10:37 pm, NK <nitinkapo...@gmail.com> wrote: > > Dear All, > > > > I need your help to understand a logic behind the session expires. > > > > My doubt is. > > > > --> Invite have "session-expire" header in Invite (from UAC to UAS) > > --> UAS did not included "session-expire" header in 200 OK to the > > correspondence of initial invite. > > > > 1) So in this case what we should assume, they accepted the sent value > > or not? > > > > 2) If that UAS accepted the value we forwarded (1800 seconds) to them > > in invite, however they did not reply whereas in invite our switch > > sent the "refresher = uas" so in that case do our switch will send the > > re-invite to them before timer expires or there is no need to send > > re-invite for target refresh. > > > > > > --> In our case we sent the invite with session expire to vendor but > > --> vendor > > did not include any session expire value, and before time expire our > > switch sent the re-invite to them despite knowing the fact that we > > never received session expire in 200 OK from them (means there is no > > expiration is for this session), but vendor replied with sip 408. > > > > --> When we tried to explain them this problem they said we never > > --> agreed on > > session expire in 200 OK so BYE is not legal. > > > > Please help on this. Thank you in advance. > > > > Regards, > > Nitin Kapoor _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
