search

sipsorcery-org / sipsorcery

A WebRTC, SIP and VoIP library for C# and .NET. Designed for real-time communications apps.
https://sipsorcery-org.github.io/sipsorcery
Other
1.48k stars 442 forks source link

Can not hang up on remote call #312

Closed FabulousGee closed 4 years ago

FabulousGee commented 4 years ago

Hey there,

not sure if it's a bug lately or if I am just using a component wrong. I hope somebody else can verify this. Anyway, when I use the code below and I get an incomging call, I can not hang up anymore. There is just silence on the remote caller's phone instead.

Steps to reproduce: 1.) Start program below 2.) Call local program from remote phone 3.) Hang up in local program 4.) Enjoy endless silence on remote phone

using System;
using System.Net;
using System.Threading;
using System.Threading.Tasks;
using SIPSorcery.Media;
using SIPSorcery.SIP;
using SIPSorcery.SIP.App;
using SIPSorceryMedia.Windows;

    public class SoftPhone : PhoneInterface
    {
        private static SIPTransport _sipTransport;
        private static SIPUserAgent _userAgent;
        private static SIPServerUserAgent _serverUserAgent;
        private static VoIPMediaSession _voipMediaSession;

        private static PhoneInterface.Callback _callback;

        public void Init(PhoneInterface.Callback callback)
        {
            _callback = callback;
            _sipTransport = new SIPTransport();
            _sipTransport.AddSIPChannel(new SIPUDPChannel(new IPEndPoint(IPAddress.Any, 5060)));

            var windowsAudio = new WindowsAudioEndPoint(new AudioEncoder());
            _voipMediaSession = new VoIPMediaSession(windowsAudio.ToMediaEndPoints()) {AcceptRtpFromAny = true};

            _userAgent = new SIPUserAgent(_sipTransport, null);
            _userAgent.ClientCallFailed += onClientCallFailed;
            _userAgent.OnCallHungup += onCallHungup;
            _userAgent.OnIncomingCall += async (ua, req) =>
            {
                _serverUserAgent = _userAgent.AcceptCall(req);
                _callback(PhoneInterface.Type.CallIncoming, true, $"Incoming call from {req.RemoteSIPEndPoint}.");
            };

            register();
        }

        private async void register()
        {
            var regUserAgent = new SIPRegistrationUserAgent(_sipTransport, Config.SIPUsername, Config.SIPPassword, Config.SIPHost, Config.getSIPExpiry());

            regUserAgent.RegistrationFailed += (uri, err) => Console.WriteLine($"{uri.ToString()}: {err}");
            regUserAgent.RegistrationTemporaryFailure += (uri, msg) => Console.WriteLine($"{uri.ToString()}: {msg}");
            regUserAgent.RegistrationRemoved += (uri) => Console.WriteLine($"{uri.ToString()} registration failed.");
            regUserAgent.RegistrationSuccessful += (uri) => Console.WriteLine($"{uri.ToString()} registration succeeded.");

            regUserAgent.Start();
        }

        private void onClientCallFailed(ISIPClientUserAgent uac, string error, SIPResponse sipResponse)
        {
            Console.WriteLine($"Call failed {error}");
            _callback(PhoneInterface.Type.CallFailed, false, error);
        }

        private void onCallHungup(SIPDialogue dialogue)
        {
            _callback(PhoneInterface.Type.CallHungup, false, null);
        }

        public async void AcceptCall()
        {
            await _userAgent.Answer(_serverUserAgent, _voipMediaSession);
            _callback(PhoneInterface.Type.CallAccepted, true, null);
        }

        public void Questions(QuestionsType qt)
        {
            throw new System.NotImplementedException();
        }

        public async void StartCall()
        {
            // Place the call and wait for the result.
            var callTask = _userAgent.Call(Config.SIPCallDestination, null, null, _voipMediaSession);

            bool callResult = await callTask;

            if (callResult)
            {
                Console.WriteLine("Call succeeded.");
                _callback(PhoneInterface.Type.CallStarted, true, null);
            }
            else
            {
                Console.WriteLine("Call failed.");
                _callback(PhoneInterface.Type.CallStarted, false, null);
            }
        }

        public void OutgoingHangUp()
        {
            cancelCall();
        }

        public void IncomingHangUp()
        {
            cancelCall();
        }

        private async void cancelCall()
        {
            if (_userAgent != null)
            {
                if (_userAgent.IsCalling || _userAgent.IsRinging)
                {
                    Console.WriteLine("Cancelling in progress call.");
                    _userAgent.Cancel();

                    _exitCts.Cancel();
                }
                else if (_userAgent.IsCallActive)
                {
                    Console.WriteLine("Hanging up established call.");
                    _userAgent.Hangup();
                }
            };
        }

        public async void Shutdown()
        {
            Console.WriteLine("Exiting...");

            if(_userAgent?.IsHangingUp == true)
            {
                Console.WriteLine("Waiting 1s for the call hangup or cancel to complete...");
                await Task.Delay(1000);
            }

            // Clean up
            _sipTransport.Shutdown();
        }
    }
sipsorcery commented 4 years ago

Problems like this often occur if the Contact header is set incorrectly due to NAT. That can prevent subsequent SIP requests, such as the BYE for a hangup getting through.

Can you use Wireshark to catch the SIP traffic when the problem occurs?

FabulousGee commented 4 years ago

I honestly don't know why this is always happening but as soon as I posted this issue, I found the fault after hours of looking into this.

It seems like the CancellationToken is the issue on my side. It seems to be waiting forever at "_exitCts.Token.WaitHandle.WaitOne();". I guess I have some error in my design. Will further investigate but when I commented it out, the call got canceled properly...

