Årsak: Når videosamtaler kobles fra etter nøyaktig 15 minutter, er det som regel fordi TCP-tidsavbruddet som er konfigurert på nettverket (brannmur/rutere), er kortere enn utløpstiden for SIP-økten. Som standard i CallManager er utløpstiden for SIP-økt satt til 1800 sekunder.

Løsning:

Slik verifiserer du dette:

1. Åpne Cisco Unified Communications Manager-administrasjon (CM).

2. Klikk på System > Tjenesteparametere.
3. Under Velg server og tjeneste i Tjeneste-rullegardinlisten, velger du Cisco Call Manager (Aktiv):

4. Se etter Tidtaker for utløp av SIP-økt:

Alle enhetene som er registrert på CUCM, bruker denne tidtakeren. Når enheten er i en samtale med en annen ekstern enhet, må en av partene oppdatere økten og sende en ny INVITASJON eller OPPDATERING. Denne oppdateringen må sendes før halvparten av økten utløper (1800/2 = 900 sekunder = 15 minutter). Hvis det ikke mottas en oppdateringsmelding, kobles samtalen fra.

Se etter tidtaker for økt i den første INVITASJONEN. En oppdatering (INVITASJON/OPPDATERING) bør mottas før denne tiden utløper:


Basert på den innledende forhandlingen for brukeragentklient/brukeragentserver (UAC/UAS), vil en av enhetene oppdatere økten når den sender en ny INVITASJON. Hvis oppdateringen er UAC, er initiativtakeren til samtalen ansvarlig for å oppdatere økten. Hvis oppdateringen er UAS, må serveren oppdatere økten. Samle SIP-feilsøkingsloggene fra begge endepunktene, og kontroller disse elementene:

Eksempel: Samtale gjort fra part A til CUCM til part B. Hvis oppdateringen er UAC på part A og UAS på part B:

1.     Part A må sende en ny INVITASJON/OPPDATERING til CUCM.
2.     CUCM må sende en ny INVITASJON/OPPDATERING til part B.
3.     Part B mottar en ny INVITASJON og svarer på den meldingen med 200 OK.
4.     CUCM må sende 200 OK til part A.

Hvis en enhet sender en ny INVITASJONSMELDING til CUCM, sender CUCM en ny INVITASJON til den andre parten. Hvis dette derimot ikke mottas av den eksterne siden, kan det være på grunn av mellomliggende nettverksenheter. Det er høyst mulig at den nye INVITASJONEN/responsen ikke kommer til en av sidene på grunn av SIP-inspeksjon eller nettverksinnstillinger.
Hvis enhetene ikke starter INVITASJONEN på nytt, kan det være et problem med enheten. Involver Cisco Technical Assistance Center (TAC) for å undersøke nærmere.
 
På listen over ting du kan prøve [hvis du ikke har gjort det allerede] i det avanserte konfigurasjonsområdet i sonen som går til Webex:
Still SIP UDP/IX-filtermodusen til på [ikke standard]:

Sjekk i tillegg tidtakerne for SIP-økter på VCS-e.
 
Vår standard er 1800s [15 min]. Dette er standard, og du må sørge for at TCP-tidtakeren på brannmuren din også samsvarer her, men du kan stille den litt opp for å se om det også har en effekt på VCS.

Dette gjøres under Konfigurasjon > Protokoller > SIP:


Legg merke til at oppdateringsintervallet for økten (sekunder) er satt til standardverdien. Du kan prøve 3600. Men den faktiske roten til problemet her er når FW tror at en økt ikke lenger er i bruk [tilfelle 1], når VCS faktisk synes det er ok, og at økten fortsatt er i gang, men ikke mottar en FIN/lukking for gjeldende økt/port, og derfor prøver å bruke den på nytt, hvorpå samtalen avbrytes. I tilfelle 2 lukker FW tilkoblingen på riktig måte og sender en FIN/lukking, VCS registrerer et normalt samtaleavbrudd/fjerning, og samtalen avbrytes. Ved å endre tidtakeren for økten her, vil du kun styre når VCS stopper en økt, når den ikke har mottatt bekreftelser på forsøk på kommunikasjon om samtalestatusen.
 
Det kan derimot hjelpe oss å finne problemet litt lettere. Det kan også være at vi må senke denne verdien, avhengig av FW-innstillingen for denne tidtakeren.