[Asterisk-Users] Very weird behaviour of Asterisk and SIP

Tue May 3 03:01:46 MST 2005

Hi All,

  I've encountered the following very weird behaviour: 

1. I have an Asterisk box located on the net, which is connected via SIP to
two endpoints.
    First endpoint is a SIPUA SPA-841 and the other is a VERAZ softswitch.
2. When tyring to run a call from the Sipua to the VERAZ, it appears that
Asterisk tries
    to dial out no problem, but the following WARNING is recieved on
asterisk:

    May  3 14:55:35 WARNING[2136]: chan_sip.c:2934 process_sdp: Unknown SDP
media type in offer: image 58232 udptl t38

3. Once this message is received, progress tones are no longer heard and
call disconnects
    on a one-way voice after 10 seconds.

  I've ran a log debug on the call, and it looks like this:

May  3 14:55:32 DEBUG[2136]: chan_sip.c:5914 check_user_full: Setting NAT on
RTP to 0
May  3 14:55:33 DEBUG[2136]: chan_sip.c:1014 __sip_ack: Stopping
retransmission on 'c603084-839e381d at 62.90.49.88' of Response 101: Found
May  3 14:55:33 DEBUG[2136]: chan_sip.c:5914 check_user_full: Setting NAT on
RTP to 0
May  3 14:55:33 DEBUG[2136]: chan_sip.c:9113 handle_request: Ignoring too
old SIP packet packet 101 (expecting >= 102)
May  3 14:55:33 DEBUG[2136]: chan_sip.c:1014 __sip_ack: Stopping
retransmission on 'c603084-839e381d at 62.90.49.88' of Response 102: Found
May  3 14:55:33 DEBUG[2136]: chan_sip.c:5914 check_user_full: Setting NAT on
RTP to 0
May  3 14:55:33 DEBUG[2136]: chan_sip.c:8600 handle_request_invite: Check
for res for nirs
May  3 14:55:33 DEBUG[2136]: chan_sip.c:5106 build_route: build_route:
Contact hop: nirs <sip:nirs at 62.90.49.88:5060>
    -- Executing Dial("SIP/nirs-e218", "SIP/902123400321 at bveraz1|30") in new
stack
May  3 14:55:33 DEBUG[2181]: chan_sip.c:1479 create_addr: Setting NAT on RTP
to 0
May  3 14:55:33 DEBUG[2181]: chan_sip.c:1643 sip_call: Outgoing Call for
902123400321
    -- Called 902123400321 at bveraz1
May  3 14:55:33 DEBUG[2136]: chan_sip.c:1060 __sip_semi_ack: (Provisional)
Stopping retransmission (but retaining packet) on
'4c1e49250ac249f22f48199407914f29 at 213.194.92.10' Request 102: Found
May  3 14:55:34 DEBUG[2136]: chan_sip.c:1060 __sip_semi_ack: (Provisional)
Stopping retransmission (but retaining packet) on
'4c1e49250ac249f22f48199407914f29 at 213.194.92.10' Request 102: Found
    -- SIP/bveraz1-b42b is ringing
May  3 14:55:35 DEBUG[2136]: chan_sip.c:1060 __sip_semi_ack: (Provisional)
Stopping retransmission (but retaining packet) on
'4c1e49250ac249f22f48199407914f29 at 213.194.92.10' Request 102: Found
May  3 14:55:35 WARNING[2136]: chan_sip.c:2934 process_sdp: Unknown SDP
media type in offer: image 58232 udptl t38
    -- SIP/bveraz1-b42b is making progress passing it to SIP/nirs-e218
May  3 14:55:53 DEBUG[2181]: chan_sip.c:1923 sip_hangup:
update_user_counter(902123400321) - decrement outUse counter
May  3 14:55:53 DEBUG[2181]: app_dial.c:1345 dial_exec_full: Exiting with
DIALSTATUS=CANCEL.
  == Spawn extension (nirs, 902123400321, 1) exited non-zero on
'SIP/nirs-e218'
May  3 14:55:53 DEBUG[2181]: chan_sip.c:1926 sip_hangup:
update_user_counter(nirs) - decrement inUse counter
May  3 14:55:53 DEBUG[2136]: chan_sip.c:996 __sip_ack: Acked pending invite
102
May  3 14:55:53 DEBUG[2136]: chan_sip.c:1014 __sip_ack: Stopping
retransmission on '4c1e49250ac249f22f48199407914f29 at 213.194.92.10' of
Request 102: Found
May  3 14:55:53 DEBUG[2136]: chan_sip.c:1014 __sip_ack: Stopping
retransmission on '4c1e49250ac249f22f48199407914f29 at 213.194.92.10' of
Request 102: Found
May  3 14:55:53 DEBUG[2136]: chan_sip.c:1014 __sip_ack: Stopping
retransmission on 'c603084-839e381d at 62.90.49.88' of Response 103: Found

Now, SIP configuration looks like this:

[general]
;context=default                        ; Default context for incoming calls
realm=dimitel           ; Realm for digest authentication
bindport=5060                   ; UDP Port to bind to (SIP standard port is
5060)
bindaddr=0.0.0.0                ; IP address to bind to (0.0.0.0 binds to
all)
srvlookup=no                    ; Enable DNS SRV lookups on outbound calls
pedantic=yes                    ; Enable slow, pedantic checking for Pingtel
tos=lowdelay                    ;
lowdelay,throughput,reliability,mincost,none
maxexpirey=3600         ; Max length of incoming registration we allow
defaultexpirey=120              ; Default length of incoming/outoing
registration
checkmwi=10                     ; Default time between mailbox checks for
peers
disallow=all                    ; First disallow all codecs
allow=ulaw                      ; Allow codecs in order of preference
allow=g729
musicclass=default              ; Sets the default music on hold class for
all SIP calls
relaxdtmf=yes                   ; Relax dtmf handling
rtptimeout=60                   ; Terminate call if 60 seconds of no RTP
activity
rtpholdtimeout=300              ; Terminate call if 300 seconds of no RTP
activity
trustrpid = no                  ; If Remote-Party-ID should be trusted
progressinband=never            ; If we should generate in-band ringing
always
useragent=DimiTrex iPBX         ; Allows you to change the user agent string
dtmfmode = info         ; Set default dtmfmode for sending DTMF. Default:
rfc2833
compactheaders =no      ; send compact sip headers.
nat=no                          ; Global NAT settings  (Affects all peers
and users)
canreinvite=no

[nirs]
type=friend
host=dynamic
nat=no
canreinvinte=no
username=nirs
secret=nirs
context=nirs

[bveraz1]
type=friend
host=62.244.xx.xx
nat=no
canreinvite=no
disallow=all
allow=g729

And just for knowladge, I do have the g729 licenses installed on the box.
Any thoughts on the issue would be highly appreciated.

Regards,
  Nir Simionovich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20050503/ad5e840c/attachment.htm