cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3586
Views
0
Helpful
19
Replies
Highlighted
Beginner

Expressway : MRA and B2B issue

Hi,

I have an issue with Expressway C (8.9.2) and CUCM (11.5) with MRA and B2B configured.

When i try to call a MRA device, i see that the call arrived like a B2B call on the Expressway C and he don't find the destination because of the weird URI for the MRA device.

CUCM / 5560 ----- [TRUNK SIP B2B] ----- 5060 / Expressway C

I don't know why the expressway take this type of call like this

Best regards,

Matthieu

19 REPLIES 19
Highlighted
Enthusiast

Hi Matthieu,

Are you trying to call from one MRA device to another MRA device or from internal to an MRA Device ?

For the MRA calls you would see weird URI in the search history which is normal.

Regards,

Alok

Highlighted

Hi Alok,

I can try from a MRA device or a on premise device, it is the same issue when we call a MRA device.

I can see that the trunk used on the reception of the Expressway-C is B2B-SIP-TRUNK and not the Automatic generate SIP trunk for the MRA between the CUCM and the Expressway-C...

On an architecture which works, i can see the generate SIP trunk used when we call a MRA device.

Best regards,

Matthieu

Highlighted

I think i have seen it once, when i was in TAC :). I can't remember exact fix, but let me ask this question to you.

Have you changed  your cucm config for e.g. putting in mixed or something recently or vice-versa. Obviously since you are using MRA so port 5060 & 5061( if cucm in mixed mode) must be already utilized and the zones are created based on that.

Also did you changed the anything else, for e.g. earlier you have added the cucm on Exp-C using ip and then later on you changed the CUCM IP's to FQDN under CUCM-->server and didn't updated the zones on Exp-c ?

I would do a refresh on the CUCM server added on the Exp-C just to make sure if any changes made on cucm can be updated across Exp-C and then try again.

Regards,

Alok

Highlighted

Hello,

I tried several things,

  • I delete the B2B CUCM-NZ on EXPC > Calls to MRA wevice work
  • I recreate the B2B CUCM-NZ on EXPC > Calls to MRA device work 
  • I restart the EXPC > Calls to MRA device NOT work

.... this is a BUG ?

Highlighted

Hi Matthieu,

Can you provide the Exp-C logs and then i can take a look at it. If you can provide the lob bundle i can check the config as well.

Regards,

Alok

Highlighted

And in the EXP_C logs, we can see this,

2017-06-15T16:53:46.217+02:00 EXPRESSWAYC tvcs: UTCTime="2017-06-15 14:53:46,217" Module="developer.nomodule" Level="INFO" CodeLocation="ppcmains/oak/zones/RemoteGatekeeperNetAddrStatus.cpp(98)" Method="RemoteGatekeeperNetAddrStatus::SetAlive" Thread="0x7f3676ea9700":  this="0x562d612ab610" RTT Values m_LastPingRTT (microseconds):1000000  m_TimeLastUpdated: 2945452420769  m_TimeLastPingStarted : 2945452407189  m_TimeLastPingSent: 2945452408376  old rtt calc: 13580

2017-06-15T16:53:46.217+02:00 EXPRESSWAYC tvcs: UTCTime="2017-06-15 14:53:46,217" Module="network.http" Level="DEBUG":  Message="Response" Src-ip="127.0.0.1" Src-port="4370" Dst-ip="127.0.0.1" Dst-port="30810" Response="200 OK" ResponseTime="0.001025" Ref="0x562d5f63b940"

2017-06-15T16:53:48.029+02:00 EXPRESSWAYC tvcs: UTCTime="2017-06-15 14:53:48,029" Module="network.sip" Level="INFO":  Action="Received" Local-ip="IP_EXPC" Local-port="5060" Src-ip="IP_CUCM" Src-port="49178" Detail="Receive Request Method=INVITE, CSeq=101, Request-URI=sip:a0a852a7-3519-b7fb-1981-ee80bbb12498@IP_EXPC:5060;transport=tcp;orig-hostport=IP_DEVICE:40337, Call-ID=6eabab80-94219f7c-8c-bc0a1eac@IP_CUCM, From-Tag=670~7120b90b-18e4-4799-b62f-613d4dcd8d57-17451617, To-Tag=, Msg-Hash=12938905069447432784"

