[SIPForum-discussion] SIP Error 481

BULANDUS, Tristan L. tlbulandus at pldt.com.ph
Sat Sep 22 02:28:24 UTC 2012


Hi Abhisek,

Thank you very much for the expertise that you are unconditionally sharing. However, I have asked some of my guys to test long duration calls using the Alcatel IPPBX, specifically Omni-PCX and the report I got from them is that calls are not cut after 5-10 minutes.

My only problem is that when IPPBX used to connect to our network is the Asterisk, it gets cut after approximately 5 minutes. The trace I sent previously wherein I used an Alcatel IPPBX was actually intentionally cancelled during the time of test just to show that ringback tone would be successful. I can get an equivalent trace for a successful call that does not get cut off next week, and I will quickly post next week. 

Now this is the question that keeps on boggling my head, why doesn't it get cut using an Alcatel IPPBX, I've searched the pcap trace and I can't find any "Required:timer"

For your comments please.

Thank you very much.

Tristan Bulandus
Network Products & Services Design
Cadet Network Engineer
Batch RING
________________________________________
From: Abhisek Acharya [abhisek.acharya at gmail.com]
Sent: Friday, September 21, 2012 7:10 PM
To: BULANDUS, Tristan L.
Cc: discussion at sipforum.org
Subject: Re: [SIPForum-discussion] SIP Error 481

Hey Bulandus,

In the mean while can you ask the IP-PBX guys and let them know that IP-PBX is not sending Require:timer even if it supports Session-Expiry mechanism.I am sure they will be happy to know that you raised this issue.Awaiting for your reply over the same.


Regards
GS-LAB-PVTLTD,PUNE
Abhisek Acharya

On Fri, Sep 21, 2012 at 4:37 PM, Abhisek Acharya <abhisek.acharya at gmail.com<mailto:abhisek.acharya at gmail.com>> wrote:
Hey

I checkd the trace that you sent and this is a failed call.Call is being CANCELLED by the calling party here.

Regards
Abhisek Acharya


On Fri, Sep 21, 2012 at 4:35 PM, Abhisek Acharya <abhisek.acharya at gmail.com<mailto:abhisek.acharya at gmail.com>> wrote:
Hi Dear Bulandus,

Low session-Expiry values are not dangerous but this can create a lot of mid-dialog request and responses which will unnecessarily over load the network.
Session-Expiry values should be greater than 90 seconds.It should not be less than this.

Significance of Require:timer

1.Let us assume UAC sends supported:timer that means it supports session-expiry mechanism.If the UAS supports Session-Refresher mechanism then it MUST send Require:timer to kick in the Session-Refresher mechanism.It does not matter who is the refresher the UAS MUST send Require:timer to kick in the Session-Expiry method.
I am yet to check the RFC.Let me check RFC 4028 and will get back to you.Also I will check your new trace and will get back to you as well.

Regards
Abhisek Acharya
GS-LAB,PVT LTD,
PUNE




On Fri, Sep 21, 2012 at 1:32 PM, BULANDUS, Tristan L. <tlbulandus at pldt.com.ph<mailto:tlbulandus at pldt.com.ph>> wrote:
Attachment I have here represents an Alcatel IPPBX with almost the same scenario but call does not get cut.

For your comments please.

Thank you very much.

Tristan Bulandus
Network Services Assurance
Customer Network, Network Engineer
0919-332-5174

PLDT Futsal Team Captain
[cid:image001.jpg at 01CD9812.7D48AAC0]

From: BULANDUS, Tristan L.
Sent: Friday, September 21, 2012 3:48 PM
To: 'Abhisek Acharya'
Cc: discussion at sipforum.org<mailto:discussion at sipforum.org>
Subject: RE: [SIPForum-discussion] SIP Error 481

What can “Require:timer” do?

Is it really dangerous to have a low session-expiration timer?

Thank you very much.

Tristan Bulandus
Network Services Assurance
Customer Network, Network Engineer
0919-332-5174

PLDT Futsal Team Captain
[cid:image001.jpg at 01CD9812.7D48AAC0]

From: Abhisek Acharya [mailto:abhisek.acharya at gmail.com<mailto:abhisek.acharya at gmail.com>]
Sent: Friday, September 21, 2012 12:44 PM

