[Home]

Summary:ASTERISK-20030: Switching from wifi to 3g on a mobile device connected to Asterisk via active SIP channel results in no audio
Reporter:Bala (b7s@a-cti.com)Labels:
Date Opened:2012-06-21 07:26:20Date Closed:2012-06-28 09:03:22
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:10.0.1 10.1.3 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:Asterisk 10.X and C-SIP Simple on AndroidAttachments:
Description:Hi

We are facing issue in Asterisk 10 that On call hanged up when we changed our device network from wifi to 3g when we are in On-Call

This is working fine in asterisk 1.6 and 1.8

The scenario is

I dialed one number from my wifi network after the call is successfully connected I changed my device network from wifi to 3g
then I cannot receive the audio stream on new network .

But it is working in Asterisk 1.6 and 1.8

Comments:By: David Woolley (davidw) 2012-06-21 09:22:13.640-0500

Mobile devices don't normally have autonomous system numbers, to allow them to be multihomed, so you are going to have to provide details of how you retain the same IP address over the transition.

As this is a SIP issue, which you are claiming as a regression, you need to provide sip debugging information for both the version that works and the version that doesn't.

At the moment this looks more like a support request than a bug report, but there isn't enough information to be certain that it is off charter.
By: Shaun Clark (shaunc869) 2012-06-21 12:48:20.108-0500

I can verify I have this same issue. It looks to me like the registration packets are coming in from the client when the 3G to WiFi (or vice versa) happens. In 1.6 Asterisk seems to re-route the RTP stream to the new IP address just fine, but in 10.5 this is not working as expected.

When I switch while directly connected to Asterisk 10.5 on a live call I see my client send this:

17:38:52.060553 IP (tos 0x68, ttl 41, id 0, offset 0, flags [DF], proto UDP (17), length 570)
   mobile-166-190-137-023.mycingular.net.3407 > ip-10-177-55-210.us-west-1.compute.internal.sip: SIP, length: 542
REGISTER sip:50.18.247.212 SIP/2.0
Via: SIP/2.0/UDP 10.156.187.158:3407;rport;branch=z9hG4bK1140390162
From: <sip:3001@50.18.247.212>;tag=115966795
To: <sip:3001@50.18.247.212>
Call-ID: 1105831428
CSeq: 4 REGISTER
Contact: <sip:3001@166.190.137.23:3407;line=c97f038efb38215>
Authorization: Digest username="3001", realm="asterisk", nonce="7cf2138f", uri="sip:50.18.247.212", response="e033e2196379a55b662a408c47e06175", algorithm=MD5
Max-Forwards: 70
User-Agent: Linphone/3.4.0 (eXosip2/unknown)
Expires: 3600
Content-Length: 0

Which I think should tell Asterisk to switch, as it contains the correct username, password, and the new ip address in the Contact field, but it seems to ignore this.

Hopefully this helps, thanks!
By: David Woolley (davidw) 2012-06-22 04:42:41.137-0500

REGISTER should not change the RTP destination; that is established by the SDP and would need a re-invite.  I don't believe it should affect active SIP sessions at all, particularly as the Contact: header should override any prior information.

It seems to me that, if it was working in 1.6, there was a bug in 1.6.

Regardless of the above, the rules for reporting SIP related problems require the attachment of SIP debugging traces, which you have not done.

If you are dual homed, and you want seamless transitions, you need to be running border gateway protocol and have an automomous system number, so that there is no IP address change.  I presume the situation still is that you need a large sub-network before backbone routers will store routing information, so a phone with an ASN is likely to remain unroutable.

The other approach might be to use a VPN, although that would need to solve the problem of the change of home network.
By: Shaun Clark (shaunc869) 2012-06-22 09:02:14.500-0500

The client is a cell phone, so it can often switch between wifi and GSM almost at random, I look at the client traces and see this:

Message sent: (to dest=75.101.244.XXX:5060)
REGISTER sip:75.101.244.XXX SIP/2.0
Via: SIP/2.0/UDP 10.165.27.161:2407;rport;branch=z9hG4bK1839704852
From: <sip:990XX@75.101.244.XXX>;tag=1689684502
To: <sip:990XX@75.101.244.XXX>
Call-ID: 1867622191
CSeq: 1 REGISTER
Contact: <sip:990XX@10.165.27.161:2407;line=daeb0d9351eff22>
Max-Forwards: 70
User-Agent: Linphone/3.4.0 (eXosip2/unknown)
Expires: 3600
Content-Length: 0

