Re: why CUBE is not transparently sending in incoming ringing(18

friskopart · ‎07-31-2012

why CUBE is not transparently sending in incoming ringing(180) with SDP to an outgoing ringing(180) with SDP?

Regards

paolo bevilacqua · ‎07-31-2012

Include traces and config to prove your point.

friskopart · ‎07-31-2012

below is an output of debug ccsip messages that proves it

Received:

INVITE sip:2188723@10.3.3.3:5060 SIP/2.0

Via: SIP/2.0/UDP 10.11.1.2:5060;branch=z9hG4bK1D7B3

Remote-Party-ID: <7777>;party=calling;screen=no;privacy=off

From: <7777>;tag=37DDA4-12B4

To: <2188723>

Date: Fri, 01 Mar 2002 01:01:01 GMT

Call-ID: A1DD5368-2BE611D6-80639ED3-CD2E991A@10.11.1.2

Supported: 100rel,timer,resource-priority,replaces

Min-SE: 1800

Cisco-Guid: 2672116199-736498134-2153684691-3442383130

User-Agent: Cisco-SIPGateway/IOS-12.x

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

CSeq: 101 INVITE

Max-Forwards: 70

Timestamp: 1014944461

Contact: <7777>

Expires: 180

Allow-Events: telephone-event

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 206

v=0

o=CiscoSystemsSIP-GW-UserAgent 3874 1391 IN IP4 10.11

AAA-FW(config.1.2

s=SIP Call

c=IN IP4 10.11.1.2

t=0 0

m=audio 16520 RTP/AVP 8 19

c=IN IP4 10.11.1.2

a=rtpmap:8 PCMA/8000

a=rtpmap:19 CN/8000

a=ptime:20

2w1d: //78482/9F4541E7805E/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 10.11.1.2:5060;branch=z9hG4bK1D7B3

From: <7777>;tag=37DDA4-12B4

To: <2188723>

Date: Tue, 31 Jul 2012 11:04:42 GMT

Call-ID: A1DD5368-2BE611D6-80639ED3-CD2E991A@10.11.1.2

Timestamp: 1014944461

CSeq: 101 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

2w1d: //78483/9F4541E7805E/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE tel:2188723 SIP/2.0

Via: SIP/2.0/UDP 10.100.1.23:5060;branch=z9hG4bK169EB1FF5

From: <10.100.1.23>;tag=4DE66988-AE8

To: <08723>

Date: Tue, 31 Jul 2012 11:04:42 GMT

Call-ID: 5D425A6B-DA3611E1-84B4F1AA-49412B66@10.100.1.23

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Min-SE: 1800

Cisco-Guid: 2672116199-0736498134-2153684691-3442383130

User-Agent: Cisco-SIPGateway/IOS-12.x

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

CSeq: 101 INVITE

Timestamp: 1343732682

Contact: <10.100.1.23:5060>

Expires: 180

Allow-Events: telephone-event

Max-Forwards: 69

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 194

v=0

o=CiscoSystemsSIP-GW-UserAgent 4138 4325 IN IP4 10.100.1.23

s=SIP Call

c=IN IP4 10.100.1.23

t=0 0

m=audio 19334 RTP/AVP 8

c=IN IP4 10.100.1.23

a=rtpmap:8 PCMA/8000

a=ptime:20

2w1d: //78483/9F4541E7805E/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 10.100.1.23:5060;branch=z9hG4bK169EB1FF5

Call-ID: 5D425A6B-DA3611E1-84B4F1AA-49412B66@10.100.1.23

From: <10.100.1.23>;tag=4DE66988-AE8

To: <08723>

CSeq: 101 INVITE

Content-Length: 0

)#

AAA-FW(config)#

2w1d: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

hello

2w1d: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

hello

2w1d: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

hello

2w1d: //78483/9F4541E7805E/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 10.100.1.23:5060;branch=z9hG4bK169EB1FF5

Call-ID: 5D425A6B-DA3611E1-84B4F1AA-49412B66@10.100.1.23

From: <10.100.1.23>;tag=4DE66988-AE8

To: <08723>;tag=kvzn899v-CC-1004

CSeq: 101 INVITE

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

Require: 100rel

Contact: <10.100.10.34:5060>

P-Early-Media: sendonly

P-Charging-Vector: icid-value=mgcf--20120731130056-100425316;term-ioi=mgcf.home.net

RSeq: 1

Content-Length: 155

Content-Type: application/sdp

Content-Disposition: session

v=0

o=ug 1073776664 1073776665 IN IP4 10.100.10.34

s=SipCall

c=IN IP4 10.100.11.1

AAA-FW(config29

t=0 0

m=audio 29244 RTP/AVP 8

a=ptime:20

a=sendrecv

2w1d: //78483/9F4541E7805E/SIP/Msg/ccsipDisplayMsg:

Sent:

PRACK sip:10.100.10.34:5060;transport=udp SIP/2.0

Via: SIP/2.0/UDP 10.100.1.23:5060;branch=z9hG4bK169EC147C

From: <10.100.1.23>;tag=4DE66988-AE8

To: <08723>;tag=kvzn899v-CC-1004

Date: Tue, 31 Jul 2012 11:04:42 GMT

Call-ID: 5D425A6B-DA3611E1-84B4F1AA-49412B66@10.100.1.23

CSeq: 102 PRACK

RAck: 1 101 INVITE

Allow-Events: telephone-event

Max-Forwards: 70

Content-Length: 0

2w1d: //78482/9F4541E7805E/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP 10.11.1.2:5060;branch=z9hG4bK1D7B3

From: <7777>;tag=37DDA4-12B4

To: <2188723>;tag=4DE67B14-2047

Date: Tue, 31 Jul 2012 11:04:42 GMT

Call-ID: A1DD5368-2BE611D6-80639ED3-CD2E991A@10.11.1.2

Timestamp: 1014944461

CSeq: 101 INVITE

Require: 100rel

RSeq: 8487

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

Allow-Events: telephone-event

Remote-Party-ID: <2188723>;party=called;screen=no;privacy=off

Contact: <2188723>

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 188

v=0

o=CiscoSystemsSIP-GW-UserAgent 6707 5274 IN IP4 10.3.3.3

s=SIP Call

c=IN IP4 10.3.3.3

t=0 0

m=audio 17260 RTP/AVP 8

c=IN IP4 10.3.3.3

a=rtpmap:8 PCMA/8000

a=ptime:20

2w1d: //78483/9F4541E7805E/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.100.1.23:5060;branch=z9hG4bK169EC147C

Call-ID: 5D425A6B-DA3611E1-84B4F1AA-49412B66@10.100.1.23

From: <10.100.1.23>;tag=4DE66988-AE8

To: <08723>;tag=kvzn899v-CC-1004

CSeq: 102 PRACK

Content-Length: 0

2w1d: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

PRACK sip:2188723@10.3.3.3:5060 SIP/2.0

Via: SIP/2.0/UDP 10.11.1.2:5060;branch=z9hG4bK1E2E0

From: <7777>;tag=37DDA4-12B4

To: <2188723>;tag=4DE67B14-2047

Date: Fri, 01 Mar 2002 01:01:01 GMT

Call-ID: A1DD5368-2BE611D6-80639ED3-CD2E991A@10.11.1.2

CSeq: 102 PRACK

RAck: 8487 101 INVITE

Max-Forwards: 70

Content-Length: 0

2w1d: //78482/9F4541E7805E/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.11.1.2:5060;branch=z9hG4bK1E2E0

From: <7777>;tag=37DDA4-12B4

To: <2188723>;tag=4DE67B14-2047

Date: Tue, 31 Jul 2012 11:04:47 GMT

Call-ID: A1DD5368-2BE611D6-80639ED3-CD2E991A@10.11.1.2

Server: Cisco-SIPGateway/IOS-12.x

CSeq: 102 PRACK

Content-Length: 0

)#

AAA-FW(config)#

2w1d: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

hello

2w1d: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

paolo bevilacqua · ‎07-31-2012

Both received and sent INVITE appears to have an SDP:

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 206

v=0

o=CiscoSystemsSIP-GW-UserAgent 3874 1391 IN IP4 10.11

AAA-FW(config.1.2

s=SIP Call

c=IN IP4 10.11.1.2

t=0 0

m=audio 16520 RTP/AVP 8 19

c=IN IP4 10.11.1.2

a=rtpmap:8 PCMA/8000

a=rtpmap:19 CN/8000

a=ptime:20

and

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 194

v=0

o=CiscoSystemsSIP-GW-UserAgent 4138 4325 IN IP4 10.100.1.23

s=SIP Call

c=IN IP4 10.100.1.23

t=0 0

m=audio 19334 RTP/AVP 8

c=IN IP4 10.100.1.23

a=rtpmap:8 PCMA/8000

a=ptime:20

paolo bevilacqua · ‎07-31-2012

Incoming '180 ringing' goes outgoing as '183 session progress', both have SDP, in bold below:

Received:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 10.100.1.23:5060;branch=z9hG4bK169EB1FF5

Call-ID: 5D425A6B-DA3611E1-84B4F1AA-49412B66@10.100.1.23

From: <10.100.1.23>;tag=4DE66988-AE8

To: <08723>;tag=kvzn899v-CC-1004

CSeq: 101 INVITE

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

Require: 100rel

Contact: <10.100.10.34:5060>

P-Early-Media: sendonly

P-Charging-Vector: icid-value=mgcf--20120731130056-100425316;term-ioi=mgcf.home.net

RSeq: 1

Content-Length: 155

Content-Type: application/sdp

Content-Disposition: session

v=0

o=ug 1073776664 1073776665 IN IP4 10.100.10.34

s=SipCall

c=IN IP4 10.100.11.1

AAA-FW(config29

t=0 0

m=audio 29244 RTP/AVP 8

a=ptime:20

a=sendrecv

2w1d: //78483/9F4541E7805E/SIP/Msg/ccsipDisplayMsg:

Sent:

PRACK sip:10.100.10.34:5060;transport=udp SIP/2.0

Via: SIP/2.0/UDP 10.100.1.23:5060;branch=z9hG4bK169EC147C

From: <10.100.1.23>;tag=4DE66988-AE8

To: <08723>;tag=kvzn899v-CC-1004

Date: Tue, 31 Jul 2012 11:04:42 GMT

Call-ID: 5D425A6B-DA3611E1-84B4F1AA-49412B66@10.100.1.23

CSeq: 102 PRACK

RAck: 1 101 INVITE

Allow-Events: telephone-event

Max-Forwards: 70

Content-Length: 0

2w1d: //78482/9F4541E7805E/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP 10.11.1.2:5060;branch=z9hG4bK1D7B3

From: <7777>;tag=37DDA4-12B4

To: <2188723>;tag=4DE67B14-2047

Date: Tue, 31 Jul 2012 11:04:42 GMT

Call-ID: A1DD5368-2BE611D6-80639ED3-CD2E991A@10.11.1.2

Timestamp: 1014944461

CSeq: 101 INVITE

Require: 100rel

RSeq: 8487

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

Allow-Events: telephone-event

Remote-Party-ID: <2188723>;party=called;screen=no;privacy=off

Contact: <2188723>

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 188

v=0

o=CiscoSystemsSIP-GW-UserAgent 6707 5274 IN IP4 10.3.3.3

s=SIP Call

c=IN IP4 10.3.3.3

t=0 0

m=audio 17260 RTP/AVP 8

c=IN IP4 10.3.3.3

a=rtpmap:8 PCMA/8000

a=ptime:20

friskopart · ‎07-31-2012

yes clearly both have SDP, but the question was why CUBE does not allow for sip 180 message transparency instead of converting it to 183 ? as IETF SIP standards do not mandate this behavior

paolo bevilacqua · ‎07-31-2012

I don't dare to give an answer myself, begin SIP and the Cisco implementation, the confusing mess that it is.

However, with SDP present, both messages are pretty much equivalent.

friskopart · ‎07-31-2012

not exactly the absence of 180 message can cause problems in some situations, so i hope some one can answer this question

paolo bevilacqua · ‎07-31-2012

I agree they are not the same thing, on the other hand I think that converting 180 to 183 will not prevent CUBE from forwarding the ringback media (if present at all) or the SIP provider from receiving it, that I suspect is the reason why you're asking this.

Ayodeji Okanlawon · ‎08-01-2012

Frisko,

You have been on this for a while. I guess this is the second post you have submitted on this issue. Why dont you open a TAC case wtih Cisco and hopefully they can answer your question. Personally I have not seen CUBE sending 180 with SDP. I know that CUCM does not send 180 with SDP it only sends 183 with SDP. Maybe this is the case with CUBE. Open a TAC case and hopefully you can share your findings.

Please rate all useful posts

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

Please rate all useful posts