[Spce-user] Call sometimes fails due to extra direction and oldmediip to Cisco CME

Gordon Sims gsims94 at gmail.com
Mon Jul 21 05:34:29 EDT 2014 

Hello,

I¹m wanting to test SPCE as a trunk provider for a couple of customers, but
first having duplicated their setups within my own lab environment, I¹m
running into some issues with the Cisco CME setup.  A trunk connected
directly to an asterisks box works fine, where as the Cisco box gets hung up
occasionally.  Its not consistent by any means, but duplicatable.  After
working with Cisco TAC thinking its a problem on their side, they came back
and reported that the SipWise box is sending extra direction and media in
the SIP INVITE.

Callflow is as follow:

(192.168.xxx.xxx) ‹ 10.0.119.252 or .253 ‹ 10.0.119.61 or .62 ‹ 10.0.119.71
‹ 66.xxx.xxx.172 ‹ 98.xxx.xxx.167
(My Direct Trunk Provider)‹Cisco CUBE‹OpenSIPS‹SPCE‹{Internet}‹(Customers
CME)

I do have other PBX systems that I test and a couple that I host for small
businesses that hang off of the OpenSIPS server directly and have no issues.
I¹ve also connected a CME system directly to the OpenSIPS and there is no
issue there.  So that solidified the issue to be with the SPCE and not with
the CME.  I have 2 different INVITEs from the SPCE gathered from the CME.
One good and the other bad.

Good Trace from CME
INVITE sip:13092226201 at 98.xxx.xxx.167:5060;transport=udp SIP/2.0

Max-Forwards: 10

Record-Route: 
<sip:66.xxx.xxx.172;r2=on;lr=on;ftag=41BAA7BD-53C3D38E00004700-70827700;ngcp
lb=yes>

Record-Route: 
<sip:127.0.0.1;r2=on;lr=on;ftag=41BAA7BD-53C3D38E00004700-70827700;ngcplb=ye
s>

Via: SIP/2.0/UDP 
66.xxx.xxx.172;branch=z9hG4bK668c.b5f1d01667d2a825cc179d600611a946.0

Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK7jlpaaKL;rport=5080

From: <sip:6305559512 at 10.0.119.252>;tag=41BAA7BD-53C3D38E00004700-70827700

To: <sip:13092226201 at 98.xxx.xxx.167>

CSeq: 10 INVITE

Call-ID: 6C07BBD0-A9711E4-85F58C48-DDEE702F at 10.0.119.252_b2b-1

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

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

Call-Info: 
<sip:66.94.208.163:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"

Expires: 180

P-Asserted-Identity: <sip:6305559512 at 10.0.119.252>

Content-Type: application/sdp

Content-Length: 395

Contact: 
<sip:ngcp-lb at 66.xxx.xxx.172:5060;ngcpct=7369703a3132372e302e302e313a35303830
>



v=0

o=CiscoSystemsSIP-GW-UserAgent 1671 9253 IN IP4 66.xxx.xxx.172

s=SIP Call

c=IN IP4 66.xxx.xxx.172

t=0 0

m=audio 30060 RTP/AVP 0 101 121

c=IN IP4 66.xxx.xxx.172

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=rtpmap:121 frf-dialed-digit/8000

a=fmtp:121 0-15

a=ptime:20

a=direction:active

a=oldmediaip:10.0.119.252

a=oldmediaip:10.0.119.252

a=rtcp:30061



Bad Trace from CME

INVITE sip:13092226201 at 98.xxx.xxx.167:5060;transport=udp SIP/2.0

Max-Forwards: 10

Record-Route: 
<sip:66.xxx.xxx.172;r2=on;lr=on;ftag=6FEE39DC-53C3D3590005E815-70625700;ngcp
lb=yes>

Record-Route: 
<sip:127.0.0.1;r2=on;lr=on;ftag=6FEE39DC-53C3D3590005E815-70625700;ngcplb=ye
s>

