BYE: Request-URI does not point to us

[mtryfoss]

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.

INVITE sip:+4749494949@sip.domain.com SIP/2.0
Via: SIP/2.0/WSS db71gp1ohcci.invalid;branch=z9hG4bK3339010
Max-Forwards: 69
To: <sip:+4749494949@sip.domain.com>
From: <sip:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com>;tag=65usgvrghd
Call-ID: 5k691v16q6gtrrvj4vds
CSeq: 8281 INVITE
P-Preferred-Identity: sip:1jjiz6hyxjgzotleyhbeejocnyv@domain.com
Contact: <sip:1jjiz6hyxjgzotleyhbeejocnyv@domain.com;gr=urn:uuid:9147fcf9-4eda-4259-8997-55f65ef7c97b>
Content-Type: application/sdp
Session-Expires: 3600;refresher=uac
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: timer,gruu,ice,replaces,outbound
User-Agent: JsSIP 3.10.1
Content-Length: 1957

....

BYE sip:1jjiz6hyxjgzotleyhbeejocnyv@domain.com;gr=urn:uuid:9147fcf9-4eda-4259-8997-55f65ef7c97b SIP/2.0
Via: SIP/2.0/WSS 192.168.23.184:443;branch=z9hG4bKf0de.9229ed59cfac0e73092ec911f1852f2c.0
Via: SIP/2.0/UDP 192.168.23.179;rport=5060;branch=z9hG4bKf0de.fc4ae3221bc63b2ed8ee75f2bc5fafbb.0
Via: SIP/2.0/UDP 192.168.23.188:5060;rport=5060;branch=z9hG4bK52fc48ec
Max-Forwards: 68
From: <sip:+4749494949@sip.domain.com>;tag=as00d6ed10
To: <sip:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com>;tag=65usgvrghd
Call-ID: 5k691v16q6gtrrvj4vds
CSeq: 102 BYE
Content-Length: 0

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:

Comparison of the userinfo of SIP and SIPS URIs is case-
         sensitive.  This includes userinfo containing passwords or
         formatted as telephone-subscribers.
...
   The URIs within each of the following sets are not equivalent:

   SIP:ALICE@AtLanTa.CoM;Transport=udp             (different usernames)
   sip:alice@AtLanTa.CoM;Transport=UDP

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.

[ibc]

Please print the initial INVITE, 100, 180/183, 200, ACK messages and then the received BYE.

[mtryfoss]

Here you go!

2024-01-17 16:28:14 +0100 : 192.168.75.141:60278 -> 192.168.23.184:443
INVITE sip:+47494949@sip.domain.com SIP/2.0
Via: SIP/2.0/WSS e2ecvh8aqqb7.invalid;branch=z9hG4bK3017171
Max-Forwards: 69
To: <sip:+47494949@sip.domain.com>
From: <sip:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com>;tag=bhkk93kg21
Call-ID: 5hpl8bbtoq2hhhfgcn2k
CSeq: 3488 INVITE
Authorization: Digest algorithm=MD5, username="1705508839:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com", realm="domain.com", nonce="...", uri="sip:+47494949@sip.domain.com", response="..."
P-Preferred-Identity: sip:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com
Contact: <sip:1jjiz6hyxjgzotleyhbeejocnyv@domain.com;gr=urn:uuid:9147fcf9-4eda-4259-8997-55f65ef7c97b>
Content-Type: application/sdp
Session-Expires: 3600;refresher=uac
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: timer,gruu,ice,replaces,outbound
User-Agent: JsSIP 3.10.1
Content-Length: 1956

<removed SDP>

2024-01-17 16:28:14 +0100 : 192.168.23.184:443 -> 192.168.75.141:60278
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/WSS e2ecvh8aqqb7.invalid;branch=z9hG4bK3017171;rport=60278;received=192.168.75.141
To: <sip:+47494949@sip.domain.com>
From: <sip:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com>;tag=bhkk93kg21
Call-ID: 5hpl8bbtoq2hhhfgcn2k
CSeq: 3488 INVITE
Content-Length: 0

