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@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@B.B.B.B>;tag=eytD49ymQr71S

To: <sip:1111111111@mnc001.mcc001.3gppnetwork.org>

Call-ID: 77d249c0-487c-1236-1997-00163edbaa97

CSeq: 115249948 INVITE

Contact: <sip:mod_sofia@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@mobile.tuenti.int>;npi=ISDN;noa=4

X-FS-Support: update_display,send_info

Remote-Party-ID: "222222222" <sip:222222222@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@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@B.B.B.B>;tag=eytD49ymQr71S

To: <sip:1111111111@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