Received message:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.165.27.161:2407;received=32.158.143.61;rport=2407;branch=z9hG4bK1839704852
From: <sip:990XX@75.101.244.XXX>;tag=1689684502
To: <sip:990XX@75.101.244.XXX>;tag=c97b4d1cb1f3d0da549e06a8d482ef63.e10d
Call-ID: 1867622191
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="75.101.244.XXX", nonce="4fe476e500000e00aa8700d49b8c668f4c6f1e6a367f2XXX"
Server: Asterisk
Content-Length: 0

REGISTER sip:75.101.244.XXX SIP/2.0
Via: SIP/2.0/UDP 10.165.27.161:2407;rport;branch=z9hG4bK123406454
From: <sip:990XX@75.101.244.XXX>;tag=1689684502
To: <sip:990XX@75.101.244.XXX>
Call-ID: 1867622191
CSeq: 2 REGISTER
Contact: <sip:990XX@10.165.27.161:2407;line=daeb0d9351eff22>
Authorization: Digest username="990XX", realm="75.101.244.XXX", nonce="4fe476e500000e00aa8700d49b8c668f4c6f1e6a367f2XXX", uri="sip:75.101.244.XXX", response="1e1d558894f2c05c322c76efbb2f9XXX", algorithm=MD5
Max-Forwards: 70
User-Agent: Linphone/3.4.0 (eXosip2/unknown)
Expires: 3600
Content-Length: 0

Received message:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.165.27.161:2407;received=32.158.143.61;rport=2407;branch=z9hG4bK123406454
From: <sip:990XX@75.101.244.XXX>;tag=1689684502
To: <sip:990XX@75.101.244.XXX>;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8b5a
Call-ID: 1867622191
CSeq: 2 REGISTER
Contact: <sip:990XX@10.165.27.161:2407;line=daeb0d9351eff22>;expires=120, <sip:990XX@50.43.101.83:51879;line=59ecc207f06f4e9>;expires=81
Server: Asterisk
Content-Length: 0

I would expect a re-INVITE to be sent by the server at this point so the call can continue, but I don't see it. Does this help?
By: Shaun Clark (shaunc869) 2012-06-22 10:08:36.843-0500

I just looked at a similar test from Asterisk 1.8.11 and I see this additional message and the call does reconnect in this instance:

SIP/2.0 408 Request Timeout
Via: SIP/2.0/UDP 10.3.10.XXX:2407;received=50.43.101.XX;rport=51879;branch=z9hG4bK1210661626
From: <sip:102611@50.17.206.XXX>;tag=2144744559
To: <sip:+15037773456@50.17.206.XXX>;tag=155c340f586c28d0300cf5a6ccf90d99-1c9d
Call-ID: 529662481
CSeq: 21 INVITE
Server: Asterisk
Content-Length: 0

Not sure why the 408 timeout
By: Shaun Clark (shaunc869) 2012-06-22 12:04:05.985-0500

I can also see this on 1.8 when I enable RTP debugging:


Got  RTP packet from    32.153.42.XXX:7076 (type 00, seq 000278, ts 046960, len 000160)
Sent RTP packet to      67.231.8.XXX:25958 (type 00, seq 034442, ts 046960, len 000160)
Got  RTP packet from    67.231.8.XXX:25958 (type 00, seq 000356, ts 056960, len 000160)
Sent RTP packet to      32.153.42.XXX:7076 (type 00, seq 026717, ts 056960, len 000160)
[Jun 22 17:01:32] DEBUG[9183]: res_rtp_asterisk.c:2212 ast_rtp_read: RTP NAT: Got audio from other end. Now sending to address 50.43.101.XX:60584
Got  RTP packet from    50.43.101.XX:60584 (type 00, seq 000281, ts 047440, len 000160)
Sent RTP packet to      67.231.8.XXX:25958 (type 00, seq 034443, ts 047440, len 000160)
Got  RTP packet from    50.43.101.XX:60584 (type 00, seq 000282, ts 047600, len 000160)
Sent RTP packet to      67.231.8.XXX:25958 (type 00, seq 034444, ts 047600, len 000160)