2024-01-17 16:28:16 +0100 : 192.168.23.184:443 -> 192.168.75.141:60278
SIP/2.0 180 Ringing
Via: SIP/2.0/WSS e2ecvh8aqqb7.invalid;rport=60278;received=192.168.75.141;branch=z9hG4bK3017171
Record-Route: <sip:192.168.23.179;lr>
Record-Route: <sip:192.168.23.184;r2=on;lr;ftag=bhkk93kg21>
Record-Route: <sip:192.168.23.184:443;transport=ws;r2=on;lr;ftag=bhkk93kg21>
From: <sip:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com>;tag=bhkk93kg21
To: <sip:+47494949@sip.domain.com>;tag=as09dc2c45
Call-ID: 5hpl8bbtoq2hhhfgcn2k
CSeq: 3488 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE, PRACK, UPDATE
Supported: timer, 100rel
Session-Expires: 3600;refresher=uac
Contact: <sip:+47494949@192.168.23.188:5060>
Require: timer
Content-Length: 0

2024-01-17 16:28:17 +0100 : 192.168.23.184:443 -> 192.168.75.141:60278
SIP/2.0 200 OK
Via: SIP/2.0/WSS e2ecvh8aqqb7.invalid;rport=60278;received=192.168.75.141;branch=z9hG4bK3017171
Record-Route: <sip:192.168.23.179;lr>
Record-Route: <sip:192.168.23.184;r2=on;lr;ftag=bhkk93kg21>
Record-Route: <sip:192.168.23.184:443;transport=ws;r2=on;lr;ftag=bhkk93kg21>
From: <sip:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com>;tag=bhkk93kg21
To: <sip:+47494949@sip.domain.com>;tag=as09dc2c45
Call-ID: 5hpl8bbtoq2hhhfgcn2k
CSeq: 3488 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE, PRACK, UPDATE
Supported: timer, 100rel
Session-Expires: 3600;refresher=uac
Contact: <sip:+47494949@192.168.23.188:5060>
Require: timer
Content-Type: application/sdp
Content-Length: 647

<removed SDP>

2024-01-17 16:28:17 +0100 : 192.168.75.141:60278 -> 192.168.23.184:443
ACK sip:+47494949@192.168.23.188:5060 SIP/2.0
Route: <sip:192.168.23.184:443;transport=ws;r2=on;lr;ftag=bhkk93kg21>
Route: <sip:192.168.23.184;r2=on;lr;ftag=bhkk93kg21>
Route: <sip:192.168.23.179;lr>
Via: SIP/2.0/WSS e2ecvh8aqqb7.invalid;branch=z9hG4bK7058213
Max-Forwards: 69
To: <sip:+47494949@sip.domain.com>;tag=as09dc2c45
From: <sip:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com>;tag=bhkk93kg21
Call-ID: 5hpl8bbtoq2hhhfgcn2k
CSeq: 3488 ACK
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: outbound
User-Agent: JsSIP 3.10.1
Content-Length: 0

2024-01-17 16:28:21 +0100 : 192.168.23.184:443 -> 192.168.75.141:60278
BYE sip:1jjiz6hyxjgzotleyhbeejocnyv@domain.com;gr=urn:uuid:9147fcf9-4eda-4259-8997-55f65ef7c97b SIP/2.0
Via: SIP/2.0/WSS 192.168.23.184:443;branch=z9hG4bK819d.79edfb897b40652e26f39143ec35b1ce.0
Via: SIP/2.0/UDP 192.168.23.179;rport=5060;branch=z9hG4bK819d.363edda7249aa41e91730a76c91ceb7f.0
Via: SIP/2.0/UDP 192.168.23.188:5060;rport=5060;branch=z9hG4bK1652c731
Max-Forwards: 68
From: <sip:+47494949@sip.domain.com>;tag=as09dc2c45
To: <sip:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com>;tag=bhkk93kg21
Call-ID: 5hpl8bbtoq2hhhfgcn2k
CSeq: 102 BYE
Content-Length: 0

