CUBE-sip-CUCM debug ccsip misunderstanding

[Vladislav Atanasov]

CUBE at ip:10.251.223.18

CUCM at ip: 10.231.184.38

A SIP trunk between them.

CUCM has received an INVITE from CUBE for phone number 511 and responds with 404 Not Found.

The QUESTION is: Why do we see the address of CUBE in VIA header?

This message is actually sent from CUCM, so its address has to be there.

Is that bug or is that implemented so by design? What is the reason for that?

Note that this is the call leg to CUCM, not the opposite call leg to SP, where CUBE is going to re-originate this message.

Here is what debug ccsip messages on CUBE shows:

Received:

SIP/2.0 404 Not Found

Via: SIP/2.0/UDP 10.251.223.18:5060;branch=z9hG4bK911316

From: <sip:00882208327@10.251.223.18>;tag=41235840-151A

To: <sip:511@10.231.184.38>;tag=4738709~23f88673-e727-4bb5-8d43-4b6fc7db659a-35724426

Date: Tue, 11 Dec 2012 17:01:48 GMT

Call-ID:

491A5B19-42EB11E2-8156F11F-C6A5C5D4@10.251.223.18

CSeq: 101 INVITE

Allow-Events: presence

Reason: Q.850;cause=1

Content-Length: 0 Received:
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 10.251.223.18:5060;branch=z9hG4bK911316
From: <sip:00882208327@10.251.223.18>;tag=41235840-151A
To: <sip:511@10.231.184.38>;tag=4738709~23f88673-e727-4bb5-8d43-4b6fc7db659a-35724426
Date: Tue, 11 Dec 2012 17:01:48 GMT
Call-ID: 491A5B19-42EB11E2-8156F11F-C6A5C5D4@10.251.223.18
CSeq: 101 INVITE
Allow-Events: presence
Reason: Q.850;cause=1
Content-Length: 0

[Ayodeji Okanlawon]

Hi Vladislav,

The via header is a stamp of the device that the invite/response originates from. So if CUCM is the the one that sent the repsonse then it should have uts ip in it.

Can you send the full debugs please

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[Jonathan Schulenberg]

RFC3261 explains the header:

The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent.

Usually a 404 from CUCM is a CSS problem. Is 511 reachable from the trunk's CSS?

Please remember to rate helpful responses and identify helpful or correct answers.

[Vladislav Atanasov]

Jonathan,

The problem is clear - it is CSS, intentionally omitted.

But, the question is why do I see a CUBE ip in VIA instead of CUCM ip?

If I understand correctly rfc3261, it has to be CUCM ip there, or I am wrong?

Thanks,

   Vladislav

[Jonathan Schulenberg · Accepted solution]

No. The via header(s) will be a reverse path of SIP proxies that want to remain in the call path. CUBE originated the message so it sets the via header to itself to ensure that responses are sent to it instead of whatever's in the From header. Without the via header the call would work more like an H323 gatekeeper: once the initial LRQ sequence has located the appropriate destination the call setup would continue directly between the two H323 entities.

Please remember to rate helpful responses and identify helpful or correct answers.

[Vladislav Atanasov]

Well, I still do not understand fully.

It is on a call leg towards the CUCM.

I would be agree with you if it was on a call leg towards the SP. In that case CUBE-to-SP it has to be CUBE's ip in the VIA for the reasons you already mentioned.

But, on the call leg towards the CUCM, I think it has to be CUCM's ip in order some additional messages or responses to be returned correctly.

What do you think, what do I miss?

[Jonathan Schulenberg]

No, it is working correctly. Not sure how else to say it.

[Ayodeji Okanlawon · Accepted solution]

The required Via header field is used to record the SIP route taken by a request and is used to route a response back to the originator. A UA generating a request records its own address in a Via header field. While the ordering of most SIP

header fi elds is not signifi cant, the Via header fi elds order is signifi cant because it is used to route responses. A proxy forwarding the request adds a Via header fi eld containing its own address to the top of the list of Via header fi elds.

Lets look at an example

CUCM: 192.105.40.14

CUBE:192.105.40.74

Invite coming from CUCM to CUBE

Received:

INVITE sip:345XXXX@192.105.10.74:5060 SIP/2.0

Via: SIP/2.0/UDP 192.105.10.14:5060;branch=z9hG4bK9edf17b6f990

From: <01YYY>;tag=335650~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-602531061

To: <34507931642506>

035297: Dec 12 17:48:21.834: //3210392/1D2026000001/SIP/Msg/ccsipDisplayMsg:

CUBE sends a trying to CUCM (NB that the via header does not change even though CUBE is sending the trying...The via header remains the same as the original invite)

035297: Dec 12 17:48:21.834: //3210392/1D2026000001/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.105.10.14:5060;branch=z9hG4bK9edf17b6f990
From: <01XXX>;tag=335650~ffa80926-5fac-4dd6-b405-2dbbc56ae9a2-602531061
To: <345YYYY>

CUBE sends Invite to ITSP

Sent:
INVITE sip:YYYYY@10.106.33.24:5070 SIP/2.0
Via: SIP/2.0/UDP 192.105.10.74:5060;branch=z9hG4bK87CC301EE
Remote-Party-ID: <441925405130>;party=calling;screen=no;privacy=off
From: <44XXXXX>;tag=19E9FCAA-1E0E

Trying received from ITSP (note that the VIa header remains the same as the original invite sent to the ITSP)

035299: Dec 12 17:48:21.848: //3210393/1D2026000001/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.105.10.74:5060;branch=z9hG4bK87CC301EE

So in summary, the VIA header does not change with response, it is set at the original request.

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson