Moving sending/receiving functionality to a single point; terminology

[jrozhon]

Hi, I am new to the party, so please forgive me if I am ignorant of rules of any kind. As I am trying to use the library as a tool for VoIP testing, I would definitely welcome more debugging options. As a newcomer, the first thing that hit me was the fact that sending and receiving messages from/to socket is done on many places of the SIP.py file making any modification or logic addition complicated.

For now, I just opted to slight modification of the SIP.py and I added two helper functions that replaced self.out.sendto() and self.s.recv() calls in the file.

These are the functions that I use:

    def send_b(
            self,
            message: str,
            dst: str | None = None,
            dst_port: int | None = None
    ) -> None:
        """
        Send a message to the server. This is the replacement for recurrent
        self.out.sendto calls to allow to check on messages being sent out.
        """

        dst = dst or self.server
        dst_port = dst_port or self.port

        print(f"----> {dst}:{dst_port}")
        print(message, end="\n")

        self.out.sendto(
            message.encode("utf8"),
            (dst, dst_port)
        )

    def recv_b(self, buffsize: int = 8192) -> bytes:
        """
        Receive a message from the server. This is the replacement for recurrent
        self.s.recv calls to allow to check on messages being received.
        """

        raw, (addr, port) = self.s.recvfrom(buffsize)
        try:
            print(f"<---- {addr}:{port}")
            print(raw.decode('utf8'), end='\n')
        except Exception as ex:
            pass
        return raw

Do you think this is something that would make sense to incorporate into your code?

And one minor thing. As I come from telco world, the terminology used in the code is confusing for me. In SIP, message can be either Request(Method) or Response. In the code it is used almost interchangeably making it a bit harder for a newcomer such as myself to orient.

I am ready to help with any of this, or anything else for that matter, but I am just a leisure time programmer so I need a bit of guidance.

Thank you for your work and wonderful library you created. J

[tayler6000]

Thanks for your comment!

Migrating send and receive to a single point is something that is being worked on in the feature/Add-TLS branch and it's actually going to encompass UDP, TCP, and TLS as well. So please hang tight for that to be implemented in full as I don't have a current timeline for 2.0.0 to be released.

As for the terminology, I apologize for that. The inconsistency may come from me not coming from the telecom world, or via other contributors, I'm not completely sure. When I made pyVoIP it was because I wanted to be able to interface with my new Asterisk server in Python, as I have always been a fan of the scene in the Iron Man movie where Tony Stark calls and leaves a message on his suite across the U.S. via a pay phone. So when pyVoIP was released and published it filled exactly the needs for that and nothing else. This is why people have experienced problems with other PBXs (which I hope are fixed now that #74 is closed). I found myself unable to use any existing VoIP library because it had different C dependencies that were either incompatible with Windows or were just annoying, which is why pyVoIP is pure Python, and always will be.

Anyways, needless to say, I was not from the telecom world and essentially all of my knowledge comes from me reading parts of relevant RFCs or mimicking packet captures of commercial/working products. (Though I'd like to think my knowledge of VoIP/SIP/RTP has grown since.) My plan for pyVoIP 2.0.0 is to truly go through all the RFCs and make pyVoIP to be 100% RFC compliant, at least for the initial RFCs for now, and I can implement features from RFC updates in subsequent releases (2.1.0, 2.2.0, etc).

Hope this helps explain why you see some of the mess you do, and hopefully, it'll be nice and pretty in 2.0.0.

[jrozhon]

Thank you for you reply. I wouldn't let myself call this library a mess, it has already proved its value as I have struggled with pjsua, liblinphone, and sipsimple and others with little to no usable results for days and this gem let me get going in hours and without segfaulting :-D, so on contrary this is really good.

My point was simply for you to consider this aspect of the library and possibly offer a view of a non-programmer as this was the only real obstacle to me.

Anyway, thanks a lot for this library, looking forward to 2.0.0 and if I can help you with anything, just let me know. J

[tayler6000]

I've hopefully fixed most of the inconsistency between the terms SIP Message SIP Request and SIP Response in the commit 8922a62 of the feature/Add-TLS branch. I am currently working on centralizing all SIP messaging to go through the sock.py file of the same branch, which will hopefully be merged into development here soon. With it, I cautiously expect 2.0.0 to be released shortly after, or at least an alpha version to PyPI for easy distribution.

Thank you for your words and your willingness to help, they both mean a lot to me.