Jul 12

Session Timer Too Small – ITSP

Receiving a Session Timer too small from the ITSP (SIP/2.0 422 Session Timer too small)?

INVITE FROM ITSP

SENT TRYING

SENT INVITE TO CUCM

RECEIVED TRYING

RECEIVED SESSION TIMER TOO SMALL

CALL FAILED

CUCM has a min session timer of 1800. By default the CUBE will accept any negotiated size for the session timer. Hence we need to ensure the session timer is negotiated correctly with the ITSP before handing onto CUCM.

 *** Required Changes on the CUBE ***

Router(config)# voice service voip

Router(conf-voi-serv)# sip

Router(conf-serv-sip)# min-se time

 *** After the above change ***

INVITE FROM ITSP

SENT TRYING to ITSP

SENT SESSION TIMER TOO SMALL to ITSP

RECEIVED INVITE (with session timer of 1800) from ITSP

SENT TRYING to ITSP

SENT INVITE TO CUCM

RECEIVED TRYING FROM CUCM

RECEIVED CALL IN PROGRESS (Ringing) from CUCM.

Call succeeded.

Nov 14

MoH Silent – SIP CUBE to ITSP without MTP – OPTION 2

More MoH talk with ITSP and CUBE’s. I mentioned in earlier posts that playing MoH without an MTP can be achieved by creating sip-profiles to manipulate some of the SDP attributes. I recently have another MoH issues where the MoH stream was simply dead air or silent. Of course enabling the MTP on the SIP Trunk in CUCM resolved the issue.. however we want to avoid forcing an MTP for all calls.

I resolved this by removing the cmd “pass-thru content sdp” under the Voice Service Voip -> SIP config menu. In this case the sip-profile route was not working for me.. The above cmd negates the Gateway in the negotiation process, hence passing through codec and mtp negotiations. The potential problem here is the mismatch between CUCM and ITSP, we want the gateway to participate and effectively inter-work between CUCM and the ITSP.

If you have other options or methods that work to combat silence in MoH using an ITSP, please post.

Nov 20

Sip Calls being Rejected – CUBE

When calling through to any of the DID number range for a customer, it was found that only a small percentage of calls were successful. The failed calls would either play an ISP announcement or just ring continuously until the timer expired.

This customer had a newly provisioned SIP Trunk to the ITSP and all was working well until this point. No changes had been made by the Internal IT. After tracing successful and failed inbound call attempts it was found the ITSP was sending additional information in the SIP SDP. The information being sent was the QoS SDP Parameters, the local CUBE was not equipped to handle/negotiate these parameters therefore the call negotiation process would fail.

Resolution was to provide the below information to the ITSP to strip the QoS SDP Parameters.

INVITE Captured during trace.

Received:
INVITE sip:2XXXXXXXX@X.X.X.X:5060 SIP/2.0
Via: SIP/2.0/UDP 203.52.1.167:5060;branch=z9hG4bKhs0g8n00eogroamlbun0.1
From: <sip:2XXXXXXXX@X.X.X.X;user=phone>;tag=866784654-1439255743666-
To: “Name”<sip:2XXXXXXXX@domain.com.au;user=phone>
Call-ID: BW111543666110815-468528800@10.83.154.184
CSeq: 220849754 INVITE
Contact: <sip:2XXXXXXXX@203.52.1.167:5060;transport=udp>
Supported: 100rel
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Accept: application/media_control+xml,application/sdp,multipart/mixed
Max-Forwards: 29
Content-Type: application/sdp
Content-Length: 641

v=0
o=BroadWorks 3668715 1 IN IP4 X.X.X.X
s=-
c=IN IP4 X.X.X.X
t=0 0
a=sendrecv
a=media-release:hngl5rp9pujvivh05pvu6ibgr83pv898756s7s8auvmg62o6u724a2ur96v3nd0v1350ln1-6
a=media-release-con-addr:d6v1k1hv6hvh1002o9j0
m=audio 18064 RTP/AVP 8 0 18 96 97
c=IN IP4 X.X.X.X
b=RR:3000
b=RS:1000
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos optional remote sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:96 AMR/8000
a=fmtp:96 mode-set=7;max-red=0
a=rtpmap:97 telephone-event/8000
a=fmtp:97 0-15
a=maxptime:40