07-31-2012 12:03 PM - edited 03-16-2019 12:28 PM
why CUBE is not transparently sending in incoming ringing(180) with SDP to an outgoing ringing(180) with SDP?
Regards
07-31-2012 12:07 PM
Include traces and config to prove your point.
07-31-2012 12:27 PM
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=off7777>
From: <7777>;tag=37DDA4-12B47777>
To: <2188723>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>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-12B47777>
To: <2188723>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-AE810.100.1.23>
To: <08723>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>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-AE810.100.1.23>
To: <08723>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-AE810.100.1.23>
To: <08723>;tag=kvzn899v-CC-100408723>
CSeq: 101 INVITE
Allow: INVITE,ACK,BYE,CANCEL,UPDATE,INFO,PRACK,NOTIFY,REFER,SUBSCRIBE,OPTIONS,MESSAGE
Require: 100rel
Contact: <10.100.10.34:5060>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-AE810.100.1.23>
To: <08723>;tag=kvzn899v-CC-100408723>
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-12B47777>
To: <2188723>;tag=4DE67B14-20472188723>
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=off2188723>
Contact: <2188723>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-AE810.100.1.23>
To: <08723>;tag=kvzn899v-CC-100408723>
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-12B47777>
To: <2188723>;tag=4DE67B14-20472188723>
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-12B47777>
To: <2188723>;tag=4DE67B14-20472188723>
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:
07-31-2012 12:32 PM
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
07-31-2012 12:43 PM
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-AE810.100.1.23>
To: <08723>;tag=kvzn899v-CC-100408723>
CSeq: 101 INVITE
Allow: INVITE,ACK,BYE,CANCEL,UPDATE,INFO,PRACK,NOTIFY,REFER,SUBSCRIBE,OPTIONS,MESSAGE
Require: 100rel
Contact: <10.100.10.34:5060>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-AE810.100.1.23>
To: <08723>;tag=kvzn899v-CC-100408723>
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-12B47777>
To: <2188723>;tag=4DE67B14-20472188723>
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=off2188723>
Contact: <2188723>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
07-31-2012 03:17 PM
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
07-31-2012 03:45 PM
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.
07-31-2012 04:50 PM
not exactly the absence of 180 message can cause problems in some situations, so i hope some one can answer this question
07-31-2012 05:04 PM
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.
08-01-2012 12:47 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide