This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

V18 Sip trunk

I am trying to set up a sip trunk with sophos v18.

I have a cisco cube router behind sophos xg v18.

The cube talks sip to cisco Call manager.

What rules and nat is needed to connect the cisco router with Sip provider?

I thought it would be as simple as making a nat dnat rule sending the sip traffic hitting our external ip address to the internal ip of the Cisco router. However it is not working as expected.

I see the sip traffic hit the cisco router and then the sip traffic is continuing on to the call manager and ringing the internal phones. I can even answer the call. But then it disconnect within a few seconds.

I see the cisco router is sending the sip OK back out to the provider but not seeing a ack back from the provider.

Coming from ASA word i am used to natting in the ASA and seeing internal ip addresses hitting the cisco cube on the incoming invite. But with the NAt in the sophos i am seeing the public ip hitting the cube in the invites?

This thread was automatically locked due to age.

Parents

0 Peter-Paul Gras over 4 years ago

Situation: VOIP PBX as VM inside the LAN, one trunk.

I only have this FW rule, no NAT rule.
Works fine for me.

SFVH (SFOS 20.0.0 GA-Build222) - Last (re)boot on November 6th 2023

Asus H410i-plus - Pentium 6605 Gold - 250GB M.2 PCIe NVMe SSD - 8GB - 3 ports

[If any of my posts are helpful to you please use the 'Verify Answer' link]
Cancel
Vote Up 0 Vote Down

Cancel
0 LuCar Toni over 4 years ago in reply to Peter-Paul Gras

Sometimes you have to reload the SIP Helper.

https://community.sophos.com/kb/en-us/123523

https://community.sophos.com/kb/en-us/127785

__________________________________________________________________________________________________________________
Cancel
Vote Up 0 Vote Down

Cancel
0 Jim Boothe1 over 4 years ago in reply to LuCar Toni

So after a lot of trial and error i found that it was the SIP headers that were causing the issue. My nat rule and firewall rules were correct in letting the traffic in. Sophos just handles sip traffic differnt than what i am used to with a cisco ASA. It does not re-write the headers. So i was seeing public information in the invite headers and header information going back to the provider was sending private information in the headers.

I had to create sip-profile and change the response in the contact and or remote party id header information as it flowed back out towards my provider to have my public ip information.

Now it is working as expected.

I am not sure if there are any other settings i could have done on the Sophos to make it work more like an ASA or if the XG just designed to work like this. Probably the latter which is fine now that i have a solution i can move forward with new customers.

Also FYI. Using a different sip provider that uses sip registration i.e. setting username password information to set up the trunk it worked without any issues behind the XG. the Traffic just went out and talked to the providers SBC and registered. The above issue only appeard when sending sip traffic to and from a provider with no registration.
Cancel
Vote Up 0 Vote Down

Cancel
0 lferrara over 4 years ago in reply to Jim Boothe1

Jim,

can you share what configuration you changed on your SIP provider?

Any details about how ASA handles this?

Thanks
Cancel
Vote Up 0 Vote Down

Cancel
0 Jim Boothe over 4 years ago in reply to lferrara

So again in my situation i have A sip provider they point towards my external IP address when sending me calls.

On the edge i have a XG firewall. Thru this Nat is done and sends the traffic to my Cisco Cube router

If the same as above was done with an ASA instead of the XG firewall my sip traffic coming into the cube would look similar to this.

Feb 24 06:48:39: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:3045554444@172.16.100.2:5060 SIP/2.0
Via: SIP/2.0/UDP 207.241.166.109:5060;branch=z9hG4bK1sansay2766498rdb139
Record-Route: <sip:sansay2766498rdb139@207.241.166.109:5060;lr;transport=udp>
To: <sip:3045554444@172.16.100.2>
From: "Caller ID" <sip:3045558888@207.241.166.109>;tag=sansay2766498rdb139
Call-ID: 2266226-0-148086546@207.241.166.100
CSeq: 1 INVITE
Contact: <sip:3045558888@207.241.166.109:5060>
Supported: timer,100rel,replaces
Session-Expires: 600;refresher=uac
Min-SE: 90
P-Asserted-Identity: "Caller ID" <sip:3045558888@207.241.166.109:5060>
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 305

