[cisco-voip] SIP session timer in IOS gateway

[Brian Meade]

Your other option is trying to force CUBE to be the refresher but your
other side may not support it and you get some glare conditions.

I don't think I've ever seen a SIP stack that didn't refresh at half the
interval.  What's the other vendor/device?

On Fri, Sep 23, 2016 at 4:54 PM, Norton, Mike <mikenorton at pwsd76.ab.ca>
wrote:

> Hmm, good idea. But oh man, what a hack that would be. I might play around
> with this on my desk but not sure I’d feel comfortable with it in
> production. I’ll have to ponder if there could be weird edge cases when the
> timers get restarted by hold/resume, caller ID updates, etc.
>
>
>
> At the rate I’m going, eventually I’ll have so much SIP header hacking
> that I might as well have just written my own SIP stack! Some of the SIP
> interop baloney I’m encountering makes FXO disconnect signaling look like a
> rock-solid worldwide standard in comparison! And this is with SIP on only
> one side of my gateways. I guess the fun is really going to start when we
> replace the PRIs with SIP trunks. Arrrrrrrrrrrgggggh.
>
>
>
> -mn
>
>
>
> *From:* bmeade90 at gmail.com [mailto:bmeade90 at gmail.com] *On Behalf Of *Brian
> Meade
> *Sent:* September-23-16 2:38 PM
> *To:* Norton, Mike <mikenorton at pwsd76.ab.ca>
> *Cc:* Daniel Pagan <dpagan at fidelus.com>; cisco-voip at puck.nether.net
>
> *Subject:* Re: [cisco-voip] SIP session timer in IOS gateway
>
>
>
> Maybe an outbound sip-profile to modify the Session-Expires header to
> advertise to the other side a smaller SE value while CUBE still thinks it
> has 1800 seconds to wait?
>
>
>
> I don't think the CUBE would change it's internal timer based on adjusting
> the SIP header via sip-profiles.
>
>
>
> On Fri, Sep 23, 2016 at 4:30 PM, Norton, Mike <mikenorton at pwsd76.ab.ca>
> wrote:
>
> No that’s not the problem. The length of the SE timer isn’t what I’m
> talking about.
>
>
>
> (BTW it is possible to adjust the SE. They added that as an additional
> parameter to the “min-se” command in 15.something.)
>
>
>
> In my case I’m using 1800 and that is getting negotiated successfully. If
> I use something else, that also gets negotiated successfully. Cranking up
> the min-se causes the proper 422 response and second INVITE attempt, etc.
> Everything is occurring exactly as the RFC says it should. But the RFC is
> too vague!
>
>
>
> For example, with SE=1800, the IOS gateway sends the BYE “slightly before”
> 1800 seconds, around 1665 seconds - which is perfectly valid according to
> the RFC. The other side is doing the refreshes. It does the refresh
> “before” 1800 seconds, around 1688 seconds - which is perfectly valid
> according to the RFC (halfway, i.e. 900, is recommended but not required;
> the only requirement is “before” 1800).
>
>
>
> My problem is that IOS’s “slightly before” occurs around 1665 seconds and
> the other side’s “before” occurs around 1688 seconds. Neither side is in
> the wrong but the RFC has a stupid hole here. I need IOS to wait until
> closer to 1800.
>
>
>
> -mn
>
>
>
>
>
> *From:* Daniel Pagan [mailto:dpagan at fidelus.com]
> *Sent:* September-23-16 2:23 PM
> *To:* Daniel Pagan <dpagan at fidelus.com>; Norton, Mike <
> mikenorton at pwsd76.ab.ca>; cisco-voip at puck.nether.net
> *Subject:* RE: SIP session timer in IOS gateway
>
>
>
> I should be more specific… the min-SE specifies the minimum value the UAS
> is willing to accept from the Session-Expires header sent by the UAC. If
> your INVITE has an SE if 1800, and the incoming dial-peer has a min-SE of
> 3600, then CUBE will reply back to the UAC with a 422 final response - this
> 422 will contain its own min-SE header with value of 3600. The UAC should
> ACK the 422 and **should** follow-up with another INVITE where the
> Session-Expires timer value is 3600. This is one way to force CUBE to
> manipulate the incoming SE. I felt my previous explanation was missing some
> information and might have been a bit too vague.
>
>
>
> “If the response to a session refresh request is a 422 (Session Interval Too Small) response message, then the UAC MAY retry the request.”
>
>
>
> CUCM, if it’s the UAC, will retry the INVITE. I can’t speak to other call-agents though. But I still suggest, if possible, to address the main problem of your session expiration.
>
>
>
> Hope this helps.
>
>
>
> - Dan
>
>
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net
> <cisco-voip-bounces at puck.nether.net>] *On Behalf Of *Daniel Pagan
> *Sent:* Friday, September 23, 2016 4:12 PM
> *To:* Norton, Mike <mikenorton at pwsd76.ab.ca>; cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] SIP session timer in IOS gateway
>
>
>
> Adjusting the SE on standard CUBE is not possible from what I’ve
> experienced and tested. One way around it though is to set your Min-SE
> timer on the incoming dial-peer on CUBE. The UAC sending the INVITE will
> receive a 422 response back, from CUBE, and will include an updated min-se
> timer. The new min-SE value in the 422 will then be copied, by the UAC,
> into the Session-Expires header within a second INVITE. The question I feel
> I should ask though… is why try manipulating the SE/minSE timers to get
> around a failed session refresh instead of addressing the session refresh
> itself? Of course this is only masking another problem.
>
>
>
> --------end attach---------
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net
> <cisco-voip-bounces at puck.nether.net>] *On Behalf Of *Norton, Mike
> *Sent:* Friday, September 23, 2016 4:01 PM
> *To:* cisco-voip at puck.nether.net
> *Subject:* [cisco-voip] SIP session timer in IOS gateway
>
>
>
> I’d like to adjust IOS’s behavior around the SIP session-expires timer.
> Wondering if anybody knows if the command I need exists...
>
>
>
> According to RFC 4028:
>
>
>
> “If the side not performing refreshes does not receive a session refresh
> request before the session expiration, it SHOULD send a BYE to terminate
> the session, slightly before the session expiration.”
>
>
>
> My problem stems from the fact that “slightly before” is left open to the
> imagination. The RFC “recommends” not more than 32 seconds but does not
> have any specific “requirement.” The default behaviour of IOS seems to use
> a longer value. I.e., it sends the BYE a little too prematurely for my
> situation. I need IOS to let the timer get closer to expiring before it
> issues the BYE.
>
>
>
> I know it’s a long-shot, but someone please tell me there is a command for
> adjusting this! Not finding anything in the docs. Hoping to avoid having to
> disable the session timer or crank it up to 11. I love SIP interop, it’s so
> much fun! :-(
>
>
>
> -mn
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160923/6ee067d8/attachment.html>