[Spce-user] Peer call not completing

John Murray john.murray at skyracktelecom.com
Wed Sep 12 20:01:16 EDT 2012


My provider had 2 problems. One with the ACK after a BYE and the other with the ACK after an INVITE.

The first is:

Once the client has learned the route set from Record-Route headers, it
must keep this route set in all in-dialog requests (as Route headers).

But it seems to "loose" those 3 Route headers after sending an ACK, so
the BYE comes in without any Route headers:

ACK sip:ngcp-lb at SIP/2.0'
Via: SIP/2.0/UDP;rport;branch=z9hG4bKe19fa6f4'
Contact: <sip:447430411440 at>'
To: 441137654321
<sip:441137654321 at>;tag=69CCD486-5045E4DB00007CB3-8AA51700'
From: "447430411440" <sip:447430411440 at>;tag=e9b8'
Call-ID: 9fede874-105f-4a18-8257-594d2a987c37'
CSeq: 1 ACK'
User-Agent: PartitionwareTM SIP Toolkit v2.0.50727'
Content-Length: 0'
Route: <sip:;r2=on;lr=on;ftag=e9b8;ngcplb=yes>'
Route: <sip:;r2=on;lr=on;ftag=e9b8;ngcplb=yes>'
Max-Forwards: 70'
Supported: timer'
Allow-Events: telephone-event'

The caller incorrectly build Request-URI in ACK message.

It gets from SPCE 200 OK with following contact:
Contact: <sip:ngcp-lb at>'
but sends ACK as:
ACK sip:441133225497 at SIP/2.0'

This ACK can't be loose-routed properly.
Correct ACK would have been ACK sip:ngcp-lb at SIP/2.0
There is no workaround I can recommend, you should fix the Partitionware 


-----Original Message-----
From: spce-user-bounces at lists.sipwise.com [mailto:spce-user-bounces at lists.sipwise.com] On Behalf Of Jon Bonilla (Manwe)
Sent: 03 September 2012 15:53
To: spce-user at lists.sipwise.com
Subject: Re: [Spce-user] Peer call not completing

El Mon, 3 Sep 2012 15:36:44 +0100
"John Murray" <john.murray at skyracktelecom.com> escribió:

> Hello,
> I have a MVNO peer who is sending me calls from a mobile handset (GSM 
> from handset converted to SIP at network edge from SS7)
> The call setup seems to work correctly however on sending the 200 OK 
> so start the media to the peer replies with an ACK.
> This ACK seems not to be matched with the transaction although it has 
> the same call ID and the SPCE resends the 200 OK a number of times 
> until it gives up and sends a BYE.

The ack sent to 200 ok is a new transaction AFAIR

> My impression is that the Record-Route list is having an effect on 
> this as the ACK seems to be passed around internally to the proxy and 
> the B2BUA and then the external address.

could you please attach ngrep-sip logs including ports 5062 and 5080? Also include the relevant lb and proxy logs please.

> Which fields other than Call ID are matched to an incoming ACK?

to-tag to match if it's an in-dialog request and nothing else as the proxy is not dialog aware and this is a new transaction. Let's see what happens with the logs and captures.

Spce-user mailing list
Spce-user at lists.sipwise.com

More information about the Spce-user mailing list