v=0
o=Sansay-VSXi 188 1 IN IP4 207.241.166.109
s=Session Controller
c=IN IP4 207.241.166.109
t=0 0
m=audio 11042 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20

The ASA seems to inspect the sip traffic and change the SIP headers as this initial invite was initially send to the public ip address of the ASA. However when this router received it the invites are pointing to the internal IP address of 172.16.100.2. The only Public ip addresses in the invite is the SIP providers public ip.

When the call is answered and the router sends OK responses back to the provider it is also sending the internal ip address of the router as the contact See below

Feb 24 06:48:39: //972717/6ED80257A228/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 207.241.166.109:5060;branch=z9hG4bK2sansay2766498rdb139
From: "Caller ID" <sip:3045558888@207.241.166.109>;tag=sansay2766498rdb139
To: <sip:3045554444@172.16.100.2>;tag=F5299B8-D11
Date: Mon, 24 Feb 2020 06:48:39 GMT
Call-ID: 2266226-0-148086546@207.241.166.100
CSeq: 2 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:7000@172.16.100.2>;party=called;screen=no;privacy=off
Contact: <sip:3045554444@172.16.100.2:5060>
Record-Route: <sip:sansay2766498rdb139@207.241.166.109:5060;lr;transport=udp>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.5.3.M4a
Require: timer
Session-Expires: 1800;refresher=uac
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 247

v=0
o=CiscoSystemsSIP-GW-UserAgent 1350 3702 IN IP4 172.16.135.2
s=SIP Call
c=IN IP4 172.16.100.2
t=0 0
m=audio 18080 RTP/AVP 0 101
c=IN IP4 172.16.100.2
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

The ASA changes these headers as it sends back out and the provider receives a sip header with the contact as the public ip address instead of the internal ip address show above.

NOW the xg firewall does not change any of the headers. When the sip invite comes into the router with an XG as the edge devices the router sees the exact same invite that came to the Public ip address. see below

*Feb 24 07:27:16.058: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+13045554444@PUBLIC IPSIP/2.0
Record-Route: <sip:54.172.60.3:5060;lr>
From: <sip:+13045558888@jbnet.pstn.twilio.com:5060>;tag=87935968_6772d868_a1892616-54fb-4b3c-9a3c-d31760ccad0c
To: <sip:+130425554444@Public IP>
CSeq: 3037 INVITE
Max-Forwards: 62
Call-ID: bc4e596bb0c37409290b4d7c47562771@0.0.0.0
Via: SIP/2.0/UDP 54.172.60.3:5060;branch=z9hG4bKbca9.ca04ac75.0
Via: SIP/2.0/UDP 172.18.13.233:5060;rport=5060;received=172.18.13.233;branch=z9hG4bKa1892616-54fb-4b3c-9a3c-d31760ccad0c_6772d868_500-444794762458710658
Contact: <sip:+13045558888@172.18.13.233:5060;transport=udp>
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,NOTIFY
User-Agent: Twilio Gateway
X-Twilio-AccountSid: AC4ae81b353ede92009eaa8dcab18e14ab
Content-Type: application/sdp
X-Twilio-CallSid: CA1e31fd9977b8dbc7af863c01276413de
Content-Length: 278

v=0
o=root 1612282389 1612282389 IN IP4 34.203.250.95
s=Twilio Media Gateway
c=IN IP4 34.203.250.95
t=0 0
m=audio 18110 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

So the sip headers have not been "translated" like an ASA does.

The router still processes the sip invite and the phone rings. It is answered and RTP traffic starts flowing however when the router sends the OK back out towards the provider it has the internal ip addresses in the headers. The external SIP provider sees this and can not process it as it is a internal ip address so after so many retries the connection is dropped. below is an example

