Hi Zoltan, Thanks a lot for your advice. CUBE is now passing PAI to the other end for Re-INVITE during Hold/Resume even though it only works for outgoing call.
For incoming call, CUBE is still not passing the PAI through to the other side during Re-INVITE. At least, I'm glad we are making some progress. Regards, --Somphol. On Thu, Feb 6, 2014 at 4:55 PM, <[email protected]> wrote: > 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 J > > 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:[email protected]] *On Behalf > Of *Somphol Boonjing > *Sent:* Wednesday, February 05, 2014 7:23 PM > *To:* [email protected] > *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@CUBE_IP) > > > > The trace of the anomaly one. > > > > Feb 3 13:11:31.062: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: > > Received: > > *INVITE sip:[email protected]:5060;transport=tcp SIP/2.0* > > Via: SIP/2.0/TCP 2.2.2.2:5060;branch=z9hG4bK224ce234d6995 > > From: <sip:[email protected] > >;tag=1518352~5715354d-5e10-479a-bb99-fd13399246ab-42474051 > > To: "Foo Foo" <sip:[email protected]>;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:[email protected]:5060;transport=tcp SIP/2.0* > > Via: SIP/2.0/TCP 2.2.2.2:5060;branch=z9hG4bK224ca3fe1b3aa > > From: <sip:[email protected] > >;tag=1518352~5715354d-5e10-479a-bb99-fd13399246ab-42474051 > > To: "Foo Foo" <sip:[email protected]>;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. > > > > >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
