Multiple Via Headers in SIP messages
I am once again dealing with yet another so-called major carrier that when they cannot determine a reason for a call failure they blame the fact that our SIP signaling has two Via Headers.
However, it is my understanding from RFC 3261, that multiple Via headers are allowed and should not even be a factor for those carriers that are terminating our SIP calls.
For example:
Section 8.2.6.2 states, “The Via header field values in the response MUST equal the Via header field values in the request and MUST maintain the same ordering.”
A quick google found a response on the SIP Implementors list from Vivek Srivastava, who stated:
UAS should calculate the response destination from the top via header but should not remove that top via header. When the response reaches at Proxy(because this proxy’s via was on top), Proxy will remove the top via(which was added by the same proxy) and forward the response back based on the new top via.
…which makes complete sense, based on my understanding of RFC 3261.
Has anyone else experienced this complete lack of SIP compliance by ‘major’ telephone carriers?
|
Related Posts:
Vonage Users Vulnerable to VoIP Identity Theft
OpenSER Code Hack: Calling Stored Procedures
Mr. Wizard Passes Away at 89
Lance LittleJohn, Pipeline Telecom Needs to Find a Clue
How to Configure OpenSER: SIP Registar, SIP Proxy and Far-End NAT Traversal for Media
I have been told by L3 that their equipment cannot deal with Multiple Via headers - are you using L3?
Mike: Stating that makes me wonder if this company that we are working with has been blatantly lying about how they are dealing with our calls.
However, we have been using this one carrier for many months now, without even so much as considering changing anything on our end - so all along they have been dealing with the two Via headers without any issue, until today……..
Really terrible. Of course, the existence of various VIA headers is essential if the message goes throught various SIP proxies or does a loop in a proxy (so two VIA with same IP but different “branch” will be added).
Really sad if a carrier tries to justify its failures with this argument.
They are confused, and here is why. RFC 3261 says:
[quote]
8.1.3.3 Vias
If more than one Via header field value is present in a response, the
UAC SHOULD discard the message.
The presence of additional Via header field values that precede
the originator of the request suggests that the message was
misrouted or possibly corrupted.
[/quote]
That probably led to the confusion - at least it confused me. It only deals with *responses*, not with *requests*, and says that only the *UAC* (user agent client, the originator of the request that caused the response, which is not neccessarily a user agent) should drop the message, not any proxies in between.
UAC adds Via1
Proxy adds Via2
Proxy adds Via3
SIP arrives at destination, sends a response the same way back
Proxy removes Via3 from response
Proxy removes Via2 from response
UAC should see exactly one Via: Via1, pointing to itself
If a response with more than one Via arrives back at the UAC, something is amiss, and the message should be dropped.
Maybe, if you explain it to them in this way they accept that they indeed have to proxy/route SIP with more than 1 Via-Header, since it’s up to the originator of the request (you) to validate that rule.