Search code examples
sip

Injecting a BYE into dialog to hangup UAC


I am experimenting with forcing a phone to hang-up while a call is still active. I have setup phone 111 to call phone 222 through a PBX. On the PBX I extracted the two and from lines from the invite (including tags), and the Call-Id, and the IP's and ports in use.

Since the communications are using UDP, I simply sent a BYE message I fabricated using the matching TO/FROM/CALL-ID lines to the phone (from a program running on the PBX). Since I wasn't sure of the CSeq number, I used the max unsigned int value. Since the RFC's say the UAC should accept a message if the CSeq is not sequential but is higher than the last, it should be accepted.

So I tried sending the following UDP datagram to the phone but it did not hangup. Can someone explain why not - and what I would need to modify to make it work?

BYE sip:[email protected]:5060 SIP/2.0
To: "Phone x111" <sip:[email protected]>;tag=r1j.i3
From: "Phone x222" <sip:[email protected];user=phone>;tag=efbedc0a-cc6f-4163-b51b-84840ae16313
Call-ID: [email protected]
CSeq: 4294967295 BYE
Max-Forwards: 70
User-Agent: Test-Agent
Reason: Q.850;cause=41;text="Test Agent Clearing"
Content-Length: 0

The end of each line contains CRLF, and the message has 1 blank line at the end (including CRLF). I send the datagram to the phones' address and port used in the invite, and from the local address in use for the dialog, but not from the same local UDP port (since it's in use) - in case that matters. From what I read the BYE message should be end to end (not appear to come from the PBX).

Please note that this is experimental (I know I could setup a proxy to this in a "better" way).


Solution

  • Your SIP message is missing a mandatory Via header. The message is invalid and can't be answered and thus, cannot end the call.

    As a side note, there will be many other reasons that may prevent the message from being received:

    • NAT may block the UDP message (depend on the implementation of the NAT)
    • the client UDP socket may be bound (using bind) to only the server IP:PORT. UDP message may be dropped.
    • using TCP will not be doable for similar bind and NAT reasons.
    • client may have a policy to reject any message not coming from the exact IP:PORT of the server.