2017-06-15T16:53:48.029+02:00 EXPRESSWAYC tvcs: UTCTime="2017-06-15 14:53:48,029" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="IP_EXPC" Local-port="5060" Src-ip="IP_CUCM" Src-port="49178" Msg-Hash="12938905069447432784"

 SIPMSG:

 |INVITE sip:a0a852a7-3519-b7fb-1981-ee80bbb12498@IP_EXPC:5060;transport=tcp;orig-hostport=IP_DEVICE:40337 SIP/2.0

 Via: SIP/2.0/TCP IP_CUCM:5060;branch=z9hG4bK8b43485f9d

 Call-ID: 6eabab80-94219f7c-8c-bc0a1eac@IP_CUCM

 CSeq: 101 INVITE

 Call-Info: <urn:x-cisco-remotecc:callinfo>;security=Unknown;orientation=from;gci=1-13002;isVoip;call-instance=1

 Remote-Party-ID: "LI1 - Informatique" <sip:sallevisiolima@DOMAIN.fr;x-cisco-number=1012;x-cisco-callback-number=1012>;party=calling;screen=yes;privacy=off

 Contact: <sip:sallevisiolima@IP_CUCM:5060;transport=tcp>;video;audio

 From: "LI1 - Informatique" <sip:sallevisiolima@DOMAIN.fr>;tag=670~7120b90b-18e4-4799-b62f-613d4dcd8d57-17451617

 To: <sip:1007@DOMAIN.fr>

 Max-Forwards: 69

 Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY

 User-Agent: TANDBERG/529 (ce8.2.1.e9daf06) Cisco-DX80

 Expires: 180

 Date: Thu, 15 Jun 2017 14:53:48 GMT

 Supported: timer,resource-priority,replaces

 Min-SE: 1800

 Allow-Events: presence

 Send-Info: conference,x-cisco-conference

 Session-ID: 9d4a73c9000f4e85ab13dd94025aa669;remote=00000000000000000000000000000000

 Alert-Info: <file://Bellcore-dr1/>

 Content-Length: 0

 

 |

 

2017-06-15T16:53:48.031+02:00 EXPRESSWAYC tvcs: Event="Search Attempted" Service="SIP" Src-alias-type="SIP" Src-alias="sallevisiolima@DOMAIN.fr" Dst-alias-type="SIP" Dst-alias="sip:a0a852a7-3519-b7fb-1981-ee80bbb12498@IP_DEVICE:40337;transport\=tls" Call-serial-number="708c927d-15e1-4da7-ad0d-97bdc82b20fe" Tag="64694ec5-fab6-4959-b00d-8fffce925e79" Detail="searchtype:INVITE" Level="1" UTCTime="2017-06-15 14:53:48,031"

2017-06-15T16:53:48.031+02:00 EXPRESSWAYC tvcs: Event="Call Attempted" Service="SIP" Src-ip="IP_CUCM" Src-port="5060" Src-alias-type="SIP" Src-alias="sip:sallevisiolima@DOMAIN.fr" Dst-alias-type="SIP" Dst-alias="sip:a0a852a7-3519-b7fb-1981-ee80bbb12498@IP_DEVICE:40337;transport\=tls" Call-serial-number="708c927d-15e1-4da7-ad0d-97bdc82b20fe" Tag="64694ec5-fab6-4959-b00d-8fffce925e79" Protocol="TCP" Auth="NO" Level="1" UTCTime="2017-06-15 14:53:48,031"

2017-06-15T16:53:48.032+02:00 EXPRESSWAYC tvcs: UTCTime="2017-06-15 14:53:48,032" Module="network.sip" Level="INFO":  Action="Sent" Local-ip="IP_EXPC" Local-port="5060" Dst-ip="IP_CUCM" Dst-port="49178" Detail="Sending Response Code=100, Method=INVITE, CSeq=101, To=sip:1007@DOMAIN.fr, Call-ID=6eabab80-94219f7c-8c-bc0a1eac@IP_CUCM, From-Tag=670~7120b90b-18e4-4799-b62f-613d4dcd8d57-17451617, To-Tag=, Msg-Hash=6708362400513117659"

2017-06-15T16:53:48.032+02:00 EXPRESSWAYC tvcs: UTCTime="2017-06-15 14:53:48,032" Module="network.sip" Level="DEBUG":  Action="Sent" Local-ip="IP_EXPC" Local-port="5060" Dst-ip="IP_CUCM" Dst-port="49178" Msg-Hash="6708362400513117659"

 SIPMSG:

 |SIP/2.0 100 Trying

 Via: SIP/2.0/TCP IP_CUCM:5060;branch=z9hG4bK8b43485f9d;received=IP_CUCM;ingress-zone=UnifiedCMNeighborZoneB2B

 Call-ID: 6eabab80-94219f7c-8c-bc0a1eac@IP_CUCM

 CSeq: 101 INVITE

 From: "LI1 - Informatique" <sip:sallevisiolima@DOMAIN.fr>;tag=670~7120b90b-18e4-4799-b62f-613d4dcd8d57-17451617

 To: <sip:1007@DOMAIN.fr>

 Server: TANDBERG/4134 (X8.9.2)

 Content-Length: 0

 

 |

 