It clearly switches to the new IP address, maybe there is a setting I'm missing in 10.6-rc1 somewhere?
By: Shaun Clark (shaunc869) 2012-06-22 16:11:05.569-0500

Upon further investigation I added this code the file res/res_rtp_asterisk.c:


/* If symmetric RTP is enabled see if the remote side is not what we expected and change where we are sending audio */
       if (ast_rtp_instance_get_prop(instance, AST_RTP_PROPERTY_NAT)) {
         ******START MY CODE ******
               socklen_t addr_len=sizeof(addr);
               char buffer[INET6_ADDRSTRLEN];
               int err=getnameinfo((struct sockaddr*)&addr,addr_len,buffer,sizeof(buffer),0,0,NI_NUMERICHOST);

               socklen_t addr_len2=sizeof(remote_address);
               char buffer2[INET6_ADDRSTRLEN];
               int err2=getnameinfo((struct sockaddr*)&remote_address,addr_len2,buffer2,sizeof(buffer2),0,0,NI_NUMERICHOST);

               ast_verb(0, "RTP NAT: remote addr:%s addr:%s\n",buffer2, buffer);
        ******END MY CODE*******

When I switch from wifi to 3g this code in 1.8 gives me:

RTP NAT: remote addr:32.155.154.XX addr:32.155.154.XX
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: remote addr:32.155.154.XX addr:32.155.154.XX
RTP NAT: remote addr:32.155.154.XX addr:50.X3.101.XX
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: remote addr:50.X3.101.XX addr:50.X3.101.XX
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: remote addr:50.X3.101.XX addr:50.X3.101.XX
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X

in 10.6-rc-1 I get:

RTP NAT: remote addr:67.231.0.XXX addr:67.231.0.XXX
RTP NAT: remote addr:50.X3.101.XX addr:50.X3.101.XX
RTP NAT: remote addr:67.231.0.XXX addr:67.231.0.XXX
RTP NAT: remote addr:50.X3.101.XX addr:50.X3.101.XX
RTP NAT: remote addr:67.231.0.XXX addr:67.231.0.XXX
RTP NAT: remote addr:50.X3.101.XX addr:50.X3.101.XX
RTP NAT: remote addr:67.231.0.XXX addr:67.231.0.XXX
RTP NAT: remote addr:50.X3.101.XX addr:50.X3.101.XX
RTP NAT: remote addr:67.231.0.XXX addr:67.231.0.XXX
RTP NAT: remote addr:67.231.0.XXX addr:67.231.0.XXX
RTP NAT: remote addr:67.231.0.XXX addr:67.231.0.XXX
RTP NAT: remote addr:67.231.0.XXX addr:67.231.0.XXX
RTP NAT: remote addr:67.231.0.XXX addr:67.231.0.XXX
RTP NAT: remote addr:67.231.0.XXX addr:67.231.0.XXX
RTP NAT: remote addr:67.231.0.XXX addr:67.231.0.XXX
RTP NAT: remote addr:67.231.0.XXX addr:67.231.0.XXX


Hopefully some smart person knows how these vars get set when an IP switch like this occurs because it looks like it could be a small bug. Thanks!

By: Shaun Clark (shaunc869) 2012-06-22 17:34:06.073-0500

Okay some additional debug code at the top of the function/method ast_rtp_read:

static struct ast_frame *ast_rtp_read(struct ast_rtp_instance *instance, int rtcp) {
****START MY CODE****
       struct ast_sockaddr them;
       ast_rtp_instance_get_remote_address(instance,&them);
       ast_verb(0, "RTP NAT: iaddr:%s\n",ast_sockaddr_stringify_addr(&them));
*****END MY CODE***

The output from this looks like this:


In 1.8

Before IP Switch (my IP is 50.43.101.XX)

RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:50.43.101.XX
RTP NAT: remote addr:50.43.101.XX addr:50.43.101.XX
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:50.43.101.XX
RTP NAT: remote addr:50.43.101.XX addr:50.43.101.XX
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:50.43.101.XX
RTP NAT: remote addr:50.43.101.XX addr:50.43.101.XX
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:50.43.101.XX

After IP Switch (my IP is 32.152.110.X)

RTP NAT: remote addr:32.152.110.X addr:32.152.110.X
RTP NAT: iaddr:32.152.110.X
RTP NAT: remote addr:32.152.110.X addr:32.152.110.X
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:32.152.110.X
RTP NAT: remote addr:32.152.110.X addr:32.152.110.X
RTP NAT: iaddr:32.152.110.X
RTP NAT: remote addr:32.152.110.X addr:32.152.110.X
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:32.152.110.X
RTP NAT: remote addr:32.152.110.X addr:32.152.110.X

In 10.6-rc1

Before IP Switch (my IP is 50.43.101.XX)

RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:50.43.101.XX
RTP NAT: remote addr:50.43.101.XX addr:50.43.101.XX
RTP NAT: iaddr:50.43.101.XX
RTP NAT: remote addr:50.43.101.XX addr:50.43.101.XX
RTP NAT: iaddr:50.43.101.XX
RTP NAT: remote addr:50.43.101.XX addr:50.43.101.XX
RTP NAT: iaddr:50.43.101.XX
RTP NAT: remote addr:50.43.101.XX addr:50.43.101.XX
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:50.43.101.XX
RTP NAT: remote addr:50.43.101.XX addr:50.43.101.XX
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:50.43.101.XX
RTP NAT: remote addr:50.43.101.XX addr:50.43.101.XX
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:50.43.101.XX
RTP NAT: remote addr:50.43.101.XX addr:50.43.101.XX
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:50.43.101.XX
RTP NAT: remote addr:50.43.101.XX addr:50.43.101.XX
RTP NAT: iaddr:67.16.122.X


After IP Switch (my IP is 32.152.110.X)

RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
*RTP NAT: iaddr:50.43.101.XX*
*RTP NAT: iaddr:67.16.122.X*
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
*RTP NAT: iaddr:50.43.101.XX*
*RTP NAT: iaddr:67.16.122.X*
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:50.43.101.XX
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:50.43.101.XX
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
*RTP NAT: iaddr:50.43.101.XX*
*RTP NAT: iaddr:50.43.101.XX*
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:67.16.122.X
RTP NAT: remote addr:67.16.122.X addr:67.16.122.X
RTP NAT: iaddr:50.43.101.XX


Notice in 10.6-rc1 we see the iaddr get printed twice, not sure why this, but hopefully this will make it easier to figure out the issue.
By: Richard Mudgett (rmudgett) 2012-06-22 20:02:35.872-0500

Asterisk v1.8 -r351287 may have a bearing on your issue.  It deals with locking out RTP sources after a probation/learning period.
By: Shaun Clark (shaunc869) 2012-06-23 11:44:50.484-0500

Currently the functionality works in 1.8, do you think this change somehow got pulled from 10? Thanks I will check it out.
By: David Woolley (davidw) 2012-06-25 05:30:02.061-0500

Digium will not accept code that is included in a comment.  It must be attached, after "signing" the electronic licence grant.  The code also needs to be in unified diff format.

I believe you are introducing a non-standard heuristic to the SIP protocol.  That would need to be done as a feature request, against the SVN trunk, and you would need to include an option to enable it, so that the default behaviour was standard SIP behaviour.

If you think this is essential for mobile phone SIP access, you should also raise an RFC.
By: Birger "WIMPy" Harzenetter (wimpy) 2012-06-25 23:35:57.969-0500

Sounds to me like strictrtp.
What do your rtp.conf files look like?
Are you aware of the potentially serious security implications by the old behavior?
By: Shaun Clark (shaunc869) 2012-06-27 16:10:11.110-0500

I can report that it did come down to strictrtp, it looks like between 1.8.11 and 10 something the default from strictrtp=no to yes. This changed the behavior we expected. I think we can close this issue since it isn't a bug, but just a change to the default config expected. Thanks!
By: Shaun Clark (shaunc869) 2012-07-19 10:37:52.080-0500

If I have direct media = yes should strictrtp=no still work fine? Thanks!
By: Mark Petersen (roadkill) 2012-07-20 06:41:04.063-0500

hi shaun

for the conversation to move over to the new IP you SIP client
must send a reinvite to asterisk with the to & from tag from the curent conversation
the new invite must contain updatet ip address for both the SIP and the RTP
I know this is supportet in asterisk 10
as we use this in openBTS to make it posible to move the mobile phone conversation from one base-station to the next