SIP/2.0 481 Call Leg/Transaction Does Not Exist

[Arturo J Garcia Jmz]

Some transfer calls , end with this error :SIP/2.0 481 Call Leg/Transaction Does Not Exist

It is something related to the network configuration, like DNS?

Or it is more related with some value on the phone configuration

Specially on the blind transfers

[Michael Picher]

95% of the time the problem is DNS...

4.9% of the time its MTU

0.1% of the time it's misconfigured.

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/cadc91ac-66c4-4da5-971c-935bc353c68cn%40googlegroups.com.

--

 

Michael Picher Product Manager, UCaaS 215.297.4400 x.445 751 Arbor Way, Arbor Crest I, Suite 150, Blue Bell, PA 19422 coredial.com

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

[Todd Hodgen]

Awesome answer Mr. Picher!   Woke me up just before going to bed!!!

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/CAKs31W3vB5p2p1FuWya6hebctrLjFS6epdJvLwc_QnE1MjwhmA%40mail.gmail.com.

[Michael Picher]

LoL...  sweet dreams :-)

[Arturo J Garcia Jmz]

Thanks Michael,

Great !, so when you said, DNS is because the phones are configured with IP in SIP server instead the FQN?

Because all my phones point to the ip at my sipxerver DNS as IP not FQN

MTU inside the the LAN?, my topology is only LAN.

[Todd Hodgen]

Describe your architecture.  How many phone?  What is your router, you dns, etc.

Can you turn on dhcp on your sipxcom server for testing?  With it on, reset some phones, then try blind transfer.  If it works, your dns is lacking srv records most likely

sent using my two left twiddling thumbs

---

From: sipxco...@googlegroups.com <sipxco...@googlegroups.com> on behalf of Arturo J Garcia Jmz <arturojg...@gmail.com>
Sent: Thursday, December 8, 2022 6:40:23 PM
To: sipxcom-users <sipxco...@googlegroups.com>
Subject: Re: [sipxcom-users] SIP/2.0 481 Call Leg/Transaction Does Not Exist

 

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/c8216f68-bf6c-4b42-90e6-524b1c37bd04n%40googlegroups.com.

[Arturo J Garcia Jmz]

Thanks

It is simple architecture.

One LAN, 20 phones all of them Grandstream (GXP2130 and WP810), 5 desk phones , the rest wifi phones, router is a TP-link TL-ER7206 ( with ALG and all those values dissabled) , my LAN has a win 2016 server with AD ( DNS and DHCP)

But the phones are configured to point DNS to sipxcom server with a IP value and the 066 value on DHCP to point sipxcom server

The test on the sipxcom DNS advisor , shows "DNS Configuration is valid"

My main concern or dobout is the value on the sip server ,should be as FQN or IP value if Im using to point sipxcom phone , and the DNS value on the Phone should be  A record or SRV or NAPTR/SRV? and the "General Setting" show a Outbond Proxy, this value should be the same IP of sipxcom server?

It is a significant difference?

Thanks

[Michael Picher]

You answered your own question.

Don't use IP...  Use fqdn/DNS. See the wiki.

95% of the time the problem is DNS (and people trying to avoid using it)

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/c8216f68-bf6c-4b42-90e6-524b1c37bd04n%40googlegroups.com.

[Michael Picher]

The MTU thing is a telcom joke...

Pretend your computer is a phone and configure it the same way, then do the DNS tests that are well documented in the wiki.

--------------------------------------------------------

Michael W. Picher

mpi...@gmail.com

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/c8216f68-bf6c-4b42-90e6-524b1c37bd04n%40googlegroups.com.

[Arturo J Garcia Jmz]

Thanks Michael

Im not the best techie in the world, specially in VoIP, I had some wireshark over the sipxecs-tcpdump-log files

And I noticed on INVITE events

The logs are not full typed

2022-12-09 10:37:11.452904 1/2.16.1.173 1ppbx.siei.local SIP 752 Request: ACKsip:8...@ippbx.siei.local;X-sipX-referror=510%40ippbx.siei.local?X-sipX-Authidentity=%3Csip:510%40ippbx.
645.. 2022-12-09 10:37:11.463464 172.16.1.173 ippbx. siei. local SIP/SDP 750 Request: INVITE sip:8...@ippbx.siei. local;X-sipX-referror=510%40ippbx.siei. local?X-sipX-Authidentity=%3Csip:510%40ipp

with 

Session Initiation Protocol (SIP as raw text
[truncated]ACKsip:8...@ippbx.siei.local;X-sipX-referror=510%40ippbx.siei.local?X-sipX-Authidentity=%3Csip:510%40ippbx.siei.local%3Bsignature%3D63936437%253A%253A1

It is this related to the network

All the phones are already with FQN in sip server name and DNS as NAPTR/SRV

But still having the issue of 481 and this references about "TRUNCATED"

[Arturo J Garcia Jmz]

I did a test using your suggestion:  Using Jitsi SoftPhone in my computer, and the problem with the  blind transfer from the softphone is away, softphone can do blind transfers, phones not!

El viernes, 9 de diciembre de 2022 a la(s) 09:34:50 UTC-6, mpi...@gmail.com escribió:

[Matt Keys]

It's hard to diagnose any calling issue without the actual log or pcap data of that call example to review.  Given your one-liner paste it looks like the message is malformed.

This might be a case of transport changes between UDP to TCP or vice-versa, or that your UA is exceeding 1500 in the UDP message. There are lots of possible causes and scenarios.

I'd recommend looking at the registration of the phone in the webui (users - {user} - registrations). If you see in the Contact: of the registration a flag "transport=tcp", then the phone is registering via TCP which does not have a size limitation. 

If you don't see the "transport=tcp" in the registration Contact, then it's registered via UDP which has size limitations. 

To determine if the phone is exceeding the UDP size limitation, packet capture the phone as you reproduce the scenario, then look at the size of the SIP messages it is sending. Over 1500 is bad. Another way to investigate transport changes is to look at the Via headers. If you see UDP, TCP, UDP etc. stacking there, then this is likely occurring. 

Often you can reduce the size of UDP messages a phone is sending by removing unnecessary codecs or injected headers from the phone configuration. 

PCMU (G.711 U-law -- PSTN standard in North America), and PCMA (G.711 A-law -- PSTN standard in parts of Europe/Asia) are required. Everything else can be removed safely and can't be used on the PSTN anyway. G.729 is the exception but must be supported by your provider and is usually transcoded to PCMU/PCMA somewhere along the line anyway. It's more headache than useful IMO.

I've also seen these issues caused by the admin neglecting to configure the correct intranet subnets in system - settings - internet calling. You should only have local networks listed there and everything else removed (include your VPN networks if any). If you're missing a network, and the phone source IP is within that same missing network, the SIP traffic from the phone will run through NAT traversal functions rather than sending messages directly to the phone.

Good luck,

Matt

[Arturo J Garcia Jmz]

Thanks a lot Matt

So in some way it will be better have the phones register by TCP instead UDP?, because mines are all UDP in the registration, I will try changing by TCP

Or I will try this: injected headers from the phone configuration, but what is that do? it is sending too much information over?

thanks in advance

[Arturo J Garcia Jmz]

Matt

I did the change on the phones using tcp and now the blind transfer is working ok, I also changed the codecs in all the phones to use G711u (I´m in Mexico) and G711a, and removed all the 

custom SIP HEADERs

Thanks

I will work on do a deeper analysis to know why the packages are missing