Via: SIP/2.0/UDP 
66.xxx.xxx.172;branch=z9hG4bKa8ad.e68544d4504db6d49e9e36daa719994f.0

Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bKMyUUpaxm;rport=5080

From: <sip:6305559512 at 10.0.119.252>;tag=6FEE39DC-53C3D3590005E815-70625700

To: <sip:13092226201 at 98.xxx.xxx.167>

CSeq: 10 INVITE

Call-ID: 4C9DBCD3-A9711E4-85E48C48-DDEE702F at 10.0.119.252_b2b-1_b2b-1

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

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

Call-Info: 
<sip:66.94.208.163:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"

Expires: 180

P-Asserted-Identity: <sip:6305559512 at 10.0.119.252>

Content-Type: application/sdp

Content-Length: 467

Contact: 
<sip:ngcp-lb at 66.xxx.xxx.172:5060;ngcpct=7369703a3132372e302e302e313a35303830
>



v=0

o=CiscoSystemsSIP-GW-UserAgent 1855 1310 IN IP4 66.xxx.xxx.172

s=SIP Call

c=IN IP4 66.xxx.xxx.172

t=0 0

m=audio 30044 RTP/AVP 0 101 121

c=IN IP4 66.xxx.xxx.172

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=rtpmap:121 frf-dialed-digit/8000

a=fmtp:121 0-15

a=ptime:20

a=direction:active

a=oldmediaip:10.0.119.252

a=oldmediaip:10.0.119.252

a=direction:active

a=oldmediaip:10.0.119.71

a=oldmediaip:10.0.119.71

a=rtcp:30045



Now I did come across another article here that was a similar issue to Sonus
SBC's tittled with Remove SDP media-level attribute ­ direction

 

Seemed like it might have fit the bill so I did try their suggestion with
modifying the /etc/ngcp-config/templates/etc/kamailio/proxy/proxy.cfg.tt2
file and adding in the following:

if(has_body("application/sdp"))

        {

                # fix SDP direction attribute for Cisco CME

                xlog("L_INFO", "Removing direction attribute from
SDP-base-nat - [% logreq -%]\n²);

                replace_body_all("a=direction:active\r?\n", "");

        }



To the following section:



########################################################################

# Reply route 'base-nat-reply'

########################################################################

onreply_route[REPLY_ROUTE_NAT]

{

        [% debug_dump('start', 'REPLY_ROUTE_NAT') %]

        xlog("L_NOTICE", "NAT-Reply - [% logres_init -%]\n");

        force_rport();



        if(has_body("application/sdp") && ($avp(s:from_faxserver) == 1 ||
$avp(s:to_faxserver) == 1))

        {

                # fix for T.38 to patton faxserver gateway, which chokes on
upper-case

                xlog("L_INFO", "Rewriting T.38 'UDPTL' to 'udptl' - [%
logres -%]\n");

                replace_body_all(" UDPTL ", " udptl ");

        }



**        if(has_body("application/sdp"))

**        {

**                # fix SDP direction attribute for Cisco CME

**                xlog("L_INFO", "Removing direction attribute from
SDP-base-nat - [% logreq -%]\n");

**                replace_body_all("a=direction:active\r?\n", "");

**        }



        if(status=~"18[0-3]|2[0-9][0-9]" && ($rm == "INVITE" || $rm ==
"UPDATE"))

        {





They also mentioned another section which I did not have as it looked like
it was a custom file that they were modifying.  I¹m hoping to modify the
existing files there.  After I was done with the modify, I did a Œngcpcfg
apply¹ and then did a reboot for safe measures and still get the call to
fail (Not every time).



Worst part about this is that its sporadic, some calls go thru, as I may
have 4 of them go right thru, then next call fails.  It might fail a couple
of times and then start going thru.  Would be nice to see it be one way or
the other to help determine the issue.



If someone has some ideas, please let me know as I really would like to use
this product more.  I see a lot of potential in it.



Thanks,



Gordon




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/mailman/private/spce-user_lists.sipwise.com/attachments/20140721/8cf7bac1/attachment.html>

More information about the Spce-user mailing list