[cisco-voip] CUBE behavior

[Somphol Boonjing]

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, <Zoltan.Kelemen at emerson.com> 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: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
> >;tag=1518352~5715354d-5e10-479a-bb99-fd13399246ab-42474051
>
> To: "Foo Foo" <sip:00222222222 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
> >;tag=1518352~5715354d-5e10-479a-bb99-fd13399246ab-42474051
>
> To: "Foo Foo" <sip:00222222222 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/d5cc037c/attachment.html>