[cisco-voip] CUBE ignoring SDP responses from ITSP
Anthony Holloway
avholloway+cisco-voip at gmail.com
Mon Aug 13 00:20:13 EDT 2018
The CUBE config is raising a few questions for me. No doubt I can learn a
thing or two. So, here we go. I'll number them to make it easier to
cherry pick them.
1) Why are you using the *address-hiding command*? What does this command
do, that CUBE doesn't already do by default, as a B2B UA?
2) Why are you using the *no supplementary-service sip moved-temporarily*
command? I have no experience with this command.
3) Why are you using the *no supplementary-service sip refer* command? I
have no experience with this command.
4) Why are you using the *registrar server* command in the sip global
config? Usually this is just for turning on the SIP registrar within the
IOS GW, for SRST as one example. Are you doing that?
5) Why are you using the* no update-callerid* command in the sip global
config? I have no experience with this command.
6) Why are you using the *early-offer forced* command in the sip global
config? Most devices on the inside of your network should be able to
produce an EO flow for you. Unless you know of something which does not?
Also, do you use Early Offer Best Effort on your SIP trunk in CUCM?
7) Why are you using the *midcall-signaling passthru* command in the sip
global config? Typically you do not want to passthru mid-call signaling,
unless it results in a media change, which you do by adding *media-change*
to the end of that command.
8) Why are you using the *pass-thru content sdp* command in the sip global
config? You are already trying to hide addresses, and CUBE is being told
what the capabilities are for the outgoing dial-peers.
9) Is this a legit way to change the ptime of the codec, as opposed to
changing it with the bytes parameter of the codec command? I do see that
you don't have it applied to any dial-peer, so you're likely not using it.
voice class sip-profiles 30
request ANY sdp-header Audio-Attribute modify "a=ptime:20" "a=ptime:30"
!
10) Why are you using NAT on CUBE?
11) Why do you have a *session target* on an incoming dial-peer?
dial-peer voice 1000 voip
description BANDWIDTH Incoming SIP and VOIP calls
session protocol sipv2
*session target sip-server*
incoming called-number .
voice-class codec 1
dtmf-relay rtp-nte sip-notify
no vad
!
12) How are you differentiating between dial-peer 4000 and dial-peer 2001
when they have the same destination-pattern?
dial-peer voice 4000 voip
description Local Dialing (10-Digit) to Bandwidth SIP Trunk
translation-profile outgoing OutgoingToBandwidthSIP
*destination-pattern [2-9]..[2-9]......$*
session protocol sipv2
session target ipv4:67.231.8.75
voice-class codec 1
dtmf-relay rtp-nte
no vad
!
dial-peer voice 2001 voip
description Incoming SIP Calls to CUCM Sub
translation-profile incoming LOCALIZE
*destination-pattern [2-9]..[2-9]......$*
session protocol sipv2
session target ipv4:192.168.1.20
voice-class codec 1
no voice-class sip outbound-proxy
dtmf-relay rtp-nte sip-notify
no vad
!
13) Why are you using the no voice-class sip outbound-proxy command on
dial-peer 2001? I have no experience with this command.
14) Is this for a lab or maybe just personal use?
Alright, so it turned out to be 14 questions, that's not too bad. I look
forward to anyone's replies to these questions, and I hope to learn
something from this.
Thanks for sparking such a lively conversation around your adventure with
CUBE.
On Sat, Aug 11, 2018 at 3:53 PM Benjamin Turner <benmturner at hotmail.com>
wrote:
> Does anyone have any objections to an IOS upgrade over moving the nat to a
> loopback interface?
>
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------------------------------
> *From:* Bill Talley <btalley at gmail.com>
> *Sent:* Saturday, August 11, 2018 4:21:03 PM
> *To:* NateCCIE
> *Cc:* Benjamin Turner; cisco-voip voyp list
> *Subject:* Re: [cisco-voip] CUBE ignoring SDP responses from ITSP
>
> Right, I may have misunderstood this was CUBE only.
>
> Sent from an iOS device with very tiny touchscreen input keys. Please
> excude my typtos.
>
> On Aug 11, 2018, at 2:55 PM, NateCCIE <nateccie at gmail.com> wrote:
>
> NAT as in ip nat outside and ip nat inside, etc, would be used for other
> traffic that is flowing through the router. Address hiding for a SIP
> connection is different.
>
>
>
> *From:* Bill Talley <btalley at gmail.com>
> *Sent:* Saturday, August 11, 2018 1:08 PM
> *To:* NateCCIE <nateccie at gmail.com>
> *Cc:* Benjamin Turner <benmturner at hotmail.com>; cisco-voip voyp list <
> cisco-voip at puck.nether.net>
> *Subject:* Re: [cisco-voip] CUBE ignoring SDP responses from ITSP
>
>
>
> Is that not essentially what address hiding and binding the telco facing
> dial-peer to the outside interface accomplishes?
>
> Sent from an iOS device with very tiny touchscreen input keys. Please
> excude my typtos.
>
>
> On Aug 11, 2018, at 1:24 PM, NateCCIE <nateccie at gmail.com> wrote:
>
> No, if you want to do NAT, it has to be on a different interface than what
> CUBE is using for SIP.
>
>
>
> *From:* Benjamin Turner <benmturner at hotmail.com>
> *Sent:* Saturday, August 11, 2018 12:03 PM
> *To:* NateCCIE <nateccie at gmail.com>
> *Cc:* Ryan Huff <ryanhuff at outlook.com>; cisco-voip voyp list <
> cisco-voip at puck.nether.net>
> *Subject:* Re: [cisco-voip] CUBE ignoring SDP responses from ITSP
>
>
>
> So should I implement a voice class sip profile to modify the sip headers?
>
>
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
>
> ------------------------------
>
> *From:* NateCCIE <nateccie at gmail.com>
> *Sent:* Saturday, August 11, 2018 1:46:31 PM
> *To:* Benjamin Turner
> *Cc:* Ryan Huff; cisco-voip voyp list
> *Subject:* Re: [cisco-voip] CUBE ignoring SDP responses from ITSP
>
>
>
> You can’t have ip NAT outside on a CUBE. It used to work before the 4K but
> it was never supported according to TAC and the BU.
>
>
>
> Inbound traffic goes to the NAT process and the SIP stack never sees it
>
> Sent from my iPhone
>
>
> On Aug 10, 2018, at 9:38 PM, Benjamin Turner <benmturner at hotmail.com>
> wrote:
>
> My brain is FRIED
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
>
> ------------------------------
>
> *From:* Benjamin Turner <benmturner at hotmail.com>
> *Sent:* Friday, August 10, 2018 11:35:15 PM
> *To:* Ryan Huff
> *Cc:* Bill Talley; cisco-voip voyp list
> *Subject:* Re: [cisco-voip] CUBE ignoring SDP responses from ITSP
>
>
>
> I did. They see my outside IP (multiple) invites and they are sending 1xx
> responses. And, I see them too on my cube with a monitor capture. I just do
> not see them with a debug ccsip messages
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
>
> ------------------------------
>
> *From:* Ryan Huff <ryanhuff at outlook.com>
> *Sent:* Friday, August 10, 2018 11:32:08 PM
> *To:* Benjamin Turner
> *Cc:* Bill Talley; cisco-voip voyp list
> *Subject:* Re: [cisco-voip] CUBE ignoring SDP responses from ITSP
>
>
>
> and you’re sure you’re signaling the correct peer address for signaling
> that the carrier gave you when they provisioned the trunk?
>
> You may need to do a live TSHOOT with the carrier so they can tell you if
> they are (and what) they see in their SBC.
>
>
> On Aug 10, 2018, at 23:29, Benjamin Turner <benmturner at hotmail.com> wrote:
>
> Yeah tried both ways. Inside and outside IP on the cucm trunk config
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
>
> ------------------------------
>
> *From:* Bill Talley <btalley at gmail.com>
> *Sent:* Friday, August 10, 2018 11:28:02 PM
> *To:* Benjamin Turner
> *Cc:* Ryan Huff; cisco-voip voyp list
> *Subject:* Re: [cisco-voip] CUBE ignoring SDP responses from ITSP
>
>
>
> Just confirming when you changed the bindings in IOS, did you change the
> SIP trunk destination IP address in CUCM to point to the inside address of
> CUBE and reset the trunk?
>
> Sent from an iOS device with very tiny touchscreen input keys. Please
> excude my typtos.
>
>
> On Aug 10, 2018, at 9:25 PM, Benjamin Turner <benmturner at hotmail.com>
> wrote:
>
> Acl is not blocking and I tried to set binding on outbound dial-peer to
> outbound interface and inbound dial-peer to inbound interface
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
>
> ------------------------------
>
> *From:* Ryan Huff <ryanhuff at outlook.com>
> *Sent:* Friday, August 10, 2018 10:23:00 PM
> *To:* Benjamin Turner
> *Cc:* Loren Hillukka; cisco-voip voyp list
> *Subject:* Re: [cisco-voip] CUBE ignoring SDP responses from ITSP
>
>
>
> I would suggest a couple of things to start with;
>
>
>
> 1.) Ditch the global bindings on 0/0/0 and bind your individual dial-peers
> to the appropriate interfaces
>
>
>
> 2.) Verify your ACL 101 isn’t interfering (you didn’t include your access
> lists so I can’t tell)
>
>
>
> Sent from my iPhone
>
>
> On Aug 10, 2018, at 22:15, Benjamin Turner <benmturner at hotmail.com> wrote:
>
> Very basic:
>
>
>
>
>
>
>
> version 15.5
>
>
>
> voice service voip
>
> ip address trusted list
>
> ipv4 67.231.8.75
>
> ipv4 67.231.12.12
>
> ipv4 192.168.1.20
>
> ipv4 162.245.36.90
>
> address-hiding
>
> mode border-element license capacity 100
>
> allow-connections sip to sip
>
> no supplementary-service sip moved-temporarily
>
> no supplementary-service sip refer
>
> fax protocol pass-through g711ulaw
>
> sip
>
> bind control source-interface GigabitEthernet0/0/0
>
> bind media source-interface GigabitEthernet0/0/0
>
> registrar server
>
> no update-callerid
>
> early-offer forced
>
> midcall-signaling passthru
>
> pass-thru content sdp
>
> !
>
> voice class codec 1
>
> codec preference 1 g711ulaw
>
> codec preference 2 g729r8
>
> !
>
> !
>
> voice class sip-profiles 30
>
> request ANY sdp-header Audio-Attribute modify "a=ptime:20" "a=ptime:30"
>
> !
>
> !
>
> !
>
> !
>
> !
>
> voice translation-rule 2
>
> rule 1 /\+1\([2-9].........\)/ /\1/
>
> !
>
> voice translation-rule 11
>
> rule 1 /\([2-9]..[2-9]......$\)/ /+1\1/
>
> rule 2 /\(.*\)/ /+\1/
>
> !
>
> voice translation-rule 22
>
> rule 1 /9\(1[2-9]..[2-9]......\)$/ /\1/
>
> rule 2 /9\(911\)$/ /\1/
>
> rule 3 /9\([2-8]11\)$/ /\1/
>
> !
>
> !
>
> voice translation-profile 10DigitTo+1
>
> translate calling 11
>
> translate called 11
>
> !
>
> voice translation-profile LOCALIZE
>
> translate calling 2
>
> !
>
> voice translation-profile OutgoingToBandwidthSIP
>
> translate calling 2
>
> translate called 11
>
> !
>
> !
>
> !
>
> !
>
> voice-card 0/4
>
> dsp services dspfarm
>
> no watchdog
>
> !
>
> !
>
> interface GigabitEthernet0/0/0
>
> description WAN SIP TRUNK TO BANDWIDTH
>
> ip address 162.245.36.90 255.255.255.248
>
> ip nat outside
>
> ip access-group 101 in
>
> ip access-group 101 out
>
> negotiation auto
>
> no cdp enable
>
> !
>
> interface GigabitEthernet0/0/1
>
> description LAN
>
> ip address 192.168.1.1 255.255.255.0
>
> ip nat inside
>
> negotiation auto
>
> !
>
> interface GigabitEthernet0/0/2
>
> no ip address
>
> negotiation auto
>
> !
>
> interface Service-Engine0/4/0
>
> !
>
> interface GigabitEthernet0
>
> vrf forwarding Mgmt-intf
>
> no ip address
>
> negotiation auto
>
> !
>
> !
>
> ip nat inside source list 100 interface GigabitEthernet0/0/0 overload
>
> !
>
> !
>
> !
>
> dial-peer voice 1000 voip
>
> description BANDWIDTH Incoming SIP and VOIP calls
>
> session protocol sipv2
>
> session target sip-server
>
> incoming called-number .
>
> voice-class codec 1
>
> dtmf-relay rtp-nte sip-notify
>
> no vad
>
> !
>
> dial-peer voice 4000 voip
>
> description Local Dialing (10-Digit) to Bandwidth SIP Trunk
>
> translation-profile outgoing OutgoingToBandwidthSIP
>
> destination-pattern [2-9]..[2-9]......$
>
> session protocol sipv2
>
> session target ipv4:67.231.8.75
>
> voice-class codec 1
>
> dtmf-relay rtp-nte
>
> no vad
>
> !
>
> dial-peer voice 4001 voip
>
> description LD Dialing (11-Digit) to Bandwidth SIP Trunk
>
> translation-profile outgoing OutgoingToBandwidthSIP
>
> destination-pattern 1[2-9]..[2-9]......$
>
> session protocol sipv2
>
> session target ipv4:67.231.8.75
>
> voice-class codec 1
>
> dtmf-relay rtp-nte
>
> no vad
>
> !
>
> dial-peer voice 2001 voip
>
> description Incoming SIP Calls to CUCM Sub
>
> translation-profile incoming LOCALIZE
>
> destination-pattern [2-9]..[2-9]......$
>
> session protocol sipv2
>
> session target ipv4:192.168.1.20
>
> voice-class codec 1
>
> no voice-class sip outbound-proxy
>
> dtmf-relay rtp-nte sip-notify
>
> no vad
>
> !
>
> !
>
> sip-ua
>
> !
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
> ------------------------------
>
> *From:* Ryan Huff <ryanhuff at outlook.com>
> *Sent:* Friday, August 10, 2018 10:04:54 PM
> *To:* Benjamin Turner
> *Cc:* Loren Hillukka; cisco-voip voyp list
> *Subject:* Re: [cisco-voip] CUBE ignoring SDP responses from ITSP
>
>
>
> Can I get a show tech or at least a show run?
>
> Sent from my iPhone
>
>
> On Aug 10, 2018, at 22:03, Benjamin Turner <benmturner at hotmail.com> wrote:
>
> Its an edge device no fw in place between cube and provider
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
>
> ------------------------------
>
> *From:* Ryan Huff <ryanhuff at outlook.com>
> *Sent:* Friday, August 10, 2018 10:02:42 PM
> *To:* Benjamin Turner
> *Cc:* Loren Hillukka; cisco-voip voyp list
> *Subject:* Re: [cisco-voip] CUBE ignoring SDP responses from ITSP
>
>
>
> Is it a PA, ASA? Do you have inspection and ALG disabled on the firewall?
>
> Sent from my iPhone
>
>
> On Aug 10, 2018, at 22:00, Benjamin Turner <benmturner at hotmail.com> wrote:
>
> Sit in front of the fw
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
>
> ------------------------------
>
> *From:* Loren Hillukka <lchillukka at hotmail.com>
> *Sent:* Friday, August 10, 2018 9:58:49 PM
> *To:* Benjamin Turner
> *Cc:* Ryan Huff; cisco-voip voyp list
> *Subject:* Re: [cisco-voip] CUBE ignoring SDP responses from ITSP
>
>
>
> Any firewall in place there? I have seen firewalls modify/drop just enough
> to make the gateway not recognize a response.
>
> Sent from my iPhone
>
>
> On Aug 10, 2018, at 8:35 PM, Benjamin Turner <benmturner at hotmail.com>
> wrote:
>
> Yes, and my LAN side too
>
>
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
> ------------------------------
>
> *From:* Ryan Huff <ryanhuff at outlook.com>
> *Sent:* Friday, August 10, 2018 9:33:49 PM
> *To:* Benjamin Turner
> *Cc:* Brian Meade; cisco-voip voyp list
> *Subject:* Re: [cisco-voip] CUBE ignoring SDP responses from ITSP
>
>
>
> So do you have all the correct signaling addresses from the provider
> included in the ipv4 trusted list (SIP ACL)?
>
>
>
> Sent from my iPhone
>
>
> On Aug 10, 2018, at 21:31, Benjamin Turner <benmturner at hotmail.com> wrote:
>
> A debug ccsip messages never sees these responses. Here is the monitor
> capture from the cube:
>
>
>
>
>
> -------------------------------------------------------------
>
> # size timestamp source destination protocol
>
> -------------------------------------------------------------
>
> 0 927 0.000000 162.245.36.90 -> 67.231.8.75 UDP
>
> 0000: 70E42202 57CB00B6 70707740 08004568 p.".W...ppw at ..Eh
>
> 0010: 03910000 0000FF11 A472A2F5 245A43E7 .........r..$ZC.
>
> 0020: 084BF7D6 13C4037D C3C2494E 56495445 .K.....}..INVITE
>
> 0030: 20736970 3A313935 34363338 39303635 sip:19546389065
>
>
>
> 1 363 0.043989 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 015DBFAA 40003311 731C43E7 084BA2F5 .].. at .3.s.C..K..
>
> 0020: 245A13C4 13C40149 21EA5349 502F322E $Z.....I!.SIP/2.
>
> 0030: 30203130 30205472 79696E67 0D0A5669 0 100 Trying..Vi
>
>
>
> 2 927 0.500026 162.245.36.90 -> 67.231.8.75 UDP
>
> 0000: 70E42202 57CB00B6 70707740 08004568 p.".W...ppw at ..Eh
>
> 0010: 03910001 0000FF11 A471A2F5 245A43E7 .........q..$ZC.
>
> 0020: 084BF7D6 13C4037D C1C2494E 56495445 .K.....}..INVITE
>
> 0030: 20736970 3A313935 34363338 39303635 sip:19546389065
>
>
>
> 3 363 0.544015 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 015DBFB1 40003311 731543E7 084BA2F5 .].. at .3.s.C..K..
>
> 0020: 245A13C4 13C40149 21EA5349 502F322E $Z.....I!.SIP/2.
>
> 0030: 30203130 30205472 79696E67 0D0A5669 0 100 Trying..Vi
>
>
>
> 4 927 1.500026 162.245.36.90 -> 67.231.8.75 UDP
>
> 0000: 70E42202 57CB00B6 70707740 08004568 p.".W...ppw at ..Eh
>
> 0010: 03910002 0000FF11 A470A2F5 245A43E7 .........p..$ZC.
>
> 0020: 084BF7D6 13C4037D BFC2494E 56495445 .K.....}..INVITE
>
> 0030: 20736970 3A313935 34363338 39303635 sip:19546389065
>
>
>
> 5 363 1.544015 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 015DC013 40003311 72B343E7 084BA2F5 .].. at .3.r.C..K..
>
> 0020: 245A13C4 13C40149 21EA5349 502F322E $Z.....I!.SIP/2.
>
> 0030: 30203130 30205472 79696E67 0D0A5669 0 100 Trying..Vi
>
>
>
> 6 439 2.289039 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 01A9C09D 40003311 71DD43E7 084BA2F5 .... at .3.q.C..K..
>
> 0020: 245A13C4 13C40195 CADC5349 502F322E $Z........SIP/2.
>
> 0030: 30203138 33205365 7373696F 6E205072 0 183 Session Pr
>
>
>
> 7 927 3.500026 162.245.36.90 -> 67.231.8.75 UDP
>
> 0000: 70E42202 57CB00B6 70707740 08004568 p.".W...ppw at ..Eh
>
> 0010: 03910003 0000FF11 A46FA2F5 245A43E7 .........o..$ZC.
>
> 0020: 084BF7D6 13C4037D CECA494E 56495445 .K.....}..INVITE
>
> 0030: 20736970 3A313935 34363338 39303635 sip:19546389065
>
>
>
> 8 439 3.544015 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 01A9C0D7 40003311 71A343E7 084BA2F5 .... at .3.q.C..K..
>
> 0020: 245A13C4 13C40195 CADC5349 502F322E $Z........SIP/2.
>
> 0030: 30203138 33205365 7373696F 6E205072 0 183 Session Pr
>
>
>
> 9 927 7.500026 162.245.36.90 -> 67.231.8.75 UDP
>
> 0000: 70E42202 57CB00B6 70707740 08004568 p.".W...ppw at ..Eh
>
> 0010: 03910004 0000FF11 A46EA2F5 245A43E7 .........n..$ZC.
>
> 0020: 084BF7D6 13C4037D C6CA494E 56495445 .K.....}..INVITE
>
> 0030: 20736970 3A313935 34363338 39303635 sip:19546389065
>
>
>
> 10 439 7.544015 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 01A9C17A 40003311 710043E7 084BA2F5 ...z at .3.q.C..K..
>
> 0020: 245A13C4 13C40195 CADC5349 502F322E $Z........SIP/2.
>
> 0030: 30203138 33205365 7373696F 6E205072 0 183 Session Pr
>
>
>
> 11 789 10.953998 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 0307C459 40003311 6CC343E7 084BA2F5 ...Y at .3.l.C..K..
>
> 0020: 245A13C4 13C402F3 36525349 502F322E $Z......6RSIP/2.
>
> 0030: 30203230 30204F4B 0D0A5669 613A2053 0 200 OK..Via: S
>
>
>
> 12 789 11.454023 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 0307C495 40003311 6C8743E7 084BA2F5 .... at .3.l.C..K..
>
> 0020: 245A13C4 13C402F3 36525349 502F322E $Z......6RSIP/2.
>
> 0030: 30203230 30204F4B 0D0A5669 613A2053 0 200 OK..Via: S
>
>
>
> 13 789 12.450026 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 0307C542 40003311 6BDA43E7 084BA2F5 ...B at .3.k.C..K..
>
> 0020: 245A13C4 13C402F3 36525349 502F322E $Z......6RSIP/2.
>
> 0030: 30203230 30204F4B 0D0A5669 613A2053 0 200 OK..Via: S
>
>
>
> 14 789 14.453016 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 0307C6B3 40003311 6A6943E7 084BA2F5 .... at .3.jiC..K..
>
> 0020: 245A13C4 13C402F3 36525349 502F322E $Z......6RSIP/2.
>
> 0030: 30203230 30204F4B 0D0A5669 613A2053 0 200 OK..Via: S
>
>
>
> 15 789 18.448027 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 0307C7FD 40003311 691F43E7 084BA2F5 .... at .3.i.C..K..
>
> 0020: 245A13C4 13C402F3 36525349 502F322E $Z......6RSIP/2.
>
> 0030: 30203230 30204F4B 0D0A5669 613A2053 0 200 OK..Via: S
>
>
>
> 16 789 22.452025 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 0307CA0B 40003311 671143E7 084BA2F5 .... at .3.g.C..K..
>
> 0020: 245A13C4 13C402F3 36525349 502F322E $Z......6RSIP/2.
>
> 0030: 30203230 30204F4B 0D0A5669 613A2053 0 200 OK..Via: S
>
>
>
> 17 789 26.447020 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 0307CC02 40003311 651A43E7 084BA2F5 .... at .3.e.C..K..
>
> 0020: 245A13C4 13C402F3 36525349 502F322E $Z......6RSIP/2.
>
> 0030: 30203230 30204F4B 0D0A5669 613A2053 0 200 OK..Via: S
>
>
>
> 18 789 30.451018 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 0307CE5F 40003311 62BD43E7 084BA2F5 ..._ at .3.b.C..K..
>
> 0020: 245A13C4 13C402F3 36525349 502F322E $Z......6RSIP/2.
>
> 0030: 30203230 30204F4B 0D0A5669 613A2053 0 200 OK..Via: S
>
>
>
> 19 396 34.456022 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 017ED190 40003311 611543E7 084BA2F5 .~.. at .3.a.C..K..
>
> 0020: 245A13C4 13C4016A B45A4259 45207369 $Z.....j.ZBYE si
>
> 0030: 703A3536 31323932 35323039 40313632 p:5612925209 at 162
>
>
>
> 20 396 34.948993 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 017ED1E2 40003311 60C343E7 084BA2F5 .~.. at .3.`.C..K..
>
> 0020: 245A13C4 13C4016A B45A4259 45207369 $Z.....j.ZBYE si
>
> 0030: 703A3536 31323932 35323039 40313632 p:5612925209 at 162
>
>
>
> 21 396 35.955005 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 017ED2D9 40003311 5FCC43E7 084BA2F5 .~.. at .3._.C..K..
>
> 0020: 245A13C4 13C4016A B45A4259 45207369 $Z.....j.ZBYE si
>
> 0030: 703A3536 31323932 35323039 40313632 p:5612925209 at 162
>
>
>
> 22 396 37.946994 67.231.8.75 -> 162.245.36.90 UDP
>
> 0000: 00B67070 7740046C 9D59F3D0 08004548 ..ppw at .l.Y....EH
>
> 0010: 017ED350 40003311 5F5543E7 084BA2F5 .~.P at .3._UC..K..
>
> 0020: 245A13C4 13C4016A B45A4259 45207369 $Z.....j.ZBYE si
>
> 0030: 703A3536 31323932 35323039 40313632 p:5612925209 at 162
>
>
>
>
>
>
> <B25E410DF89143769AD0C60141937C05.png>
>
> *Benjamin Turner*
> Senior Collaboration Engineer
>
> bturner at c3cloud.com
> Direct: 561.939.4002
>
>
>
> <D419B95F598C431394BFB6C03BB940A4.png>
>
> *Come Meet With Us!*
>
> Oct 9-12
>
> Channel Evolution / Philadelphia
>
> Booth 530
>
> Jan 29-Feb 1
>
> ITEXPO / Fort Lauderdale
>
> Booth 809
>
> Apr 9-12
>
> Channel Partners / Las Vegas
>
> Booth 7043
>
> <D419B95F598C431394BFB6C03BB940A4.png>
>
>
>
> <F60F3978D7164ED69F2520FB0F125D27.jpg> <http://www.c3cloud.com>
> 110 E Atlantic Avenue - Suite 420
> Delray Beach, FL 33444
> www.c3cloud.com
> Main: 561.939.4000
> Help Desk: 877.247.4949 <144479115B534386BBD84134E78DB2A3.png>
> <http://www.facebook.com/c3office>
> <10889A3292EE41C4A7127ACD0CF1DA7C.png>
> <http://www.linkedin.com/company/cloud-computing-concepts-llc-c3->
> <D04742E927C5495886C9A9206DEF7F91.png> <http://www.twitter.com/c3office>
>
>
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
> ------------------------------
>
> *From:* cisco-voip <cisco-voip-bounces at puck.nether.net> on behalf of
> Benjamin Turner <benmturner at hotmail.com>
> *Sent:* Friday, August 10, 2018 9:26:35 PM
> *To:* Brian Meade
> *Cc:* cisco-voip voyp list
> *Subject:* Re: [cisco-voip] CUBE ignoring SDP responses from ITSP
>
>
>
> SIP is bound to the outside interface going to the ITSP:
>
>
>
> bind control source-interface GigabitEthernet0/0/0
>
> bind media source-interface GigabitEthernet0/0/0
>
>
>
> - Tried to bind it to the dial-peer as well
>
>
>
> No response from carrier
>
>
>
> IP is for outbound Invite is my public IP configured on gi0/0/0
>
>
>
> <DEB31912DBE84EA0A9775C00DA7EF37A.png>
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Brian Meade <bmeade90 at vt.edu>
> *Sent: *Friday, August 10, 2018 8:52 PM
> *Subject: *Re: [cisco-voip] CUBE ignoring SDP responses from ITSP
>
>
>
> What does your SIP bind config look like? What IP addresses do you see in
> the 1XX response from the carrier? What is the IP in the Contact header
> for the outbound invite?
>
>
>
> On Fri, Aug 10, 2018 at 6:42 PM Benjamin Turner <benmturner at hotmail.com>
> wrote:
>
> Hey guys,
>
>
>
> Ran out of options. I have a new CUBE deployment to Bandwidth.com SIP
> provider and I see the SDP invites going out the egress interface and
> running a monitor capture on the CUBE, I see the return 1xx responses but
> still not seeing them on the debug messages. So, CUCM sends a CANCEL after
> not receiving any reply’s from the CUBE. The kicker is the call still
> connects. Any help at this point will be great.
>
>
>
>
>
> Thanks,
>
> Ben
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180812/25011faf/attachment.html>
More information about the cisco-voip
mailing list