cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
11317
Views
91
Helpful
1
Comments
Ayodeji Okanlawon
VIP Alumni
VIP Alumni

For most cisco UC guys, the concept of sip we are used to is a little restricted to the functionality that cisco cucm, cube etc use.

In most scenarios, these devices acts as B2BUA and as such we do not see the sip proxy functionality of the sip architecture.

Well all that has changed with the introduction of Expressway servers for MRA. Expressway- E and C fully utilize the sip proxy functionality even in ways the traditional VCS-E and C do not

As such I felt its a good idea to understand the sip messaging that enable proxies like the expressways function.

In this short write up we will be looking at sip traces from jabber and the expressway servers to fully understand how sip messaging flows from one end to the other.

 

Before we go ahead, there are three important sip headers that I need to explain. I previously wrote a documentation on understanding sip traces.

Please refer to this here (https://supportforums.cisco.com/document/113271/understanding-sip-traces)to get a solid understanding of sip messaging.

Moving on, we need to understand three key headers that are used by sip proxies for sip messages.

  • ROUTE: header

  • Record-Route: header

  • VIA header

 

ROUTE: header

The destination of a sip request is normally taken from its request-URI (RURI), but to force traffic to use a certain path, a client/server can insert a route header. UAs may include a Route header field in an initial request to force that request to visit and potentially be serviced by one or more proxies

once a route header is present, the RURI should be disregarded and the request should be sent directly to the URI contained in the route header.

 

Record-Route: header

The record route header records the path for later use with the route header.  A proxy forwarding a request uses this header to demand to stay in the signaling path of the dialog. It contains the URI where the proxy wishes the requests be addressed.

The UAS must if it receives a dialog creating request (e.g. INVITE) copy any available Record-Route headers into all the responses it creates to ensure that the UAC also becomes informed of the so called “Route set”. The term Route set refers to the entire list of proxies that have added themselves ti the record route header.

 

 

Now let’s look at a jabber sample trace for MRA call..

 

2014-09-04 17:50:08,049 DEBUG [0x00000fb8] [oftphonewrapper\CC_SIPCCService.cpp(342)] [csf.ecc.sipcc] [_SIPCCLoggerFunction] - sipio-sent---> INVITE sip:5001@uclabcucm-pub;user=phone SIP/2.0
Via: SIP/2.0/TLS 10.106.4.73:53567;branch=z9hG4bK000013fc
From: "5002" <sip:5002@uclabcucm-pub>;tag=0050568b4cc4000f000051c2-0000142d
To: <sip:5001@uclabcucm-pub>
Call-ID: 0050568b-4cc4000e-000032dd-00001c81@10.106.4.73
Max-Forwards: 70
Date: Thu, 04 Sep 2014 16:50:08 GMT
CSeq: 101 INVITE
User-Agent: Cisco-CSF
Contact: <sip:96446082-3aa2-435b-9c73-671751df5635@10.106.4.73:53567;transport=tls>;video;bfcp
Expires: 180
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: "5002" <sip:5002@uclabcucm-pub>;party=calling;id-type=subscriber;privacy=off;screen=yes
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-
cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1
Allow-Events: kpml,dialog
Recv-Info: conference
Recv-Info: x-cisco-conference
Route: <sip:uclabexpwe02.uclab.com;transport=tls;lr>,<sip:10.106.4.80:5061;transport=tls
;zone-id=1;directed;lr>,<sip:uclabcucm-pub;transport=tcp;lr>
Proxy-Authorization: Digest username="mac.donald",realm="uclabexpwe02.uclab.com",uri="sip:5001@uclabcucm-pub;user=phone",response="45decd9e69225d5e559f21795f5536de",nonce="bb4f529367d63377d96523
bccb6f2e2c68289c736cc2475ce1eed7997085",
opaque="AQAAANogJPAxhatFayqXEKX3rGJKBhJu",cnonce="00001576",qop=auth,nc=00000006,algorithm=MD5
Content-Length: 1719
Content-Type: application/sdp
Content-Disposition: session;handling=optional
v=0
o=Cisco-SIPUA 2594 0 IN IP4 10.106.4.73

 

In this trace, here is our request-URI. Note that request URI is extracted from a request as follow:

  • METHOD URI sip/2.0s

 

So from our trace, the request is as follows:

INVITE sip:5001@uclabcucm-pub;user=phone SIP/2.0

 

Method=INVITE and URI= sip:5001@uclabcucm-pub

 

In a traditional cisco deployment, the request would have been sent to the uclabcucm-pub, however because there is a ROUTE header present,

this RURI is ignored and the request is sent instead to:

 

Route: <sip:uclabexpwe02.uclab.com;transport=tls;lr>,<sip:10.106.4.80:5061;transport=tls;zone-id=1;directed;lr>,<sip:uclabcucm-pub;transport=tcp;lr>

 

As we can see this is sent directly to the expressway-e server or we can say that the call is proxied through the expressway-e server.

It is important to note that when a proxy generates a request, it must strip its own Route header from the outgoing request. As you can imagine this could lead to call loop and failures if this is not done.  So here is the outbound INVITE sent by expressway-e after receiving the INVITE from jabber.

Note that it has stripped of its route header and replaced it with a new route header:

 

2014-09-04T10:46:55+00:00 uclabexpwe01 tvcs: UTCTime="2014-09-04 10:46:55,042" Module="network.sip" Level="DEBUG":  Action="Sent"  Local-ip="10.106.4.81"  Local-port="7002"  Dst-ip="10.106.4.85"  Dst-port="25000"  Msg-Hash="5908947394448701934"
 SIPMSG:
 |INVITE sip:5001@uclabcucm-sub;user=phone SIP/2.0
 Via: SIP/2.0/TLS 10.106.4.81:7002;egress-zone=TZone;branch=z9hG4bKbec1447aa98f9b167a3f8376725920872800.e2bd2ac9275d3ae23f9294064e32e111;proxy-call-id=a07ee132-ce04-47b9-afa4-b67b51c58b34;rport
 Via: SIP/2.0/TLS 10.106.4.73:52912;branch=z9hG4bK0000451b;received=10.106.4.73;ingress-zone=CollaborationEdgeZone
 Call-ID: 0050568b-4cc40004-00006fca-000037f1@10.106.4.73
 CSeq: 101 INVITE
 Remote-Party-ID: "5002" <sip:5002@uclabcucm-sub>;party=calling;id-type=subscriber;privacy=off;screen=yes
 Contact: <sip:96446082-3aa2-435b-9c73-671751df5635@10.106.4.73:52912;transport=tls>;video;bfcp
From: "5002" <sip:5002@uclabcucm-sub>;tag=0050568b4cc40006000074e2-000063a2
 To: <sip:5001@uclabcucm-sub>
 Max-Forwards: 15
 Route: <sip:uclabcucm-sub;transport=tcp;lr>
 Record-Route: <sip:proxy-call-id=a07ee132-ce04-47b9-afa4-b67b51c58b34@10.106.4.81:7002;transport=tls;lr;zone-id=1>
 Record-Route: <sip:proxy-call-id=a07ee132-ce04-47b9-afa4-b67b51c58b34@10.106.4.81:5061;transport=tls;lr>

 

Now let’s move on to what happens on expressway-C.

Here expressway-C receives the INVITE from expressway-E

NB: Observe that the route header and record route headers are both the same as seen in the INVITE sent by expressway-E

 

2014-09-04T10:46:55+00:00 uclabexpwc02 tvcs: UTCTime="2014-09-04 10:46:55,040" Module="network.sip" Level="DEBUG":  Action="Received"  Local-ip="10.106.4.85"  Local-port="25000"  Src-ip="10.106.4.81"  Src-port="7002"  Msg-Hash="5908947394448701934"
SIPMSG:
 |INVITE sip:5001@uclabcucm-sub;user=phone SIP/2.0
 Via: SIP/2.0/TLS 10.106.4.81:7002;egress-zone=TZone;branch=z9hG4bKbec1447aa98f9b167a3f8376725920872800.e2bd2ac9275d3ae23f9294064e32e111;proxy-call-id=a07ee132-ce04-47b9-afa4-b67b51c58b34;rport
 Via: SIP/2.0/TLS 10.106.4.73:52912;branch=z9hG4bK0000451b;received=10.106.4.73;ingress-zone=CollaborationEdgeZone
 Call-ID: 0050568b-4cc40004-00006fca-000037f1@10.106.4.73
 CSeq: 101 INVITE
 Remote-Party-ID: "5002" <sip:5002@uclabcucm-sub>;party=calling;id-type=subscriber;privacy=off;screen=invite
 Contact: <sip:96446082-3aa2-435b-9c73-671751df5635@10.106.4.73:52912;transport=tls>;video;bfcp
 From: "5002" <sip:5002@uclabcucm-sub>;tag=0050568b4cc40006000074e2-000063a2
 To: <sip:5001@uclabcucm-sub>
 Max-Forwards: 15
 Route: <sip:uclabcucm-sub;transport=tcp;lr>
 Record-Route: <sip:proxy-call-id=a07ee132-ce04-47b9-afa4-b67b51c58b34@10.106.4.81:7002;transport=tls;lr;zone-id=1>
 Record-Route: <sip:proxy-call-id=a07ee132-ce04-47b9-afa4-b67b51c58b34@10.106.4.81:5061;transport=tls;lr>
Once expressway-C receives this request it does a zone search to see if there is any rule that matches the request. This request is destined for Route: <sip:uclabcucm-sub;transport=tcp;lr>
 
2014-09-04T10:46:55+00:00 uclabexpwc02 tvcs: UTCTime="2014-09-04 10:46:55,045" Module="network.search" Level="DEBUG":   Detail="Search rule 'LocalZoneMatch' ignored due to system generated search rule filtering"
2014-09-04T10:46:55+00:00 uclabexpwc02 tvcs: UTCTime="2014-09-04 10:46:55,045" Module="network.search" Level="DEBUG":   Detail="Search rule 'CEtcp-uclabcucm-pub' did not match destination alias 'uclabcucm-sub;transport=tcp;lr'"
2014-09-04T10:46:55+00:00 uclabexpwc02 tvcs: UTCTime="2014-09-04 10:46:55,045" Module="network.search" Level="DEBUG":   Detail="Considering search rule 'CEtcp-uclabcucm-sub' towards target 'CEtcp-uclabcucm-sub' at priority '45' with alias 'uclabcucm-sub;transport=tcp;lr'"

 

Now that a search rule has been matched and observer that this search rule is the auto generated rule after expressway completes the UC servers discovery.

Now things get a little more interesting. Expressway-C sends several INVITEs out based on its route headers.

Here is the first INVITE sent.

2014-09-04T10:46:55+00:00 uclabexpwc02 tvcs: UTCTime="2014-09-04 10:46:55,055" Module="network.sip" Level="DEBUG":  Action="Sent"  Local-ip="10.106.4.85"  Local-port="25157"  Dst-ip="10.106.4.85"  Dst-port="5071"  Msg-Hash="12322756966698911465"
 SIPMSG:
 |INVITE sip:5001@uclabcucm-sub;user=phone;box-call-serial-number=71663b53-4240-42d9-8102-0b142aeb6fad SIP/2.0
 Via: SIP/2.0/TLS 10.106.4.85:5061;egress-zone=DefaultZone;branch=z9hG4bKe02249bb94ef34840ef58a674cc8036f47911.b6053c28fbf666f9512b9a4bc75c11e5;proxy-call-id=51d64dee-4e7d-4dde-acb8-181be27afe36;rport
 Via: SIP/2.0/TLS 10.106.4.81:7002;egress-zone=TZone;branch=z9hG4bKbec1447aa98f9b167a3f8376725920872800.e2bd2ac9275d3ae23f9294064e32e111;proxy-call-id=a07ee132-ce04-47b9-afa4-b67b51c58b34;received=10.106.4.81;rport=7002;ingress-zone=UCTraversalZone
 Via: SIP/2.0/TLS 10.106.4.73:52912;branch=z9hG4bK0000451b;received=10.106.4.73;ingress-zone=CollaborationEdgeZone
 Call-ID: 0050568b-4cc40004-00006fca-000037f1@10.106.4.73
 CSeq: 101 INVITE
 Remote-Party-ID: "5002" <sip:5002@uclabcucm-sub>;party=calling;id-type=subscriber;privacy=off;screen=yes
 Contact: <sip:96446082-3aa2-435b-9c73-671751df5635@10.106.4.73:52912;transport=tls>;video;bfcp
 From: "5002" <sip:5002@uclabcucm-sub>;tag=0050568b4cc40006000074e2-000063a2
 To: <sip:5001@uclabcucm-sub>
 Max-Forwards: 14
 Route: <sip:10.106.4.85:5071;transport=tls;ingress-encryption-mode=on;egress-encryption-mode=auto;ingress-traversal-mode=assent_client;egress-traversal-mode=undefined;ingress-ice-mode=off;egress-ice-mode=off;ingress-peer-mode=Edge;egress-peer-mode=Edge;ingress-refer-mode=forward;egress-refer-mode=forward;egress-zone=2;copy-routes;lr>
 Route: <sip:10.106.4.85:5061;transport=tls;lr>
 Route: <sip:CEtcpuclabcucmsub;zone-id=2;protocol=sip;contact-id=%3Csip%3A96446082-3aa2-435b-9c73-671751df5635%4010.106.4.73%3A52912%3Btransport%3Dtls%3E%3Bvideo%3Bbfcp;orig-ingress-zone=4;lr>
 Route: <sip:10.106.4.84:5060;transport=tcp;ds;lr>
 Route: <sip:uclabcucm-sub;transport=tcp;lr>
 Record-Route: <sip:proxy-call-id=51d64dee-4e7d-4dde-acb8-181be27afe36@10.106.4.85:5061;transport=tls;lr>
 Record-Route: <sip:proxy-call-id=51d64dee-4e7d-4dde-acb8-181be27afe36@10.106.4.85:5061;transport=tls;lr>
 Record-Route: <sip:proxy-call-id=a07ee132-ce04-47b9-afa4-b67b51c58b34@10.106.4.81:7002;transport=tls;lr;zone-id=1>

 

From this trace Expway-C has added four additional route headers to its outbound requests.

  • The first is sent to its internal port 5071, this is the port used for B2BUA calls.

  • The second route header is used to send the call to sip port 5061 on itself.

  • The next route header routes the call out via the CEtcpuclabcucm zone

  • The next one is used to route the call to CUCM using tcp on port 5060

It is important to note that as the request is sent to each destination in the route header, the route header is removed. This is very important. So here is the INVITE as expressway-C sends them out.

INVITE sent to port 5061 on itself. Observe that the route header has reduced to four and more importantly the first route header which was already processes has been removed.

 
2014-09-04T10:46:55+00:00 uclabexpwc02 b2bua[7473]: UTCTime="2014-09-04 10:46:55,078" Module="network.sip" Level="DEBUG":  Action="Sent"  Local-ip="10.106.4.85"  Local-port="32670"  Dst-ip="10.106.4.85"  Dst-port="5061"  Msg-Hash="6368636122619067762"
 SIPMSG:
 |INVITE sip:5001@uclabcucm-sub;user=phone;box-call-serial-number=71663b53-4240-42d9-8102-0b142aeb6fad SIP/2.0
 Via: SIP/2.0/TLS 10.106.4.85:5073;branch=z9hG4bK3e3659dea48b700b546d216391215bdf305;x-cisco-local-service=nettle;rport
 Via: SIP/2.0/TLS 10.106.4.85:5061;egress-zone=DefaultZone;branch=z9hG4bKe02249bb94ef34840ef58a674cc8036f47911.b6053c28fbf666f9512b9a4bc75c11e5;proxy-call-id=51d64dee-4e7d-4dde-acb8-181be27afe36;received=10.106.4.85;rport=25157
 Via: SIP/2.0/TLS 10.106.4.81:7002;egress-zone=TZone;branch=z9hG4bKbec1447aa98f9b167a3f8376725920872800.e2bd2ac9275d3ae23f9294064e32e111;proxy-call-id=a07ee132-ce04-47b9-afa4-b67b51c58b34;received=10.106.4.81;rport=7002;ingress-zone=UCTraversalZone
 Via: SIP/2.0/TLS 10.106.4.73:52912;branch=z9hG4bK0000451b;received=10.106.4.73;ingress-zone=CollaborationEdgeZone
 Call-ID: 0050568b-4cc40004-00006fca-000037f1@10.106.4.73
 CSeq: 101 INVITE
 Remote-Party-ID: "5002" <sip:5002@uclabcucm-sub>;id-type=subscriber;privacy=off;screen=no;party=calling
 Contact: <sip:10.106.4.85:5073;transport=tls>;video;bfcp
 From: "5002" <sip:5002@uclabcucm-sub>;tag=0050568b4cc40006000074e2-000063a2
 To: <sip:5001@uclabcucm-sub>
 Max-Forwards: 13
 Route: <sip:10.106.4.85:5061;transport=tls;lr>
 Route: <sip:CEtcpuclabcucmsub;zone-id=2;protocol=sip;contact-id=%3Csip%3A96446082-3aa2-435b-9c73-671751df5635%4010.106.4.73%3A52912%3Btransport%3Dtls%3E%3Bvideo%3Bbfcp;orig-ingress-zone=4;lr>
 Route: <sip:10.106.4.84:5060;transport=tcp;ds;lr>
Final INVITE sent to CUCM. Observe that the route header has reduced to just one (the current route been processed) and the Record-Route headers were included to indicate inform cucm to send responses back to expwc.

 

2014-09-04T10:46:55+00:00 uclabexpwc02 tvcs: UTCTime="2014-09-04 10:46:55,088" Module="network.sip" Level="DEBUG":  Action="Sent"  Local-ip="10.106.4.85"  Local-port="25160"  Dst-ip="10.106.4.84"  Dst-port="5060"  Msg-Hash="3951558401431138988"
 SIPMSG:
 |INVITE sip:5001@uclabcucm-sub;user=phone SIP/2.0
 Via: SIP/2.0/TCP 10.106.4.85:5060;egress-zone=CEtcpuclabcucmsub;branch=z9hG4bKb301ef8d22c5c3da6bb208ffad62159047912;proxy-call-id=bda25a8f-1768-4d52-a582-c98435240815;rport
 Via: SIP/2.0/TLS 10.106.4.85:5073;branch=z9hG4bK3e3659dea48b700b546d216391215bdf305;x-cisco-local-service=nettle;received=10.106.4.85;rport=32670;ingress-zone=DefaultZone
 Via: SIP/2.0/TLS 10.106.4.85:5061;egress-zone=DefaultZone;branch=z9hG4bKe02249bb94ef34840ef58a674cc8036f47911.b6053c28fbf666f9512b9a4bc75c11e5;proxy-call-id=51d64dee-4e7d-4dde-acb8-181be27afe36;received=10.106.4.85;rport=25157
 Via: SIP/2.0/TLS 10.106.4.81:7002;egress-zone=TZone;branch=z9hG4bKbec1447aa98f9b167a3f8376725920872800.e2bd2ac9275d3ae23f9294064e32e111;proxy-call-id=a07ee132-ce04-47b9-afa4-b67b51c58b34;received=10.106.4.81;rport=7002;ingress-zone=UCTraversalZone
 Via: SIP/2.0/TLS 10.106.4.73:52912;branch=z9hG4bK0000451b;received=10.106.4.73;ingress-zone=CollaborationEdgeZone
 Call-ID: 0050568b-4cc40004-00006fca-000037f1@10.106.4.73
 CSeq: 101 INVITE
 Remote-Party-ID: "5002" <sip:5002@uclabcucm-sub>;id-type=subscriber;privacy=off;screen=no;party=calling
 Contact: <sip:96446082-3aa2-435b-9c73-671751df5635@10.106.4.85:5060;transport=tcp;orig-hostport=10.106.4.73:52912>;video;bfcp
 From: "5002" <sip:5002@uclabcucm-sub>;tag=0050568b4cc40006000074e2-000063a2
 To: <sip:5001@uclabcucm-sub>
 Max-Forwards: 12
 Route: <sip:uclabcucm-sub;transport=tcp;lr>
 Record-Route: <sip:proxy-call-id=bda25a8f-1768-4d52-a582-c98435240815@10.106.4.85:5060;transport=tcp;lr>
 Record-Route: <sip:proxy-call-id=bda25a8f-1768-4d52-a582-c98435240815@10.106.4.85:5061;transport=tls;lr>

 

The next header I want us to look at is the VIA header.

 

VIA header: (also called the "sent-by" field)

Responses always follow the VIA header, except for non-INVITE methods such as (ACK and BYE) where the responses are sent to the contact header.

UA/proxy uses the VIA header to indicate where they want to receive the response to their requests. There are a few rules that is important to know with VIA header especially with proxies.

 

1. Each UA/proxy adds the via header to indicate where it wants to receive a response

2.All responses are routed backwards, along the VIA header path, stripping as it goes through.

3. Receiving proxy checks that the top VIA header is its own, otherwise it drops the response

 

Lets look at the following examples...

Here is an INVITE from jabber to expressway-e. We can see that the VIA header shows the ip address of jabber client..This is where the response to this request should be sent to.

 

2014-09-04T10:46:55+00:00 uclabexpwe01 tvcs: UTCTime="2014-09-04 10:46:55,032" Module="network.sip" Level="DEBUG":  Action="Received"  Local-ip="10.106.4.81"  Local-port="5061"  Src-ip="10.106.4.73"  Src-port="52912"  Msg-Hash="228276377448874545"
 SIPMSG:
 |INVITE sip:5001@uclabcucm-sub;user=phone SIP/2.0
 Via: SIP/2.0/TLS 10.106.4.73:52912;branch=z9hG4bK0000451b
 Call-ID: 0050568b-4cc40004-00006fca-000037f1@10.106.4.73
 CSeq: 101 INVITE
 Remote-Party-ID: "5002" <sip:5002@uclabcucm-sub>;party=calling;id-type=subscriber;privacy=off;screen=yes
 Contact: <sip:96446082-3aa2-435b-9c73-671751df5635@10.106.4.73:52912;transport=tls>;video;bfcp

 

 Next we see expressway-sends this request to expressway-C. Observer that the VIA header has increased and the top most via header is now the one of the expressway-e.

 ( You will see the VIA header from jabber because when a UA/proxy receives a request it copies the mandatory headers and then use them as part of its own new request)

 

 2014-09-04T10:46:55+00:00 uclabexpwe01 tvcs: UTCTime="2014-09-04 10:46:55,042" Module="network.sip" Level="DEBUG":  Action="Sent"  Local-ip="10.106.4.81"  Local-port="7002"  Dst-ip="10.106.4.85"  Dst-port="25000"  Msg-Hash="5908947394448701934"
 SIPMSG:
 |INVITE sip:5001@uclabcucm-sub;user=phone SIP/2.0
 Via: SIP/2.0/TLS 10.106.4.81:7002;egress-zone=TZone;branch=z9hG4bKbec1447aa98f9b167a3f8376725920872800.e2bd2ac9275d3ae23f9294064e32e111;proxy-call-id=a07ee132-ce04-47b9-afa4-b67b51c58b34;rport
 Via: SIP/2.0/TLS 10.106.4.73:52912;branch=z9hG4bK0000451b;received=10.106.4.73;ingress-zone=CollaborationEdgeZone
 Call-ID: 0050568b-4cc40004-00006fca-000037f1@10.106.4.73
 CSeq: 101 INVITE
 Remote-Party-ID: "5002" <sip:5002@uclabcucm-sub>;party=calling;id-type=subscriber;privacy=off;screen=yes
 Contact: <sip:96446082-3aa2-435b-9c73-671751df5635@10.106.4.73:52912;transport=tls>;video;bfcp

 

 When the response is created by the destination (UA/proxy), it starts with a copy of all the mandatory headers which includes the via header and then sends the response to the top-most value.

 This next trace shows the expressway-C sending this request to itself and to cucm. Observer that the top-most value now has changed to the ip of expressway-c

 
 2014-09-04T10:46:55+00:00 uclabexpwc02 tvcs: UTCTime="2014-09-04 10:46:55,055" Module="network.sip" Level="DEBUG":  Action="Sent"  Local-ip="10.106.4.85"  Local-port="25157"  Dst-ip="10.106.4.85"  Dst-port="5071"  Msg-Hash="12322756966698911465"
 SIPMSG:
 |INVITE sip:5001@uclabcucm-sub;user=phone;box-call-serial-number=71663b53-4240-42d9-8102-0b142aeb6fad SIP/2.0
 Via: SIP/2.0/TLS 10.106.4.85:5061;egress-zone=DefaultZone;branch=z9hG4bKe02249bb94ef34840ef58a674cc8036f47911.b6053c28fbf666f9512b9a4bc75c11e5;proxy-call-id=51d64dee-4e7d-4dde-acb8-181be27afe36;rport
 Via: SIP/2.0/TLS 10.106.4.81:7002;egress-zone=TZone;branch=z9hG4bKbec1447aa98f9b167a3f8376725920872800.e2bd2ac9275d3ae23f9294064e32e111;proxy-call-id=a07ee132-ce04-47b9-afa4-b67b51c58b34;received=10.106.4.81;rport=7002;ingress-zone=UCTraversalZone
 Via: SIP/2.0/TLS 10.106.4.73:52912;branch=z9hG4bK0000451b;received=10.106.4.73;ingress-zone=CollaborationEdgeZone
 Call-ID: 0050568b-4cc400

 

 

I hope this helps you understand the sip messaging for the proxy functionality of the expressway servers.

1 Comment
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: