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