baresip keeps re-sending 200 Answering after receiving ACK #3029
Comments
|
why is the connection address 0.0.0.0 ? the network address in SDP is not set... |
|
It is 0.0.0.0, because there is no media in the call. Edit 0.0.0.0 is a valid IP address and thus according to RFC 8866 can be used on c= line. |
|
please take a look at this code: https://github.com/baresip/baresip/blob/main/src/ua.c#L850 Can you please try to add some debug printf here and figure out what is going on ? The problem is that the incoming offer has IPv4, while the answer has IPv6. |
|
I added some debug: and got: So |
|
It is not set because of this test in which means that in Could that explain Anyway, 0.0.0.0 clearly is a IP4 address and even if |
|
Thanks!
|
|
Yes, and in this (0.0.0.0) case, af should be AF_INET. |
|
hi @juha-h please take a look at this logic: https://github.com/baresip/re/blob/main/src/sdp/msg.c#L409 the address family info in SDP is encoded in two places: example: The address part may also contain a hostname, mainly used in the old days. The sdp_connection function should parse the SDP message |
|
In the test call, bareip knows the address family used in the offer and allocates the call with correct af param: But why does it use |
|
Here is a small patch, please test it if you want: diff --git a/src/call.c b/src/call.c
index 48f6ddf5..15127208 100644
--- a/src/call.c
+++ b/src/call.c
@@ -833,6 +833,11 @@ int call_alloc(struct call **callp, const struct config *cfg, struct list *lst,
debug("call: alloc with params laddr=%j, af=%s, use_rtp=%d\n",
&prm->laddr, net_af2name(prm->af), prm->use_rtp);
+ if (prm->af == AF_UNSPEC)
+ return EAFNOSUPPORT;
+ if (!sa_isset(&prm->laddr, SA_ADDR))
+ return EINVAL;
+
call = mem_zalloc(sizeof(*call), call_destructor);
if (!call)
return ENOMEM;
diff --git a/src/ua.c b/src/ua.c
index 5daeff45..ea9e358b 100644
--- a/src/ua.c
+++ b/src/ua.c
@@ -671,10 +671,15 @@ static int sdp_connection(const struct mbuf *mb, int *af, struct sa *sa)
if (err)
goto out;
+ sa_init(sa, *af);
+
err = sa_set(sa, &pl2, pl_u32(&pl1));
if (sa_af(sa) == AF_INET6 && sa_is_linklocal(sa))
err |= net_set_dst_scopeid(net, sa);
+ if (!sa_isset(sa, SA_ADDR))
+ return EPROTO;
+
out:
return err;
}I am afraid that the whole logic is broken. The logic in ua.c is trying to connect to the SDP address What happens if the SIP traffic is over IPv4 but the SDP contains IPv6 ? |
|
Now SDP in 200 response looks OK: But the original issue still remains, i.e., baresip keeps re-sending |
|
Here is once more INVITE, 200, and ACK: I have been reading RFC3261 and the ACK looks OK:
Why is the call not established and baresip keeps of sending the 200 response? |
|
Any hints where I could place debug about handling of the ACK in order to find out if there is something wrong with it? |
|
https://github.com/baresip/re/blob/main/src/sipsess/listen.c#L129 this is where we receive ACK. Please try to add debug print here. btw, did you try Route or Record-Route ? |
|
OK, I added lots of debug to listen.c starting with this: Then I made call between two baresips to verify that the debug works and got: Then I made the click2dial test where the problem appears (SIP proxy sends INVITE to baresip which replies with 200 and then gets ACK from SIP proxy). When baresip got the ACK, it didn't call the handler at all! Where do I need to add debug to find out why the ACK handler was not called? |
|
Here is the same test with pjsua and it does handle the ACK and changes call state to CONFIRMED: |
|
Regarding |
|
Can you try to test both UDP and TCP transport to see if there is any difference ? Please add some debug info to this function in transp.c: static void sip_recv(struct sip *sip, const struct sip_msg *msg,
size_t start)
{
struct le *le = sip->lsnrl.head;
if (sip->traceh) {
sip->traceh(false, msg->tp, &msg->src, &msg->dst,
msg->mb->buf + start, msg->mb->end - start,
sip->arg);
}
if (msg->req) {
if (!have_essential_fields(msg)){
(void)sip_reply(sip, msg, 400, "Bad Request");
return;
}
}
/* check consistency between CSeq method and that of request line */
if (msg->req && pl_casecmp(&(msg->cseq.met), &(msg->met))){
(void)sip_reply(sip, msg, 400, "Bad Request");
return;
}
while (le) {
struct sip_lsnr *lsnr = le->data;
le = le->next;
if (msg->req != lsnr->req)
continue;
if (lsnr->msgh(msg, lsnr->arg))
return;
}
if (msg->req) {
(void)re_fprintf(stderr, "unhandled request from %J: %r %r\n",
&msg->src, &msg->met, &msg->ruri);
if (!pl_strcmp(&msg->met, "CANCEL"))
(void)sip_reply(sip, msg,
481, "Transaction Does Not Exist");
else
(void)sip_reply(sip, msg,
501, "Not Implemented");
}
else {
(void)re_fprintf(stderr, "unhandled response from %J:"
" %u %r (%r)\n", &msg->src,
msg->scode, &msg->reason, &msg->cseq.met);
}
}Does the ACK message get into the SIP-stack at all, i.e. are you running with SIP trace (-s) ? |
|
I'll try to test with UDP and will add debug. The packets that I showed in #3029 (comment), come from -s. So baresip is receiving the ACK. Isn't there any debug or warning message if baresip drops a request without processing it? |
|
Changing transport to UDP didn't make any difference. Will add debug next. |
|
Found why ACK is not processed: It does not appear in baresip trace nor in wireshark capture. |
|
Max-Forwards is a mandatory header for all requests. Could you please try to add it It is not possible to reply to a ACK message: https://github.com/baresip/re/blob/main/src/sip/reply.c#L34 You could try to add some extra logging where the messages is checked -> |
|
Missing Max-Forwards from ACK seems to be Kamailio bug, since it automatically generates the ACK. Since there cannot be response to ACK, a warning or debug message should be generated instead. |
|
Related commit: commit f6db77d |
|
So if |
|
How about this? Should I create a PR? |
|
I could now close this, since the issue is solved. A new one should be opened about bogus SDP with ? address or a PR created to fix it. |
|
Closed due to new PR baresip/re#1124 and new issue #3033. |
I converted this to an issue. I don't know if re-sending of 200 response and call not being established is due to bug in SDP handing or something else. I suspect there is bug in baresip somewhere, since the same test with pjsip pjsua works fine.
Discussed in #3028
Originally posted by juha-h May 16, 2024
Can someone figure out why in below baresip keeps on re-sending
200 Answeringafter it has receivedACK? ACK URI is the same as Contact URI of 200 response and also Call-IDs, To and From tags match. Why is the call not established?The text was updated successfully, but these errors were encountered: