Fonality Trixbox Pro EE - SIP Trunk Reject - CSeq: 101/102 INVITE
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.n
From: "4224" <sip:258845_2064624224_422
To: <sip:4074941007@speakeasy.
Call-ID: f98c5033-62147f00@192.168.
CSeq: 101 INVITE
Contact: "4224" <sip:258845_2064624224_422
Expires: 240
SDP IP: 74.211.232.107
SDP Port: 16552
BAD:
Request: Invite
Request URI: sip:xxx.xxx.xxx.xxx@VAxxx.
From: "Al Fisher" <sip:4xxx.xxx.xxx.xxx@xxx.
To: <sip:1xxx.xxx.xxx.xxx@VAxx
Contact: <sip:xxx.xxx@xxx.xxx.xxx.x
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
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.n
From: "4224" <sip:258845_2064624224_422
To: <sip:4074941007@speakeasy.
Call-ID: f98c5033-62147f00@192.168.
CSeq: 101 INVITE
Contact: "4224" <sip:258845_2064624224_422
Expires: 240
SDP IP: 74.211.232.107
SDP Port: 16552
BAD:
Request: Invite
Request URI: sip:xxx.xxx.xxx.xxx@VAxxx.
From: "Al Fisher" <sip:4xxx.xxx.xxx.xxx@xxx.
To: <sip:1xxx.xxx.xxx.xxx@VAxx
Contact: <sip:xxx.xxx@xxx.xxx.xxx.x
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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.
ASKER
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-b75
-- 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
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-b75
-- 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
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
ASKER
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
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
ASKER
Answers correctly covered what a CSeq request was, and how it functioned, along with an accurate suggestion of CallerID being a root problem.
fromuser=4074941007
in trunks settings.