*Feb 24 07:27:18.500: //5866/EAB5FB748DF9/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 54.172.60.3:5060;branch=z9hG4bKbca9.ca04ac75.0,SIP/2.0/UDP 172.18.13.233:5060;rport=5060;received=172.18.13.233;branch=z9hG4bKa1892616-54fb-4b3c-9a3c-d31760ccad0c_6772d868_500-444794762458710658
From: <sip:+13045554444@jbnet.pstn.twilio.com:5060>;tag=87935968_6772d868_a1892616-54fb-4b3c-9a3c-d31760ccad0c
To: <sip:+13045558888@Public IP;tag=2CAF75D6-64B
Date: Mon, 24 Feb 2020 07:27:16 GMT
Call-ID: bc4e596bb0c37409290b4d7c47562771@0.0.0.0
CSeq: 3037 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "Jim Boothe" <sip:1000@10.10.7.3>;party=called;screen=yes;privacy=off
Contact: <sip:+13045558888@10.10.7.3:5060>
Record-Route: <sip:54.172.60.3:5060;lr>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-16.9.5
Session-ID: b03f9bde87ab037f338308ba31352863;remote=2ad3ad20d0f85a0b9f88d318a6d33259
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 236

v=0
o=CiscoSystemsSIP-GW-UserAgent 9868 843 IN IP4 10.10.7.3
s=SIP Call
c=IN IP4 10.10.7.3
t=0 0
m=audio 8500 RTP/AVP 0 101
c=IN IP4 10.10.7.3
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

So to fix this i create a sip-profile in the cisco router

voice class sip-profiles 100
response ANY sip-header Contact modify "10.10.7.3" "Public IP"

there are many other headers in the above that you can modify if having problems. Will be different with different sip providers i would imagine on what they are looking for. For example you may need to add the remote-party-ID header as well.

The above sip profile was then added to the incoming dial-peer of the router.

so now when the responses go back out to towards the sip provider it looks like the following

Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 54.172.60.3:5060;branch=z9hG4bKbca9.ca04ac75.0,SIP/2.0/UDP 172.18.13.233:5060;rport=5060;received=172.18.13.233;branch=z9hG4bKa1892616-54fb-4b3c-9a3c-d31760ccad0c_6772d868_500-444794762458710658
From: <sip:+13045554444@jbnet.pstn.twilio.com:5060>;tag=87935968_6772d868_a1892616-54fb-4b3c-9a3c-d31760ccad0c
To: <sip:+13045558888@Public IP;tag=2CAF75D6-64B
Date: Mon, 24 Feb 2020 07:27:16 GMT
Call-ID: bc4e596bb0c37409290b4d7c47562771@0.0.0.0
CSeq: 3037 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "Jim Boothe" <sip:1000@10.10.7.3>;party=called;screen=yes;privacy=off
Contact: <sip:+13045558888@Public IP5060>
Record-Route: <sip:54.172.60.3:5060;lr>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-16.9.5
Session-ID: b03f9bde87ab037f338308ba31352863;remote=2ad3ad20d0f85a0b9f88d318a6d33259
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 236

v=0
o=CiscoSystemsSIP-GW-UserAgent 9868 843 IN IP4 10.10.7.3
s=SIP Call
c=IN IP4 10.10.7.3
t=0 0
m=audio 8500 RTP/AVP 0 101
c=IN IP4 10.10.7.3
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

I hope this helps the next person trying to work with Cisco behind a Sophos.

Also if you are working with a sip provider that you actually have a registered sip trunk where you provide credentials to register the trunk the above should not be involved as the registration process is different and will go out of the xg talk with your sip provider use the handshake with the credentials and the trunk will register and calls will flow through the trunk no problem. The above is only when dealing with NON registered trunks where the provider is sending calls towards our Public ip addess.
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 Jim Boothe over 4 years ago in reply to lferrara

So again in my situation i have A sip provider they point towards my external IP address when sending me calls.

On the edge i have a XG firewall. Thru this Nat is done and sends the traffic to my Cisco Cube router

If the same as above was done with an ASA instead of the XG firewall my sip traffic coming into the cube would look similar to this.

