invalid target uri in NOTIFY - missing "sip:" prefix

manti

New Member
Aug 7, 2019
1
0
1
FusionPBX Version: 4.5.27
Switch Version: 1.10.7 (64bit)
OS: Debian 10


Hi all,

I'm facing a really strange problem with invalid NOTIFY messages. More precisely, it's about the target URI in the xml body. It sometimes happens that freeswitch does not send a "sip:" prefix there, which subsequently leads to problems with the call pickup. Most of the time the NOTIFY messages are correct.

Here is an example of an incorrect NOTIFY:

Code:
2022/08/16 16:09:41.063707 xxx.xxx.xxx.xxx:5060 -> xxx.xxx.xxx.xxx:21714
NOTIFY sip:1332@192.168.206.111:36283;line=gx1px7uv SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx;rport;branch=z9hG4bK5HF7D7QXD52ZN
Route: <sip:xxx.xxx.xxx.xxx:21714>;transport=udp
Max-Forwards: 70
From: <sip:1334@example.com>;tag=pSd9MGkrWNc8
To: <sip:1332@example.com>;tag=69kw4joxc5
Call-ID: 313636303633393336323337303634-6pb8txfvfv1b
CSeq: 983549051 NOTIFY
Contact: <sip:1334@xxx.xxx.xxx.xxx:5060>
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: path, replaces
Event: dialog
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Subscription-State: active;expires=60
Content-Type: application/dialog-info+xml
Content-Length: 698

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="580" state="full" entity="sip:1334@example.com">
<dialog id="7df5cdb6-07f6-4704-9f5e-4de1f56254e9" call-id="e5d3160a-980f-123b-e1ae-005056820a6f" local-tag="tU2F9gg1e7yXa" remote-tag="sf6m0bth73" direction="recipient">
 <state>early</state>
 <local>
  <identity display="1334">sip:1334@example.com</identity>
  <target uri="sip:1334@example.com">
   <param pname="+sip.rendering" pvalue="yes"/>
  </target>
 </local>
 <remote>
  <identity display="0699xxxxxxxxx">sip:0699xxxxxxxxx@example.com</identity>
  <target uri="**1334@example.com"/>
 </remote>
</dialog>

</dialog-info>

And this is how the NOTIFY should look like:

Code:
2022/08/16 17:06:36.057218 xxx.xxx.xxx.xxx:5060 -> xxx.xxx.xxx.xxx:18596
NOTIFY sip:1332@192.168.206.111:36283;line=gx1px7uv SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx;rport;branch=z9hG4bK6gHeNQ1cU0Kpj
Route: <sip:xxx.xxx.xxx.xxx:18596>;transport=udp
Max-Forwards: 70
From: <sip:1334@example.com>;tag=YRqaO64TI8zT
To: <sip:1332@example.com>;tag=nuz6vw1mvu
Call-ID: 3136363036363233343636323032-9h1qh5njsstz
CSeq: 983719802 NOTIFY
Contact: <sip:1334@xxx.xxx.xxx.xxx:5060>
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: path, replaces
Event: dialog
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Subscription-State: active;expires=48
Content-Type: application/dialog-info+xml
Content-Length: 584

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="2" state="full" entity="sip:1334@example.com">
<dialog id="6e4cbef2-70c4-4f2d-a50b-95a9af42065c" direction="recipient">
<state>early</state>
<local>
<identity display="1334">sip:1334@example.com</identity>
<target uri="sip:1334@example.com">
<param pname="+sip.rendering" pvalue="yes"/>
</target>
</local>
<remote>
<identity display="0699xxxxxxxxx">sip:xxxxxxxxx@example.com</identity>
<target uri="sip:**1334@example.com"/>
</remote>
</dialog>
</dialog-info>
<target uri="sip:**1334@example.com"/>

If freeswitch sends this wrong NOTIFY on an incoming call and you then make a call pickup, e.g. via a Snom function key, the Snom gets the message "416 Unsupported URI Scheme" back from the server.
Because of the wrong target URI from server the URI of the INVITE from Snom is also wrong:

Code:
INVITE **1334@example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.206.111:36283;branch=z9hG4bK-zubygxrfzeav;rport
From: "1332" <sip:1332@example.com>;tag=vxexbsh2qc
To: "0699xxxxxxxxx" <sip:0699xxxxxxxxx@example.com>
Call-ID: 313636303635373737383237343634-nuwo0dn244ma
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: snomD345/10.1.84.12
Contact: <sip:1332@192.168.206.111:36283;line=gx1px7uv>;reg-id=1
Replaces: 19a09eca-980d-123b-e1ae-005056820a6f;to-tag=856wo6fe4w;from-tag=mp3ZamNFBXKZc
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Session-Expires: 180
Min-SE: 90
Authorization: Digest username="1332",realm="example.com",nonce="14066da0-4c81-491f-8e30-da43b130bf15",uri="**1334@example.com",qop=auth,nc=00000008,cnonce="7652b202",response="ce9e7a1c50075f5ccb6cd7dd60349f73",algorithm=MD5
Content-Type: application/sdp
Content-Length: 212
INVITE **1334@example.com SIP/2.0 instead of INVITE sip:**1334@example.com SIP/2.0

Response from server:

Code:
SIP/2.0 416 Unsupported URI Scheme
Via: SIP/2.0/UDP 192.168.206.111:36283;branch=z9hG4bK-zubygxrfzeav;rport=21714;received=xxx.xxx.xxx.xxx
From: "1332" <sip:1332@example.com>;tag=vxexbsh2qc
To: "0699xxxxxxxxx" <sip:0699xxxxxxxxx@example.com>;tag=p8NHeaQp5e04K
Call-ID: 313636303635373737383237343634-nuwo0dn244ma
CSeq: 1 INVITE
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: path, replaces
Content-Length: 0


I have no idea where this misbehavior comes from. Especially because it only occurs sporadically and works most of the time. This looks like a bug to me.
I hope that someone of you has an idea, or a solution.

Thanks a lot in advance!