SPA5XX - Fake ringback when receiving SIP 181 - Xfers

[gorka.irontec]

Hi All,

After some intense debug we can post here a situation than can be easy replayed and we think it can be a bug.

• Our scenario is:
  • 3 IP Phones (A+B+C)
  • 1 Asterisk box.
  • B has call forward to C, setup on terminal.

The operation in brief is:

• A calls B via Asterisk
• B replys to Asterisk SIP 302 Moved Temp. to C
• Asterisk sends to A SIP 181 (Being forwarded...).
• Asterisk then calls C
• At the end, A is bridged with C.

But the fact is that as soon as the IP Phone receives the 181, it starts the playing ringback tone.

This ringback tone is kind of  'fake', because no RINGING or SESSION Progress has been sent to phone A, just the message 181.

We know that when finally C is really ringing, Asterisk is sending the message, but this is not the case.

So, this applys also to XFERS, where the scenario is:

• 4 IP PHONES: A+B+C+D.
• C has call forward to D.

The operation in brief is:

• A calls B
• B starts an XFER to C
• C is being forwarded to D
• B confirms the XFER pushing again the XFER key
• At the end A is bridged with D.

So, what is the problem ?

• The problem is that when B starts the XFER to C, the user can confirm the XFER as soon as the phone recieves SIP181, not on SESSION PROGRESS or RINGING.
• So, what happens when B confirms the XFERs before the phone receives the SESSIONS PROGRESS or RINGING:
• It happens that Asterisk when receiving a SIP 302 spawns a ChanLocal that finally disappear when the other leg answer or is on SESSION Progress, and finally the channel masquerade is done with the correct legs.
• So, if the XFER is confirmed before the final leg is really on SESSION Progress or RINGING, the channel masquerade is done with the soon to disappear local channel.

I know that it can look like an Asterisk specific problem, but the fact is that the IP Phone permits to confirm the transfer as soon as the SIP181 is received, when the normal way of transfer confirmation can be done only on session progress or ringing.

Also, the ringback that the calling user can heard as soon as the SIP181 is received  is a fake ringback.

When using only local SIP UA's everything is quite fast and no problems, but if there are SIP 302 forwards to PSTN using GSM Networks or simillar and the timing to start to receiving SESSION Progress or RINGING is not very very fast, this can cause problems. Wich is our problems

I think the solution on the phone should be:

• Not play ringback on SIP181 received.
• Not permit to confirm XFER when only SIP181 is received.

We have tested with firmware 7.4.7 and SPA504G phones.

I hope we make this post understable and clear

We have here multiple labs, so, if needed we can provide SIP Traces, configs, etc ...

Thanks all for this great place

[nseto]

For this issue, please try the following.

1.  In the Ext tab, under SIP Settings, there's a parameter called Sticky 183.  Default is No, change this to Yes and retry the call.

If this doesn't resolve the issue, please enclose the wireshark of this call. Thanks.

[gorka.irontec]

Hi Nseto,

First at all, thanks for your answer.

In fact, i ve read about this option, but according to administrator manual:

"Sticky 183 If this feature is enabled, the IP telephony ignores further 180

SIP responses after receiving the first 183 SIP response for an

outbound INVITE. To enable this feature, select yes. Otherwise,

select no.

Defaults to no."

Its not related to 183 Session Progress && 180 Ringing.

The fact is the phone starts to play ringback as soon as it receives a 181 Call is forwarded.

For replay this, as easy as:

-2 Phones A+B

-B has call forwarding to a remote GSM Mobile phone (something that takes some seconds to really ringing).

Call from A to B, you will hear the ringback tone as soon as you starts calling, not when the remote destination is ringing.

At same time, with ngrep/wireshark the packet capture will show that there is no SDP at all with session progress and not 180 ringing, just the 181 Call is Being Forwarded.

Im far from a IP Phone now, but tomorrow will be on our lab and i can upload the pcap files or ngrep dumps.

And I will try the Sticky 183 option, but looks like is not related.

Thanks again Nseto

Gorka.

[gorka.irontec]

Hi,

After some debugging... Sticky option, in this case, doesn't do anything special.

The main problem is that phone plays a Ringback tone when it receives a 181 SIP message.

-So, A phone calls B and B phones answers to Asterisk with a 302 SIP message:

U 10.10.0.180:5060 -> 10.1.100.190:5060