Feb 24 06:48:39: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:3045554444@172.16.100.2:5060 SIP/2.0
Via: SIP/2.0/UDP 207.241.166.109:5060;branch=z9hG4bK1sansay2766498rdb139
Record-Route: <sip:sansay2766498rdb139@207.241.166.109:5060;lr;transport=udp>
To: <sip:3045554444@172.16.100.2>
From: "Caller ID" <sip:3045558888@207.241.166.109>;tag=sansay2766498rdb139
Call-ID: 2266226-0-148086546@207.241.166.100
CSeq: 1 INVITE
Contact: <sip:3045558888@207.241.166.109:5060>
Supported: timer,100rel,replaces
Session-Expires: 600;refresher=uac
Min-SE: 90
P-Asserted-Identity: "Caller ID" <sip:3045558888@207.241.166.109:5060>
Max-Forwards: 69
Content-Type: application/sdp
Content-Length: 305

v=0
o=Sansay-VSXi 188 1 IN IP4 207.241.166.109
s=Session Controller
c=IN IP4 207.241.166.109
t=0 0
m=audio 11042 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20

The ASA seems to inspect the sip traffic and change the SIP headers as this initial invite was initially send to the public ip address of the ASA. However when this router received it the invites are pointing to the internal IP address of 172.16.100.2. The only Public ip addresses in the invite is the SIP providers public ip.

When the call is answered and the router sends OK responses back to the provider it is also sending the internal ip address of the router as the contact See below

Feb 24 06:48:39: //972717/6ED80257A228/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 207.241.166.109:5060;branch=z9hG4bK2sansay2766498rdb139
From: "Caller ID" <sip:3045558888@207.241.166.109>;tag=sansay2766498rdb139
To: <sip:3045554444@172.16.100.2>;tag=F5299B8-D11
Date: Mon, 24 Feb 2020 06:48:39 GMT
Call-ID: 2266226-0-148086546@207.241.166.100
CSeq: 2 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:7000@172.16.100.2>;party=called;screen=no;privacy=off
Contact: <sip:3045554444@172.16.100.2:5060>
Record-Route: <sip:sansay2766498rdb139@207.241.166.109:5060;lr;transport=udp>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.5.3.M4a
Require: timer
Session-Expires: 1800;refresher=uac
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 247

v=0
o=CiscoSystemsSIP-GW-UserAgent 1350 3702 IN IP4 172.16.135.2
s=SIP Call
c=IN IP4 172.16.100.2
t=0 0
m=audio 18080 RTP/AVP 0 101
c=IN IP4 172.16.100.2
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

The ASA changes these headers as it sends back out and the provider receives a sip header with the contact as the public ip address instead of the internal ip address show above.

NOW the xg firewall does not change any of the headers. When the sip invite comes into the router with an XG as the edge devices the router sees the exact same invite that came to the Public ip address. see below

*Feb 24 07:27:16.058: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+13045554444@PUBLIC IPSIP/2.0
Record-Route: <sip:54.172.60.3:5060;lr>
From: <sip:+13045558888@jbnet.pstn.twilio.com:5060>;tag=87935968_6772d868_a1892616-54fb-4b3c-9a3c-d31760ccad0c
To: <sip:+130425554444@Public IP>
CSeq: 3037 INVITE
Max-Forwards: 62
Call-ID: bc4e596bb0c37409290b4d7c47562771@0.0.0.0
Via: SIP/2.0/UDP 54.172.60.3:5060;branch=z9hG4bKbca9.ca04ac75.0
Via: SIP/2.0/UDP 172.18.13.233:5060;rport=5060;received=172.18.13.233;branch=z9hG4bKa1892616-54fb-4b3c-9a3c-d31760ccad0c_6772d868_500-444794762458710658
Contact: <sip:+13045558888@172.18.13.233:5060;transport=udp>
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,NOTIFY
User-Agent: Twilio Gateway
X-Twilio-AccountSid: AC4ae81b353ede92009eaa8dcab18e14ab
Content-Type: application/sdp
X-Twilio-CallSid: CA1e31fd9977b8dbc7af863c01276413de
Content-Length: 278

v=0
o=root 1612282389 1612282389 IN IP4 34.203.250.95
s=Twilio Media Gateway
c=IN IP4 34.203.250.95
t=0 0
m=audio 18110 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

