GNOME Bugzilla – Bug 330778
BYE request is sent to the wrong address (opal bug?)
Last modified: 2006-02-11 18:26:46 UTC
When I'm being called and I hang up, the BYE request is sent to the wrong address. I'm attaching a debug trace. More details: + note the "Via: SIP/2.0/UDP 213.91.9.213:5060;branch=z9hG4bK-1400-4966A" in the INVITE + note the "From: <sip:0870230756@192.168.70.20;user=phone>;tag=00-01620-005a1aec-089196f82" + note that the BYE are sent to 192.168.70.20 (but should really be sent to 213.91.9.213) I quickly looked at opal and I believe this is an opal bug: + in SIPConnection::OnReleased(), we see that packets are sent using SendPDU(response, originalInvite->GetViaAddress(endpoint)) which is correct (it uses the via address + when we use ReleaseWithBYE, we create a SIP transaction and looking at SIPTransaction::Start(), I don't believe the packet is sent to the via address
Created attachment 59132 [details] Debug output
Actually, the BYE request should be sent to the address of the contact field in this case, as it is a request in a dialog. I have fixed the problem. The From and To addresses sent by your provider are weird. The To field SHOULD (not must) be set to the remote request uri. Similarly, it doesn't stop sending the second INVITE despite the 100 Trying has been sent to the correct place. Moreover, you receive the second INVITE because you have 2 different addresses registered with them 5063 and 5065. Probably you exited once without unregistering. However, as the first INVITE gave an answer (100 Trying), the second must not be sent. The bug you describe is fixed, but their configuration seems to be severely broken to me.
(In reply to comment #2) > Similarly, it doesn't stop sending the second INVITE despite the 100 Trying has > been sent to the correct place. Moreover, you receive the second INVITE because > you have 2 different addresses registered with them 5063 and 5065. Probably you > exited once without unregistering. Damien: AFAICT from the trace, the provider sends an INVITE to port 5063 and ekiga sends two Trying, one from port 5063 and one from port 5065. And then the second INVITE is received on port 5065. I don't know who's doing something wrong, but there's indeed something wrong.
I guess the trace is not complete and you already received an INVITE on port 5065 when the 100 Trying is sent.
Ah no, I'm wrong. This is the intended behavior, the first 100 Trying is sent from the endpoint context, the second one is sent from the connection context. When you receive the second INVITE, it is received in the dialog, and thus on port 5065 which was just created for the new connection. After that, you receive a reINVITE, in the same connection context. A 100 Trying is sent to the right place and the remote proxy is getting crazy and doesn't stop sending INVITE's. Sorry, but that is not a problem in OPAL.