[asterisk-bugs] [Asterisk 0010647]: SIP Reinvite behaviour does not work as expected with certain dial() options

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10647 
====================================================================== 
Reported By:                samdell3
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10647
Category:                   Core/RTP
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.11  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             09-05-2007 00:50 CDT
Last Modified:              10-19-2007 03:52 CDT
====================================================================== 
Summary:                    SIP Reinvite behaviour does not work as expected
with certain dial() options
Description: 
With canreinvite=no on any SIP peer, the call is never reinvited (this is
correct behaviour)

With canreinvite=yes, and using with a Dial() option from below,
re-invites are not issued correctly. (actually, reinvites should not be
issued at all...)

Asterisk is not supposed to perform a re-invite when using any of the
following Dial() options: t, T, h, H, w, W or L (with multiple arguments)
This is not the case. 
Asterisk still issues a Re-invite to one of the call legs causing an
asytmetrical RTP traffic flow (causing one-way audio if the SIP peer
filters RTP packets coming from somehwere that was not in it's own SDP)

EG 
SIPPeerA------ASTERISK-----SIPPeerB

SIPPeerA calls SIPPeerB

If either or both SIPPeerA or SIPPeerB have canreinvite=no, the RTP flow
is always via Asterisk - this is correct.

If Both SIPPeers are canreinvite=yes, AND the dial command contains any of
the above dial() options, then the RTP flow forms a triangle due to a
single re-invite STILL being issued by Asterisk. EG A's RTP goes to
Asterisk, Asterisk's RTP goes to B, but B's RTP goes to A. This is because
Asterisk issues a re-invite and tells B to talk to A when it shouldn't. 
If Asterisk does issue a re-invite for one leg, it should issue a
re-invite for both legs! But in this case it should not issues any
re-invites at all.
====================================================================== 

---------------------------------------------------------------------- 
 GMvoip - 10-19-07 03:52  
---------------------------------------------------------------------- 
Hi,

I have been trying the possibility of setting up a Direct RTP session
between two SIP clients.
I tried all the permutations suggested, with Trixbox(1.2.18) as my
server and clients A and B made through resiprocate but Asterisk doesnt
send me the re-invite after the session establishment(OnConnectedConfirmed
state). So, A and B are unable to see each other's IP.
In Asterisk, I have set canreinvite=yes(I have set this for both the
clients or trunks in sip_additional.conf) and all the 3 conditions below
are satisfied

* If one of the clients is configured with canreinvite=NO, Asterisk will
not issue a re-invite at all.
* If the clients use different codecs, Asterisk will not issue a
re-invite.( I use pcmu for both)
* If the Dial() command contains ''t'', ''T", "h", "H", "w", "W" or "L"
(with multiple arguments) Asterisk will not issue a re-invite(dial option =
r in my case)

I tried another field in sip.conf, directrtpsetup=yes, also
canreinvite=nonat,update .. doesnt work either.
The set up is a normal LAN. A,B and server all on same subnet, so i
presume no NAT issues are there.(Tried nat=no also) ....
Probably the problem is on Asterisk side. Has somebody got this re-invite
after session
establishmet with IP's of A and B ?

Any hints would be great.
Regards
Megs 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-19-07 03:52  GMvoip         Note Added: 0072258                          
======================================================================