So the sip headers have not been "translated" like an ASA does.

The router still processes the sip invite and the phone rings. It is answered and RTP traffic starts flowing however when the router sends the OK back out towards the provider it has the internal ip addresses in the headers. The external SIP provider sees this and can not process it as it is a internal ip address so after so many retries the connection is dropped. below is an example

*Feb 24 07:27:18.500: //5866/EAB5FB748DF9/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 54.172.60.3:5060;branch=z9hG4bKbca9.ca04ac75.0,SIP/2.0/UDP 172.18.13.233:5060;rport=5060;received=172.18.13.233;branch=z9hG4bKa1892616-54fb-4b3c-9a3c-d31760ccad0c_6772d868_500-444794762458710658
From: <sip:+13045554444@jbnet.pstn.twilio.com:5060>;tag=87935968_6772d868_a1892616-54fb-4b3c-9a3c-d31760ccad0c
To: <sip:+13045558888@Public IP;tag=2CAF75D6-64B
Date: Mon, 24 Feb 2020 07:27:16 GMT
Call-ID: bc4e596bb0c37409290b4d7c47562771@0.0.0.0
CSeq: 3037 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "Jim Boothe" <sip:1000@10.10.7.3>;party=called;screen=yes;privacy=off
Contact: <sip:+13045558888@10.10.7.3:5060>
Record-Route: <sip:54.172.60.3:5060;lr>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-16.9.5
Session-ID: b03f9bde87ab037f338308ba31352863;remote=2ad3ad20d0f85a0b9f88d318a6d33259
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 236

v=0
o=CiscoSystemsSIP-GW-UserAgent 9868 843 IN IP4 10.10.7.3
s=SIP Call
c=IN IP4 10.10.7.3
t=0 0
m=audio 8500 RTP/AVP 0 101
c=IN IP4 10.10.7.3
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

So to fix this i create a sip-profile in the cisco router

voice class sip-profiles 100
response ANY sip-header Contact modify "10.10.7.3" "Public IP"

there are many other headers in the above that you can modify if having problems. Will be different with different sip providers i would imagine on what they are looking for. For example you may need to add the remote-party-ID header as well.

The above sip profile was then added to the incoming dial-peer of the router.

so now when the responses go back out to towards the sip provider it looks like the following

Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 54.172.60.3:5060;branch=z9hG4bKbca9.ca04ac75.0,SIP/2.0/UDP 172.18.13.233:5060;rport=5060;received=172.18.13.233;branch=z9hG4bKa1892616-54fb-4b3c-9a3c-d31760ccad0c_6772d868_500-444794762458710658
From: <sip:+13045554444@jbnet.pstn.twilio.com:5060>;tag=87935968_6772d868_a1892616-54fb-4b3c-9a3c-d31760ccad0c
To: <sip:+13045558888@Public IP;tag=2CAF75D6-64B
Date: Mon, 24 Feb 2020 07:27:16 GMT
Call-ID: bc4e596bb0c37409290b4d7c47562771@0.0.0.0
CSeq: 3037 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "Jim Boothe" <sip:1000@10.10.7.3>;party=called;screen=yes;privacy=off
Contact: <sip:+13045558888@Public IP5060>
Record-Route: <sip:54.172.60.3:5060;lr>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-16.9.5
Session-ID: b03f9bde87ab037f338308ba31352863;remote=2ad3ad20d0f85a0b9f88d318a6d33259
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 236

v=0
o=CiscoSystemsSIP-GW-UserAgent 9868 843 IN IP4 10.10.7.3
s=SIP Call
c=IN IP4 10.10.7.3
t=0 0
m=audio 8500 RTP/AVP 0 101
c=IN IP4 10.10.7.3
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

I hope this helps the next person trying to work with Cisco behind a Sophos.

Also if you are working with a sip provider that you actually have a registered sip trunk where you provide credentials to register the trunk the above should not be involved as the registration process is different and will go out of the xg talk with your sip provider use the handshake with the credentials and the trunk will register and calls will flow through the trunk no problem. The above is only when dealing with NON registered trunks where the provider is sending calls towards our Public ip addess.
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data