[Spce-user] Peer call not completing

[Gene]

Thanks..

My issue appears to be a misbehaving SIP ALG in the Verizon Fios firewall..



-----Original Message-----
From: John Murray [mailto:johnmmurray at gmail.com] On Behalf Of John Murray
Sent: Tuesday, September 18, 2012 9:40 AM
To: 'Gene '; 'Jon Bonilla (Manwe)'; spce-user at lists.sipwise.com
Subject: RE: [Spce-user] Peer call not completing

Sorry all, I should have been clearer with this.

The 2 problems I had here were both with the PSTN provider using incorrectly formatted ACK and BYE messages.
They had missed the Record-Route information which must be maintained and incorrectly formatted the RURI in the ACK.
After getting the correct information from the Sipwise guys the provider modified their switch (a very rare thing:-) and calls now function correctly.

There was never a problem with the SPCE.

Best regards

John

-----Original Message-----
From: Gene [mailto:gwillingham at telasip.com]
Sent: 18 September 2012 14:31
To: 'John Murray'; 'Jon Bonilla (Manwe)'; spce-user at lists.sipwise.com
Subject: RE: [Spce-user] Peer call not completing

I have the same issue, but with an XLite softphone.  I believe this worked prior to 2.6.


-----Original Message-----
From: spce-user-bounces at lists.sipwise.com [mailto:spce-user-bounces at lists.sipwise.com] On Behalf Of John Murray
Sent: Wednesday, September 12, 2012 8:01 PM
To: 'Jon Bonilla (Manwe)'; spce-user at lists.sipwise.com
Subject: Re: [Spce-user] Peer call not completing

Hello,

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 101.231.111.181:5060 SIP/2.0'
Via: SIP/2.0/UDP 191.211.111.131:5060;rport;branch=z9hG4bKe19fa6f4'
Contact: <sip:447430411440 at 191.211.111.131:5060>'
To: 441137654321
<sip:441137654321 at 101.231.111.181>;tag=69CCD486-5045E4DB00007CB3-8AA51700'
From: "447430411440" <sip:447430411440 at 191.211.111.131>;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:101.231.111.181;r2=on;lr=on;ftag=e9b8;ngcplb=yes>'
Route: <sip:127.0.0.1;r2=on;lr=on;ftag=e9b8;ngcplb=yes>'
Route:
<sip:127.0.0.1:5062;lr=on;ftag=e9b8;did=783.c842;mpd=ii;rtpprx=yes;vsf=d2dLZ
XhtNDRMWXNiUjRrOUVFUEZ3Z0tleG00NExZc2I->'
Max-Forwards: 70'
Allow: INVITE, ACK, CANCEL, BYE, INFO, OPTIONS'
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 101.231.111.181:5060>'
but sends ACK as:
ACK sip:441133225497 at 101.231.111.181 SIP/2.0'

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

HTH.
Andrew

-----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
http://lists.sipwise.com/listinfo/spce-user


_______________________________________________
Spce-user mailing list
Spce-user at lists.sipwise.com
http://lists.sipwise.com/listinfo/spce-user