Modify URI? 1

[84Mike]

I am trying to route calls from my CM thru Session Manager/SBC (inbound is working), but I am having issues with the URI, I believe. I can't figure out how to modify the domain for the outgoing call, as I assume it needs to be the IP address of our SIP provider. I have included a trace. Anyone with insight would be greatly appreciated. Thanks in advance!

 

[kyle555]

Generally speaking, the carrier shouldn't care. If their far end IP is 1.2.3.4, it shouldn't matter if you send PSTN#@1.2.3.4 or PSTN#@yourdomain.com so long as you're sending it to 1.2.3.4.

SM really likes domains. As in, it won't work without them. Per TCP/UDP port, you can define a default domain that's implied if a message arrives @SM100IP, but you can't do it the other way around.

If you absolutely want to hit the carrier that way, you'd do it on the sbc.

 

[84Mike]

I'm still new to the Session Manager/SBC world, so trying to muddle through this. I think the initial 'Route not found' is coming from the SBC....I guess I should start there.

 

[84Mike]

Scratch that previous comment...doesn't look like the call ever makes it to SBC. Something I am missing in session manager.

 

[84Mike]

I'm getting closer. I added a regular expression matching the number I am attempting to dial in session manager, I am now seeing the call go thru SBC, but getting "404 Number not in e164 format". Trying to figure out how to add the +1 in front of the number. Seems this should be simple? Can you point me in the right direction?

 

[kyle555]

you wouldn't need regular expression matches in SM, dial patterns are good enough. Regexes are good for your.name@domain.com, dial patterns are just fine when it's digits.

Your carrier is telling you they want things in a e164 format with that 404. You can use an adaptation on your SBC SIP Entity in SM of type "digit conversion adapter" and match dialed numbers and insert a plus or a plus one to the calling and/or called party number if the carrier wants to see +1-555-555-1234 is calling +1-555-444-4321

 

[84Mike]

Thanks Kyle...I have been making attempts with the conversion...but can't seem to get it squared away. I have tried multiple combinations on the attached page...

 

[kyle555]

I'd ditch the odstd of IP address - is that your SBC or carrier IP? either way, the SBC would rewrite it or pass it to the carrier with whatever that IP means and it just confuses things.

pattern should be x. it means anything. * is a digit you can dial. So your pattern matches on a phone number like *123456789 and it would get to be +1*123456789

swap the * for a x

 

[84Mike]

Yet another update...

I now have calls completing outbound to my cell phone, but have one-way audio. Yay!


Thanks for the assistance, Kyle.

 

[kyle555]

what's the SDP look like in the flow from the SBC to the carrier?

any SDP in any of the messaging say 'send-only'?

 

[84Mike]

Forgive the newbie-ness...but I'm not sure how to answer that question yet.

 

[kyle555]

Is it an Avaya SBC? CLI in, sudo su or sudo traceSBC and it's a terminal SIP capture. It'll show messages from SM to SBC and from SBC to carrier.

In a SIP message, you can have SDP - it defines how the endpoint will do media. So, in the SDP of a SIP message, your phone or server or carrier will have something saying "i do G711 and or 729 and i send packets that are 20 ms of audio".

SIP/SDP also has means to switch to one-way audio. If I put you on hold, I'd send a re-invite with the same SDP as my original invite but my SDP would include something saying "send-only" to mean "hey, shut up! I'm not listening to you! I'm sending you hold music".

SDP renegotiation happens all the time on calls. Whether you hold/unhold, whether you shuffle an IP phone off a gateway DSP, etc. It can be common enough for 1 way audio problems to be caused by SIP signaling and not network issues of using the wrong UDP ports for RTP.

So, if you fired up a traceSBC and looked at every message involved in setting up a call and never saw a "send-only" anywhere, you'd be certain that the signaling of that call intended a two-way conversation.

 

[84Mike]

CLI using putty to the management interface? I only have experience with the web interface so far. I am using traceSM on Session Manager now to try and troubleshoot. I have suspicion that our firewall is involved in the problem. I'm waiting to hear back from the firewall guy to check that side of it.

I just tried connecting to my SBC management with putty, and it did not connect successfully.

I really appreciate you taking time to help out.

 

[kyle555]

No worries.

TraceSM and traceSBC are the same thing. Putty on port 222. If you have a all-in-1 EMS+SBC, it'll be the 1 management IP.

If you have a separate EMS and SBC(HAmaybe?) Then it's ssh port 222 of the management IP of the server actually routing SIP traffic. Same as traceSM but it'll give you the inside and outside view.

 

[84Mike]

It is an Avaya SBC+EMS

I was able to get to the login, but my credentials fail to log me in. 'Access denied'

 

[kyle555]

ucsec for the webpage, ipcs for the console. if whoever installed it was generous, they'd be the same. Same privileges, just from the web or the command line.

 

[84Mike]

Well, I got logged...

ran traceSBC, and hit 's' to start tracing, left default selection of 'SIP'...then it blows up.


Used trace files:
Error opening /usr/local/ipcs/log/ss/logfiles/elog/SSYNDI/: Permission denied
[ipcs@Avaya84EMS ~]$

 

[84Mike]

I remembered seeing 'su' command in one of your earlier posts...now capturing

 

[84Mike]

Also, noticed the time is set to incorrect timezone on my SBC. Would like to update that, as well.

 

[kyle555]

timezone not such a big deal, so long as UTC is correct. If right now, it thinks its 20h42 in UTC, it won't really matter.