2017-06-15T16:53:48.033+02:00 EXPRESSWAYC tvcs: Event="Search Completed" Reason="Not Found" Service="SIP" Src-alias-type="SIP" Src-alias="sallevisiolima@DOMAIN.fr" Dst-alias-type="SIP" Dst-alias="sip:a0a852a7-3519-b7fb-1981-ee80bbb12498@IP_DEVICE:40337;transport\=tls" Call-serial-number="708c927d-15e1-4da7-ad0d-97bdc82b20fe" Tag="64694ec5-fab6-4959-b00d-8fffce925e79" Detail="found:false, searchtype:INVITE, Info:Policy Response" Level="1" UTCTime="2017-06-15 14:53:48,033"

2017-06-15T16:53:48.033+02:00 EXPRESSWAYC tvcs: Event="Call Rejected" Service="SIP" Src-ip="IP_CUCM" Src-port="5060" Src-alias-type="SIP" Src-alias="sip:sallevisiolima@DOMAIN.fr" Dst-alias-type="SIP" Dst-alias="sip:a0a852a7-3519-b7fb-1981-ee80bbb12498@IP_DEVICE:40337;transport\=tls" Call-serial-number="708c927d-15e1-4da7-ad0d-97bdc82b20fe" Tag="64694ec5-fab6-4959-b00d-8fffce925e79" Detail="Not Found" Protocol="TCP" Response-code="404" Level="1" UTCTime="2017-06-15 14:53:48,033"

2017-06-15T16:53:48.033+02:00 EXPRESSWAYC tvcs: UTCTime="2017-06-15 14:53:48,033" Module="network.sip" Level="INFO":  Action="Sent" Local-ip="IP_EXPC" Local-port="5060" Dst-ip="IP_CUCM" Dst-port="49178" Detail="Sending Response Code=404, Method=INVITE, CSeq=101, To=sip:1007@DOMAIN.fr, Call-ID=6eabab80-94219f7c-8c-bc0a1eac@IP_CUCM, From-Tag=670~7120b90b-18e4-4799-b62f-613d4dcd8d57-17451617, To-Tag=14f99e1e347ed8cb, Msg-Hash=1033216847583256819"

2017-06-15T16:53:48.033+02:00 EXPRESSWAYC tvcs: UTCTime="2017-06-15 14:53:48,033" Module="network.sip" Level="DEBUG":  Action="Sent" Local-ip="IP_EXPC" Local-port="5060" Dst-ip="IP_CUCM" Dst-port="49178" Msg-Hash="1033216847583256819"

 SIPMSG:

 |SIP/2.0 404 Not Found

 Via: SIP/2.0/TCP IP_CUCM:5060;branch=z9hG4bK8b43485f9d;received=IP_CUCM;ingress-zone=UnifiedCMNeighborZoneB2B

 Call-ID: 6eabab80-94219f7c-8c-bc0a1eac@IP_CUCM

 CSeq: 101 INVITE

 From: "LI1 - Informatique" <sip:sallevisiolima@DOMAIN.fr>;tag=670~7120b90b-18e4-4799-b62f-613d4dcd8d57-17451617

 To: <sip:1007@DOMAIN.fr>;tag=14f99e1e347ed8cb

 Server: TANDBERG/4134 (X8.9.2)

 Warning: 399 IP_EXPC:5060 "Policy Response"

 Content-Length: 0

 

 |

 

2017-06-15T16:53:48.034+02:00 EXPRESSWAYC tvcs: UTCTime="2017-06-15 14:53:48,034" Module="network.sip" Level="INFO":  Action="Received" Local-ip="IP_EXPC" Local-port="5060" Src-ip="IP_CUCM" Src-port="49178" Detail="Receive Request Method=ACK, CSeq=101, Request-URI=sip:a0a852a7-3519-b7fb-1981-ee80bbb12498@IP_EXPC:5060;transport=tcp;orig-hostport=IP_DEVICE:40337, Call-ID=6eabab80-94219f7c-8c-bc0a1eac@IP_CUCM, From-Tag=670~7120b90b-18e4-4799-b62f-613d4dcd8d57-17451617, To-Tag=14f99e1e347ed8cb, Msg-Hash=3165085070373505674"

