Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: Gef Buneri on October 10, 2023, 10:29:34 AM
-
Hello all, hope all is fine around there. Any clue on how to troubleshoot this error? 8801 is the remote number, call is routed (TRoute) from a strategy (URS 8.1.4), to the Sip Server (8.1.1) using a trunk configured with IP:PORT pair of the remote Asterisk. The call invokes the expected trunk, but then this error occurs.
Can it be caused by the remote device?
12:07:43.210: Call 18471603 dn <8801> SetPartyId 22539267
12:07:43.210 SIPCONN(<8801>): SIPCONN(b440dd0,01L0V49B74A87400R5F2E2LAES047EL5) +Tr(72419215,SipTransactionTransferCall)
12:07:43.210 SIPCONN(<8801>): re-invite-null
12:07:43.210 SIPCONN(<8801>): main dialog 0 created, flags 0x21f
12:07:43.210 SIPCONN(<8801>): Local contact: '<sip:[CALLERNUMBER]@[SIPSERVERIP]:[PORT]>'
12:07:43.210: add party info '<8801>' state 0.
12:07:43.210 SIPCONN(<8801>): HandleSipDialogEvent(SEND_INVITE) - filtered
12:07:43.210 SIPCONN(<8801>): sdp state SDP_STATE_NULL, event SDP_EVENT_OFFER_REQUESTED
12:07:43.210 SIPCONN(<8801>): new sdp state SDP_STATE_OFFER_REQUESTED, event SDP_EVENT_OFFER_REQUESTED
12:07:43.236 SIPCONN(<8801>): HandleSipDialogEvent(CALLING_RESREJECT)
12:07:43.236 SIPCONN(<8801>): ConvertResponse: 404
12:07:43.236 SIPCONN(<8801>): ConvertResponse: no conversion configured for 404
2:07:43.236 SIPCONN(<8801>): Failed to obtain Media Server ID
12:07:43.236 SIPCONN(<8801>): Failed to obtain Media Server ID
12:07:43.236 SIPCONN(<8801>): state e:4,p:0,s:6,c:23,rc:404,m:1
12:07:43.236 SIPPARTY(<8801>): 22539267 verify update of party-connection state N-F
12:07:43.236 SIPPARTY(<8801>): 22539267 update party-connection state N-F
AttributeOtherDN '<8801>'
12:07:43.236 SIPCONN(<8801>): terminate dialog
12:07:43.236 SIPCONN(<8801>): state e:4,p:6,s:6,c:23,rc:404,m:1
12:07:43.236 SIPPARTY(<8801>): 22539267 verify update of party-connection state F-F
12:07:43.236 SIPCONN(<8801>): SIPCONN(b440dd0,01L0V49B74A87400R5F2E2LAES047EL5) -Tr(72419215,SipTransactionTransferCall)
12:07:43.237: PI: 01 S[FN]D[<8801>]P[-] - can't recover
12:07:43.237 SIPCONN(<8801>): CONNCHECK: dialog=0
12:07:43.237 SIPCONN(<8801>): CONNCHECK: dialog=0
12:07:43.237 SIPCONN(<8801>): set monitor b440dd0, 0
12:07:43.237 SIPCONN(<8801>): state e:1,p:6,s:0,c:0,rc:0,m:0
12:07:43.237 SIPCONN(<8801>): DetachMediaPeer
12:07:43.237 -- setting cntrlDN=<8801> (for 2 parties)
12:07:43.237 -- setting cntrlDN=<8801> (for 2 parties)
12:07:43.237 ClearContext: party <8801>.bbcca00-aabe200:1
Devices: <-/<8801>> <-/[CALLERNUMBER]> <-/->
Parties: X<8801>/8801.bbcca00-aabe200:1/l:2/r:0/Null,Destination
Parties: X8801/<8801>.bbcca00-aabe200:1/l:2/r:0/Null,Destination
-- XAction: start <8801>.bbcca00-aabe200:1
SetReleased: party <8801>.bbcca00-aabe200:1, cause Null
-- XAction: commit <8801>.bbcca00-aabe200:1
Devices: <-/<8801>> <-/[CALLERNUMBER]> <-/->
Parties: X<8801>/8801.bbcca00-aabe200:1/l:2/r:0/Released,Destination
Parties: X8801/<8801>.bbcca00-aabe200:1/l:2/r:0/Released,Destination
12:07:43.237 -- RemoveParty <8801>.bbcca00-aabe200:1
12:07:43.237: SIPCM: delete party <8801>:22539267
12:07:43.237: SIPCALL(18471603): delete party '<8801>'
**************
The remote device seems to be seen by SipServer, as it retrieves correct ID and version, annd this msg is shown "SIP/2.0 404 Not Found":
12:08:14.896: $+NET:SIP::0:0
12:08:14.896: SIPTR: Received [0,UDP] 605 bytes from REMOTEASTERISKIP]:[PORT] <<<<<
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP [SIPSERVERIP]:[PORT];branch=z9hG4bK0085ADE0-228E-1525-9000-D95E270AAA77;received=[SIPSERVERIP];rport=[PORT]
From: <sip:[EXPECTEDTRUNKNAME]@[SIPSERVERIP]:[PORT]>;tag=0061AB84-2B39-1483-9000-D95E270AAA77-7154780
To: <sip:[EXPECTEDTRUNKNAME]@[SIPSERVERIP]:[PORT]>;tag=as35779a77
Call-ID: 0061AB66-2B39-1483-9000-D95E270AAA77-5458154@[SIPSERVERIP]
CSeq: 1696932494 OPTIONS
Server: Asterisk PBX 1.8.15-cert5
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Accept: application/sdp
Content-Length: 0
12:08:14.896: GSProxyRegistrar:ActiveTransport In Service for dn '[EXPECTEDTRUNKNAME]' '[REMOTEASTERISKIP]:[PORT]:1'
12:08:14.896: $-NET:SIP::0:0
-
It's just a guess without further logs:
Try changing the options "sip-ring-tone-mode" = 1 or "ring-tone-on-make-call" = false (or both)
My guess of what is happening is your SIP Server is attempting to play a ringback but no MSML trunk is configured
-
Thanks Hsujdik, may I provide any further log? which part would be relevant?
btw setting both those options as indicated at the Trunk DN level, doesn't resolve.
-
Oh, nevermind my previous suggestion... it seems Asterisk is replying with 404.
Are you using sip-link-type = 3 on your SIP Server (separate log files for SIP messages)?
If yes, it would be helpful to confirm on <filename>-001.* logs that Asterisk is actually replying an INVITE with SIP/2.0 404 Not Found
Also, on asterisk, are you using chansip or pjsip? If pjsip, you might want to double-check if a trunk to SIP Server is properly set up.
try on asterisk: show pjsip endpoints
-
Sip link type set to 0, here. This file should contain all relevant infos:
[url=https://we.tl/t-nglkO2uxmj]https://we.tl/t-nglkO2uxmj[/url]
yes, the answer is: SIP/2.0 404 Not Found
I'm asking on the remote side about the chansip/pjsip usage.
-
Well, looks like its on Asterisk side then...
so... probably has to check if the number 8801 is actually registered on Asterisk, if it has a dialplan context associated for the incoming call, if the trunk from Asterisk to SIP Server is properly configured...
I'd still start with the: show pjsip endpoints to check for their statuses
-
Thank you very much Hsujdik, unfortunately I have no knowledge of Asterisk, so I'm gathering troubleshooting operations here and there in the web about this topic and I'll try to confront with the remote side to find a solution. I'll keep you informed. Thank you for you precious time.
Currently the remote Asterisk uses CHAN_SIP, but they are considering migrating to PJSIP (it changes anything?)
-
You need to ask Asterisk side, if that number makes sense to their numbering plan, or if maybe there is aneed of a prefix.
Nothing you can solve alone
-
[quote author=Gef Buneri link=topic=12467.msg55425#msg55425 date=1696944792]
Thank you very much Hsujdik, unfortunately I have no knowledge of Asterisk, so I'm gathering troubleshooting operations here and there in the web about this topic and I'll try to confront with the remote side to find a solution. I'll keep you informed. Thank you for you precious time.
Currently the remote Asterisk uses CHAN_SIP, but they are considering migrating to PJSIP (it changes anything?)
[/quote]
well, it changes a little bit on how to troubleshoot on Asterisk side :)
could go for this command to check for the Registered status:
sip show peers
to check for the configuration and the dialplan context:
sip show peer 8801
to check for the configuration and the dialplan of the SIP Server peer:
sip show peer <name of the SIP Server peer>
to check for the dialplan:
show dialplan <name of the context for inbound calls on SIP Server peer>
It could be the Extension is not registered, or maybe the SIP Server peer context does not have a proper dialplan to send the call to the 8801 "friend" (extension)
-
Currently I solved the 404 asking to the Asterisk side to configure the peer type as peer and the context as default as reported by the Sip Server integration guide, now the call is up and stays up, so the signaling seems established, but totally mute. Waiting availability from the "lan guys" to check the correct RTP flux to and from the devices.
-
Be careful not to have NAT and if so, you will need some extra configurations. Check your SIP logs to determine the RTP target ip address and port.
Enviado de meu SM-S918B usando o Tapatalk
-
Hi Cav, thank you. RDP address and ports are the next element in the investigation.
Any clue about the extra configuration you're pointing to? btw don't think nat is enabled, but I'll check that too.
Other services than Sip Server and Media Servers need to be allowed in the tunneling between the two endpoints?
-
RTP is between your SBC and Endpoints. If you are doing recording then yes, media servers too.
Enviado de meu SM-S918B usando o Tapatalk
-
No recording, only call transfers, unidirectional from Sip Server to the remote Asterisk. No way back, at the moment.
-
Ok so SBC should be fine.
Enviado de meu SM-S918B usando o Tapatalk
-
Ok, so in the end it seems that it's all about access policies on the SBC. Someone "forgot" that all trunks passing through this Sip server are forced to pass the RTP content through the SBC that isn't allowed to send/receive to and from the endpoint IP.
So basically the points to fix where 2:
1. 404 error on the remote side: "NOT FOUND" - resolved by configuring peers as type=peer on the Asterisk side and context=default, as reported in the Integration Reference Manual for Sip Server.
2. ACP rules on the SBC side that still need to be fully fixed to allow RTP content to go back and forth from the remote Asterisk IP.
Thank you all for the advice you have given me.