SIP/2.0 302 Moved Temporarily.

To: ;tag=cfbb797044ea96aai0.

From: "Irontec " <5998>;tag=as0ff349ee.

Call-ID: 19c731632eb7a97a438a127061834cbe@10.1.100.190:5060.

CSeq: 102 INVITE.

Via: SIP/2.0/UDP 10.1.100.190:5060;branch=z9hG4bK7241485e.

Contact: <123456789>.

Diversion: ;reason=unconditional.

Server: Cisco/SPA504G-7.4.7.

Content-Length: 0.

.

-And then Asterisk tells phone A that call is going to be forwarded (without any SDP):

U 10.1.100.190:5060 -> 10.10.0.177:5061

SIP/2.0 181 Call is being forwarded.

Via: SIP/2.0/UDP 10.10.0.177:5061;branch=z9hG4bK-587a5e23;received=10.10.0.177.

From: ;tag=481115c9fa844b6bo1.

To: "Irontec Remoto" <5999>;tag=as6e94e4bc.

Call-ID: a85753a1-a2f36773@10.10.0.177.

CSeq: 102 INVITE.

Server: "Irontec IVOZ".

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.

Supported: replaces, timer.

Contact: <5999>.

Diversion: ;reason=unconditional.

Content-Length: 0.

.

-In this moment phone A starts a Ringback tone until receives a 183 SIP message:

U 10.1.100.190:5060 -> 10.10.0.177:5061

SIP/2.0 183 Session Progress.

Via: SIP/2.0/UDP 10.10.0.177:5061;branch=z9hG4bK-587a5e23;received=10.10.0.177.

From: ;tag=481115c9fa844b6bo1.

To: "Irontec Remoto" <5999>;tag=as6e94e4bc.

Call-ID: a85753a1-a2f36773@10.10.0.177.

CSeq: 102 INVITE.

Server: "Irontec IVOZ".

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.

Supported: replaces, timer.

Contact: <5999>.

Content-Type: application/sdp.

Content-Length: 221.

.

v=0.

o=root 461548446 461548446 IN IP4 10.1.100.190.

s=Asterisk PBX 1.8.2.3 (RSP (Community supported branch) 1.8.2.3).

c=IN IP4 10.1.100.190.

t=0 0.

m=audio 16618 RTP/AVP 8.

a=rtpmap:8 PCMA/8000.

a=ptime:20.

a=sendrecv.

So, we think that phone shouldn't give a RingBack Tone with a 181 SIP message.

There are some posts at SIP-Implementors mailing list about this:

https://lists.cs.columbia.edu/pipermail/sip-implementors/2010-March/024500.html

Thanks all.

[gorka.irontec]

Hello,

¿Any news regarding this?

We really think it's a bug and phone plays ringback when no needed, it plays ringback as soon as received the 181.

Its very easy to "reproduce" this scenario.

Just register a phone to SIP IP PBX, set call forwarding to an external pstn cell phone (better cell, because it takes a little more time), call from phone A to phone B and:

-Displays will print: "Call is being forwarded" [Perfect]

-Phone will play ringback [Not correct]

Thanks!

[nseto]

Sorry, I was out for a week.  I need to log a bug report on this, but I need the trace, please enclose the trace and I can enter your info and the trace into the bug report.  Thanks.

[ciscoirontec]

Hi,

I've attached a pcap file with the info. If you need more captures you only have to tell us.

In the capture it's very clear how the PBX sends the termianl first a 181 and then 183 Session progress, and between them the phone gives a ringback tone to the user.

Thanks!

[nseto]

Thanks, I've entered as a bug request.  It's cdet number CSCto80487.

[nseto]

Hi, dev is working on the issue and they would like a test accounts with your asterisk server.  Please send me 3 test accounts to nseto at cisco.com.  Then dev can work on the case that you show as

A calls B via Asterisk

    B replys to Asterisk SIP 302 Moved Temp. to C

    Asterisk sends to A SIP 181 (Being forwarded...).

    Asterisk then calls C

    At the end, A is bridged with C.

Thanks!

[nseto]

Gorka, as requested a few days ago, please have three test accounts for dev to use so they can address the issue.  Please email the info to nseto at cisco.com.  Thanks.

[ciscoirontec]

Sorry, we've been out those days.

We'll prepare a testing environment as soon as possible.

thanks.