Hadriel Kaplan
changed
bug 9021
| What |
Removed |
Added |
| Status |
UNCONFIRMED
|
CONFIRMED
|
| Ever confirmed |
|
1
|
Comment # 6
on bug 9021
from Hadriel Kaplan
(In reply to comment #5)
> The RTP setup mechanism was changed some time ago to need both the offer and
> the answer to set up the conversation to overcom bugs with the previous way
> things where done.
Yes, the setup part was changed inr47564. I don't know why/what changed the
UDP dissector creating its own conversations though, and that causes more
problems even just with normal early media, let alone the latching cases.
> I don't think we can handle the latching case (easily) in
> wireshark, that's normaly used to handle NAT e.g the UE IP port combination
> is not seen in the SIP signaling as the UE is behind NAT and the signaling
> contains the private addresses.
Yup, but the UE sends to the real address:port indicated in SDP - the SDP the
UE received; it's just that the other/latching side sends to a different
address:port (the NAT'ed address). So the UDP packets from the UE should at
least be decoded as RTP, because they do match one of the SDP's. They don't
get decoded as RTP though, if they're sent before the 200 OK w/SDP, because the
UDP dissector changed in 1.10 to create a new conversation for all packets - a
non-wildcarded conversation. So by the time the 200 OK with SDP answer gets
processed it's too late, for even that one RTP stream.
That change to UDP's conversation behavior also broke the latching case for the
RTP coming the other direction, from the public/latching device to the UE
through the NAT. Because if UDP didn't create the conversation, then the
packets would have matched the wildcard entry for the RTP stream coming back,
since a latching device always sends its RTP using the same source addr:port as
it advertises wanting to get them on in SDP.
In other words, SDP said this:
SDP from UE: receive on addr:port A
SDP from latching device: receive on addr:port B
The UE then sends packets of C -> B
The latching device sends B -> C
Previously, both of those (C->B, B->C) flows would have matched the wildcard
entry created by the SDP from the latching device, because wildcard entries
don't care about direction - they both would have matched (B->*, *->B).
So in summary: currently if the UE behind a NAT receives an INVITE w/SDP and
sends RTP immediately to the SDP's address, wireshark won't properly decode it
ever. If the UE either waits in sending RTP, or if the UE was the one sending
the INVITE w/SDP, then it will work.
You are receiving this mail because:
- You are watching all bug changes.
