UC540 Gamma Telecom SIP Trunk

dataIP · ‎08-20-2013

Hi all,

I have a problem setting up a SIP trunk from the UC540 to Gamma Telecom here in the UK. Our service provider isn't being very forthcomming with information.

All the other SIP trunks I have done, use a user/password for uthentication... this one uses the IP address.

UC540 is on a private IP, behind an ASA with suitable static NAT. The public IP for the UC540 is know by the SIP provider.

I can't get the UC540 to register on the SIP channel.

It is my suspicion that the service provider requires our public IP to be in the SIP messages rather than our private one. How do I set the UC540 to put the public IP in its SIP messages?

I have tried adding a loopback address on the UC540 with our public IP but it does not do what I hoped.

interface Loopback1

ip address <public IP of UC540> 255.255.255.255

!

Example SIP messages that I see currently are shown below;

000155: Aug 20 11:25:00.269: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

REGISTER sip:88.215.61.195:5060 SIP/2.0

Via: SIP/2.0/UDP 192.168.88.250:5060;branch=z9hG4bK1466E

From: <sip:01785xxxxxx@88.215.61.195>;tag=61228-D70

To: <sip:01785xxxxxx@88.215.61.195>

Date: Tue, 20 Aug 2013 10:25:00 GMT

Call-ID: 9A57992C-8B911E3-801AA089-CCBE030A

User-Agent: Cisco-SIPGateway/IOS-12.x

Max-Forwards: 70

Timestamp: 1376994300

CSeq: 2 REGISTER

Contact: <sip:01785xxxxxx@192.168.88.250:5060>

Expires: 3600

Supported: path

Content-Length: 0

paolo bevilacqua · ‎08-20-2013

Your best choice is to give UC a public IP address, or use an Internet rotuer that does NAT properly (eg Cisco).

Otherwise you will have nothing but problems.

dataIP · ‎08-20-2013

Hi Paulo,

Thanks for the reply. I probably should have given a bit more of a description of the setup... it is my 'standard' setup of an UC540 behind and ASA 5505 doing static NAT, and front ended by an 887VA giving me a connection to FTTC (VDSL).

I have this running with no issues using another SIP provider... it just looks like the issue may be the way Gamma Telecom do their SIP. The examples I have from them show for example the INVITE message as having sip:OurPSTNNumber@OurPublicIP SIP/2.0

I looked at another UC540 which is up and running (different provider, user/password authentication) and that seems to work fine even though I see the SIP messages as being in the format sip:UserName@OurPrivateIP SIP/2.0

I don't think the issue is t the IP level, more the SIP level (though I may be wrong).

paolo bevilacqua · ‎08-20-2013

Then ASA is not doing NAT (SIP ALG) properly. The 887 instead would.

UC IPs received by UC must be private, not public.

You can play with loopback and stuff to work around, chances are you will find more problems after.

dataIP · ‎08-20-2013

Hi Paulo,

I am not sure I am fully understaning SIP traffic at the moment...

I think that the IP level traffic is fine... what I think is that the CONTENTS of the messages is wrong not the IP headers.

As far as I understand it, SIP is text based, what I think the issue is here is that the service provider is looking for some specific text in the message.

We send eg. "INVITE sip:0123456789@192.180.10.128 SIP/2.0"

whereas the provider is expecting "INVITE sip:0123456789@46.47.48.49 SIP/2.0"

(where in the example 192... is our private address, and 46.47.48.49 is an example of an outside address.

They tell me I can also use the form "INVITE sip:0123456789@your.domain.local SIP/2.0"

I am lead to believe there is a way of setting the text in the SIP traffic?

I realise I may be barking up the wrong tree on this though.

paolo bevilacqua · ‎08-20-2013

Exactly, the content is wrong (ASA doign wrong or no SIP ALG).

That is what I'm telling you since the first answer.

dataIP · ‎08-20-2013

Hi again Paolo,

I do have

policy-map global_policy

class inspection_default

inspect sip

in the ASA, so I think we should be correctly setup.

There may be a hole in my knowledge here, I always thought that the fixup/inspect statements applied to the IP addresses inside user data within the packet, (the static NAT doing the IP header stuff)... I wasn't aware that the inspect should be manipulating the TEXT contents of the packet... or have I misunderstood your reply?

paolo bevilacqua · ‎08-20-2013

I don't know anything about the ASA, try posting in security - firewalling.

Correct NAT adjusts all the addreses wherever they are, like IOS NAT does.

dataIP · ‎08-22-2013

Thanks again Paolo,

I have made some progress, as oddly I noticed in the ASA that the show sip command returned nothing. A reboot of the ASA and I do now see information in response to the show sip command.... So we now know that the inspect sip is doing something.

I may be being mislead by the data, but the UC540 still isn't showing as being registered on the SIP trunk... BUT I have found that I can make incoming calls to it. Voice works both ways and is fine.

Now I find that an outgoing call can't be made.

It strikes me as odd that incoming calls can be received if the trunk is not registered... but maybe that is how it functions?

Now I am not sure if it is a SIP NAT issue at the ASA, or if I am back to looking at the UC540.

If you think it is ASA related I shall repost my question in the security/firewall section as you suggested.

Thanks

Mark

paolo bevilacqua · ‎08-22-2013

Some providers, knowings that registration may fail, use the last IP seen in an outgoing call, as the destination for incoming (to user). or perhaps they just use static call routing.

Yes I think you should post any ASA question in the secuirty forum.