2024-01-17 16:28:21 +0100 : 192.168.75.141:60278 -> 192.168.23.184:443
SIP/2.0 404 Not Found
Via: SIP/2.0/WSS 192.168.23.184:443;branch=z9hG4bK819d.79edfb897b40652e26f39143ec35b1ce.0
Via: SIP/2.0/UDP 192.168.23.179;rport=5060;branch=z9hG4bK819d.363edda7249aa41e91730a76c91ceb7f.0
Via: SIP/2.0/UDP 192.168.23.188:5060;rport=5060;branch=z9hG4bK1652c731
To: <sip:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com>;tag=bhkk93kg21
From: <sip:+47494949@sip.domain.com>;tag=as09dc2c45
Call-ID: 5hpl8bbtoq2hhhfgcn2k
CSeq: 102 BYE
Content-Length: 0

[ibc]

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?

[mtryfoss]

You're correct. I'm not specifying the contact directly.
Afaik, I wasn't aware that that was an option.

It seems like some other people also had the same struggle, so would be nice with a fix and/or at least - a clarification :)

[mtryfoss]

I tested using contact_uri too with the original non-lowercased value, and it seems to end with the same result.

[jmillan]

@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.

[mtryfoss]

The user-part of To and From is in lower case, while username in Authorization header is like it should be.

REGISTER sip:domain.com SIP/2.0
Via: SIP/2.0/WSS tkb9vrejfuua.invalid;branch=z9hG4bK9724461
Max-Forwards: 69
To: <sip:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com>
From: <sip:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com>;tag=4l3k4ii8o1
Call-ID: rdpm76h7q47lujq80n9dup
CSeq: 2 REGISTER
Authorization: Digest algorithm=MD5, username="1705577130:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com", realm="domain.com", nonce="...", uri="sip:domain.com", response="..."
Contact: <sip:s64qtlfe@tkb9vrejfuua.invalid;transport=ws>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:44e0581c-0d2a-4a7f-aca5-bfdcddd9f742>";expires=300
Expires: 300
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: path,gruu,outbound
User-Agent: JsSIP 3.10.1
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/WSS tkb9vrejfuua.invalid;rport=49556;received=192.168.75.141;branch=z9hG4bK1484306
To: <sip:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com>;tag=78322ec717f7a5b13edafae546c3bb10.49460000
From: <sip:1jjIz6hYXjgzOTLEyhBEeJoCnYV@domain.com>;tag=kp3a0fcvvq
Call-ID: rdpm76h7q47lujq80n9dup
CSeq: 2 REGISTER
Contact: <sip:s64qtlfe@tkb9vrejfuua.invalid;transport=ws>;expires=300;pub-gruu="sip:1jjiz6hyxjgzotleyhbeejocnyv@domain.com;gr=urn:uuid:44e0581c-0d2a-4a7f-aca5-bfdcddd9f742";temp-gruu="sip:uloc-65a69615-354ff-915-b804a376@domain.com;gr";+sip.instance="<urn:uuid:44e0581c-0d2a-4a7f-aca5-bfdcddd9f742>";reg-id=1
Supported: outbound
Require: outbound
Content-Length: 0

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).
However, I see the user-part of the Kamailio-registration appears to be saved in all lower.

Checking the docs, I see this one:

3.10. case_sensitive (integer)
If set to 1 then AOR comparison and also storing will be case sensitive, if set to 0 then AOR comparison and storing will be case insensitive. This is recommended. This parameter can be modified via Kamailio config framework.

Default value is 0.

Changing that to 1, stores the AOR correct.

Now the INVITE is sent with the correct user in the Contact (and From) too:

Contact: <sip:1jjIz6hYXjgzOTLEyhBEeJoCnYV@....

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.
The question is then, would it cause any trouble for JsSIP to handle this situation for others which may not be able to fix it server side?

[ibc]

Despite what kamailio registrar does, the fact here is that:

