[cisco-voip] CUBE behavior
Zoltan.Kelemen at Emerson.com
Zoltan.Kelemen at Emerson.com
Thu Feb 6 00:55:28 EST 2014
Hi Somphol,
1) Why I'm not sure WHY CUCM would send the INVITE with <caller_ext>@CUBE, the key for putting a call on hold and resuming is in the SDP attached to that INVITE's, not the address URL. As long as the outcome is as desired, the actual address URL used after the INVITE may not matter. Although I suspect this does have a reasonable explanation :)
2) CUBE, by default is designed to maximize security, hiding everything and anything behind it. To pass PAI use:
sip
asserted-id pai
Regards,
Zoltan Kelemen
Global Communications and Information Security
Implementation Engineering
Emerson
From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Somphol Boonjing
Sent: Wednesday, February 05, 2014 7:23 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] CUBE behavior
Hi,
We are running CUCM 8.6.2 and CUBE 15.2(2)T1. I collect SIP trace from an incoming call made between from ITSP to one of our number.
There are two things from SIP trace collected from CUBE that I don't quite understand. If anyone has seen similar things and able to explain what happens, that would be great.
[1] After the call is put on hold and a Resume button is pressed. CUCM seems to send an INVITE to CUBE, but addressing it to our local number. (ext 1111 registered to our CUCM at 2.2.2.2, but the CUCM send out INVITE to 1111 at CUBE_IP)
The trace of the anomaly one.
Feb 3 13:11:31.062: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:1111 at 203.13.194.13:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 2.2.2.2:5060;branch=z9hG4bK224ce234d6995
From: <sip:1111 at 2.2.2.2<mailto:sip%3A1111 at 2.2.2.2>>;tag=1518352~5715354d-5e10-479a-bb99-fd13399246ab-42474051
To: "Foo Foo" <sip:00222222222 at 203.13.194.13<mailto:sip%3A00222222222 at 203.13.194.13>>;tag=BCC14C68-1155
All other Re-INVITEs in the trace contain the correct target URI.
Feb 3 13:11:28.086: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:00222222222 at 203.13.194.13:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 2.2.2.2:5060;branch=z9hG4bK224ca3fe1b3aa
From: <sip:1111 at 2.2.2.2<mailto:sip%3A1111 at 2.2.2.2>>;tag=1518352~5715354d-5e10-479a-bb99-fd13399246ab-42474051
To: "Foo Foo" <sip:00222222222 at 203.13.194.13<mailto:sip%3A00222222222 at 203.13.194.13>>;tag=BCC14C68-1155
Is this a known bug or by design?
[2] For Re-INVITE, CUBE seems to filter both "Remote-Party-ID" & "P-Asserted-Identify" before sending it out to our ITSP. Is this expected? CUBE seems to be very young and many aspect of its operation is fairly undocumented so I don't know whether this is a bug or by-design.
Here is the relevant configuration on CUBE
#show run | b voice service voip
voice service voip
ip address trusted list
....
...
address-hiding
mode border-element
allow-connections sip to sip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
bind control source-interface GigabitEthernet0/0
bind media source-interface GigabitEthernet0/0
session transport tcp
rel1xx disable
header-passing
error-passthru
midcall-signaling passthru
pass-thru content sdp
...
...
A full call trace in question is attached.
Regards,
--Somphol.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140206/9a2eff40/attachment.html>
More information about the cisco-voip
mailing list