Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
1245
Views
2
Helpful
9
Replies

CUBE outgoing to IMS SIP trunk using dns for session target/registrar

Go to solution
steveAkerman
Level 1
Level 1

‎06-04-2023 05:09 AM

Good morning,

My outgoing SIP Trunk provider uses IMS and multiple servers (3 FQDN each resolving to 7 IP addresses).

The provider requires that outbound calls go to the same IP as the registration, if not a 407 is returned without authorisation credentials, and the call fails.

Initially, I selected one IP address and hard coded that for the Registrar and Session target. Predictably this eventually failed when the provider reconfigured his network topology.

I then switch to using the same FQDN for Registrar and session target. 

This also failed as the provider uses round-robin on the dns and each INVITE does a new lookup so it is unlikely that the returned IP will match.

To bypass this, I set up dnsmasq on a local server to return only one ip address, and to refresh this address every 24 hours.

This still failed, as the CUBE caches the Registrar IP. When I do the dns refresh and the IP changes, I am now sending to the wrong IP, and getting a 407 as the CUBE refuses to do a new dns lookup for the REGISTER (with/without outbound-proxy; with/without reuse).

To resolve this, I now run a cron applet to change the tenant registrar, after the dns refresh:

 

 

event manager applet reset_registrar
 event timer cron name job1 cron-entry "15 4 * * 0-6"
 action 1 cli command "enable"
 action 2 cli command "config t"
 action 3 cli command "voice class tenant 1"
 action 4 cli command "no registrar"
 action 5 cli command "registrar dns:xxxxxxxxxxx:5062 expires 600 auth-realm yyyy"
 action 6 cli command "end"

 

 

This works, as it forces a fresh lookup to resolve the dns, but seems like a lot of workarounds for what should be a simple configuration, and I consider it less than elegant.

My questions is:

Is there any way to stop the CUBE caching the dns result for the REGISTER?

Appreciate any ideas, and hope that if there is no solution, that these workarounds may be of use to someone else

 

 

 

 

0 Helpful
1 Accepted Solution

Accepted Solutions

Go to solution
steveAkerman
Level 1
Level 1

‎06-27-2023 12:32 AM - edited ‎06-27-2023 12:45 AM

The answer to my question is yes. 

To control dns caching of the registrar dns lookup, the command is

 

timers dns registrar-cache ttl

 

As I am using dnsmasq, the default ttl returned is 0 so there is no caching. If the ttl is high, the solution is to use

 

timers dns registrar-cache 60

 

which sets the ttl to the minimum 60 s.

This can be set at the tenant or the system level (sip-ua) noting that if set at the tenant, there is no way to show the actual value. The command

 

show sip-ua timers

 

will show the current value at the system level, which may or maynot be overridden by the tenant!!!

There is another setting that has to be disabled in order for this to work, which is the "outbound proxy .....reuse."

If this is set, the system will reuse the last successful Registrar, (effectively caching the ip address returned from the dns), which means that troubleshooting can be painful. This command is only useful if the Registrar returns a service-route header in the 200 OK, which mine does not. If there was this header, then all subsequent invites would go to the Registrar.

The best debug to check that this works correctly, is "ip domain"; this will show a dns query at each registration attempt.

Finally, the documentation is misleading for both of these settings!

I hope that this helps someone, and thanks to all who proposed assistance.

 

 

 

View solution in original post

9 Replies 9

Go to solution
Celso Silva
Level 1
Level 1

‎06-04-2023 08:56 AM

This seems to be a case for sip header manipulation. Sharing traces for a good and bad call is a good starting point.
0 Helpful

Go to solution
Jonathan Schulenberg
Hall of Fame
Hall of Fame

‎06-04-2023 02:47 PM

Have you tried “session target registrar” by chance? Your post suggests that you’re specifying an IPv4 or DNS value on the session target; registrar should force CUBE to use the specific server it has an active registration with.

Go to solution
steveAkerman
Level 1
Level 1
In response to Jonathan Schulenberg

‎06-16-2023 11:38 PM

Sorry for the delay replying Jonathan

I tried using “session target registrar”, which I agree appears to be the correct solution, but outbound calls just failed (nothing left the CUBE) as if it did not know which registrar to use.

