Solved

Fonality Trixbox Pro EE - SIP Trunk Reject - CSeq: 101/102 INVITE

Posted on 2010-09-03
8
1,039 Views
Last Modified: 2013-11-12
Aloha,

This should be a relatively easy answer, I hope.

I have an above listed Asterisk flavor by Fonality/Trixbox, and while I've setup and configured a new SIP Trunk providers lines via their recommended config, we are experiencing a call reject situation, which they believe to be based upon the type of CSeq request we are providing.

Examples:

GOOD:
Request: Invite
Request URI: sip:4074941007@speakeasy.net
From: "4224" <sip:258845_2064624224_4224@speakeasy.net>;tag=18e2d6971b470beco0
To: <sip:4074941007@speakeasy.net>
Call-ID: f98c5033-62147f00@192.168.1.151
CSeq: 101 INVITE
Contact: "4224" <sip:258845_2064624224_4224@74.211.232.107:5060>
Expires: 240
SDP IP: 74.211.232.107
SDP Port: 16552

BAD:
Request: Invite
Request URI: sip:xxx.xxx.xxx.xxx@VAxxx.xxx.xxx.xxx.net
From: "Al Fisher" <sip:4xxx.xxx.xxx.xxx@xxx.xxx.xxx.xxx.net>;tag=as3b570f9a
To: <sip:1xxx.xxx.xxx.xxx@VAxxx.xxx.xxx.xxx.net>
Contact: <sip:xxx.xxx@xxx.xxx.xxx.xxx>
Call-ID: xxx.xxx@speakeasy.net
CSeq: 102 INVITE
SDP IP: xxx.xxx.xxx.xxx
SDP Port: 10534

Any thoughts on how to control that?  Remember, this flavor is the hosted hybrid PBX, so config line alterations are often overwritten when the system performs a refresh, so configuration through the GUI is preferable from a stability/management standpoint.

Thanks.  -Ian
0
Comment
Question by:Ian-DEC
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 2
  • 2
  • +1
8 Comments
 
LVL 11

Accepted Solution

by:
jfaubiontx earned 250 total points
ID: 33605700
Just as a test, go to the trunk configuration. Click on the Never Override CallerID box. Submit and apply changes. I suspect that your provider doesn't like that your trying to send your own caller ID information.
0
 
LVL 2

Expert Comment

by:xReaper
ID: 33606659
add
fromuser=4074941007
in trunks settings.
0
 
LVL 19

Expert Comment

by:feptias
ID: 33607395
You will have to provide more information. Why do you use x's to mask the address info on the Bad call yet you have made no attempt to mask the addresses of the Good call? It almost looks like the good call is incoming and the bad one is outgoing, in which case comparing them makes little sense.

Please explain the direction of the failing calls and the type of device being used to make/receive the call. Explain the difference between a good and a bad call - is it that a call from the same device to the same number sometimes works and other times does not? Or is there a consistent pattern to the good vs the bad?

Can you capture all the SIP packets for a failing call. Just posting a cut-down interpretation of one Invite is not sufficient. We need to see the whole sequence including the responses.
0
Windows Server 2016: All you need to know

Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!

 

Author Comment

by:Ian-DEC
ID: 33607672
jfaubiontx:
Good suggestion, the SIP provider apparently set the lines up to use two other numbers then the assigned pilots.  We will be looking into this more on Tuesday.

xReaper:
This isn't for a local (in system) call or number, but a remote number we are contacting.

feptias:
Both calls are outgoing, one merely originates from within the SIP providers system, and the second is an export of my system talking to theirs.  I don't quite see what you think would indicate one being outbound, and the other inbound.  I merely neglected to mask the 'good' call information, it holds no weight either way.

We are specifically unable to perform any outbound call on these trunks.  I have no issues with trunks from another provider on the same system.

As stated, the vendor brought up the point of a 101 vs 102 invite type, and that is still my posted question.  

Their system is rejecting it with the following:

    -- Executing Dial("SIP/0004F224014A-b7560408", "SIP/SPEAKEASY/14074941007") in new stack
    -- Called SPEAKEASY/14074941007
    -- Got SIP response 604 "Does not exist anywhere" back from 216.254.95.177

And they are digging through the logs and asking various questions, this being their first concern.

Thanks.  -Ian
0
 
LVL 19

Assisted Solution

by:feptias
feptias earned 250 total points
ID: 33608025
The number used in a CSeq is simply an incrementing counter to show if the request is a duplicate of a previous or is a new request within the same dialogue. The UDP protocol can quite easily lose packets during transmission so the SIP protocol includes a CSeq counter to let the receiving end point see if a request is simply a resend of an earlier packet or is a new request. However, it makes no sense at all to compare the CSeq number on two different calls. It does not different types of Invite because there is only one type of SIP Invite. I think they are dissembling.

I would think it more useful to check if the format of the dialled number is correct. For example, if the leading 1 is required. I am not familiar with US numbering so cannot make informed suggestions on that matter. However, your service provider should really be able to give you better guidance if their equipment is returning 604 "Does not exist anywhere".

If you could post the entire SIP dialogue here then I will check through it for clues.
0
 
LVL 11

Expert Comment

by:jfaubiontx
ID: 33608132
Were you able to make the call after my suggestion? If not did the call trace change? I agree with fepitas that we need more of the call trace. Try setting the debug and verbosity parameters higher and pull a full trace.
0
 

Author Comment

by:Ian-DEC
ID: 33623035
It ended up being both an incorrect FROM header, as the provider was expecting us to pass what our eventual numbers would be, rather then the pilot numbers they provided, and they also incorrectly requested that we utilize an Outbound Proxy, which later proved to be incorrect.

Thanks for explaining what CSeq is feptias, and jfaubiontx you correctly nailed the CallerID component, which would have been extremely useful if the provider hadn't already tagged it as a possible issue.

Awarding points.

Thanks all.  -Ian
0
 

Author Closing Comment

by:Ian-DEC
ID: 33623047
Answers correctly covered what a CSeq request was, and how it functioned, along with an accurate suggestion of CallerID being a root problem.
0

Featured Post

Announcing the Most Valuable Experts of 2016

MVEs are more concerned with the satisfaction of those they help than with the considerable points they can earn. They are the types of people you feel privileged to call colleagues. Join us in honoring this amazing group of Experts.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

The Zaptel people (www.zaptel.com) got kind of annoyed with the fact that they were getting bombarded with searches for the zaptel driver system for Asterisk (not to mention they own the trademark on zaptel). So, they kindly requested that Digium ch…
I recently purchased a Bluetooth headset called the Music Jogger (model BSH10). The control buttons on it look like this: One of my goals is to use it as the microphone and speakers for Skype calls. In that respect, it works well. However, I …
In an interesting question (https://www.experts-exchange.com/questions/29008360/) here at Experts Exchange, a member asked how to split a single image into multiple images. The primary usage for this is to place many photographs on a flatbed scanner…

726 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question