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
