Using canreinivte = yes to route content away from server

Asterisk Asterisk Support
1

If I understand the instructions correctly,i f canreinvite is set to yes for two phones (sip peers), then the actual content (voice) traffic should route directly from one phone to the other, and should only involve the asterisk server for signaling.

However in testing this behaviour, it appears that all of the traffic does route through the server rather than around it. Traffic during a phone to phone (both phones on the same asterisk server, but in different physical locations) call goes up by about 150kb/sec in both directions.

If the content traffic is being routed from phone to phone and not through the asterisk server, then what accounts for this rise in traffic at the server?

If anybody has any info on this, please let me know. TIA.

2

Answered my own question:

If the Dial() command contains t, ''T", “h”, “H”, “w”, “W” or “L” (with multiple arguments) Asterisk will not issue a re-invite.

If you get rid of the t in the dial command, then the calls go phone to phone.

3

I had several issues between 2 asterisks, one behind NAT with canreinvite=yes. Sometimes it worked, sometimes it cutted the call by sending a CANCEL from the asterisk behind NAT. Stange thing, I switched back to canreinvite=no until I have more time or ideas for what happens here. (Asterisk 1.2 on both sides). Maybe here is somebody who knows.

Rolf

4

In digging into the whole question of reinvites more, I have found a number of issues that relate. So here is what I have learned so far.

I have three incoming line accounts with Broadvoice. Registrations look like this in sip.conf:
register => 7075044511:passwd:7075044511@sip.broadvoice.com/7075044511
register => 7075044514:Npasswd:7075044514@sip.broadvoice.com/7075044514

register => 7029910135:passwd:7029910135@sip.broadvoice.com/7029910135

I have three peers set up for these three lines: also in sip.conf

[sip.broadvoice.com]
;context=from-broadvoice

type=peer
;user=phone
host=sip.broadvoice.com
fromdomain=sip.broadvoice.com
fromuser=7075044511
secret=Xpasswd
username=7075044511
insecure=very

authname=7075044511
dtmfmode=auto
dtmf=inband
;Disable canreinvite if you are behind a NAT
canreinvite=yes

[broadvoice2]
;context=from-broadvoice

type=peer
;user=phone
host=sip.broadvoice.com
fromdomain=sip.broadvoice.com
fromuser=7029910135
secret=passwd
username=7029910135
insecure=very

authname=7029910135
dtmfmode= auto
;dtmf=inband
;Disable canreinvite if you are behind a NAT
canreinvite=yes

[broadvoice3]
;context=from-broadvoice

type=peer
user=phone
host=sip.broadvoice.com
fromdomain=sip.broadvoice.com
fromuser=7075044514
secret=passwd
username=7075044514
insecure=very

authname=7075044514
dtmfmode=auto
dtmf=inband
;Disable canreinvite if you are behind a NAT
canreinvite=yes

When a call comes in on any of three lines, sip does a search by IP address (all three are the same) and matches to the last peer in the sequence. INthis case, line 7075044514. No matter which line the call comes in on, the channel is identified as 7075044514.

As far as canreinvite is concerned, only calls that actually come in on 7075044514 will accept a reinvite. Calls coming in on the other two lines simply hang up when they are answered (as soon as the reinvite is attempted). It appears that the reinvite is rejected because the wrong secret is returned. (the asterisk log shows authentication fails).

Two things about this behaviour don’t seem right to me.

First, it would seem that if the reinvite fails, asterisk should simply continue to handle the call through the server, rather than hanging up on the caller.

Second, there must be some way around this behaviour, but I can’t find it. I have tried setting the three peers to users, but in this case none of the inbound lines will reinvite. Not sure what is causing this. The only difference as far as the channel identifier is concerned is that the channel comes up as SIP/147.135.20.128 (that is the IP of the BV server originating the call).

Anybody has anything to add to this, it would be greatly appreciated.

5

I have the exact same issue as you.

Multiple SIP registrations to the same Provider.

Did you ever find a solution to this problem?

This too is causing me alot of greif.

Regards,
Richard

6

Nothing yet, I ahve posted the same question ocer on voxilla. Will let you know if I hear back from someone.

7

This is a known issue;
bugs.digium.com/view.php?id=5177

C.

8

Thanks, hopefully this will be incorporated into an upcoming release of asterisk.

9

This is a known issue;
http://bugs.digium.com/view.php?id=5177

Indeed, but it’s not treated as a bug. So it maybe won’t be fixed at all?

regards
Rolf

10

I disagree with reducing this to a feature request. This action of the code prevents reinvites from working properly in a multi trunk system. This forces all of the calls to route through the asterisk server. (a waste of resources).

Since this is a source of failure for the reinvite routine, I think this should be treated as a bug and be given an appropriate level of attention.