There were two other options possibly related - "Registrar Index" and "associate registered-number", but whatever combination I tried, calls failed. I am sure that this is a configuration issue. Below are the current dial-peer and tenant configs:

dial-peer voice 22 voip
 description outgoing calls to xxx from cube
 preference 1
 destination-pattern 0T
 session protocol sipv2
 session target dns:FQDN:5062
 session transport udp
 voice-class codec 10  
 no voice-class sip early-offer forced
 voice-class sip profiles 2
 voice-class sip tenant 1
 voice-class sip bind control source-interface GigabitEthernet0/2
 dtmf-relay rtp-nte sip-notify
 no vad
voice class tenant 1
  registrar dns:FQDN:5062 expires 600 auth-realm REALM
  credentials number +123456 username USERNAME password 7 realm REALM
  authentication username USERNAME password 7 PASSWORD realm REALM
  rel1xx disable
  bind control source-interface GigabitEthernet0/2
  bind media source-interface GigabitEthernet0/2
  no pass-thru content custom-sdp
  sip-profiles 3
  outbound-proxy dns:FQDN:5062 reuse
  early-offer forced

With this configuration, all calls are fine but I have to hack the DNS......

0 Helpful

Go to solution
Roger Kallberg
VIP
VIP
In response to steveAkerman

‎06-17-2023 11:47 PM - edited ‎06-17-2023 11:51 PM

Can you please share the output from these debugs running in parallel, debug ccsip message and debug voip ccapi inout, for a call that fails with the session target set to registrar?

Also I’m wondering if this command is actually needed or if it could be apart of your problem?

outbound-proxy dns:FQDN:5062 reuse

 



Response Signature


0 Helpful

Go to solution
steveAkerman
Level 1
Level 1
In response to Roger Kallberg

‎06-21-2023 07:04 AM

Please see the relevant sections of a session with a FQDN session target, and a REGISTRAR session target:

Successful Call (Session Target FQDN)

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.50.254:5060;rport;branch=z9hG4bKPj0faf69b2-b38b-4abf-80ff-c3a262286bd1
From: <sip:+33xxxxxxxxxx@169.254.171.243;user=phone>;tag=d474238a-448c-469c-9f2a-32adfb85cb00
To: <sip:0123456789@192.168.50.1;user=phone>
Date: Wed, 21 Jun 2023 13:41:59 GMT
Call-ID: 6caa676a-114f-4ecc-882a-42edbcf1d720
CSeq: 29050 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.7.3.M8
Session-ID: 00000000000000000000000000000000;remote=9c4635eacfc857dc85d93e05b3697bae
Content-Length: 0


Jun 21 2023 15:41:59.785 CEST: //2915/3B209C228AA2/CCAPI/ccCallProceeding:
   Progress Indication=NULL(0)
Jun 21 2023 15:41:59.785 CEST: //2915/3B209C228AA2/CCAPI/ccCallSetupRequest:
   Destination=, Calling IE Present=TRUE, Mode=0,
   Outgoing Dial-peer=22, Params=0x25631DEC, Progress Indication=NULL(0)
Jun 21 2023 15:41:59.785 CEST: //2915/3B209C228AA2/CCAPI/ccCheckClipClir:
   In: Calling Number=+33xxxxxxxx(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed)
Jun 21 2023 15:41:59.785 CEST: //2915/3B209C228AA2/CCAPI/ccCheckClipClir:
   Out: Calling Number=+33xxxxxxxxxx(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed)
Jun 21 2023 15:41:59.785 CEST: //2915/3B209C228AA2/CCAPI/ccCallSetupRequest:
   Destination Pattern=0T, Called Number=0123456789, Digit Strip=FALSE
