Re: [SR-Users] [EXT] Re: Kamailio I-CSCF not sending SIP:200 OK messages to Asterisk (to tag) -RESOLVED

2020-06-26 Thread Martin W Woscek
Hello,

Just wanted to update what fixed our issue.
The "contact_user" which is "asterisk" that we were using for the Kamailio 
context for outgoing SIP trunk/channel in the pjsip.conf file of the Asterisk 
16 server was not a valid user in the IMS HSS database (FHoSS implementation).

However not being an expert in the IMS, IMHO, the IMS should have kicked out 
this INVITE as soon as credentials were checked at the front door of the IMS, 
but rather Kamailio sent it from I-CSCF to S-CSCF to P-CSCF, which is the 
correct flow, until the P-CSCF sent it back to I-CSCF which then resulted in a 
604 HSS user unknown being sent thru the reverse direction back to Asterisk.

Anyway, its always good to end Friday on a high note.

Thanks,
_Martin


From: sr-users  On Behalf Of Martin W 
Woscek
Sent: Wednesday, June 24, 2020 1:32 PM
To: Kamailio (SER) - Users Mailing List ; 
mico...@gmail.com
Subject: Re: [SR-Users] [EXT] Re: Kamailio I-CSCF not sending SIP:200 OK 
messages to Asterisk (to tag)

Just to clarify what we are seeing, here is a packet from the INVITE from the 
S-CSCF (6060) to the P-CSCF(4060).  I have eliminated the S-CSCF as this packet 
looks correct.
The P-CSCF is not handling the request URI correctly, and simply sends it back 
to the I-CSCF where I-CSCF cannot find the user in the HSS based on the ruri 
updated by the S-CSCF with the local IP address of the UE (192.168.20.1).  The 
P-CSCF should send this INVITE to the UE 
(703222888@192.168.20.1<mailto:703222888@192.168.20.1>)

No. Arrival Time SourceDestination   Source Port 
Destination Port SIP to tag SIP from tag Method Record-Route Userinfo 
Request-URI Media Port Protocol Length Request-URI Host Port Owner Username 
Media Type Media Format Origin-Host Type   slice_type SIP from address User 
Part SIP from address Host Part SIP to address User Part SIP to address Host 
Part Contact URI User Part Contact URI Host Part Request-URI User Part 
Request-URI Host Part Request-URI Host Port Info
   1553 Jun 17, 2020 09:31:21.722451703 Eastern Daylight Time 192.168.20.128
192.168.20.12860604060
d490a30c-42a8-4fc0-9fe9-b7a21537386d INVITE mt
sip:703222@192.168.20.1:63871;transport=udp 10626,13370 SIP/SDP  2263   
63871 -  audio,video ITU-T G.711 
PCMU,DynamicRTP-Type-101,0,101,101,DynamicRTP-Type-99,99,99 
  70 asterisk.irisims.org   703222  
 ims522.irisims.org   asterisk  192.168.20.131  
  703222192.168.20.1  63871 Request: 
INVITE sip:703222@192.168.20.1:63871;transport=udp |

Frame 1553: 2263 bytes on wire (18104 bits), 2263 bytes captured (18104 bits) 
on interface any, id 0
Linux cooked capture
Internet Protocol Version 4, Src: 192.168.20.128, Dst: 192.168.20.128
User Datagram Protocol, Src Port: 6060, Dst Port: 4060
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:703222@192.168.20.1:63871;transport=udp SIP/2.0
Method: INVITE
Request-URI: sip:703222@192.168.20.1:63871;transport=udp
Request-URI User Part: 703222
Request-URI Host Part: 192.168.20.1
Request-URI Host Port: 63871
[Resent Packet: False]
Message Header
Record-Route: 

Route: 
Via: SIP/2.0/UDP 
192.168.20.128:6060;branch=z9hG4bK285b.2a57abaad57cfd55bc18a23d4e9cefc8.0
Via: SIP/2.0/UDP 
192.168.20.128;branch=z9hG4bK285b.793ba7dcf9fcd18ddef225b83896340e.1
Via: SIP/2.0/UDP 
192.168.20.131:5060;received=192.168.20.131;rport=5060;branch=z9hG4bKPjef451437-0a4f-4732-ac54-318740956335
From: 
;tag=d490a30c-42a8-4fc0-9fe9-b7a21537386d
To: 
Contact: 
Call-ID: 39c15c42-b0b7-48b5-b4bf-ac7a99fbe660
[Generated Call-ID: 39c15c42-b0b7-48b5-b4bf-ac7a99fbe660]
CSeq: 19314 INVITE
Route: 
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, 
CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 68
User-Agent: Asterisk PBX 16.6.0
Content-Type: application/sdp
Content-Length:  1121
Message Body


