Discussion:
] SipXecs not transferring calls
Luis Sicat
2012-10-03 02:55:41 UTC
Permalink
Hi Ma'am and Sirs,

Newbie using SipXecs and unfortunately I found myself with a problem that I
can't get around with.
I'm hoping some experts here could find time and extend some help to a noob
like me.

Basically I'm having problem with Auto Attendant transferring calls to a
specific extension.
If I call the PSTN number from an outside line, the gateway passes me over
to the Auto Attendant and I hear the IVR.
After I dial in the extension number, I just hear "Please wait while I
transfer your call..." then nothing happens.
I tried calling the AA extension number (500) from another extension to
rule out the gateway that I'm using but it still the same problem.

I'm running sipXecs(4.6.0. 2012-08-22EDT21:08:29
ip-10-72-43-110.ec2.internal)
I tried runnning a debug on the SipProxy and I checked the logs. Below is
what I noticed:

"2012-10-01T08:11:00.051807Z"
:16100:AUTH:DEBUG:sipx.volenday.intra:SipRouter-12:7fa70d403 700:SipXProxy:
"SipProxy::proxyMessage plugin 200_xfer returned DENY for
***@192.168.200.51"

I'm not sure if that's the relevant part of the log but it seems the only
one that makes sense.
I'd like to know if there is a specific configuration that I should be
looking at or some permissions that I should be setting somewhere.

Again, if I'm looking at the wrong place, I'd appreciate if anyone could
point me in the right direction.
I've attached a Snapshot of the system for reference but if anyone should
need more information, please do let me know so I can provide it.

Thank you very much!
Joegen Baclor
2012-10-03 04:29:00 UTC
Permalink
Luis,

Unfortunately, the snapshot does not contain a single INVITE in the
logs. Please do a log rotate or simply delete sipXproxy.log and do the
test again. Send the proxy log instead of the whole snapshot. It
should give us the information we need to shed some light on your
issue. Are you from Manila?

Joegen
Post by Luis Sicat
Hi Ma'am and Sirs,
Newbie using SipXecs and unfortunately I found myself with a
problem that I can't get around with.
I'm hoping some experts here could find time and extend some help to a
noob like me.
Basically I'm having problem with Auto Attendant transferring calls to
a specific extension.
If I call the PSTN number from an outside line, the gateway passes me
over to the Auto Attendant and I hear the IVR.
After I dial in the extension number, I just hear "Please wait while I
transfer your call..." then nothing happens.
I tried calling the AA extension number (500) from another extension
to rule out the gateway that I'm using but it still the same problem.
I'm running sipXecs(4.6.0. 2012-08-22EDT21:08:29
ip-10-72-43-110.ec2.internal)
I tried runnning a debug on the SipProxy and I checked the logs. Below
"2012-10-01T08:11:00.051807Z"
:16100:AUTH:DEBUG:sipx.volenday.intra:SipRouter-12:7fa70d403
700:SipXProxy: "SipProxy::proxyMessage plugin 200_xfer
I'm not sure if that's the relevant part of the log but it seems the
only one that makes sense.
I'd like to know if there is a specific configuration that I should be
looking at or some permissions that I should be setting somewhere.
Again, if I'm looking at the wrong place, I'd appreciate if anyone
could point me in the right direction.
I've attached a Snapshot of the system for reference but if anyone
should need more information, please do let me know so I can provide it.
Thank you very much!
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
Luis Sicat
2012-10-03 06:18:30 UTC
Permalink
Hi Joegen,

I've attached the sipXproxy log as requested.
Thanks for taking the time to look into this.
Appreciate it.

Yes, I'm from Manila.

Luis
Joegen Baclor
2012-10-03 06:38:42 UTC
Permalink
Luis,

Thanks for the logs. I'm from Manila too. Good to hear your company is
using sipXecs.

----

Hi George,

I am referring this case to you. Perhaps you can shed light as to why
the proxy is unable to find the credentials for ~~id~media.