1. JsSIP sets this Contact in its INVITE: Contact: <sip:1jjiz6hyxjgzotleyhbeejocnyv@domain.com;gr=urn:uuid:9147fcf9-4eda-4259-8997-55f65ef7c97b>
2. Then JsSIP receives a BYE with RURI sip:1jjiz6hyxjgzotleyhbeejocnyv@domain.com;gr=urn:uuid:9147fcf9-4eda-4259-8997-55f65ef7c97b which perfectly matches the Contact URI that JsSIP used in the INVITE.
3. But JsSIP cannot match the BYE and replies with 404. So something is wrong in JsSIP.

[ibc]

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.

[mtryfoss]

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:

• the default settings in Kamailio is not honouring the RFC for the REGISTER-handling.
• JsSIP is not handling this INVITE/BYE scenario isolated (it should accept the URI in a BYE that has been used as Contact in the INVITE).

[ibc]

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).

[mtryfoss]

This should be before the client workaround, and with default setting in Kamailio.

REGISTER sip:domain.com SIP/2.0
Via: SIP/2.0/WSS q5q96qlrkps3.invalid;branch=z9hG4bK1767564
Max-Forwards: 69
To: <sip:1nbDtTItg1DaVroTrzmBRjLTB7q@domain.com>
From: <sip:1nbDtTItg1DaVroTrzmBRjLTB7q@domain.com>;tag=de0133hugt
Call-ID: igh7bgvafcobtbp26jsgs9
CSeq: 2 REGISTER
Authorization: Digest algorithm=MD5, username="1705508948:1nbDtTItg1DaVroTrzmBRjLTB7q@domain.com", realm="domain.com", nonce="...", uri="sip:domain.com", response="..."
Contact: <sip:7crp59qm@q5q96qlrkps3.invalid;transport=ws>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:d1996bf3-326c-4d2d-9f7b-f91a017f123f>";expires=300
Expires: 300
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: path,gruu,outbound
User-Agent: JsSIP 3.10.1
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/WSS q5q96qlrkps3.invalid;rport=61044;received=192.168.54.193;branch=z9hG4bK1767564
To: <sip:1nbDtTItg1DaVroTrzmBRjLTB7q@domain.com>;tag=78322ec717f7a5b13edafae546c3bb10.b2010000
From: <sip:1nbDtTItg1DaVroTrzmBRjLTB7q@domain.com>;tag=de0133hugt
Call-ID: igh7bgvafcobtbp26jsgs9
CSeq: 2 REGISTER
Contact: <sip:7crp59qm@q5q96qlrkps3.invalid;transport=ws>;expires=300;pub-gruu="sip:1nbdttitg1davrotrzmbrjltb7q@domain.com;gr=urn:uuid:d1996bf3-326c-4d2d-9f7b-f91a017f123f";temp-gruu="sip:uloc-65a69615-35501-6c2-a0423bf8@domain.com;gr";+sip.instance="<urn:uuid:d1996bf3-326c-4d2d-9f7b-f91a017f123f>";reg-id=1
Supported: outbound
Require: outbound
Content-Length: 0

Returned contact: pub-gruu="sip:1nbdttitg1davrotrzmbrjltb7q@domain.com

[ibc]

Returned contact: pub-gruu="sip:1nbdttitg1davrotrzmbrjltb7q@domain.com

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)

[jmillan]

JsSIP is not handling this INVITE/BYE scenario isolated (it should accept the URI in a BYE that has been used as Contact in the INVITE).

I don't think JsSIP should store all temp and and pub GRUU's that have been used during a session. The spec clear says that the GRUU generation must adhere to the following:

https://www.rfc-editor.org/rfc/rfc5627#section-5.4

 Every GRUU is associated with a single AOR
   and a single instance ID.

sip:1nbdttitg1davrotrzmbrjltb7q@domain.com;gr=urn:uuid:d1996bf3-326c-4d2d-9f7b-f91a017f123f
is different from
sip:1NBdttitg1davrotrzmbrjltb7q@domain.com;gr=urn:uuid:d1996bf3-326c-4d2d-9f7b-f91a017f123f

, meaning that the GRUU cannot convert the case of the AOR it contains.

[ibc]

@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?