Solved: Re: SIP ringing out issue - Page 2

kevinhobson2000 · ‎05-14-2013

Hi All,

I have an issue with a sip call.

Basically the phone rings but times out when calling in externally.

The topology is:

ITSP ------ CUBE ----- CUCM

All call legs are SIP.

I have done a debug ccsip messages and it would appear that after the CUBE acknowledges the OK from the CUCM the CUBE isnt then passing the SDP information on to the ITSP.

So as a result it just rings out.

Thanks for the help.

Cheers

Kev

kevinhobson2000 · ‎05-15-2013

Disabled rel1xx on dial-peer 1.

Makes sense as this is the dial-peer with the incoming called number on it.

Must stop the re1xx being sent from the cube when it hits this dial-peer.

Im going to debug it to confirm.

Cheers

kevinhobson2000 · ‎05-15-2013

Ok its connecting now at both ends but im getting one way voice called can hear caller but not the other way around.

Call then drops after about 20 seconds.

Debug attached.

Cheers

Ayodeji Okanlawon · ‎05-15-2013

We are not getting an ACK from your provider..It is possible that your sip messages are not even getting to them. Do you have sip bind commands configured..You may have configured it wrongly...Can you please send your sh run..

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

kevinhobson2000 · ‎05-15-2013

Ive attached the config.

The control and media are bound to gi0/1.300 under dial-peer 1.

Cheers

Ayodeji Okanlawon · ‎05-15-2013

OK..So you have set the bind commands on gig 0/1.200. The question is this..Can your provider connect to this IP: 192.168.60.254? I doubt this because I can see that they are sending you invite on a different interface..

INVITE sip:0218169019@192.168.244.250:5060;user=phone SIP/2.0

interface GigabitEthernet0/1.200

description VOIP LAN

encapsulation dot1Q 200

ip address 192.168.60.254 255.255.255.0

If they cant talk to you on that ip then you cant configure your dial-peers and sip bind commands like this..

You have two options:

1. Dont use any bind comands at all, and the CUBE will chose the closest interface to the destination to send sip signalling and media

2. configure seperate dial-peers for calls coming in and outgoing from your CUBE

You need to seperate your inbound dial-peer and apply your bind commands like this..

dial-peer voice 3 voip

description From ITSP

session protocol sipv2

incoming called-number 021816.... (DDI BLOCK here)

voice-class codec 1

voice-class sip bind control source-interface GigabitEthernetx/y --where gigx/y will be the interface facing your ITSP

voice-class sip bind media source-interface GigabitEthernetx/y

dtmf-relay rtp-nte

no vad

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

kevinhobson2000 · ‎05-15-2013

Hi,

I realised after my last post that the sip was bound to the wrong interface and so it was in a different VLAN.

I changed the bind to .300 and changed the ip on the trunk on UCM and bang its fixed.

Cheers

Ayodeji Okanlawon · ‎05-16-2013

Kevin,

Good to know its resolved. You can enable PRACK back, this can be useful in some cases. The problem wasnt PRACK after all

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

kevinhobson2000 · ‎05-16-2013

Aye mate,

I already have.

Thanks for the use of your eyes much appreciated.

Cheers

Kev

kevinhobson2000 · ‎05-28-2013

Hi,

There are now problems with supplemntary services. A debug seems to show the audio inactive messages being passed to the ITSP and the ITSP sending an ok. The CUBE then sends an ACK and the a BYE to end the call.

Debug below:

*May 28 15:22:22.687: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

INVITE sip:0824636267@192.168.244.250:5060 SIP/2.0

Via: SIP/2.0/UDP 10.128.16.21:5060;branch=z9hG4bK27bcd7da7872c

From: <0218169019>;tag=9a6faa78-a360-49d5-b7da-21602c33796a-44746543

To: <0824636267>;tag=1F99CD74-669

Date: Tue, 28 May 2013 15:24:03 GMT

Call-ID: 37657887-C6E111E2-85E0F85B-C341310C@192.168.244.250

Supported: timer,resource-priority,replaces

Min-SE: 1800

Cisco-Guid: 0929196991-3336638946-2245589083-3275829516

User-Agent: Cisco-CUCM8.0

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

CSeq: 101 INVITE

Max-Forwards: 70

Contact: <0218169019>

Expires: 180

Allow-Events: presence

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires: 1800;refresher=uac

P-Asserted-Identity: "Test JR" <9019>

Remote-Party-ID: "Test JR" <9019>;party=calling;screen=yes;privacy=off

Content-Type: application/sdp

Content-Length: 221

v=0

o=CiscoSystemsCCM-SIP 2000 2 IN IP4 10.128.16.21

s=SIP Call

c=IN IP4 0.0.0.0

t=0 0