I will reopen if necessary.

FabulousGee commented 4 years ago

So, I came one step further. The issue persists on incoming calls. I can not hang up on them. Weirdly, I can hang up on outgoing calls without any issues. Remote client is the same in both scenarios.

This is what I logged on outgoing call BYE. There is an OK coming back on this one and the call is stopped like it should.

Request sent: udp:192.168.1.54:5060->udp:192.168.1.1:5060
BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.54:5060;branch=z9hG4bK5c2feae1551e4c37a78716d32b07533a;rport
To: <sip:**623@fritz.box:5060>;tag=81FB1391B941AAA3
From: <sip:SIP-SILS@fritz.box>;tag=AWWWSUBKFI
Call-ID: 99123ac4701a4a678198c7739e443d4f
CSeq: 3 BYE
Max-Forwards: 70
Content-Length: 0

When I accept the incoming call and hang up again, it seems like some kind of time out - there is no answer coming.

Request retransmit 8 for request BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0, initial transmit 19,815s ago.
Request sent: udp:192.168.1.54:5060->udp:192.168.1.1:5060
BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.54:5060;branch=z9hG4bK5a505450974a443db1f28c96501c965d;rport
To: "Name" <sip:**621@fritz.box>;tag=7E7E2EE54B901BEB
From: <sip:192.168.1.54:5060>;tag=DISWMOKGNE
Call-ID: 6173EB9B0BDF2CCD@192.168.1.1
CSeq: 5 BYE
Max-Forwards: 70
Content-Length: 0

A full call from remote to local with answering and then hanging up local in the end:

sip:SIP@fritz.box registration succeeded.
Request received: udp:192.168.1.54:5060<-udp:192.168.1.1:5060
INVITE sip:192.168.1.54:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK70B5D539D3B9ECBA
To: <sip:192.168.1.54:5060>
From: "Name" <sip:**621@fritz.box>;tag=011E73AEB05365D5
Call-ID: D895CB61C1792B34@192.168.1.1
CSeq: 8 INVITE
Contact: <sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1>
Max-Forwards: 70
User-Agent: AVM FRITZ!Box 6490 Cable (kdg) 141.07.12 TAL (Sep 11 2019)
Expires: 120
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Supported: 100rel,replaces,timer
Content-Length: 196
Content-Type: application/sdp
P-Called-Party-ID: <sip:**9@fritz.box>
Session-Expires: 600;refresher=uac
Min-SE: 90
Allow-Events: telephone-event,refer

v=0
o=user 10732979 10732979 IN IP4 192.168.1.1
s=call
c=IN IP4 192.168.1.1
t=0 0
m=audio 7078 RTP/AVP 9 8 0 101
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtcp:7079

Response sent: udp:192.168.1.54:5060->udp:192.168.1.1:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK70B5D539D3B9ECBA;received=192.168.1.1;rport=5060
To: <sip:192.168.1.54:5060>
From: "Name" <sip:**621@fritz.box>;tag=011E73AEB05365D5
Call-ID: D895CB61C1792B34@192.168.1.1
CSeq: 8 INVITE
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE
Content-Length: 0

Response sent: udp:192.168.1.54:5060->udp:192.168.1.1:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK70B5D539D3B9ECBA;received=192.168.1.1;rport=5060
To: <sip:192.168.1.54:5060>;tag=MSAXXCPRGA
From: "Name" <sip:**621@fritz.box>;tag=011E73AEB05365D5
Call-ID: D895CB61C1792B34@192.168.1.1
CSeq: 8 INVITE
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE
Require: replaces, norefersub, 100rel
Content-Length: 0
RSeq: 669791670

Request received: udp:192.168.1.54:5060<-udp:192.168.1.1:5060
PRACK sip:192.168.1.54:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bKA17ABD5737712648
To: <sip:192.168.1.54:5060>;tag=MSAXXCPRGA
From: "Name" <sip:**621@fritz.box>;tag=011E73AEB05365D5
Call-ID: D895CB61C1792B34@192.168.1.1
CSeq: 9 PRACK
Max-Forwards: 70
User-Agent: AVM FRITZ!Box 6490 Cable (kdg) 141.07.12 TAL (Sep 11 2019)
Content-Length: 0
RAck: 669791670 8 INVITE

Response sent: udp:192.168.1.54:5060->udp:192.168.1.1:5060
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bKA17ABD5737712648;received=192.168.1.1;rport=5060
To: <sip:192.168.1.54:5060>;tag=MSAXXCPRGA
From: "Name" <sip:**621@fritz.box>;tag=011E73AEB05365D5
Call-ID: D895CB61C1792B34@192.168.1.1
CSeq: 9 PRACK
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE
Content-Length: 0

Response sent: udp:192.168.1.54:5060->udp:192.168.1.1:5060
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK70B5D539D3B9ECBA;received=192.168.1.1;rport=5060
To: <sip:192.168.1.54:5060>;tag=MSAXXCPRGA
From: "Name" <sip:**621@fritz.box>;tag=011E73AEB05365D5
Call-ID: D895CB61C1792B34@192.168.1.1
CSeq: 8 INVITE
Contact: <sip:192.168.1.54:5060>
Server: sipsorcery_v4.0.77.0
Supported: replaces, norefersub, 100rel
Content-Length: 238
Content-Type: application/sdp

v=0
o=- 1862889552 0 IN IP4 127.0.0.1
s=-
c=IN IP4 192.168.1.54
t=0 0
m=audio 54636 RTP/AVP 9 8 0 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

