[asterisk-bugs] [Asterisk 0017851]: SIp/SDP for Non-NAT phone not used during 183 Session Progress with Non-NAT peer

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17851 
====================================================================== 
Reported By:                whardier
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17851
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           Older 1.6.2 - please test a newer version 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-08-12 20:27 CDT
Last Modified:              2010-08-24 05:39 CDT
====================================================================== 
Summary:                    SIp/SDP for Non-NAT phone not used during 183
Session Progress with Non-NAT peer
Description: 
SIP phone sends initial SDP for media path and makes a call through
chan_sip to a peer that sends back a 183 Session Progress with media.  I
cannot force the peer not to send a 183 it seems.

As soon as a 183 is received from the peer chan_sip sends a new SDP to the
phone and the peer to including itself in the media path and proxies the
media for the session progress between the peer and the phone.  Once
connected a new SDP is sent to the phone and the peer referencing eachother
and a native bridge is done.

Is this the intentional behavior of the SIP channel driver - will it
always attempt to proxy media when a 183 is present?  I am currently
attempting to save bandwidth by using the 'r' flag when dialing this peer
to keep from sending the phone session audio.  Session audio is still
present of course between the peer and Asterisk system.

I am classifying this as major priority since the difference in bandwidth
usage is substantial when you plan on only handling SIP traffic without
media.  The servers I am using handle media for some peers that don't have
heavy bandwidth requirements - however when you plan on only handling
signalling for some heavier peers the session progress can eat all your
bandwidth pretty quickly.
====================================================================== 

---------------------------------------------------------------------- 
 (0126256) davidw (reporter) - 2010-08-24 05:39
 https://issues.asterisk.org/view.php?id=17851#c126256 
---------------------------------------------------------------------- 
The presence of a local channel will always prevent (early) media being
externally bridged.  External bridging can only happen when the bridge is
between two endpoints using the same technology.  (When the call is finally
answered, the local channel will, normally, optimise out, leaving you with
the two SIP channels bridged, and eligible for external bridging.)

For early media in the SIP to SIP case, I believe you need to set an
explicit option to enable early media.  I believe I remember seeing
comments in the code warning that early media was unreliable, and there
have been bugs where early media was established and not cleaned up when
the call failed, even though it was not supposed to have been enabled.  It
is possible that early external bridging has been disabled because failures
are not handled well.

Incidentally, I believe in the latest versions, the dial application will
not forward Progress indications, unless the caller is up or has been
forced into an early media state using the Progress application.  I guess,
though, that you have already answered the caller.

I'd say that, in the local channel case, it is behaving as intended, and
any problem in the direct SIP to SIP case is minor, as it is an
optimisation that is failing. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-24 05:39 davidw         Note Added: 0126256                          
======================================================================