I’m having an issue with an Oracle SBC and SIP session timers: calls lasting for more than 900 seconds are cut, when shorter ones are working OK.
When sending a call to an Oracle SBC, I must add a custom SIP header in outbound INVITE.
When the call is established and it session timer expires, Asterisk sends a new INVITE.
In my tests (with Asterisk 15.7.3), I observed that:
- custom headers that were present in the first oubound INVITE are not present anymore in the re-INVITE
- but the second INVITE includes a Call-ID header with a value exactly matching the one the first INVITE.
From RFC4028, it seems to me, this Call-ID is enough for a UAS to maintain an ongoing call.
What is your opinion about this ?
Do you think custom headers need to be included in re-INVITEs for refreshing a session state ?
Custom headers are, by definition, not standardised. The SBC can insist on them wherever it wants, but insisting on them anywhere will mean that they will seriously reduce what can interwork with the SBC.
Are you sure this is really custom, and not an unusual standard header. In the latter case, ir you tell us what it is, it might turn out that it is supported, with the right choice of options, by Asterisk.
You also need from tag and to tag, to uniquely identify a session.
The SBC I’m having the issue with, seats between an Asterisk box and a Microsoft Teams instance as in:
PSTN ---- Asterisk ---- SBC ---- Teams
As this SBC is configured, it requires for establishing a call, a customer name (for both billing and routing purpose) to be sent by Asterisk as a value in a custom so-called Teams header.
This Teams header is “hand-crafted” in Asterisk’s dialplan.
I really don’t how I could add this custom header in re-INVITE during session refreshing.
For me, two alternatives:
A- either the SBC should be able to maintain ongoing calls, just looking at Call-IDs, without requiring what was needed to establish the call,
B- either Asterisk should save headers for reuse in re-INVITE, hopefully, without requiring sys-admin to dig too deep in Asterisk programming to implement this.
Replying to your mention about To and From headers:
- From header value in first re-INVITE exactly matches the one in initial INVITE
- To header value in first re-INVITE does not exactly match the one in initial INVITE: it add the “;tag=123…” present in initial 200OK response.
Which channel driver are you using? At the moment, the only legitimate reason I can think of for requiring a custom header on Re-INVITEs is if the Contact header on the 200 OK included them, and chan_pjsip is more likely to handle Contact well.
Does the ACK to the original 200 OK include the custom header, because the only technical reason I can think for having it is that the SBC is a stateless proxy, but if the ACK goes through it, a stateless proxy wouldn’t know how to route that ACK.
Most likely, the SBC implementer wasn’t thinking clearly. However, if that is Microsoft, then market domination rules apply, and it becomes impossible to do anything wrong, as what you do becomes the de facto standard.
I should have stated I met this using PJSIP.
Re-phrasing my original question:
"From previous experience, would you say that for session timers to successfully work:
- It’s up to UAC to craft re-INVITEs repeating all needed custom headers if such exist
- It’s up to UAS to recover these needed custom headers from original INVITE at the moment re-INVITEs clearly reference this original INVITE"
My feeling is that case 2 applies but I’ve not found written evidences of 1 or 2 in RFC4028.
Session timers assume there is a session, which has all the necessary state between the refreshes, and there is no reason why anything other than the refresher, timer, and time limits should change.
Of course that doesn’t necessarily apply to custom headers, as the RFCs say nothing about their meaning.
I’d say that you are up against either lazy implementation that goes through the motions of dealing with authentication for re-INVITEs, but has no need to, or you have a partially stateless proxy that is being misused. With a stateless proxy, the Contact header on the 200 OK should bypass the proxy, or at least provide extra header parameters to maintain the routing through the proxy. The Contact header also applies to ACK, which is why I’m suggesting that the proxy could only be partially stateless, as it still needs to remember where to send the ACK.
Do you also have problems with BYEs, as they would get rejected by the proxy.
Are you getting your refreshes rejected by the proxy or by the end system?
Is the proxy from Microsoft? (In that case, as noted before market dominance probably trumps any RFC.)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.