Request received: udp:192.168.1.54:5060<-udp:192.168.1.1:5060
ACK sip:192.168.1.54:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK3AE4B93FC56CEAAB
To: <sip:192.168.1.54:5060>;tag=MSAXXCPRGA
From: "Name" <sip:**621@fritz.box>;tag=011E73AEB05365D5
Call-ID: D895CB61C1792B34@192.168.1.1
CSeq: 8 ACK
Contact: <sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1>
Max-Forwards: 70
User-Agent: AVM FRITZ!Box 6490 Cable (kdg) 141.07.12 TAL (Sep 11 2019)
Content-Length: 0

AttentionSeeker has been canceled by token.
Hanging up established call.
Request sent: udp:192.168.1.54:5060->udp:192.168.1.1:5060
BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.54:5060;branch=z9hG4bK23a7a9be8b384f83b1887ea8c3ea43dc;rport
To: "Name" <sip:**621@fritz.box>;tag=011E73AEB05365D5
From: <sip:192.168.1.54:5060>;tag=MSAXXCPRGA
Call-ID: D895CB61C1792B34@192.168.1.1
CSeq: 9 BYE
Max-Forwards: 70
Content-Length: 0

Request retransmit 2 for request BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0, initial transmit 0,501s ago.
Request sent: udp:192.168.1.54:5060->udp:192.168.1.1:5060
BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.54:5060;branch=z9hG4bK23a7a9be8b384f83b1887ea8c3ea43dc;rport
To: "Name" <sip:**621@fritz.box>;tag=011E73AEB05365D5
From: <sip:192.168.1.54:5060>;tag=MSAXXCPRGA
Call-ID: D895CB61C1792B34@192.168.1.1
CSeq: 9 BYE
Max-Forwards: 70
Content-Length: 0

Request retransmit 3 for request BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0, initial transmit 1,558s ago.
Request sent: udp:192.168.1.54:5060->udp:192.168.1.1:5060
BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.54:5060;branch=z9hG4bK23a7a9be8b384f83b1887ea8c3ea43dc;rport
To: "Name" <sip:**621@fritz.box>;tag=011E73AEB05365D5
From: <sip:192.168.1.54:5060>;tag=MSAXXCPRGA
Call-ID: D895CB61C1792B34@192.168.1.1
CSeq: 9 BYE
Max-Forwards: 70
Content-Length: 0

Request retransmit 4 for request BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0, initial transmit 3,612s ago.
Request sent: udp:192.168.1.54:5060->udp:192.168.1.1:5060
BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.54:5060;branch=z9hG4bK23a7a9be8b384f83b1887ea8c3ea43dc;rport
To: "Name" <sip:**621@fritz.box>;tag=011E73AEB05365D5
From: <sip:192.168.1.54:5060>;tag=MSAXXCPRGA
Call-ID: D895CB61C1792B34@192.168.1.1
CSeq: 9 BYE
Max-Forwards: 70
Content-Length: 0

I also noticed that the audio is fine, when I accept the incoming call. When I call the remote phone myself, the sound is messed up (crackling and rustling), you can't understand anything. Is this an issue with ports not opened correctly or do I have to negotiate another codec somehow?

As for wireshark, do you want a special filtered trace or everything?

sipsorcery commented 4 years ago

For the hangup issue I can't see anything wrong. The BYE is being sent to the correct URI.

Received:

INVITE sip:192.168.1.54:5060 SIP/2.0
Contact: <sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1>

Sent:

BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0

The fact that there is no OK response to the BYE means there's likely a problem with the SIP path somewhere. Where is the call originating from? Also try with a different softphone, such as MicroSIP, and see if you get the same problem.

I also noticed that the audio is fine, when I accept the incoming call. When I call the remote phone myself, the sound is messed up (crackling and rustling), you can't understand anything. Is this an issue with ports not opened correctly or do I have to negotiate another codec somehow?

That sounds like a codec mismatch and could be a bug. A wireshark trace would be useful for that, capture filter: udp port 5060 or udp portrange 49000-65535 Once you've captured you should be able to apply a display filter of: sip or rtp Export that and attach here or email to me at aaron@sipsorcery.com.

FabulousGee commented 4 years ago

Just sent you the Wireshark export.

The call is originating from a SIP phone I've got around here (Aastra 55i). After your answer, I also tried MicroSIP and my Android smartphone - both show the same issue. Note: (just to emphasize) it is working fine with outgoing calls from my program above. It is just not working on the incoming calls AND hanging up from my program above (everything else works as expected)

For the crackling sounds, I noticed in Wireshark, that the codec is switching between ITU-T G.722 and ITU-T G.711 PCMU - is this the cause?

sipsorcery commented 4 years ago

The hangup trace does support the theory there is no issue with the BYE request being sent by the sipsorcery library. The problem looks to be between your Frtiz!Box and Aastra. It could be the Aastra is putting its public IP address in the Contact header or it could be the Fritz!Box is incorrectly mangling the IP address in that header. Both things are unfortunately quite common and one of the big problems with SIP and IPv4.

The crackling noise is almost certainly because of the G711/G722 codec mismatch. Do both ends have crackling audio or just one?

A quick fix is:

windowsAudio.RestrictCodecs(new System.Collections.Generic.List<SIPSorceryMedia.Abstractions.V1.AudioCodecsEnum> { SIPSorceryMedia.Abstractions.V1.AudioCodecsEnum.PCMU });

FabulousGee commented 4 years ago

Crackling was on both sides. But the quick fix is working - thanks for that!