To: BULANDUS, Tristan L.
Cc: discussion at sipforum.org<mailto:discussion at sipforum.org>
Subject: Re: [SIPForum-discussion] SIP Error 481

Hey BULANDUS,

If I am not wrong Your call gets disconnected in every five minutes.If that is true then in your system session refresher mechanism is not working as per the standard.

I saw a INVITE is coming from 10.249.211.20 with Supported:timer value and Session-Expiry time with 300 seconds.And in 200 OK response the 10.251.3.153 MUST send Require:timer but rather it is sending Supported timer which is not correct.First thing what you need to check with the AsteriskIP-PBX is why it is not sending Require:timer .May be you can raise a BUG or something.

Post that I am seeing a lot of  Session-Refresher requests from 10.251.3.153 IP travelling till the end.And at times it is not getting the proper response and and request is pending on the other side.Because the INVITE is not processed and yet another comes.

And Also 10.251.3.153 sending so many INVITES with chaning the sdp body without getting the response is also a problem.
And due to some reason 10.249.211.20 removes the state of the dialog which it should not do.

FEW SUGGESTIONS

1.Check Why 10.251.3.153 not replying with Reuire:timer even if it supports Session-refresher mechanism.It should not send Supported:timer rather it should send Require:timer value.

2.Change the SessionExpiry value to a big number such as 1800 seconds or something becuase small session-expiry values are dangerous to network as it will create a lot of congestion with huge number of message flow.

3.Calls getting disconnected excatly in 5 minutes because Session-Refresher value is 300 seconds.481 response has nothing to do with the call disconnection as this happens way after the call set up.

Awaiting for your response over the same.

Regards
Abhisek Acharya
GS-LAB
PUNE





Please feel free to ask queries if any or if any something is not clear on this.








On Fri, Sep 21, 2012 at 6:36 AM, BULANDUS, Tristan L. <tlbulandus at pldt.com.ph<mailto:tlbulandus at pldt.com.ph>> wrote:
Team,
Appreciate help on below.

10.251.3.153 - Asterisk IPPBX
10.249.211.20 - Acme SBC facing Asterisk
10.249.212.32 - Acme SBC facing Huawei Softswitch
10.249.200.1 - Huawei Softswitch facing PSTN

Thank you very much.

Tristan Bulandus
Network Services Assurance
Customer Network, Network Engineer
0919-332-5174

PLDT Futsal Team Captain
[cid:image001.jpg at 01CD9812.7D48AAC0]

From: Abhisek Acharya [mailto:abhisek.acharya at gmail.com<mailto:abhisek.acharya at gmail.com>]
Sent: Thursday, September 20, 2012 12:37 PM
To: BULANDUS, Tristan L.
Cc: discussion at sipforum.org<mailto:discussion at sipforum.org>
Subject: Re: [SIPForum-discussion] SIP Error 481

Hey Buddy,


My initial question to you is open the INVITE message and check the FROM and TO header.Also try to check the TO header in specific.There should be no TO-TAG present in the TO header.As the Initial INVITE never contains a TO-TAG.


481 means call-leg does not exist.You are saying call gets disconnected after 5 minutes.Which means the call gets disconnected after the session is established.Can you please check if the RE-INVITE contains the same FROM and TO TAG or not.

Also Please send me the full wireshark trace and IP addresses.So that I can quickly check and get back to you.

Regards
Abhisek
On Wed, Sep 19, 2012 at 2:03 PM, BULANDUS, Tristan L. <tlbulandus at pldt.com.ph<mailto:tlbulandus at pldt.com.ph>> wrote:
Hi Team,

We have a network set-up of SIP Peering services, with details below:

ASTERISK PBX – SESSION BORDER CONTROLLER (PROXY) – HUAWEI SOFTSWITCH (PSTN GATEWAY)
[cid:image002.jpg at 01CD9812.7D48AAC0]

Calls originating from the PSTN Gateway is able to establish connection to Asterisk PBX but the call gets cut after 5 minutes. We experience Error 481 from (SBC - 10.249.211.20) to (Asterisk – 10.251.3.153).

Expert advice please on how to resolve this.

Thank you very much.

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org<mailto:discussion at sipforum.org>









More information about the discussion mailing list