"2012-10-03T04:49:11.672255Z":10857:SIP:DEBUG:sipx.volenday.intra:SipRouter-12:7fbebcd42700:SipXProxy:"SipMessage::normalizeProxyRoutes
popped route to self
'<sip:192.168.200.20:5060;lr;sipXecs-CallDest=UNK%2CAA;sipXecs-rs=*auth~.*from~MTZhOWIzZTQ1Yzk5ODEyMA%60%60.900_ntap*id~NDg5Mi0w!36266e30dcb647f84879e686fc2d8a51>'"
"2012-10-03T04:49:11.672372Z":10858:SIP:DEBUG:sipx.volenday.intra:SipRouter-12:7fbebcd42700:SipXProxy:"SipRouter::proxyMessage
A bRequestShouldBeAuthorized = 1, bForwardingRulesShouldBeEvaluated = 0,
bMessageWillSpiral = 0"
"2012-10-03T04:49:11.672385Z":10859:SIP:DEBUG:sipx.volenday.intra:SipRouter-12:7fbebcd42700:SipXProxy:"SipRouter::proxyMessage
B bRequestShouldBeAuthorized = 1, bMessageWillSpiral = 0"
"2012-10-03T04:49:11.672438Z":10860:SIP:DEBUG:sipx.volenday.intra:SipRouter-12:7fbebcd42700:SipXProxy:"SipNonceDb::nonceSignature:
callId='***@192.168.200.51' fromTag='m27c3a2rQQc1p'
realm='volenday.intra' timestamp='506bc3c7'"
"2012-10-03T04:49:11.672457Z":10861:LOG:DEBUG:sipx.volenday.intra:SipRouter-12:7fbebcd42700:SipXProxy:"UtlString::findToken:
built regexp '(^|,)\\s*auth\\s*(,|$)' to find 'auth' with delimiter ','
suffix '(null)'"
"2012-10-03T04:49:11.672479Z":10862:LOG:DEBUG:sipx.volenday.intra:SipRouter-12:7fbebcd42700:SipXProxy:"UtlString::findToken:
'auth' with delimiter ',' found in 'auth': "
"2012-10-03T04:49:11.672489Z":10863:SIP:DEBUG:sipx.volenday.intra:SipRouter-12:7fbebcd42700:SipXProxy:"SipMessage::parseQopValue
- qop='auth' is \"auth\" "
"2012-10-03T04:49:11.672687Z":10864:ODBC:INFO:sipx.volenday.intra:SipRouter-12:7fbebcd42700:SipXProxy:"EntityDB::findByUserId
- Finding entity record for ~~id~media from namespace imdb.entity"
"2012-10-03T04:49:11.672723Z":10865:AUTH:INFO:sipx.volenday.intra:SipRouter-12:7fbebcd42700:SipXProxy*:"SipRouter::isAuthenticated()
No credentials found for user: '~~id~media'"*
"2012-10-03T04:49:11.672758Z":10866:AUTH:INFO:sipx.volenday.intra:SipRouter-12:7fbebcd42700:SipXProxy:"TransferControl[200_xfer]::authorizeAndModify
challenging transfer in call '***@192.168.200.51'"


This causes the REFER to fail. Attached is the identity db.

Joegen
Post by Luis Sicat
Hi Joegen,
I've attached the sipXproxy log as requested.
Thanks for taking the time to look into this.
Appreciate it.
Yes, I'm from Manila.
Luis
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
George Niculae
2012-10-03 07:28:18 UTC
Permalink
Post by Joegen Baclor
Luis,
Thanks for the logs. I'm from Manila too. Good to hear your company is
using sipXecs.
----
Hi George,
I am referring this case to you. Perhaps you can shed light as to why the
proxy is unable to find the credentials for ~~id~media.
It looks like mongo lookup is made after ~~id~media while field in doc
is "ident" : "~~id~***@volenday". Maybe proxy should append domain?

George
George Niculae
2012-10-03 07:46:31 UTC
Permalink
Post by George Niculae
Post by Joegen Baclor
Luis,
Thanks for the logs. I'm from Manila too. Good to hear your company is
using sipXecs.
----
Hi George,
I am referring this case to you. Perhaps you can shed light as to why the
proxy is unable to find the credentials for ~~id~media.
It looks like mongo lookup is made after ~~id~media while field in doc
On a 2nd look - domain should be volenday.intra not volenday simple,
Luis, could you send profiles to server and see if this fix your
issue? Have you run sipxecs-setup 2 times, first time specifying
volenday as SIP domain?

George
Luis Sicat
2012-10-03 08:32:04 UTC
Permalink
Hi Sir,

Sending profiles to server did the trick;) Thank you so
much!
As for the sipxecs-setup, I believe I did it twice now that
you mentioned it.
Defining "volenday" as the initial domain. I hope I didn't
mess up anything by doing that.
If yes, Is there anything I should do be doing?

You guys rock!
George Niculae
2012-10-03 08:33:57 UTC
Permalink
Post by Luis Sicat
Hi Sir,
Sending profiles to server did the trick;) Thank you so
much!
As for the sipxecs-setup, I believe I did it twice now that
you mentioned it.
Defining "volenday" as the initial domain. I hope I didn't
mess up anything by doing that.
If yes, Is there anything I should do be doing?
You should be good now, just that when you rerun sipxecs-setup on top
of an existing one (different domains) do sipxecs-setup --reset-all

George

Loading...