Dear All, Thanks à lot for helping me on this!!
Regards, Nitin On 13:00, Wed, Jul 22, 2015 Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > On 7/22/15 3:12 PM, Brett Tate wrote: > > 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. > > Oh, duh. When I wrote my response I was thinking of 481, not 408. Sorry. > > Thanks, > Paul > > >> -----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 > > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