m=audio 30060 RTP/AVP 18 101

a=rtpmap:18 G729/8000

a=ptime:20

a=inactive

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

*May 28 15:22:22.695: //495/37626BBF85D8/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 10.128.16.21:5060;branch=z9hG4bK27bcd7da7872c

From: <0218169019>;tag=9a6faa78-a360-49d5-b7da-21602c33796a-44746543

To: <0824636267>;tag=1F99CD74-669

Date: Tue, 28 May 2013 15:22:22 GMT

Call-ID: 37657887-C6E111E2-85E0F85B-C341310C@192.168.244.250

CSeq: 101 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-15.2.4.M2

Content-Length: 0

*May 28 15:22:22.695: //493/37626BBF85D8/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:0824636267@192.168.244.10:5060;user=phone;transport=udp SIP/2.0

Via: SIP/2.0/UDP 192.168.244.250:5060;branch=z9hG4bK2D02489

From: <0218169019>;tag=1F99CE18-20DF

To: <0824636267>;tag=isn3930u-CC-29

Date: Tue, 28 May 2013 15:22:22 GMT

Call-ID: rwswtmxrwmxsrqxtviiu03qtuvb1u0im@SoftX3000

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

Min-SE: 1800

Cisco-Guid: 0929196991-3336638946-2245589083-3275829516

User-Agent: Cisco-SIPGateway/IOS-15.2.4.M2

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

CSeq: 101 INVITE

Max-Forwards: 70

Timestamp: 1369754542

Contact: <0218169019>

Expires: 180

Allow-Events: telephone-event

Content-Type: application/sdp

Content-Length: 289

v=0

o=CiscoSystemsSIP-GW-UserAgent 3683 3901 IN IP4 192.168.244.250

s=SIP Call

c=IN IP4 192.168.244.250

t=0 0

m=audio 17364 RTP/AVP 18 97

c=IN IP4 192.168.244.250

a=inactive

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=yes

a=rtpmap:97 telephone-event/8000

a=fmtp:97 0-15

a=ptime:20

*May 28 15:22:22.755: //493/37626BBF85D8/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.244.250:5060;branch=z9hG4bK2D02489

From: <0218169019>;tag=1F99CE18-20DF

To: <0824636267>;tag=isn3930u-CC-29

Call-ID: rwswtmxrwmxsrqxtviiu03qtuvb1u0im@SoftX3000

CSeq: 101 INVITE

Timestamp: 1369754542

Contact: <0824636267>

Content-Length: 243

Content-Type: application/sdp

v=0

o=HuaweiSoftX3000 15910632 15910633 IN IP4 192.168.244.10

s=Sip Call

c=IN IP4 192.168.244.10

t=0 0

m=audio 20342 RTP/AVP 18 97

a=rtpmap:18 G729/8000

a=rtpmap:97 telephone-event/8000

a=fmtp:97 0-15

a=fmtp:18 annexb=no

a=inactive

*May 28 15:22:22.755: //493/37626BBF85D8/SIP/Msg/ccsipDisplayMsg:

Sent:

ACK sip:0824636267@192.168.244.10:5060;user=phone;transport=udp SIP/2.0

Via: SIP/2.0/UDP 192.168.244.250:5060;branch=z9hG4bK2D1FE

From: <0218169019>;tag=1F99CE18-20DF

To: <0824636267>;tag=isn3930u-CC-29

Date: Tue, 28 May 2013 15:22:22 GMT

Call-ID: rwswtmxrwmxsrqxtviiu03qtuvb1u0im@SoftX3000

Max-Forwards: 70

CSeq: 101 ACK

Allow-Events: telephone-event

Content-Length: 0

*May 28 15:22:22.759: //493/37626BBF85D8/SIP/Msg/ccsipDisplayMsg:

Sent:

BYE sip:0824636267@192.168.244.10:5060;user=phone;transport=udp SIP/2.0

Via: SIP/2.0/UDP 192.168.244.250:5060;branch=z9hG4bK2D2B11

From: <0218169019>;tag=1F99CE18-20DF

To: <0824636267>;tag=isn3930u-CC-29

Date: Tue, 28 May 2013 15:22:22 GMT

Call-ID: rwswtmxrwmxsrqxtviiu03qtuvb1u0im@SoftX3000

User-Agent: Cisco-SIPGateway/IOS-15.2.4.M2

Max-Forwards: 70

Timestamp: 1369754542

CSeq: 102 BYE

Reason: Q.850;cause=65

P-RTP-Stat: PS=123,OS=2460,PR=112,OR=2240,PL=0,JI=0,LA=0,DU=2

Content-Length: 0

*May 28 15:22:22.759: //495/37626BBF85D8/SIP/Msg/ccsipDisplayMsg:

Sent:

