BYE: Request-URI does not point to us #844
Comments
|
Please print the initial INVITE, 100, 180/183, 200, ACK messages and then the received BYE. |
|
Here you go! |
|
You are not explicitly passing any "contact" to new UA, right? So it looks like if JsSIP takes the identity uri, converts it to low case and use it as Contact header. That's perfectly fine since it can use whatever it wants. Problem is that the incoming BYE is rejected with 404 despite its RURI matches the Contact URI of the initial INVITE. My guess is that JsSIP stores internally the contact header without converting it to low case, then it converts it to low case when sending the INVITE, and later when the BYE arrives JsSIP tries to match the RURI (which is all low case to match the INVITE'/s Contact) using its internally stored identity URI which is not in low case. @jmillan thoughts? |
|
You're correct. I'm not specifying the contact directly. It seems like some other people also had the same struggle, so would be nice with a fix and/or at least - a clarification :) |
|
I tested using contact_uri too with the original non-lowercased value, and it seems to end with the same result. |
|
@mtryfoss, can you please share the REGISTER request and response? I'm wondering if the registrar server is the one lowercasing the URI in the pub gruu. |
|
The user-part of To and From is in lower case, while username in Authorization header is like it should be. I'm using save() in the Kamailio registrar module with an explicit URI based on the Authorization header, which is the correct string (non-lower case). Checking the docs, I see this one: Changing that to 1, stores the AOR correct. Now the INVITE is sent with the correct user in the Contact (and From) too:
And the BYE is accepted, even after I removed the toLowerCase() in the settings for the client. I'm part of the Kamailio team too, but was not aware of this setting. I'll bring it up to maybe change the default. All in all, a quite confusing case. |
|
Despite what kamailio registrar does, the fact here is that:
|
|
BTW I fail to see how the Authorization header can affect this problem, it's supposed to be the credentials for the client to get registered and make calls. It should not directly affect the generated Contact URIs. Also I don't understand the problem you said in the REGISTER flow. JsSIP sets a low case uri in the REGISTER and Kamailio honors it (in low case) in the 200 to the REGISTER. |
|
I originally included the signalling with my client-side workaround in place, so it registers with all-lower. Edited the post to what I can see after altering behaviour in both ends. To conclude I think we can say:
|
|
Can you please show the changes in the edited REGISTER flow with that kamailio setting set to default value? I cannot see the difference (note: I'm in mobile with super low availability for some days). |
|
This should be before the client workaround, and with default setting in Kamailio. Returned contact: |
Sorry, and what's the problem or unexpected thing with this returned contact? Why should it be different? I insi that the fact that it doesn't match the username in the Authorization header is irrelevant. Do I miss something? (Sorry I'm on vacation) |
I don't think JsSIP should store all
, meaning that the GRUU cannot convert the case of the AOR it contains. |
|
@jmillan, despite the kamailio gruu low case stuff, do you see the problem in the REGISTER + INVITE + incoming BYE flow? Because I don't so I don't really understand why JsSIP fails to match the incoming BYE. The RURI of the BYE matches the Contact in the 200 of the REGUSTER. So what's the problem? |
|
Seems like JsSIP is somehow falling back to matching this against the configured value (settings), and not what it use for the INVITE? |
|
And what is the configured value in settings? |
|
Sorry, my bad. It's been so much back and forth here :) It will not match against the settings, since they could be in both upper and lower while the contact is in lower. |
|
But I insist something must be wrong in JsSIP side. Can you show the settings you pass to new JsSIP.UA()? |
|
At first we only used: but then we also tried specifying contact_uri explicitely:
Same effect. |
So here the bug because the uri is given with low and upper chars but the JsSIP generated Contact URI is in low case so later it doesn't match the RURI of the incoming BYE (which is correct) because it's in low case. Yes, here the bug. Somewhere in JsSIP we are converting the given settings uri to low case when we generate the REGISTER and the INVITE, but we keep it in upper+low case in memory and use it to match incoming requests. That's the bug. |
|
Nop,
In summary, the issue is in the server lowercasing the AoR in the pub_gruu, which makes it identify a different AoR. |
Where do you see that in messages above? I see this instead in the REGISTER sent by JsSIP: Contact: sip:7crp59qm@q5q96qlrkps3.invalid;transport=ws;+sip.ice;reg-id=1;+sip.instance="urn:uuid:d1996bf3-326c-4d2d-9f7b-f91a017f123f";expires=300 All in low case. So it should match and accept a BYE with same RURI in low case. But it doesn't. |
here: #844 (comment) |
The contact in that REGISTER is: Contact: sip:s64qtlfe@tkb9vrejfuua.invalid;transport=ws;+sip.ice;reg-id=1;+sip.instance="urn:uuid:44e0581c-0d2a-4a7f-aca5-bfdcddd9f742";expires=300 Where do you see upper chars there? |
That is the Contact generated by us in the REGISTER. I did not mention that in my comment here #844 (comment) |
This is your comment but still I don't see any evidence that JsSIP sends REGISTER with upper case chars in the Contact header. I just see it in your comment, nowhere else. I may be wrong. |
Not the in the Contact header, but in the To header. The registrar extracts the AoR from the To header field and creates the GRUU out of it, which adds to the Contact header in the response. As part of the GRUU creation, the registrar lower cases the AoR, which I claim to be the bug. |
|
I would absolutely say it's a non-optimal behaviour/bug in the way Kamailio works without modified settings. Regardless of that, wouldn't it be a good idea to handle this in JsSIP so it at least accepts a BYE to a URI matching a contact in an INVITE sent by the same client? It was more or less pure luck I found the cause relatively quick. |
The pub-gruu in the REGISTER 200 is clearly in low case, and JsSIP uses that pub-gruu in low case in the Contact of the INVITE so it honors it. So it should match the BYE since its RURI perfectly matches the Contact URI that JsSIP told to the callee. But is doesn't so hence the bug in JsSIP. The pub-gruu is chosen/decided by the registrar server. JsSIP should not expect any specific URI. That's why the pub-gruu is indicated in the REGISTER 200. |
|
Section 5.4 of RGC 5627 clearly says: Appendix A says: In other words: the registrar can decide how the entire pub gruu looks. So this is only a bug in JsSIP despite the low case stuff of kamailio. |
|
I missread the spec and interpreted that the AoR should be included too. I don't have an ETA myself for this fix as for now, as I have my hands at this momemt. |
|
No hurry for me - we're covered by the server side fix. |
Hello!
I've seen a couple of posts/tickets regarding this message.
Although a workaround would do for me by doing
.toLowerCase()on this in the settings:uri: '1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com'.. I think it would be smart to adjust the cause of this problem - or at least make a note regarding it.
I have this scenario with an outgoing JsSIP call which is terminated with a BYE from the callee. Results in a 404 towards the callee.
According to the rules, the URI or BYE matches the Contact of the initial INVITE - which it does.
That's why I used some time debugging this. Everything seems ok by looking at the SIP.
While digging a bit deeper, it seems like the username of the uri is lower cased when starting the call.
According to https://datatracker.ietf.org/doc/html/rfc3261#section-19.1.4:
Because of that, JsSIP will not be able to use a username that is in not pure lower case in settings.
I suggest leaving the settings.user as it is configured when starting calls.
The text was updated successfully, but these errors were encountered: