No ring back tone in TDM extensions when dialing to SIP Trunk

[edgarquadros]

Hello friends!
I'm having some problems in a customer with SIP Trunk between MX-ONE 6.3 SP1 HF4 (VMWare virtualized server + physical MGU v 2.5.4), and a GSM SIP GW used to calls to cell phones.
Per example, when I'm dialing from analog or digital extensions to my cell phone using this GW, I can't hear the ringback tone in the extension, but I can see my cell phone ringing.
But I have other SIP routes in the same customer, connected to other 3rd Party SIP PBX, and I can hear the ringback tone when I call them.
By the way, I'm using the same route parameters in this SIP routes (ROCAI, RODAI, RODDP, and sip_route).
I took a packet capture between MX-ONE and GW GSM SIP, and I can see that GW GSM SIP is sending the "180 Ringing" signal correctly.
In the same way, I took a packet capture between MX-ONE e 3rd Party SIP PBX, and I can see the same "180 Ringing" signal coming from 3rd Party SIP PBX.

Can you have any idea?

BR

 

[inlsp05]

check rocap and compare that...

http://telfonika.blogfa.com

 

[edgarquadros]

I've been checked it, but the 2 routes have the same parameters, as you can see bellow:

ROCAP:ROU=84&101;
ROUTE CATEGORY DATA
ROU CUST SEL TRM SERV NODG DIST DISL TRAF SIG BCAP
84 7110000000000010 4 3110000000 0 30 128 03151515 0111111000A0 000100
101 7110000000000010 4 3110000000 0 30 128 03151515 0111111000A0 000100

RODAP:ROU=84&101;
ROUTE DATA
ROU TYPE VARC VARI VARO FILTER
84 TL66 H'00000002 H'00000000 H'00000104 NO
101 TL66 H'00000002 H'00000000 H'00000104 NO

RODDP:ROU=401&68;
EXTERNAL DESTINATION ROUTE DATA
DEST DRN ROU CHO CUST ADC TRC SRT NUMACK PRE
401 101 1606000000000250006000000000 0 4
68 84 1606000000000250006000000000 0 3

Route 84 is to a GW GSM SIP and route 101 is to a Panasonic PBX. When I dial to Panasonic, I can hear ringback tone, but if I dial to GW GSM SIP, I can't hear ringback tone.

 

[snor]

How I can see, you have updated your system from HF3 to HF4.
Do you have a difference in the settings of sip_route ?
e.g. in "profile" or "service"
(sip_route -print -route xx -short)

are the RINGING really "same" ?
As I already told you, I have same problem with a SIP trunk to an IPC trading system (Unigy V2), where CONTACT-header was missed in the RINGING (sent from IPC).

best regards,
Norbert

 

[edgarquadros]

Dear snor, I updated HF3 to HF4 in hope to solve the problem, but without success. The 2 SIP routes have exactly the same parameters. Follow sip_route printout:
mxone_admin@mxone63:~> sip_route -print -route 84 -short
Route data for SIP destination

route : 84
protocol = udp
profile = Default
service = PUBLIC
uristring0 = sip:?@10.4.96.16
accept = REMOTE_IP
match = 10.4.96.16
register = NO_REG

mxone_admin@mxone63:~> sip_route -print -route 101 -short
Route data for SIP destination

route : 101
protocol = udp
profile = Default
service = PUBLIC
uristring0 = sip:?@10.4.140.29
accept = REMOTE_IP
match = 10.4.140.29
register = NO_REG

I did not find CONTACT-header in the RINGING packet in any calls. I attached here a zipfile with 2 pcap files, one from MX-ONE to PANASONIC (ringback ok) and another from MX-ONE to GW GSM (ringback not ok) for your information.
MX-ONE IP: 10.4.96.6
GW GSM IP: 10.4.96.16
PANASONIC IP: 10.4.140.29

BR,
Edgar Q.

 

[snor]

Hi Edgar,
the RINGING to GSM and PANASONIC are a little bit different.
PANASONIC sends a CONTACT header, GSM do not sned a CONTACT header.
That`s the reason, while you can hear ring-back to Panasonic and not to GSM.
In the past, MX-ONE didnot take care about this (before HF3)

GSM
Signal Nr. 5
...
Status-Line: SIP/2.0 180 Ringing
Message Header
Via: SIP/2.0/UDP 10.4.96.6:5060;branch=z9hG4bK-524287-1---82e0bb0cbb4ab026;rport=5060;received=10.4.96.6
From: "SETIC - SRT" <sip:2487@lim1.trt4.gov.br;user=phone>;tag=7c7ca443
To: <sip:995418859@10.4.96.16;user=phone;transport=UDP>;tag=1701830305
Call-ID: g9SnlCFzotCaS-LONxKuvQ..
CSeq: 1 INVITE
User-Agent: Digistar-XIP
Content-Length:

PANASONIC
Signal Nr. 3
...
Status-Line: SIP/2.0 180 Ringing
Message Header
Via: SIP/2.0/UDP 10.4.96.6:5060;branch=z9hG4bK-524287-1---0c3fec77d349d202;rport=5060
To: <sip:2398@10.4.140.29;user=phone>;tag=7863
From: "SETIC - SRT" <sip:2487@lim1.trt4.gov.br;user=phone>;tag=47f3f81f
Call-ID: vOwaXTEKUj3lgECoBv2F0g..
CSeq: 1 INVITE
Contact: sip:10.4.140.29@10.4.140.29:5060
Allow: INVITE,ACK,CANCEL,BYE,PRACK,OPTIONS,REGISTER,INFO,NOTIFY,UPDATE
User-Agent: Panasonic-MPR09-V5.0002/VSIPGW-V2.3002
Server: Panasonic-MPR09-V5.0002/VSIPGW-V2.3002
Content-Length: 0

I have reportet this behaviour in the past, and here is the answer I received:

When MX-ONE sends an INVITE to IPC, the 180 Ringing in retour does not have "Contact" header.

As per SIP RFC 3261 it is a MUST:

12.1.1 UAS behavior

When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE),
the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters,
and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values.
The UAS MUST add a Contact header field to the response. The Contact header field contains an address where the UAS would like to be contacted
for subsequent requests in the dialog (which includes the ACK for a 2xx response in the case of an INVITE).
Generally, the host portion of this URI is the IP address or FQDN of the host.
The URI provided in the Contact header field MUST be a SIP or SIPS URI.
If the request that initiated the dialog contained a...

best regards,
Norbert

 

[edgarquadros]

Dear Norbert,

Sorry about my inattention! I confess, my eyes cheated me and I didn't see the CONTACT field in the packet earlier.
Thank you so much for your diagnose!
Now, I will request to GSM SIP GW developer to apply this correction.

Best Regards,
Edgar