BYE sip:0218169019@10.128.16.21:5060 SIP/2.0

Via: SIP/2.0/UDP 192.168.244.250:5060;branch=z9hG4bK2D3792

From: <0824636267>;tag=1F99CD74-669

To: <0218169019>;tag=9a6faa78-a360-49d5-b7da-21602c33796a-44746543

Date: Tue, 28 May 2013 15:22:22 GMT

Call-ID: 37657887-C6E111E2-85E0F85B-C341310C@192.168.244.250

User-Agent: Cisco-SIPGateway/IOS-15.2.4.M2

Max-Forwards: 70

Timestamp: 1369754542

CSeq: 102 BYE

Reason: Q.850;cause=65

P-RTP-Stat: PS=112,OS=2240,PR=130,OR=2600,PL=0,JI=0,LA=0,DU=2

Content-Length: 0

*May 28 15:22:22.795: //493/37626BBF85D8/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.244.250:5060;branch=z9hG4bK2D2B11

From: <0218169019>;tag=1F99CE18-20DF

To: <0824636267>;tag=isn3930u-CC-29

Call-ID: rwswtmxrwmxsrqxtviiu03qtuvb1u0im@SoftX3000

Timestamp: 1369754542

CSeq: 102 BYE

Content-Length: 0

*May 28 15:22:22.919: //495/37626BBF85D8/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.244.250:5060;branch=z9hG4bK2D3792

From: <0824636267>;tag=1F99CD74-669

To: <0218169019>;tag=9a6faa78-a360-49d5-b7da-21602c33796a-44746543

Date: Tue, 28 May 2013 15:24:03 GMT

Call-ID: 37657887-C6E111E2-85E0F85B-C341310C@192.168.244.250

CSeq: 102 BYE

Content-Length: 0

Thanks

Kev

Ayodeji Okanlawon · ‎05-28-2013

Kevin,

This is how call hold/transfer works with CUBE/CUCM

1. CUCM sends invite (re-invite) with an inactive SDP (a=inactive) to indicate a break in media path

2. CUCM sends a Delayed offer to insert MOH or to resume Media stream

NB: CUCM expects a sendrecv offer with SDP to the DO. (NB:if cucm gets an inactive offer SDP in the 200 OK instead of providing a send-recv offer SDP, the media path remains in an inactive state and causes calls to dropcall will drop),CUCM sends an ACK with sendonly to the 200 OK

3.CUCM establishes newcall leg with the intended transfered destination..Once this call is connected

4.CUCM receives a new Transfer instruction from the transferring phone to connect the held party

5. Next CUCM sends a re-invite with an inactive SDP to indicate a break in media path to MOH (in attempt to complete transfer)

6.Next CUCM sends an inactive SDP to indicate a break in media path between transfering party & transfered party to remove Xferring party from call

7. Next CUCM sends a DO re-invite to connect the transfered party. The far end then sends 200 OK with the required SDP to connect the call

As you can see, when CUBE sent an INVITE with a=inactive, the respond was a 200 ok with a=inactive...Looka the step 2 from above..CUBE expected a send-recv. This is why the call is disconnected

CUCM sends a Delayed offer to insert MOH or to resume Media stream

NB: CUCM expects a sendrecv offer with SDP to the DO. (NB:if cucm gets an inactive offer SDP in the 200 OK instead of providing a send-recv offer SDP, the media path remains in an inactive state and causes calls to dropcall will drop),CUCM sends an ACK with sendonly to the 200 OK

The strange thing is that according to the RFC3264

rfc-3264 sec-6.1(Unicast Stream), It says the
following must requirement:

If a stream is offered as sendonly, the corresponding stream MUST be
marked as recvonly or inactive in the answer.

If a media stream is
listed as recvonly in the offer, the answer MUST be marked as
sendonly or inactive in the answer.

If an offered media
stream is listed as inactive, it MUST be marked as inactive in the
answer.

So your ITSP is doing the correct thing but Cisco implementation doesnt follow that.

If you were on CUCM8.5, then you can enable the parameter use MTP if needed but its not available in CUCM8.0.

Yor options

1. Use an MTP on CUCM sip trunk..Hence CUCM wont send an inactive SDP to the CUBE during transfer or hold. Be careful here is you have faxes etc..Doesnt work well..But you can try this for test and see if it works then that will confirm what I have described

2. We can try and configure a sip profile that will change any SDP with a=inacive to a=send-recv and see if that helps

Please rate all useful posts

kevinhobson2000 · ‎06-07-2013

Sorry for the late reply pal.

Been busy.

I configured the CUBE as a HW MTP and it sorted it.

Now no MOH even though the SIP trunk is assigned an MOH server.

Im thinking maybe its because of the g729br8 codec as i dont even see CUCM invoke MOH.