From: sr-users 
mailto:sr-users-boun...@lists.kamailio.org>>
 On Behalf Of Martin W Woscek
Sent: Wednesday, June 24, 2020 11:21 AM
To: mico...@gmail.com<mailto:mico...@gmail.com>; Kamailio (SER) - Users Mailing 
List mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] [EXT] Re: Kamailio I-CSCF not sending SIP:200 OK 
messages to Asterisk (to tag)

Hi,
The issue is the P should be sending to the UE not back to the I like the 
failed flow:
Asterisk16-[phone]  --->ICSCF--->S-CSCF--->P-CSCF--->I-CSCF ---> [604  HSS user 
unknown] 

Re: [SR-Users] [EXT] Re: Kamailio I-CSCF not sending SIP:200 OK messages to Asterisk (to tag)

2020-06-24 Thread Martin W Woscek
Just to clarify what we are seeing, here is a packet from the INVITE from the 
S-CSCF (6060) to the P-CSCF(4060).  I have eliminated the S-CSCF as this packet 
looks correct.
The P-CSCF is not handling the request URI correctly, and simply sends it back 
to the I-CSCF where I-CSCF cannot find the user in the HSS based on the ruri 
updated by the S-CSCF with the local IP address of the UE (192.168.20.1).  The 
P-CSCF should send this INVITE to the UE (703222888@192.168.20.1)

No. Arrival Time SourceDestination   Source Port 
Destination Port SIP to tag SIP from tag Method Record-Route Userinfo 
Request-URI Media Port Protocol Length Request-URI Host Port Owner Username 
Media Type Media Format Origin-Host Type   slice_type SIP from address User 
Part SIP from address Host Part SIP to address User Part SIP to address Host 
Part Contact URI User Part Contact URI Host Part Request-URI User Part 
Request-URI Host Part Request-URI Host Port Info
   1553 Jun 17, 2020 09:31:21.722451703 Eastern Daylight Time 192.168.20.128
192.168.20.12860604060
d490a30c-42a8-4fc0-9fe9-b7a21537386d INVITE mt
sip:703222@192.168.20.1:63871;transport=udp 10626,13370 SIP/SDP  2263   
63871 -  audio,video ITU-T G.711 
PCMU,DynamicRTP-Type-101,0,101,101,DynamicRTP-Type-99,99,99 
  70 asterisk.irisims.org   703222  
 ims522.irisims.org   asterisk  192.168.20.131  
  703222192.168.20.1  63871 Request: 
INVITE sip:703222@192.168.20.1:63871;transport=udp |

Frame 1553: 2263 bytes on wire (18104 bits), 2263 bytes captured (18104 bits) 
on interface any, id 0
Linux cooked capture
Internet Protocol Version 4, Src: 192.168.20.128, Dst: 192.168.20.128
User Datagram Protocol, Src Port: 6060, Dst Port: 4060
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:703222@192.168.20.1:63871;transport=udp SIP/2.0
Method: INVITE
Request-URI: sip:703222@192.168.20.1:63871;transport=udp
Request-URI User Part: 703222
Request-URI Host Part: 192.168.20.1
Request-URI Host Port: 63871
[Resent Packet: False]
Message Header
Record-Route: 

Route: 
Via: SIP/2.0/UDP 
192.168.20.128:6060;branch=z9hG4bK285b.2a57abaad57cfd55bc18a23d4e9cefc8.0
Via: SIP/2.0/UDP 
192.168.20.128;branch=z9hG4bK285b.793ba7dcf9fcd18ddef225b83896340e.1
Via: SIP/2.0/UDP 
192.168.20.131:5060;received=192.168.20.131;rport=5060;branch=z9hG4bKPjef451437-0a4f-4732-ac54-318740956335
From: 
;tag=d490a30c-42a8-4fc0-9fe9-b7a21537386d
To: 
Contact: 
Call-ID: 39c15c42-b0b7-48b5-b4bf-ac7a99fbe660
[Generated Call-ID: 39c15c42-b0b7-48b5-b4bf-ac7a99fbe660]
CSeq: 19314 INVITE
Route: 
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, 
CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 68
User-Agent: Asterisk PBX 16.6.0
Content-Type: application/sdp
Content-Length:  1121
Message Body


From: sr-users  On Behalf Of Martin W 
Woscek
Sent: Wednesday, June 24, 2020 11:21 AM
To: mico...@gmail.com; Kamailio (SER) - Users Mailing List 

