[Home]

Summary:ASTERISK-16560: SIp/SDP for Non-NAT phone not used during 183 Session Progress with Non-NAT peer
Reporter:Shane Spencer (whardier)Labels:
Date Opened:2010-08-12 20:27:36Date Closed:2011-06-07 14:04:45
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) sipsdp-183.txt
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.
Comments:By: Leif Madsen (lmadsen) 2010-08-16 13:51:55

Dropped to minor as the severity is related to number of people affected.
By: Leif Madsen (lmadsen) 2010-08-16 13:52:30

You'll need to provide console output of the call, along with sip.conf configuration and dialplan configuration you're using here. My instinct is this is a configuration issue.
By: Shane Spencer (whardier) 2010-08-23 14:45:25

At first I thought this was because I was using local channels.. I set up a sip->sip dialplan to test this.. it seems as though if the phone sends an sdp in the invite chan_sip sets up a 183 even if it's told to ignore sdp in invites.  However.. the Asterisk box did not send a 183 to the provider this time around since it didn't use local channels to route the call.

--- sip.conf
[general]
context=default
allowguest=no
match_auth_username=yes
allowoverlap=no

[vz-outbound](!)
type=peer
disallow=all
allow=g729
allow=ulaw
sendrpid=yes
canreinvite=yes
directmedia=yes

[vz-67.77.76.248](vz-outbound)
host=67.77.76.248
[vz-67.217.40.210](vz-outbound)
host=67.217.40.210

[libertytest]
type=friend
accountcode=9718210178
host=dynamic
allow=g729
secret=poot
canreinvite=yes
directmedia=yes
context=inbound
callerid=Liberty Telecom <9072640000>

--- extensions.conf
[general]
static=yes
writeprotect=no
clearglobalvars=no

[globals]

[inbound]
exten => 19078562879,1,Dial(SIP/vz-67.217.40.210/${EXTEN},1200)

--- Console

Connected to Asterisk 1.6.2.9-0.8541 currently running on sbc01 (pid = 21553)
Verbosity is at least 20
Core debug is at least 20
 == Using SIP RTP CoS mark 5
   -- Executing [19078562879@inbound:1] Dial("SIP/libertytest-00000048", "SIP/vz-67.217.40.210/19078562879,1200") in new stack
 == Using SIP RTP CoS mark 5
   -- Called vz-67.217.40.210/19078562879
   -- SIP/vz-67.217.40.210-00000049 is making progress passing it to SIP/libertytest-00000048
   -- SIP/vz-67.217.40.210-00000049 answered SIP/libertytest-00000048
   -- Native bridging SIP/libertytest-00000048 and SIP/vz-67.217.40.210-00000049
   -- Executing [h@inbound:1] Hangup("SIP/libertytest-00000048", "") in new stack
 == Spawn extension (inbound, 19078562879, 1) exited non-zero on 'SIP/libertytest-00000048'
By: David Woolley (davidw) 2010-08-24 05:39:40

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.
By: Russell Bryant (russell) 2011-01-17 16:15:43.000-0600

Yes, this is the expected behavior of Asterisk in this situation.