2017-06-15T16:53:48.034+02:00 EXPRESSWAYC tvcs: UTCTime="2017-06-15 14:53:48,034" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="IP_EXPC" Local-port="5060" Src-ip="IP_CUCM" Src-port="49178" Msg-Hash="3165085070373505674"

 SIPMSG:

 |ACK sip:a0a852a7-3519-b7fb-1981-ee80bbb12498@IP_EXPC:5060;transport=tcp;orig-hostport=IP_DEVICE:40337 SIP/2.0

 Via: SIP/2.0/TCP IP_CUCM:5060;branch=z9hG4bK8b43485f9d

 Call-ID: 6eabab80-94219f7c-8c-bc0a1eac@IP_CUCM

 CSeq: 101 ACK

 From: "LI1 - Informatique" <sip:sallevisiolima@DOMAIN.fr>;tag=670~7120b90b-18e4-4799-b62f-613d4dcd8d57-17451617

 To: <sip:1007@DOMAIN.fr>;tag=14f99e1e347ed8cb

 Max-Forwards: 70

 User-Agent: TANDBERG/529 (ce8.2.1.e9daf06) Cisco-DX80

 Date: Thu, 15 Jun 2017 14:53:48 GMT

 Allow-Events: presence

 Content-Length: 0

 

 |

Highlighted

Can you post the screenshot for CUCM NZ and MRA CUCM zone generated by default on Exp-c ? 

Also what port you have configured under the SIP trunk on CUCM pointing towards Exp- C ??

Regards,

Alok

Highlighted

The B2B_Zone to the CUCM : 

And the generate MRA Zone to the CUCM :

CUCM TRK SIP B2B / 5560 ====== 5060 / ExpC

Highlighted

Hi All, 

Any update ?

Best regards

Matthieu

Highlighted

Hi Matthieu,

Happy to do a webex to verify issue tomorrow, if you want ? From the Invite message it looks ok, but seems some additional config on the server might be causing it.

Regards,

Alok

Highlighted

I find the bug id !!!! 

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvc98425

===============================================

MRA calls incorrectly classified when pass-through recieved user-agent and server header is set
CSCvc98425
Description
Symptom:
Inbound Calls to MRA Registered Endpoints fail with a 404 Not Found on VCS

Outbound Calls from the Unit to other Endpoints work.

Conditions:
Failure Conditions : if any of these are NOT met the call will work.

1. 8.8.x or later

2. Neighbor Zone created and active before adding CUCM to Unified Communication Servers.

3. SIP Profile on the Endpoint with User-Agent and Server header information set to: Pass through received information as User-Agent and Server Header

Workaround:
1. Modify SIP Profile on the Endpoint

User-Agent and Server header information to: Send Unified CM Version Information as User-Agent Header

Or

2. Remove Neighbor Zone and re-add Neighbor Zone
==================================
i apply the workaround 1 and it's works ! :)
Thanks all for your help
Highlighted

I don't think it is a bug.

Please try to check the following:

  1. The zone that is configured on the Expressway-C for your B2B to the CUCM, is configured with this port: 5560, and not 5060.
  2. Your traversal zones should be using different ports. For example I'm using port 7001 for my UC Traversal zone (MRA) and 7003 for my Traversal Client type zone (for the B2B), and of course on the Expressway-E itself your traversal zones should match the appropriate ports that are on the EXPR-C.
  3. Make sure that you configure Search Rules for each traversal zone and that the target is the correct target zone. If you configured search rule for B2B, so the target will in the search rule will be the B2B zone.
  4. I found out on my very own flesh, that it is very important to configure the right priorities in the search rules. So my recommendation, from my configurations, is:
    1. Search rule for UC Traversal search: configure priority as 100.
    2. Search rule for B2B Traversal search: configure priority as 102.
  5. BTW, did you configure the CUCM listening port 5560 for the Expressway-C SIP trunk under the  System -> Security -> SIP Trunk Security Profile? And did you allocated this security sip trunk profile in the SIP trunk configurations?
Highlighted

Hi Slavik,

All your points is ok on my system,

As you can see,

The search rules,

And Zones,

I repeat myself but,

  • I delete the B2B CUCM-NZ on EXPC > Calls to MRA wevice work
  • I recreate the B2B CUCM-NZ on EXPC > Calls to MRA device work 
  • I restart the EXPC > Calls to MRA device NOT work

Thanks for your help ! :)

Highlighted

Oh, now I paid more attention to what you wrote in the end. Yeah that sounds very strange, that when you restart the EXPR-C it stops working. I can only guess that maybe when you delete the zone, and make a call it opens the correct session and it stays, so even after you re-configure it, the session is open and it's working fine. But after you restart the EXPR-C, when session opens something goes wrong, but that's just a lucky guess.

I will look more on the configurations later, and I'll also look on mine.

But just a question out of curiosity. Why do you implement 2 different zones, one for the B2B and one for CMR? In my setups I always implement one zone, called B2B, and it serves me for CMR dialing also. Because it is the same.

So in my opinion, you can remove it. Unless you did something over there in purpose.

Content for Community-Ad