Subject: Re: [SR-Users] [EXT] Re: Kamailio I-CSCF not sending SIP:200 OK 
messages to Asterisk (to tag)

Hi,
The issue is the P should be sending to the UE not back to the I like the 
failed flow:
Asterisk16-[phone]  --->ICSCF--->S-CSCF--->P-CSCF--->I-CSCF ---> [604  HSS user 
unknown]  to Asterisk16[phone]

The successful call should look like:
Asterisk16-[phone]  --->ICSCF--->S-CSCF--->P-CSCF--->Kamailio-[UE]

Does anyone have a example P-cscf scripts including the mt.cfg or other script 
file that make this work?

The reverse calls work just fine.

Thanks,
_Martin

From: Daniel-Constantin Mierla mailto:mico...@gmail.com>>
Sent: Wednesday, June 24, 2020 4:53 AM
To: Kamailio (SER) - Users Mailing List 
mailto:sr-users@lists.kamailio.org>>; Martin W 
Woscek mailto:mwos...@mitre.org>>
Subject: [EXT] Re: [SR-Users] Kamailio I-CSCF not sending SIP:200 OK messages 
to Asterisk (to tag)


Hello,

Kamailio is not generating the 200ok for INVITE (calls), it just sends out what 
it received from end point, after consuming own Via header (of course, other 
headers can be changed based on config rules, but Kamailio is not in charge of 
setting To-tag).

Cheers,
Daniel
On 19.06.20 21:19, Martin W Woscek wrote:
Hello all,

SIP/UE (boghe or imsdroid) client registered to Kamailio makes call to an 
Asterisk registered SIP phone is successful:
[UE]-Kamailio--->INVITE--->Asterisk16-[phone]
[UE]-Kamailio--->200 OK with 

Re: [SR-Users] [EXT] Re: Kamailio I-CSCF not sending SIP:200 OK messages to Asterisk (to tag)

2020-06-24 Thread Martin W Woscek
Hi,
The issue is the P should be sending to the UE not back to the I like the 
failed flow:
Asterisk16-[phone]  --->ICSCF--->S-CSCF--->P-CSCF--->I-CSCF ---> [604  HSS user 
unknown]  to Asterisk16[phone]

The successful call should look like:
Asterisk16-[phone]  --->ICSCF--->S-CSCF--->P-CSCF--->Kamailio-[UE]

Does anyone have a example P-cscf scripts including the mt.cfg or other script 
file that make this work?

The reverse calls work just fine.

Thanks,
_Martin

From: Daniel-Constantin Mierla 
Sent: Wednesday, June 24, 2020 4:53 AM
To: Kamailio (SER) - Users Mailing List ; Martin W 
Woscek 
Subject: [EXT] Re: [SR-Users] Kamailio I-CSCF not sending SIP:200 OK messages 
to Asterisk (to tag)


Hello,

Kamailio is not generating the 200ok for INVITE (calls), it just sends out what 
it received from end point, after consuming own Via header (of course, other 
headers can be changed based on config rules, but Kamailio is not in charge of 
setting To-tag).

Cheers,
Daniel
On 19.06.20 21:19, Martin W Woscek wrote:
Hello all,

SIP/UE (boghe or imsdroid) client registered to Kamailio makes call to an 
Asterisk registered SIP phone is successful:
[UE]-Kamailio--->INVITE--->Asterisk16-[phone]
[UE]-Kamailio--->200 OK with to_tag--->Asterisk16-[phone]

But in reverse direction for a call, Kamailio does not return the SIP OK so no 
to_tag is sent so call fails to ring and complete:
[phone]-Asterisk16 --->INVITE--->Kamailio

Where the UE device never receives the INVITE, Asterisk never gets and 200 OK 
message with the to_tag from the I-CSCF, the call flow itself gets lost in 
Kamailio, where the P-CSCF sends final INVITE to I-CSCF and and ultimately a 
604 HSS user unknown message is sent back to Asterisk from the I-CSCF.

Basically Im using the default "sample" configs for both the P and the I-CSCF.  
Our sauce is in the S-CSCF for out going calls that originate by a registered 
UE.

Any insight or sample Kamailio configuration that Im lacking?
Has anyone done this and could share the asterisk and Kamailio script snippets 
that make it possible.

Thanks,
_Martin



___

Kamailio (SER) - Users Mailing List

sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>

https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

--

Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com>

www.twitter.com/miconda<http://www.twitter.com/miconda> -- 
www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>

Funding: https://www.paypal.me/dcmierla
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users