Jun 21 2023 15:41:59.785 CEST: //2915/3B209C228AA2/CCAPI/ccCallSetupRequest:
   Calling Number=+33xxxxxxxxxxx(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
   Called Number=0123456789(TON=Unknown, NPI=Unknown),
   Redirect Number=, Display Info=
   Account Number=+33xxxxxxxxxx, Final Destination Flag=TRUE,
   Guid=3B209C22-0F70-11EE-8AA2-E8F3F8227D38, Outgoing Dial-peer=22
Jun 21 2023 15:41:59.785 CEST: //2915/3B209C228AA2/CCAPI/cc_api_display_ie_subfields:
   ccCallSetupRequest:
   cisco-username=+33xxxxxxxxxx
   ----- ccCallInfo IE subfields -----
   cisco-ani=+33xxxxxxxxxxx
   cisco-anitype=0
   cisco-aniplan=0
   cisco-anipi=0
   cisco-anisi=0
   dest=0123456789
   cisco-desttype=0
   cisco-destplan=0
   cisco-rdie=FFFFFFFF
   cisco-rdn=
   cisco-rdntype=0
   cisco-rdnplan=0
   cisco-rdnpi=-1
   cisco-rdnsi=-1
   cisco-redirectreason=-1   fwd_final_type =0
   final_redirectNumber =
   hunt_group_timeout =0

Jun 21 2023 15:41:59.785 CEST: //2915/3B209C228AA2/CCAPI/ccIFCallSetupRequestPrivate:
   Interface=0x3F2C71B8, Interface Type=3, Destination=, Mode=0x0,
   Call Params(Calling Number=+33547925499,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
   Called Number=0123456789(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
   Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=22, Call Count On=FALSE,
   Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)
Jun 21 2023 15:41:59.785 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
   
Jun 21 2023 15:41:59.785 CEST: :cc_get_feature_vsa malloc success
Jun 21 2023 15:41:59.785 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
   
Jun 21 2023 15:41:59.789 CEST:  cc_get_feature_vsa count is 2
Jun 21 2023 15:41:59.789 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
   
Jun 21 2023 15:41:59.789 CEST: :FEATURE_VSA attributes are: feature_name:0,feature_time:633124912,feature_id:20
Jun 21 2023 15:41:59.789 CEST: //2915/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
   
Jun 21 2023 15:41:59.789 CEST: cc_api_get_xcode_stream : 5007
Jun 21 2023 15:41:59.789 CEST: //2915/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
   
Jun 21 2023 15:41:59.789 CEST: cc_api_get_xcode_stream : 5007
Jun 21 2023 15:41:59.789 CEST: //2915/3B209C228AA2/CCAPI/cc_api_event_indication:
   Event=101, Call Id=2915
Jun 21 2023 15:41:59.789 CEST: //2915/3B209C228AA2/CCAPI/cc_api_event_indication:
   Event Is Sent To Conferenced SPI(s) Directly
Jun 21 2023 15:41:59.789 CEST: //2916/3B209C228AA2/CCAPI/ccIFCallSetupRequestPrivate:
   SPI Call Setup Request Is Success; Interface Type=3, FlowMode=1
Jun 21 2023 15:41:59.789 CEST: //2916/3B209C228AA2/CCAPI/ccCallSetContext:
   Context=0x25631D9C
Jun 21 2023 15:41:59.789 CEST: //2915/3B209C228AA2/CCAPI/ccSaveDialpeerTag:
   Outgoing Dial-peer=22
Jun 21 2023 15:41:59.789 CEST: //2916/3B209C228AA2/CCAPI/ccGetMediaClassTag:
   media class tag 0
Jun 21 2023 15:41:59.789 CEST: //2916/3B209C228AA2/CCAPI/ccSetMediaclassIp2ipTags:
   media class tags set: NR 0, ASP 0
Jun 21 2023 15:41:59.789 CEST: //2915/3B209C228AA2/CCAPI/ccGetMediaClassTag:
   media class tag 0
Jun 21 2023 15:41:59.789 CEST: //2915/3B209C228AA2/CCAPI/ccSetMediaclassIp2ipTags:
   media class tags set: NR 0, ASP 0
Jun 21 2023 15:41:59.789 CEST: //2916/3B209C228AA2/CCAPI/ccGet_xc_nr_asp_info:
   media class tags: NR 0, ASP 0
Jun 21 2023 15:41:59.789 CEST: //2915/3B209C228AA2/CCAPI/ccGet_xc_nr_asp_info:
   media class tags: NR 0, ASP 0
Jun 21 2023 15:41:59.789 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_is_cng_fax_detect_active:
   Call Id 2915
Jun 21 2023 15:41:59.789 CEST: //2916/3B209C228AA2/CCAPI/cc_api_call_proceeding:
   Interface=0x3F2C71B8, Progress Indication=NULL(0)
Jun 21 2023 15:41:59.789 CEST: Domain: Using source interface GigabitEthernet0/0.10
Jun 21 2023 15:41:59.789 CEST: search_nametype_index: FQDN
Jun 21 2023 15:41:59.789 CEST: search_nametype_index: found FQDN for FQDN
Jun 21 2023 15:41:59.789 CEST: //2916/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
   
Jun 21 2023 15:41:59.789 CEST: cc_api_get_xcode_stream : 5007
Jun 21 2023 15:41:59.793 CEST: //2916/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
   
Jun 21 2023 15:41:59.793 CEST: cc_api_get_xcode_stream : 5007
Jun 21 2023 15:41:59.793 CEST: //2916/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
   
Jun 21 2023 15:41:59.793 CEST: cc_api_get_xcode_stream : 5007
Jun 21 2023 15:41:59.793 CEST: //2916/3B209C228AA2/SIP/Msg/ccsipDisplayMsg:
Sent: 
INVITE sip:0123456789@

Failed Call (Session Target Registrar)

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.50.254:5060;rport;branch=z9hG4bKPjd61beb0d-df97-4667-b09b-030411965146
From: <sip:+33xxxxxxxxxx@169.254.171.243;user=phone>;tag=42bcb7cd-f6eb-4e0f-85db-3a8be42d79bc
To: <sip:0123456789@192.168.50.1;user=phone>
Date: Wed, 21 Jun 2023 13:47:52 GMT
Call-ID: da6bd4e0-2d58-4886-97fb-d112eb089a1c
CSeq: 23393 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.7.3.M8
Session-ID: 00000000000000000000000000000000;remote=dde908c2b6285e1fb61031b49d7e2481
Content-Length: 0


Jun 21 2023 15:47:52.392 CEST: //2927/0D4B8F808AB2/CCAPI/ccCallProceeding:
   Progress Indication=NULL(0)
Jun 21 2023 15:47:52.392 CEST: //2927/0D4B8F808AB2/CCAPI/ccCallSetupRequest:
   Destination=, Calling IE Present=TRUE, Mode=0,
   Outgoing Dial-peer=22, Params=0x256196FC, Progress Indication=NULL(0)
Jun 21 2023 15:47:52.392 CEST: //2927/0D4B8F808AB2/CCAPI/ccCheckClipClir:
   In: Calling Number=+33xxxxxxxxxx(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed)
Jun 21 2023 15:47:52.392 CEST: //2927/0D4B8F808AB2/CCAPI/ccCheckClipClir:
   Out: Calling Number=+33xxxxxxxxxxx(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed)
Jun 21 2023 15:47:52.392 CEST: //2927/0D4B8F808AB2/CCAPI/ccCallSetupRequest:
   Destination Pattern=0T, Called Number=0123456789, Digit Strip=FALSE
Jun 21 2023 15:47:52.392 CEST: //2927/0D4B8F808AB2/CCAPI/ccCallSetupRequest:
   Calling Number=+33xxxxxxxxxx(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
   Called Number=0123456789(TON=Unknown, NPI=Unknown),
   Redirect Number=, Display Info=
   Account Number=+33xxxxxxx, Final Destination Flag=TRUE,
   Guid=0D4B8F80-0F71-11EE-8AB2-E8F3F8227D38, Outgoing Dial-peer=22
Jun 21 2023 15:47:52.392 CEST: //2927/0D4B8F808AB2/CCAPI/cc_api_display_ie_subfields:
   ccCallSetupRequest:
   cisco-username=+33xxxxxxxxx
   ----- ccCallInfo IE subfields -----
   cisco-ani=+33xxxxxxxxx
   cisco-anitype=0
   cisco-aniplan=0
   cisco-anipi=0
   cisco-anisi=0
   dest=0123456789
   cisco-desttype=0
   cisco-destplan=0
   cisco-rdie=FFFFFFFF
   cisco-rdn=
   cisco-rdntype=0
   cisco-rdnplan=0
   cisco-rdnpi=-1
   cisco-rdnsi=-1
   cisco-redirectreason=-1   fwd_final_type =0
   final_redirectNumber =
   hunt_group_timeout =0

Jun 21 2023 15:47:52.392 CEST: //2927/0D4B8F808AB2/CCAPI/ccIFCallSetupRequestPrivate:
   Interface=0x3F2C71B8, Interface Type=3, Destination=, Mode=0x0,
   Call Params(Calling Number=+33547925499,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),
   Called Number=0123456789(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
   Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=22, Call Count On=FALSE,
   Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)
Jun 21 2023 15:47:52.392 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
   
Jun 21 2023 15:47:52.392 CEST: :cc_get_feature_vsa malloc success
Jun 21 2023 15:47:52.392 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
   
Jun 21 2023 15:47:52.392 CEST:  cc_get_feature_vsa count is 2
Jun 21 2023 15:47:52.392 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
   
Jun 21 2023 15:47:52.396 CEST: :FEATURE_VSA attributes are: feature_name:0,feature_time:633125136,feature_id:22
Jun 21 2023 15:47:52.396 CEST: //2927/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
   
Jun 21 2023 15:47:52.396 CEST: cc_api_get_xcode_stream : 5007
Jun 21 2023 15:47:52.396 CEST: //2927/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
   
Jun 21 2023 15:47:52.396 CEST: cc_api_get_xcode_stream : 5007
Jun 21 2023 15:47:52.396 CEST: //2927/0D4B8F808AB2/CCAPI/cc_api_event_indication:
   Event=101, Call Id=2927
Jun 21 2023 15:47:52.396 CEST: //2927/0D4B8F808AB2/CCAPI/cc_api_event_indication:
   Event Is Sent To Conferenced SPI(s) Directly
Jun 21 2023 15:47:52.396 CEST: //2928/0D4B8F808AB2/CCAPI/ccIFCallSetupRequestPrivate:
   SPI Call Setup Request Is Success; Interface Type=3, FlowMode=1
Jun 21 2023 15:47:52.396 CEST: //2928/0D4B8F808AB2/CCAPI/ccCallSetContext:
   Context=0x256196AC
Jun 21 2023 15:47:52.396 CEST: //2927/0D4B8F808AB2/CCAPI/ccSaveDialpeerTag:
   Outgoing Dial-peer=22
Jun 21 2023 15:47:52.396 CEST: //2928/0D4B8F808AB2/CCAPI/ccGetMediaClassTag:
   media class tag 0
Jun 21 2023 15:47:52.396 CEST: //2928/0D4B8F808AB2/CCAPI/ccSetMediaclassIp2ipTags:
   media class tags set: NR 0, ASP 0
Jun 21 2023 15:47:52.396 CEST: //2927/0D4B8F808AB2/CCAPI/ccGetMediaClassTag:
   media class tag 0
Jun 21 2023 15:47:52.396 CEST: //2927/0D4B8F808AB2/CCAPI/ccSetMediaclassIp2ipTags:
   media class tags set: NR 0, ASP 0
Jun 21 2023 15:47:52.396 CEST: //2928/0D4B8F808AB2/CCAPI/ccGet_xc_nr_asp_info:
   media class tags: NR 0, ASP 0
Jun 21 2023 15:47:52.396 CEST: //2927/0D4B8F808AB2/CCAPI/ccGet_xc_nr_asp_info:
   media class tags: NR 0, ASP 0
Jun 21 2023 15:47:52.396 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_is_cng_fax_detect_active:
   Call Id 2927
Jun 21 2023 15:47:52.400 CEST: //2928/0D4B8F808AB2/CCAPI/cc_api_call_disconnected:
   Cause Value=3, Interface=0x3F2C71B8, Call Id=2928
Jun 21 2023 15:47:52.400 CEST: //2928/0D4B8F808AB2/CCAPI/cc_api_call_disconnected:
   Call Entry(Responsed=TRUE, Cause Value=3, Retry Count=0)
Jun 21 2023 15:47:52.400 CEST: //2927/0D4B8F808AB2/CCAPI/ccCallReleaseResources:
   release reserved xcoding resource.
Jun 21 2023 15:47:52.400 CEST: //2928/0D4B8F808AB2/CCAPI/ccCallSetAAA_Accounting:
   Accounting=0, Call Id=2928
Jun 21 2023 15:47:52.400 CEST: //2928/0D4B8F808AB2/CCAPI/ccCallDisconnect:
   Cause Value=3, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=3)
Jun 21 2023 15:47:52.400 CEST: //2928/0D4B8F808AB2/CCAPI/ccCallDisconnect:
   Cause Value=3, Call Entry(Responsed=TRUE, Cause Value=3)
Jun 21 2023 15:47:52.408 CEST: //2928/0D4B8F808AB2/CCAPI/cc_api_call_disconnect_done:
   Disposition=-11, Interface=0x3F2C71B8, Tag=0x0, Call Id=2928,
   Call Entry(Disconnect Cause=3, Voice Class Cause Code=0, Retry Count=0)
Jun 21 2023 15:47:52.408 CEST: //2928/0D4B8F808AB2/CCAPI/cc_api_call_disconnect_done:
   Call Disconnect Event Sent
Jun 21 2023 15:47:52.408 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
   
Jun 21 2023 15:47:52.408 CEST: :cc_free_feature_vsa freeing 25BCB908
Jun 21 2023 15:47:52.408 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
   
Jun 21 2023 15:47:52.408 CEST:  vsacount in free is 1
Jun 21 2023 15:47:52.408 CEST: //2927/0D4B8F808AB2/CCAPI/ccCallDisconnect:
   Cause Value=3, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Jun 21 2023 15:47:52.408 CEST: //2927/0D4B8F808AB2/CCAPI/ccCallDisconnect:
   Cause Value=3, Call Entry(Responsed=TRUE, Cause Value=3)
Jun 21 2023 15:47:52.408 CEST: //2927/0D4B8F808AB2/SIP/Msg/ccsipDisplayMsg:
Sent: 
SIP/2.0 404 Not Found

I agree with you on removing the outbound proxy - it has no affect. However according to the documentation, it is the required configuration.

Regarding "Associated Registered-Number" - is this the "line" as shown in "show sip-ua register status" - it appears also to have no effect

Appreciate any thoughts that you may have

 

 

 

0 Helpful

Go to solution
Roger Kallberg
VIP
VIP
In response to steveAkerman

‎06-21-2023 07:44 AM

You are getting a cause value 3, that means no route to destination. It seems like you may have enabled one of the two debugs that I suggested as I see no output from debug ccsip message. Can you please redo the same tests and make sure that you have both debugs running and that you capture the entire call dialogue?



Response Signature


0 Helpful

Go to solution
steveAkerman
Level 1
Level 1
In response to Roger Kallberg

‎06-21-2023 10:30 PM

Both debugs are enabled - the output posted has been truncated to improve focus; each starts with the 100 Trying, and ends with the start of the next message. Prior messages are identical, and at the end, it either passes with an INVITE to the trunk, or fails with a 404. I have only posted the relevant parts as the issue is clearly that with "session target registrar"; as you point out, it finds no destination.

0 Helpful

Go to solution
Roger Kallberg
VIP
VIP
In response to steveAkerman

‎06-22-2023 02:24 AM - edited ‎06-22-2023 02:26 AM

It would help if you could post the complete output of the entire dialogue as is, without removing parts that you do not think is relevant. Please collect it and save it in a text file and attach that to the post as that makes it much easier to look at what's going on.



Response Signature


0 Helpful

Go to solution
steveAkerman
Level 1
Level 1

‎06-27-2023 12:32 AM - edited ‎06-27-2023 12:45 AM

The answer to my question is yes. 

To control dns caching of the registrar dns lookup, the command is

 

timers dns registrar-cache ttl

 

As I am using dnsmasq, the default ttl returned is 0 so there is no caching. If the ttl is high, the solution is to use

 

timers dns registrar-cache 60

 

which sets the ttl to the minimum 60 s.

This can be set at the tenant or the system level (sip-ua) noting that if set at the tenant, there is no way to show the actual value. The command

 

show sip-ua timers

 

will show the current value at the system level, which may or maynot be overridden by the tenant!!!

There is another setting that has to be disabled in order for this to work, which is the "outbound proxy .....reuse."

If this is set, the system will reuse the last successful Registrar, (effectively caching the ip address returned from the dns), which means that troubleshooting can be painful. This command is only useful if the Registrar returns a service-route header in the 200 OK, which mine does not. If there was this header, then all subsequent invites would go to the Registrar.

The best debug to check that this works correctly, is "ip domain"; this will show a dns query at each registration attempt.

Finally, the documentation is misleading for both of these settings!

I hope that this helps someone, and thanks to all who proposed assistance.

 

 

 

Customers Also Viewed These Support Documents