[SR-Users] RV: CANCEL not being matched by tm module when via address does not have port included

CARLOS GARCIA MORCHON carlos.garciamorchon at telefonica.com
Wed Nov 22 12:57:25 CET 2017


Hi,

I have an IMS core deployed using kamailio 5.0.2. Calls from clients are reaching the core pcscf from a freeswitch (with address A.A.A.A) + a kamailio acting as proxy (with address B.B.B.B), so the INVITE request looks like this:


INVITE sip:1111111111 at mnc001.mcc001.3gppnetwork.org SIP/2.0
Record-Route: <sip:A.A.A.A;lr>
Via: SIP/2.0/UDP A.A.A.A;branch=z9hG4bK8735.ef7a61e110f335b2e92a8c1d430de585.0
Via: SIP/2.0/UDP B.B.B.B:5080;received=B.B.B.B;rport=5080;branch=z9hG4bKHpB704ZaXSKtm
Max-Forwards: 65
From: "222222222" <sip:222222222 at B.B.B.B>;tag=eytD49ymQr71S
To: <sip:1111111111 at mnc001.mcc001.3gppnetwork.org>
Call-ID: 77d249c0-487c-1236-1997-00163edbaa97
CSeq: 115249948 INVITE
Contact: <sip:mod_sofia at B.B.B.B:5080>
User-Agent: FreeSWITCH-mod_sofia/1.6.19+git~20170927T175834Z~38f568d343~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 224
P-Charge-Info: <sip:222222222 at mobile.tuenti.int>;npi=ISDN;noa=4
X-FS-Support: update_display,send_info
Remote-Party-ID: "222222222" <sip:222222222 at B.B.B.B>;party=calling;screen=yes;privacy=off


If the client cancels the request, the CANCEL request that gets to the core pcscf looks like this:

CANCEL sip:1111111111 at mnc001.mcc001.3gppnetwork.org SIP/2.0
Via: SIP/2.0/UDP A.A.A.A;branch=z9hG4bK8735.ef7a61e110f335b2e92a8c1d430de585.0
Max-Forwards: 65
From: "222222222" <sip:222222222 at B.B.B.B>;tag=eytD49ymQr71S
To: <sip:1111111111 at mnc001.mcc001.3gppnetwork.org>
Call-ID: 77d249c0-487c-1236-1997-00163edbaa97
CSeq: 115249948 CANCEL
Content-Length: 0
Reason: Q.850;cause=16;text="Normal Call Clearing"

The processing of the CANCEL at the pcscf is eventually reaching the t_check_trans() function, but the logs return “no CANCEL matching found!” and thus the processing ends. I have followed the code up to the via_matching function in the t_lookup.c file of the tm module source and added some logs. The via matching is failing at the port comparison (the port stored for the INVITE is “5060”, the port stored for the CANCEL is “0”.
The flow works ok with a different client (connected directly to the core) which includes the port in the Via headers.
¿Can this be a bug in kamailio or am I doing something wrong?. AFAIK The RFC 3261 does not mandate to include the ports in the sent-by element of the Via header

Thanks!

Carlos

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171122/f218af0d/attachment.html>


More information about the sr-users mailing list