Mailing List Archive: CUBE un-normalizing P-Asserted-Identity on 200 OK after REINVITE for hold

CUBE un-normalizing P-Asserted-Identity on 200 OK after REINVITE for hold

Aug 28, 2020, 4:29 PM

Post #1 of 3 (958 views)

So from the PSTN side I get 10 digit caller id and called number, I
transform both calling and called with a voice translation profile. Works
great, been doing it for years.

However I am working on this 3rd party IVR that does some call treatment
then does a hold with a REINVITE and then a REFER. After the REINVITE
happens the CUBE responds with a 200 OK, but it changes the
P-Asserted-Identity from having the +15554441234 to just the 5554441234,
CUCM sees this and says oh I need to send an UPDATE out the other leg, but
the other leg is sending the REFER and doesn't process the UPDATE and so
CUCM won't process the REFER and the whole thing blows up. If I require a
MTP on the incoming CUBE leg, it seems like that isolates the CUBE from the
HOLD reinvite and then it doesn't change the P-Asserted-Identity and the
flow works fine.

Why would CUBE decide to change the P-Asserted-Identity, and how do I make
it not? I was thinking I could just do a SIP Profile to change the
P-Asserted-Identity back to the normalized form on the OK, but I don't want
to go there first.

Running 16.9.5 IOS, feels like a bug but not finding anything with my
googling.

Thanks,
-Nate

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: CUBE un-normalizing P-Asserted-Identity on 200 OK after REINVITE for hold [ In reply to ]

tschlotterer at presidio

Aug 31, 2020, 6:27 AM

Post #2 of 3 (950 views)

Permalink

You can use:

Voice service voip
sip
no update-callerid

To stop the cube from sending the updated caller ID out.

You can also use the following on the dialpeer side to disable the updates:

no voice-class sip asserted-id

Thanks

Tommy

Tommy Schlotterer | Engineer

Presidio
| presidio.com<http://www.presidio.com/>

20 N Saint Clair 3rd Floor, Toledo, OH 43604
D: 419.214.1415<tel:419.214.1415> | C: 419.706.0259<tel:419.706.0259> | tschlotterer@presidio.com<mailto:tschlotterer@presidio.com>

[https://www2.presidio.com/signatures/Presidio_Blue_FutureBuilt_200px.png]<http://www.presidio.com/>

-----Original Message-----
From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of nateccie@gmail.com
Sent: Friday, August 28, 2020 7:30 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] CUBE un-normalizing P-Asserted-Identity on 200 OK after REINVITE for hold

EXTERNAL EMAIL

So from the PSTN side I get 10 digit caller id and called number, I transform both calling and called with a voice translation profile. Works great, been doing it for years.

However I am working on this 3rd party IVR that does some call treatment then does a hold with a REINVITE and then a REFER. After the REINVITE happens the CUBE responds with a 200 OK, but it changes the P-Asserted-Identity from having the +15554441234 to just the 5554441234, CUCM sees this and says oh I need to send an UPDATE out the other leg, but the other leg is sending the REFER and doesn't process the UPDATE and so CUCM won't process the REFER and the whole thing blows up. If I require a MTP on the incoming CUBE leg, it seems like that isolates the CUBE from the HOLD reinvite and then it doesn't change the P-Asserted-Identity and the flow works fine.

Why would CUBE decide to change the P-Asserted-Identity, and how do I make it not? I was thinking I could just do a SIP Profile to change the P-Asserted-Identity back to the normalized form on the OK, but I don't want to go there first.

Running 16.9.5 IOS, feels like a bug but not finding anything with my googling.

Thanks,
-Nate

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments. Please be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.

Re: CUBE un-normalizing P-Asserted-Identity on 200 OK after REINVITE for hold [ In reply to ]

nateccie at gmail

Aug 31, 2020, 4:25 PM

Post #3 of 3 (950 views)

Permalink

Tommy,

Thank you for your reply.

As it turns out the customer had “midcall-signaling passthru” configured which was sending the hold INVITEs to the service provider, and then the CUBE was not re-translating the PAI. I changed it to “midcall-signaling passthru media-change” which made the hold INVITEs stop at the SBC which made the caller id not update and then CUCM not send the UPDATE message so the REFER worked.

Thanks,

-Nate

From: Schlotterer, Tommy <tschlotterer@presidio.com>
Sent: Monday, August 31, 2020 7:27 AM
To: nateccie@gmail.com; cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] CUBE un-normalizing P-Asserted-Identity on 200 OK after REINVITE for hold

You can use:

Voice service voip
sip
no update-callerid

To stop the cube from sending the updated caller ID out.

You can also use the following on the dialpeer side to disable the updates:

no voice-class sip asserted-id

Thanks

Tommy

Tommy Schlotterer

|

Engineer

Presidio

|

<http://www.presidio.com/> presidio.com

20 N Saint Clair 3rd Floor, Toledo, OH 43604

D: <tel:419.214.1415> 419.214.1415

|

C: <tel:419.706.0259> 419.706.0259

|

<mailto:tschlotterer@presidio.com> tschlotterer@presidio.com

<http://www.presidio.com/>

-----Original Message-----
From: cisco-voip <cisco-voip-bounces@puck.nether.net <mailto:cisco-voip-bounces@puck.nether.net> > On Behalf Of nateccie@gmail.com <mailto:nateccie@gmail.com>
Sent: Friday, August 28, 2020 7:30 PM
To: cisco-voip@puck.nether.net <mailto:cisco-voip@puck.nether.net>
Subject: [cisco-voip] CUBE un-normalizing P-Asserted-Identity on 200 OK after REINVITE for hold

EXTERNAL EMAIL

So from the PSTN side I get 10 digit caller id and called number, I transform both calling and called with a voice translation profile. Works great, been doing it for years.

However I am working on this 3rd party IVR that does some call treatment then does a hold with a REINVITE and then a REFER. After the REINVITE happens the CUBE responds with a 200 OK, but it changes the P-Asserted-Identity from having the +15554441234 to just the 5554441234, CUCM sees this and says oh I need to send an UPDATE out the other leg, but the other leg is sending the REFER and doesn't process the UPDATE and so CUCM won't process the REFER and the whole thing blows up. If I require a MTP on the incoming CUBE leg, it seems like that isolates the CUBE from the HOLD reinvite and then it doesn't change the P-Asserted-Identity and the flow works fine.

Why would CUBE decide to change the P-Asserted-Identity, and how do I make it not? I was thinking I could just do a SIP Profile to change the P-Asserted-Identity back to the normalized form on the OK, but I don't want to go there first.

Running 16.9.5 IOS, feels like a bug but not finding anything with my googling.

Thanks,
-Nate

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net <mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments. Please be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.