As for the hangup: I understand your point since we have no clue WHY this is happening. But after all, I am not convinced that it's a problem between Aastra and FritzBox. If this would be true, then it shouldn't be working with e.g. MicroSIP and Aastra. But it does work with it! Just had a call from MicroSIP to Aastra and hangup did work quite well in any direction :-(

So the problem only comes up as soon as SIPSorcery is involved - and only, if the call has been an incoming call.

Just some guessing: Is it possible that there is any problem with my code? I noticed that sometimes there is a timeout with the register and then it re-registers and is working fine again. Maybe I missed something? Or maybe I overlap anything so the communication channel is not set up correctly leading the BYE to the wrong place (e.g. to an already closed connection?)

sipsorcery commented 4 years ago

I've missed something with regards, the hangup problem.

The call is originating from a SIP phone I've got around here (Aastra 55i). After your answer, I also tried MicroSIP and my Android smartphone - both show the same issue. Note: (just to emphasize) it is working fine with outgoing calls from my program above. It is just not working on the incoming calls AND hanging up from my program above (everything else works as expected)

Just had a call from MicroSIP to Aastra and hangup did work quite well in any direction :-(

So hangups do work correctly when initiated from MicroSIP? If so can you email me a wireshark capture of that so I can compare it to the one you sent me with sipsorcery.

FabulousGee commented 4 years ago

Yup, indeed - they do. Capture should be in your inbox.

sipsorcery commented 4 years ago

See what happens if you use a different UDP port for the sipsorcery app, e.g:

_sipTransport.AddSIPChannel(new SIPUDPChannel(new IPEndPoint(IPAddress.Any, 6060)));

FabulousGee commented 4 years ago

Tried it, no luck. Same result.

So am I right that you can't reproduce the issue right now on your side?

sipsorcery commented 4 years ago

I might have found the problem (fixed in commit above).

Nuget package v4.0.78-pre is being built now, should be automatically published on nuget.org in 5-10 mins. Give that a try.

FabulousGee commented 4 years ago

Nope, still not hanging up :-( Behaviour like before.

Can I somehow help you with some additional stuff or anything? Or is it more like testing some possible solutions now?

Edit: tried with port 5060 and 6060

sipsorcery commented 4 years ago

Turns out I didn't do the fix properly.

Can you try again with the new package v4.0.79-pre.

FabulousGee commented 4 years ago

Still no luck with v4.0.79-pre. Tried both ports again.

sipsorcery commented 4 years ago

That's a shame. There were three difference I spotted between the sipsorcery and MicroSIP traces:

I'm really only able to guess now. Maybe the Aastra phone does something different if a PRACK's involved. Maybe the Fritz!box doesn't like something else in the sipsorcery call flow and doesn't forward the BYE request.

I can probably come up with a command line test app that allows tweaking of the BYE request. But it will mean a bit of trial and error detective work on your end to run the tests and feedback results.

FabulousGee commented 4 years ago

Okay, let's see what I can tell you on top of that:

So imho it seem to be an issue between sipsorcery and fritzbox in any way. I don't understand, why there isn't even an answer. Seems like the package doesn't reach it's destination or gets dropped silently Since fritzbox has some kind of firewall built in, may this be a problem? I could think of an issue that FB expects ports to be opened while sipsorcery doesn't do that. Just a guess. The port MicroSIP uses also looks more like a port that has been opened automatically (UPnP maybe? https://www.homenethowto.com/ports-and-nat/upnp-automatic-port-forward/ )

Since I need this function and don't want to switch libraries, give me anything you have :-) I will test and give you feedback until this is fixed... Hope we can figure it out quickly

sipsorcery commented 4 years ago

If you suspect it could be some kind of packet filtering on the Fritz~Box another useful test would be to try TCP instead of UDP. It will need the other end of the call to support SIP over TCP as well, MicroSIP does. To specify TCP as the transport set the call destination URI as:

sip:aaron@192.168.0.50;transport=tcp

FabulousGee commented 4 years ago

Can't seem to get it to work with TCP at all. Getting a lot of timeouts with the following:

            _sipTransport = new SIPTransport();
            _sipTransport.CanCreateMissingChannels = false;
            //_sipTransport.AddSIPChannel(new SIPUDPChannel(new IPEndPoint(IPAddress.Any, Config.getSIPServerListenPort())));
            _sipTransport.AddSIPChannel(new SIPTCPChannel(new IPEndPoint(IPAddress.Any, 5070)));

When using the following, it always seems to default back to UDP (in MicroSIP I set it to TCP of course). No change if I comment out the last line or not:

            _sipTransport = new SIPTransport();
            _sipTransport.AddSIPChannel(new SIPTCPChannel(new IPEndPoint(IPAddress.Any, 5070)));
            _sipTransport.AddSIPChannel(new SIPUDPChannel(new IPEndPoint(IPAddress.Any, Config.getSIPServerListenPort())));

I will try to get my fritzbox on "debug mode" later on so I can sniff packages there - maybe there is something interesting in it.

sipsorcery commented 4 years ago

The Fritz!Box log file you sent me may have a clue to the issue. If you locate the BYE request from the sipsorcery user agent it's missing the SIP version prefix.

2020-09-24 14:04:18.154 - IN: my=192.168.1.1%12:5060 peer=192.168.1.54 port=5060 UDP, sipiface=none:
BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 2.0

Note the 2.0 on the BYE status line should be SIP 2.0.

In the Wireshark traces you sent me the SIP version is captured as the full SIP 2.0 so the question is why is it seemingly correct on the network but then wrong in the Fritz!Box capture?? It would be worth checking what the log shows for a BYE request from the MicroSIP softphone to see if it's a quirk with the Fritz!Box logging or potentially something deeper.

FabulousGee commented 4 years ago

Aha! This looks like something right here... I ain't even had to log again with the FritzBox yet (although I will do this right after writing this).

But look at the last BYE which is from my regular telephone. Like I wrote in the email, I first hang up in SIPSorcery, then on the real phone. First BYE is the one from SIPSorcery, second one from phone:

2020-09-24 14:04:21.823 - IN: my=192.168.1.1%12:5060 peer=192.168.1.54 port=5060 UDP, sipiface=none:
BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 2.0

2020-09-24 14:04:22.874 - OUT: my=192.168.1.1%12:5060 peer=192.168.1.54 port=5060 UDP, sipiface=none:
BYE sip:192.168.1.54:5060 SIP/2.0

2.0 vs. SIP/2.0

FabulousGee commented 4 years ago

Damn, I was already happy, but it seems like another dead end. MicroSIP is logged the same way:

2020-09-24 17:30:28.057 - IN: my=192.168.1.1%12:5060 peer=192.168.1.54 port=50864 TCP, sipiface=none:
BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1:5060;transport=tcp 2.0
Via: SIP/2.0/TCP 192.168.1.54:50864;rport;branch=xxx;alias
From: <sip:aastra-1@192.168.1.54;ob>;tag=xxx;reg-id=1;+sip.instance="<urn:uuid:xxx>"
To: "xxx" <sip:**621@fritz.box>;tag=xxx
Call-ID: 999890697ABE376D@192.168.1.1
CSeq: 26299 BYE
Max-Forwards: 70
User-Agent: MicroSIP/3.20.1
Content-Length: 0

So... I have no ideas left what to check next. I think I will try one of the examples, just to be sure it's really not related to my code. If you have anything else to check, just let me know

FabulousGee commented 4 years ago

Based on the CallAndHoldTransfer example combined with the UserAgentRegister example, this is what I came up with: Program.zip

Can you please run this on your side and test if the hangup works for you? Procedure: 1.) (Configure data and) Run Main 2.) Call this instance from anywhere else (other computer/telephone/whatever) 3.) Press H to hangup in this instance 4.) Sound should stop (I guess the media session is getting closed) but call will continue

