22 Nov
2017
22 Nov
'17
4:46 p.m.
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