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!
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Modify URI? 1
- Thread starter 84Mike
- Start date
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.
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.
- Thread starter
- #3
- Thread starter
- #4
- Thread starter
- #5
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?
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
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
- Thread starter
- #7
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
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
- Thread starter
- #9
- Thread starter
- #11
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.
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.
- Thread starter
- #13
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.
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.
-
1
- #14
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.
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.
- Thread starter
- #15
- Thread starter
- #17
- Thread starter
- #18
- Thread starter
- #19
- Status