@sipsorcery Can you reproduce this or does it work fine for you?

Disclaimer: Should be pretty straight forward - you can publish/use/share/whatever with it. Basically just your code.

sipsorcery commented 4 years ago

Yes your example program works fine for me.

Here's the BYE request and response generated after pressing H.

[17:46:49 DBG] Request sent: udp:192.168.0.50:5060->udp:192.168.0.50:6060
[17:46:49 DBG] BYE sip:aaron@192.168.0.50:6060;ob SIP/2.0
Via: SIP/2.0/UDP 192.168.0.50:5060;branch=z9hG4bKebb617d64b664672a5a87aed0d3b8643;rport
To: <sip:aaron@192.168.0.50>;tag=3d6c9c063d5546339166baa4f2d1d49b
From: <sip:2@192.168.0.50>;tag=YHMSEBAGTX
Call-ID: e02191b8f306404e82ca264bc4bdfa29
CSeq: 12838 BYE
Max-Forwards: 70
Content-Length: 0

[17:46:49 DBG] Response received: udp:192.168.0.50:5060<-udp:192.168.0.50:6060
[17:46:49 DBG] SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.50:5060;rport=5060;received=192.168.0.50;branch=z9hG4bKebb617d64b664672a5a87aed0d3b8643
To: <sip:aaron@192.168.0.50>;tag=3d6c9c063d5546339166baa4f2d1d49b
From: <sip:2@192.168.0.50>;tag=YHMSEBAGTX
Call-ID: e02191b8f306404e82ca264bc4bdfa29
CSeq: 12838 BYE
Content-Length: 0
FabulousGee commented 4 years ago

Are you testing on the same machine or different ones? Asking because the IPs don't differ on your BYE. If you have the possibility, maybe you could re-run the test with different machines so we have it comparable?

For me it's:

[19:24:12 DBG] Request retransmit 6 for request BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0, initial transmit 11,585s ago.
[19:24:12 DBG] Request sent: udp:192.168.1.54:65528->udp:192.168.1.1:5060
[19:24:12 DBG] BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.54:65528;branch=z9hG4bK519f9e3381a14f12a86d175111b9ce75;rport
To: "Aastra 1" <sip:**621@fritz.box>;tag=5CFBE82642D430FA
From: <sip:192.168.1.54:65528>;tag=ZMVCBLSTKV
Call-ID: 132C14E3FEE870B0@192.168.1.1
CSeq: 15 BYE
Max-Forwards: 70
Content-Length: 0
FabulousGee commented 4 years ago

Not sure if it is relevant but another thing I noticed is the hostname change. I always use the IP 192.168.1.1 but in the BYE the sip is **621@fritz.box - where does that hostname come from? And how is it resolved on SIPSorcery side? Is there a way to deactivate this for testing purpose? Had a small warning that fritz.box could not be found but I can not reproduce it, so I am not sure why it came up and if it's related.

sipsorcery commented 4 years ago

It's not a network issue. It's a SIP integration issue between the sipsorcery library and the SIP stack on the Fritz!Box. I would run SIP calls of one kind or another everyday between the sipsorcery test apps and an Asterisk server and Cisco IP phone in addition to the softphones on the same machine.

If you call directly between sipsorcery and MicroSIP across the network and without the Fritz!Box in the middle it will work fine.

I'll try and put together a test app later today where you can tweak the SIP headers on the BYE to test with the Fritz!Box.

FabulousGee commented 4 years ago

Okay, I see. Didn't manage it yet to have a call locally, guess that's a rather uncommon setup so examples aren't popular :-)

