Nir Simionovich
2005-May-03 03:01 UTC
[Asterisk-Users] Very weird behaviour of Asterisk and SIP
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@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@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@62.90.49.88:5060>
-- Executing Dial("SIP/nirs-e218",
"SIP/902123400321@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@bveraz1
May 3 14:55:33 DEBUG[2136]: chan_sip.c:1060 __sip_semi_ack: (Provisional)
Stopping retransmission (but retaining packet) on
'4c1e49250ac249f22f48199407914f29@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@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@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@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@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@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
Domjan Attila
2005-May-03 04:08 UTC
[Asterisk-Users] Very weird behaviour of Asterisk and SIP
Hi, I had similar problem with today cvs. When I make call gs phones eachother no voice both direction. I downgraded to yesterday cvs. On Tue, 2005-05-03 at 12:01 +0200, Nir Simionovich wrote:> 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@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@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@62.90.49.88:5060> > -- Executing Dial("SIP/nirs-e218", "SIP/902123400321@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@bveraz1 > May 3 14:55:33 DEBUG[2136]: chan_sip.c:1060 __sip_semi_ack: > (Provisional) Stopping retransmission (but retaining packet) on > '4c1e49250ac249f22f48199407914f29@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@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@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@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@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@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 > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20050503/bd0f16e6/attachment.pgp