[cisco-voip] SIP session timer in IOS gateway

Sat Sep 24 01:28:24 EDT 2016

Hmm makes sense, well I have been doing some microsoft integration and i
have seen that its not 100% correct when they say that they are compatible
with another device and also when they say they are following standards to
the DOT. The only inter-op that Microsoft 100% supports is only with S4B
and older Lync versions. :)

VCS is a B2B UA that cisco makes and supports fully supports Lync SIP
messaging , so that you dont have to bother with creating sip profiles and
modifying the timers for any other device. If your company budget allows ,
you could potentially route all calls to a VCS and then VCS will forward
them to all Cisco routers you might have and you wont face any SIP
messaging incompatibilities.

I am saying this as part of a company that just got acquired by Microsoft :)

-Ankur

On Sat, Sep 24, 2016 at 10:46 AM, Norton, Mike <mikenorton at pwsd76.ab.ca>
wrote:

> Sorry, I don't actually know what a VCS is.  Maybe it would work, I don't
> know.
>
> But there is not any "integration" to speak of. We replaced CUCM with Lync.
>
> We are using the ISRs for PSTN connectivity to Lync primarily because we
> already had one at most of our sites, because they are good, and because
> they are one of the gateways that Microsoft officially says Lync is
> supposedly-compatible with. ;-)
>
> -mn
>
> Sent from my Windows Phone
> ________________________________
> From: Ankur Srivastava
> Sent: 23/09/2016 9:58 PM
> To: Norton, Mike
> Cc: Brian Meade; voip puck
> Subject: Re: [cisco-voip] SIP session timer in IOS gateway
>
>
> Hi Mike,
>
> Just curious to know, why aren't you using a VCS for integration with
> Lync2013? You would be much better off with a VCS than a router with Lync.
> Any specific use case where VCS won't work?
>
> -Ankur
>
> On Sep 24, 2016 02:49, "Norton, Mike" <mikenorton at pwsd76.ab.ca<mailto:
> mikenorton at pwsd76.ab.ca>> wrote:
> Oh yeah, good call. The other side isn’t specifying a refresher choice
> when it sends INVITEs, so the RFC would permit me to force my own choice.
> From what I have seen so far though, the other side seems to have
> misbehaviours when it’s not the refresher. I’ll play with that some more.
>
> As for what the other side is... well, it’s a whole ‘nother ball of fun:
> Lync 2013. I miss CUCM + MGCP!!!
>
> -mn
>
>
> From: bmeade90 at gmail.com<mailto:bmeade90 at gmail.com> [mailto:
> bmeade90 at gmail.com<mailto:bmeade90 at gmail.com>] On Behalf Of Brian Meade
> Sent: September-23-16 3:09 PM
> To: Norton, Mike <mikenorton at pwsd76.ab.ca<mailto:mikenorton at pwsd76.ab.ca>>
> Cc: Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>>;
> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] SIP session timer in IOS gateway
>
> 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<
> mailto: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> [mailto:
> 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<mailto:mikenorton at pwsd76.ab.ca>>
> Cc: Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>>;
> cisco-voip at puck.nether.net<mailto: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<
> mailto: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<mailto:dpagan at fidelus.com>]
> Sent: September-23-16 2:23 PM
> To: Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>>; Norton,
> Mike <mikenorton at pwsd76.ab.ca<mailto:mikenorton at pwsd76.ab.ca>>;
> cisco-voip at puck.nether.net<mailto: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] On Behalf Of
> Daniel Pagan
> Sent: Friday, September 23, 2016 4:12 PM
> To: Norton, Mike <mikenorton at pwsd76.ab.ca<mailto:mikenorton at pwsd76.ab.ca>>;
> cisco-voip at puck.nether.net<mailto: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] On Behalf Of
> Norton, Mike
> Sent: Friday, September 23, 2016 4:01 PM
> To: cisco-voip at puck.nether.net<mailto: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<mailto:cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<mailto: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/20160924/caf85c56/attachment.html>