But when searching for similiar issues regarding FritzBox with SIP, I came across a german forum post. An user there stated, that the FROM header needs to have the FritzBox username set (it's not easy to describe it more detailed since they were talking about Asterisk and Fritzbox having a similar issue...). https://www.ip-phone-forum.de/threads/fritz-box-verarbeitet-bye-von-asterisk-nicht.303021/

So basically instead of the currently sent

From: <sip:user-IP:user-port>
or
From: <sip:192.168.1.54:64078>

it seems to be needed

From: <sip:username@sip-server>
or
From: <sip:aastra-3@192.168.1.1>

From what I understand at least... You are much more into all these stack stuff and how it should look like... I will try that as soon as you have the test app with header tweaking ready.

sipsorcery commented 4 years ago

The header you're referring to is set by the caller, it's the To header sent to sipsorcery or MicroSIP.

You can easily get the username field set. Instead of placing the call to the sipsorcery library as:

sip:192.168.1.54

Place it as:

sip:1234@192.168.1.54

It's up to your application if it wants to do anything with the 1234 User portion of the request URI.

FabulousGee commented 4 years ago

So this may finally be the mismatch - fingers crossed!

Let me explain: I call sip:**623@192.168.1.1 in MicroSIP. I use the example Program.cs from before to answer the call. Following ACK in Program.cs:

[20:59:29 DBG] ACK sip:192.168.1.54:57910 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK17920725EFE88B11
To: <sip:192.168.1.54:57910>;tag=UZUYLPFKSA
From: "MicroSIP" <sip:**621@fritz.box>;tag=43CDA8D04CD679CE
Call-ID: F7BDC54C38DD0634@192.168.1.1
CSeq: 65 ACK
Contact: <sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1>
Max-Forwards: 70
User-Agent: AVM FRITZ!Box 6490 Cable (kdg) 141.07.12 TAL (Sep 11 2019)
Content-Length: 0

As you can see, the From header is correctly set here as you described above. But when I hang up in Program.cs the following BYE gets send:

[20:56:25 DBG] BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.54:61472;branch=z9hG4bK23ee49083a954ed8bdd2ebb9877023ad;rport
To: "MicroSIP" <sip:**621@fritz.box>;tag=0D5541C7DB92C808
From: <sip:192.168.1.54:61472>;tag=HWEMNYKSKQ
Call-ID: 2912B330D488C563@192.168.1.1
CSeq: 47 BYE
Max-Forwards: 70
Content-Length: 0

As you can see here, the To from the former ACK is not used in the BYE! And therefore might be dropped in the FritzBox

sipsorcery commented 4 years ago

That looks correct to me. The To and From headers switch for either end of the call.

The bit I was talking about is:

To: <sip:192.168.1.54>

You need to change the way you place the call so it becomes:

To: <sip:1324@192.168.1.54>

It's the call originator that sets that. The answering user agent simply uses whatever it received. That's the same no matter whether sipsorcery, MicroSIP or other.

FabulousGee commented 4 years ago

I got ya. But how can I achieve this? I believe that's what the FritzBox is doing (stupid NAT-like behaviour). Like I said before, in MicroSIP I started the call (imho) correctly with sip:**623@192.168.1.1

Isn't there any way to let me decide which From to use? Like a simple override? Anyway. I still hope this is the problem after all. We will see as soon as I am able to modify the headers - can't wait for it.

Edit: If you compare it to MicroSIP (https://github.com/sipsorcery/sipsorcery/issues/312#issuecomment-698427505), you see that it uses another From although it's used in the same way:

2020-09-24 17:30:28.057 - IN: my=192.168.1.1%12:5060 peer=192.168.1.54 port=50864 TCP, sipiface=none:
BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1:5060;transport=tcp 2.0
Via: SIP/2.0/TCP 192.168.1.54:50864;rport;branch=xxx;alias
From: <sip:aastra-1@192.168.1.54;ob>;tag=xxx;reg-id=1;+sip.instance="<urn:uuid:xxx>"
To: "xxx" <sip:**621@fritz.box>;tag=xxx
Call-ID: 999890697ABE376D@192.168.1.1
CSeq: 26299 BYE
Max-Forwards: 70
User-Agent: MicroSIP/3.20.1
Content-Length: 0

It's what I meant before, the username (in case of MicroSIP aastra-1) needs to be set in order to have it passed at FritzBox

FabulousGee commented 4 years ago

Another example for what I see the issue is... I believe, that in SIPSorcery, there may be a bug at the INVITE.

To prove it, I have set up two identical setups. I used my Aastra-phone (aastra-2/**622) to call either MicroSIP (registered as aastra-1) or Program.cs (registered as aastra-3) - sorry for the confusing names, but it's a running config...

Have a closer look at the initial INVITE. MicroSIP logs To: <sip:aastra-1@192.168.1.54:57935;ob> whereas Program.cs logs To: <sip:192.168.1.54:65470>. Why is that? Isn't SIPSorcery omitting the username here?

So this is the full SIP log for Aastra -> MicroSIP:

INVITE sip:aastra-1@192.168.1.54:57935;ob SIP/2.0
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK268D5B6BEB497650
From: "Arno Nym" <sip:**622@fritz.box>;tag=2153B4A608AA2D41
To: <sip:aastra-1@192.168.1.54:57935;ob>
Call-ID: 26C78D12504BF7D0@192.168.1.1
CSeq: 11 INVITE
Contact: <sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1>
Max-Forwards: 70
P-Called-Party-ID: <sip:**9@fritz.box>
Expires: 120
Session-Expires: 600;refresher=uac
Min-SE: 90
User-Agent: AVM FRITZ!Box 6490 Cable (kdg) 141.07.12 TAL (Sep 11 2019)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Content-Type: application/sdp
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length:   194

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.1:5060;received=192.168.1.1;branch=z9hG4bK268D5B6BEB497650
Call-ID: 26C78D12504BF7D0@192.168.1.1
From: "Arno Nym" <sip:**622@fritz.box>;tag=2153B4A608AA2D41
To: <sip:aastra-1@192.168.1.54;ob>
CSeq: 11 INVITE
Content-Length:  0

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.1.1:5060;received=192.168.1.1;branch=z9hG4bK268D5B6BEB497650
Call-ID: 26C78D12504BF7D0@192.168.1.1
From: "Arno Nym" <sip:**622@fritz.box>;tag=2153B4A608AA2D41
To: <sip:aastra-1@192.168.1.54;ob>;tag=97d588d9ce3f42ec9e019df51379f5a6
CSeq: 11 INVITE
Contact: <sip:aastra-1@192.168.1.54:57935;ob>
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length:  0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.1:5060;received=192.168.1.1;branch=z9hG4bK268D5B6BEB497650
Call-ID: 26C78D12504BF7D0@192.168.1.1
From: "Arno Nym" <sip:**622@fritz.box>;tag=2153B4A608AA2D41
To: <sip:aastra-1@192.168.1.54;ob>;tag=97d588d9ce3f42ec9e019df51379f5a6
CSeq: 11 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Contact: <sip:aastra-1@192.168.1.54:57935;ob>
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 600;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length:   313

ACK sip:aastra-1@192.168.1.54:57935;ob SIP/2.0
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK2850D2A8CA9D442E
From: "Arno Nym" <sip:**622@fritz.box>;tag=2153B4A608AA2D41
To: <sip:aastra-1@192.168.1.54;ob>;tag=97d588d9ce3f42ec9e019df51379f5a6
Call-ID: 26C78D12504BF7D0@192.168.1.1
CSeq: 11 ACK
Contact: <sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1>
Max-Forwards: 70
User-Agent: AVM FRITZ!Box 6490 Cable (kdg) 141.07.12 TAL (Sep 11 2019)
Content-Length: 0

BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.54:57935;rport;branch=z9hG4bKPjad22f7a9bacc47409b7c0dfdaca7229b
Max-Forwards: 70
From: <sip:aastra-1@192.168.1.54;ob>;tag=97d588d9ce3f42ec9e019df51379f5a6
To: "Arno Nym" <sip:**622@fritz.box>;tag=2153B4A608AA2D41
Call-ID: 26C78D12504BF7D0@192.168.1.1
CSeq: 26299 BYE
User-Agent: MicroSIP/3.20.1
Content-Length:  0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.54:57935;rport=57935;branch=z9hG4bKPjad22f7a9bacc47409b7c0dfdaca7229b
From: <sip:aastra-1@192.168.1.54;ob>;tag=97d588d9ce3f42ec9e019df51379f5a6
To: "Arno Nym" <sip:**622@fritz.box>;tag=2153B4A608AA2D41
Call-ID: 26C78D12504BF7D0@192.168.1.1
CSeq: 26299 BYE
X-RTP-Stat: CS=11;PS=0;ES=74;OS=0;SP=0/0;SO=0;QS=-;PR=73;ER=74;OR=11680;CR=0;SR=0;QR=-;PL=0,0;BL=0;LS=0;RB=0/0;SB=-/-;EN=PCMU;DE=PCMU;JI=12,0;DL=0,0,0;IP=192.168.1.1:7086,192.168.1.54:4000
X-RTP-Stat-Add: DQ=0;DSS=0;DS=0;PLCS=0;JS=0
X-SIP-Stat: DRT=2;IR=0
User-Agent: AVM FRITZ!Box 6490 Cable (kdg) 141.07.12 TAL (Sep 11 2019)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer
Content-Length: 0

And this is the full SIP log for Aastra -> Program.cs:

[21:42:09 DBG] INVITE sip:192.168.1.54:65470 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK4C765B392FBA488A
To: <sip:192.168.1.54:65470>
From: "Arno Nym" <sip:**622@fritz.box>;tag=13B3F554F02BDAAF
Call-ID: 13C8A58054ADF8A4@192.168.1.1
CSeq: 80 INVITE
Contact: <sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1>
Max-Forwards: 70
User-Agent: AVM FRITZ!Box 6490 Cable (kdg) 141.07.12 TAL (Sep 11 2019)
Expires: 120
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Supported: 100rel,replaces,timer
Content-Length: 194

[21:42:09 DBG] SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK4C765B392FBA488A;received=192.168.1.1;rport=5060
To: <sip:192.168.1.54:65470>
From: "Arno Nym" <sip:**622@fritz.box>;tag=13B3F554F02BDAAF
Call-ID: 13C8A58054ADF8A4@192.168.1.1
CSeq: 80 INVITE
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE
Content-Length: 0

[21:42:09 DBG] SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK4C765B392FBA488A;received=192.168.1.1;rport=5060
To: <sip:192.168.1.54:65470>;tag=MFAGLOUOMN
From: "Arno Nym" <sip:**622@fritz.box>;tag=13B3F554F02BDAAF
Call-ID: 13C8A58054ADF8A4@192.168.1.1
CSeq: 80 INVITE
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE
Require: replaces, norefersub, 100rel
Content-Length: 0
RSeq: 73355132

[21:42:10 DBG] SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK4C765B392FBA488A;received=192.168.1.1;rport=5060
To: <sip:192.168.1.54:65470>;tag=MFAGLOUOMN
From: "Arno Nym" <sip:**622@fritz.box>;tag=13B3F554F02BDAAF
Call-ID: 13C8A58054ADF8A4@192.168.1.1
CSeq: 80 INVITE
Contact: <sip:192.168.1.54:65470>
Server: sipsorcery_v4.0.79.0
Supported: replaces, norefersub, 100rel
Content-Length: 190

[21:42:10 DBG] PRACK sip:192.168.1.54:65470 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bKB4213A9EBCEB6218
To: <sip:192.168.1.54:65470>;tag=MFAGLOUOMN
From: "Arno Nym" <sip:**622@fritz.box>;tag=13B3F554F02BDAAF
Call-ID: 13C8A58054ADF8A4@192.168.1.1
CSeq: 81 PRACK
Max-Forwards: 70
User-Agent: AVM FRITZ!Box 6490 Cable (kdg) 141.07.12 TAL (Sep 11 2019)
Content-Length: 0
RAck: 73355132 80 INVITE

[21:42:10 DBG] SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bKB4213A9EBCEB6218;received=192.168.1.1;rport=5060
To: <sip:192.168.1.54:65470>;tag=MFAGLOUOMN
From: "Arno Nym" <sip:**622@fritz.box>;tag=13B3F554F02BDAAF
Call-ID: 13C8A58054ADF8A4@192.168.1.1
CSeq: 81 PRACK
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE
Content-Length: 0

[21:42:10 DBG] ACK sip:192.168.1.54:65470 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK27E39627A2FAD8B9
To: <sip:192.168.1.54:65470>;tag=MFAGLOUOMN
From: "Arno Nym" <sip:**622@fritz.box>;tag=13B3F554F02BDAAF
Call-ID: 13C8A58054ADF8A4@192.168.1.1
CSeq: 80 ACK
Contact: <sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1>
Max-Forwards: 70
User-Agent: AVM FRITZ!Box 6490 Cable (kdg) 141.07.12 TAL (Sep 11 2019)
Content-Length: 0

[21:42:15 DBG] BYE sip:537D773E49AD97D6EDDEE54705FA3@192.168.1.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.54:65470;branch=z9hG4bKc06cf0ad9aa549b88ec186b9a71e6aba;rport
To: "Arno Nym" <sip:**622@fritz.box>;tag=13B3F554F02BDAAF
From: <sip:192.168.1.54:65470>;tag=MFAGLOUOMN
Call-ID: 13C8A58054ADF8A4@192.168.1.1
CSeq: 81 BYE
Max-Forwards: 70
Content-Length: 0
sipsorcery commented 4 years ago

There's no bug in the INVITE or logging, at least not for this case.

Whatever dialplan you are using on the Fritz!Box is controlling the called destination. If you are registering from your program to the Fritz!Box then it's probably using the Contact header you provide as part of the registration. You can change that to include any 'User` portion you want.

FabulousGee commented 4 years ago

I really understand your point but there is no special dial plan or anything set?! These sip-accounts are brand new (set them up like 5 days ago) and all identical. When I call from device1 to device2 and from device1 to device3 and get different results (with all settings being identical on the "in-the-middle"-device) I can't see how this could be related to device1 or the "in-the-middle"-device.

Don't get me wrong, not saying this is not possible but it seems unlikely to me and I have no idea how to proceed from there. Maybe I just don't get it - I hope we can figure that out somehow.

sipsorcery commented 4 years ago

Sure but there's no way any SIP user agent, in this case you app using the sipsorcery library, can dictate what the SIP URI and headers sent to it in the INVITE are going to be. The critical headers in the INVITE must be used in all subsequent in-dialog requests such as ACKs and BYEs.

If your hypothesis is correct and the Fritz!Box is rejecting the BYE due to no User portion in the To header URI then the correct way to fix it is to make sure the original INVITE does set a User portion.

I'd recommend again having a look at whatever registrations you are using from your program. And yes this is frustrating but it gets way worse with more complicated servers like Asterisk or FreeSWITCH.

FabulousGee commented 4 years ago

I still don't get what you are currently on - I think we talk past each other...

I am still trying to get this Program.cs working: https://github.com/sipsorcery/sipsorcery/issues/312#issuecomment-698452167 As a proof of concept. Basic and simple.

So following your advice, I am trying to figure out WHY those original INVITE headers seem to differ (like I said, they differ even though it's the same physical device with no modifications done meanwhile. Just another endpoint: SIPSorcery example program vs. MicroSIP)

If I understand correctly, you state that MicroSIP seems to register in another way than I do in my example program, right? So when I look at the SIPRegistrationUserAgent I can see the overloaded method with a lot of additional stuff - is this the right spot to proceed?

Edit: For registration I now use the following code:

var sipAOR = new SIPURI(USERNAME, DOMAIN, null, SIPSchemesEnum.sip, SIPProtocolsEnum.udp);
var sipContact = new SIPURI(USERNAME, "0.0.0.0", null, SIPSchemesEnum.sip, SIPProtocolsEnum.udp);
var regUserAgent = new SIPRegistrationUserAgent(sipTransport, null, sipAOR, USERNAME, PASSWORD, "fritz.box", DOMAIN, sipContact, EXPIRY, null);

It does register fine and also does it hang up correctly. THANKS FOR YOUR TIRELESS HELP ON THIS!! 🥇

Just one last question: is this what you meant? And is this the wanted behaviour? Still unsure if this is a bug or a feature :D

sipsorcery commented 4 years ago

Just one last question: is this what you meant? And is this the wanted behaviour?

Yes.

Still unsure if this is a bug or a feature :D

Definitely a bug from my point of view. A SIP URI of the form 'sip:192.168.1.54`, with no user portion, is perfectly valid and not uncommon. If the Fritz!Box is not accepting them it's hard to classify it as anything else other than a bug.

It's worth being aware that these types of quirks are not unusual when dealing with SIP interoperability. There are a handful of cases in the sipsorcery code where explicit logic has been added to deal with specific SIP stacks.