[Home]

Summary:ASTERISK-11304: Moved Temporarily Contact Transport information not used in next invite
Reporter:Patrik Estermann (pestermann)Labels:
Date Opened:2008-01-25 02:34:54.000-0600Date Closed:2008-08-12 17:45:31
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20080722__issue11843_302_ignores_transport_16branch.ERROR.txt
( 1) 20080723__issue11843_302_ignores_transport_16branch.diff
( 2) 20080723__issue11843_302_ignores_transport_trunk.diff
( 3) bt_full.txt
( 4) bt.txt
( 5) chan_sip.c.rej.txt
( 6) full.txt
( 7) malloc_debug.txt
( 8) valgrind.txt
( 9) working.txt
Description:When getting back an Moved Temporarily from the called party the transport information in the contact header is not used for the next invite based on promiscredir=yes.

In the SIP debug

****** ADDITIONAL INFORMATION ******

sip.conf
[0439607912]
type=peer
username=0439607912
host=192.168.0.11
transport=tcp
promiscredir=yes

extensions.conf
[default]
exten => 0439607912,1,Dial(SIP/0439607912)
exten => 0439607912,2,Hangup()

SIP debug
<--- SIP read from UDP://192.168.0.11:53024 --->
INVITE sip:0439607912@192.168.0.10 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.11:53024;branch=z9hG4bK-d87543-ce3beb2d2117bc52-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:PC@192.168.0.11:53024>
To: "0439607912 (Softphone)"<sip:0439607912@192.168.0.10>
From: "PC"<sip:PC@192.168.0.10>;tag=005b7e19
Call-ID: YjcwYWEyZGM3OGUzMjU3MzY4OGQ1NzU1MjU2NTRmNzE.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: X-Lite release 1011s stamp 41150
Content-Length: 420

v=0
o=- 6 2 IN IP4 192.168.0.11
s=CounterPath X-Lite 3.0
c=IN IP4 192.168.0.11
t=0 0
m=audio 32008 RTP/AVP 107 119 100 106 0 105 98 8 101
a=alt:1 1 : K1/Ezcm/ +3IVIJ27 192.168.0.11 32008
a=fmtp:101 0-15
a=rtpmap:107 BV32/16000
a=rtpmap:119 BV32-FEC/16000
a=rtpmap:100 SPEEX/16000
a=rtpmap:106 SPEEX-FEC/16000
a=rtpmap:105 SPEEX-FEC/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

<------------->
--- (12 headers 16 lines) ---
 == Using SIP RTP CoS mark 5
Sending to 192.168.0.11 : 53024 (NAT)
Using INVITE request as basis request - YjcwYWEyZGM3OGUzMjU3MzY4OGQ1NzU1MjU2NTRmNzE.
Found user 'PC' for 'PC'
Found RTP audio format 107
Found RTP audio format 119
Found RTP audio format 100
Found RTP audio format 106
Found RTP audio format 0
Found RTP audio format 105
Found RTP audio format 98
Found RTP audio format 8
Found RTP audio format 101
Peer audio RTP is at port 192.168.0.11:32008
Found unknown media description format BV32 for ID 107
Found unknown media description format BV32-FEC for ID 119
Found audio description format SPEEX for ID 100
Found unknown media description format SPEEX-FEC for ID 106
Found unknown media description format SPEEX-FEC for ID 105
Found audio description format iLBC for ID 98
Found audio description format telephone-event for ID 101
Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x60c (ulaw|alaw|speex|ilbc)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0xc (ulaw|alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 192.168.0.11:32008
Looking for 0439607912 in default (domain 192.168.0.10)
list_route: hop: <sip:PC@192.168.0.11:53024>

<--- Transmitting (no NAT) to 192.168.0.11:53024 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.0.11:53024;branch=z9hG4bK-d87543-ce3beb2d2117bc52-1--d87543-;received=192.168.0.11;rport=53024
From: "PC"<sip:PC@192.168.0.10>;tag=005b7e19
To: "0439607912 (Softphone)"<sip:0439607912@192.168.0.10>
Call-ID: YjcwYWEyZGM3OGUzMjU3MzY4OGQ1NzU1MjU2NTRmNzE.
CSeq: 1 INVITE
User-Agent: Asterisk PBX 1.6.0-beta1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:0439607912@192.168.0.10>
Content-Length: 0


<------------>
   -- Executing [0439607912@default:1] Dial("SIP/PC-09265630", "SIP/0439607912") in new stack
 == Using SIP RTP CoS mark 5
Audio is at 192.168.0.10 port 18576
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x2 (gsm) to SDP
Adding codec 0x8 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 192.168.0.11:5060:
INVITE sip:0439607912@192.168.0.11 SIP/2.0
Via: SIP/2.0/TCP 192.168.0.10:5060;branch=z9hG4bK335043a8;rport
Max-Forwards: 70
From: "PC" <sip:PC@192.168.0.10:5060>;tag=as38ea14f8
To: <sip:0439607912@192.168.0.11>
Contact: <sip:PC@192.168.0.10:5060;transport=TCP>
Call-ID: 2e1c71c90c6e9f5b1b29531120445b6e@192.168.0.10
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.6.0-beta1
Date: Fri, 25 Jan 2008 09:25:17 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 314

v=0
o=root 1508780322 1508780322 IN IP4 192.168.0.10
s=Asterisk PBX 1.6.0-beta1
c=IN IP4 192.168.0.10
t=0 0
m=audio 18576 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
   -- Called 0439607912
localhost*CLI>
<--- SIP read from TCP://192.168.0.11:5060 --->
SIP/2.0 100 Trying
FROM: "PC"<sip:PC@192.168.0.10:5060>;tag=as38ea14f8
TO: <sip:0439607912@192.168.0.11>
CSEQ: 102 INVITE
CALL-ID: 2e1c71c90c6e9f5b1b29531120445b6e@192.168.0.10
VIA: SIP/2.0/TCP 192.168.0.10:5060;branch=z9hG4bK335043a8;rport
CONTENT-LENGTH: 0


<------------->
--- (7 headers 0 lines) ---
localhost*CLI>
<--- SIP read from TCP://192.168.0.11:5060 --->
SIP/2.0 302 Moved Temporarily
FROM: "PC"<sip:PC@192.168.0.10:5060>;tag=as38ea14f8
TO: <sip:0439607912@192.168.0.11>;tag=da41fd957a
CSEQ: 102 INVITE
CALL-ID: 2e1c71c90c6e9f5b1b29531120445b6e@192.168.0.10
VIA: SIP/2.0/TCP 192.168.0.10:5060;branch=z9hG4bK335043a8;rport
CONTACT: <sip:0439607912@192.168.0.11:2663;transport=Tcp;maddr=192.168.0.11;x-mss-call-id=2e1c71c90c6e9f5b1b29531120445b6e%40192.168.0.10>
CONTENT-LENGTH: 0
SERVER: RTCC/3.0.0.0


<------------->
--- (9 headers 0 lines) ---
   -- Got SIP response 302 "Moved Temporarily" back from 192.168.0.11
Transmitting (no NAT) to 192.168.0.11:5060:
ACK sip:0439607912@192.168.0.11 SIP/2.0
Via: SIP/2.0/TCP 192.168.0.10:5060;branch=z9hG4bK335043a8;rport
Max-Forwards: 70
From: "PC" <sip:PC@192.168.0.10:5060>;tag=as38ea14f8
To: <sip:0439607912@192.168.0.11>;tag=da41fd957a
Contact: <sip:PC@192.168.0.10:5060;transport=TCP>
Call-ID: 2e1c71c90c6e9f5b1b29531120445b6e@192.168.0.10
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.6.0-beta1
Content-Length: 0


---
   -- Now forwarding SIP/PC-09265630 to 'SIP/0439607912@192.168.0.11:2663' (thanks to SIP/0439607912-092699a0)
 == Using SIP RTP CoS mark 5
Audio is at 192.168.0.10 port 12430
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x2 (gsm) to SDP
Adding codec 0x8 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 192.168.0.11:2663:
INVITE sip:0439607912@192.168.0.11:2663 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.10:5060;branch=z9hG4bK2d2eda46;rport
Max-Forwards: 70
From: "PC" <sip:PC@192.168.0.10:0>;tag=as6da13583
To: <sip:0439607912@192.168.0.11:2663>
Contact: <sip:PC@192.168.0.10:0>
Call-ID: 4eb86984061e3bf9685fadf34ba90893@192.168.0.10
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.6.0-beta1
Date: Fri, 25 Jan 2008 09:25:17 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 314

v=0
o=root 1491739837 1491739837 IN IP4 192.168.0.10
s=Asterisk PBX 1.6.0-beta1
c=IN IP4 192.168.0.10
t=0 0
m=audio 12430 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv




Comments:By: Olle Johansson (oej) 2008-01-30 03:18:55.000-0600

That code is just bad. It should send the call back to the dial plan instead of issuing a new INVITE directly.
By: Patrik Estermann (pestermann) 2008-01-30 07:00:19.000-0600

To send the invite to the dialplan is possible is promiscredir=false but then the something like
Dial(SIP/1234@192.168.0.10:3456;transport=tcp) should be possible otherwise only with the transport parameter in sip.conf the tcp parameter can be set.
By: Olle Johansson (oej) 2008-01-30 07:02:46.000-0600

That's another issue - the TCP/TLS patch is very immature and needs some serious work. We need a way to define transport in the dialplan, right.
By: Raj Jain (rjain) 2008-02-23 07:22:16.000-0600

The issue w/ handling 302 in the dial-plan is that not every call uses dial-plan. I had reported the same issue a while back where I was using a call file to originate a SIP call and Asterisk couldn't handle 302 in that case.

SIP redirection mechanism is something specific to SIP signalling. It might make sense to keep higher layers (such as dial-plan, call files) be agnostic of this mechanism and let chan_sip handle 3XX responses by itself.
By: Paul Belanger (pabelanger) 2008-04-29 11:51:47

Does Dial(SIP/1234@192.168.0.10:3456;transport=tcp) exist today, or was that a suggestion?  The second issue I see with this route, which is the issue I currently have with 302, how to extract dynamic information from the 302 message regarding port number.

The above example has a hardcoded '3456' port, the application I work with dynamically generates the port to contact from the 302 moved.

Either way, attaching myself to the thread to trace progress.
By: Olle Johansson (oej) 2008-04-30 10:25:54

rjain: ALL CALLS in Asterisk should go through the dialplan. It's the architecture. A redirect should definitely go through the dialplan so that a asterisk sysadm can decide how to handle redirects.
By: Olle Johansson (oej) 2008-04-30 10:27:17

This is a good example of the poor status of the 302 in asterisk as well as the experimental status we've set on the tcp/tls support. It does need a redesign. I'm sorry that you hit both of these areas in one bug report.
By: Brett Bryant (bbryant) 2008-07-15 10:44:42

pestermann, please try out the following patch to see if it fixes your issue.
By: Paul Belanger (pabelanger) 2008-07-15 14:22:14

bbryant: I just applied your patch to one of our 1.6.0-beta9 systems, however it did not work.  Please see attached (full) for the results.
By: Brett Bryant (bbryant) 2008-07-15 14:48:03

pabelanger, thanks for testing so quickly. I've uploaded a new patch that I think fixes the issue.
By: Paul Belanger (pabelanger) 2008-07-15 15:20:07

bbryant: Thanks for the quick turn around.  Applying patch 2 seems to have worked.  full_working attached for you information.

The following is the only error produced:

 [Jul 15 16:18:07] ERROR[3558] astobj2.c: bad magic number 0x29 for 0x81dc7e0

Besides that, calls are now working properly after the 302 Moved.

Thanks again,
PB
By: Brett Bryant (bbryant) 2008-07-16 15:11:14

I've uploaded one more patch which cleans things up a bit, and should work better.
By: Paul Belanger (pabelanger) 2008-07-18 12:04:21

bbryant: We have not been able to test 20080716__issue1843_302_ignores_transport_3.diff.  It fails to apply to 1.6.0-beta9.
By: Brett Bryant (bbryant) 2008-07-18 16:52:22

pabelanger, here is a version of the patch that applies cleanly to the 1.6.0-beta9 branch and not the 1.6 development branch. I removed some functionality that depended on the development branch, but it shouldn't be relevant to your testing (thus the note not to apply to trunk). Thanks for testing.
By: Paul Belanger (pabelanger) 2008-07-18 21:54:11

bbryant: Thanks for the patch.  We applied it to your system, but there is an issue with it.  It seems the INVITE from asterisk is always sent to the peers TCP/5061, overriding the settings from the sip.conf.  

Please see attached.
By: Brett Bryant (bbryant) 2008-07-21 12:23:50

pabelanger, thanks again for testing. I've fixed the issue with sending to 5061 instead of 5060 with the newest patch.
By: Paul Belanger (pabelanger) 2008-07-21 20:43:25

bbryant: This looks to be good.  Attached is trace / debugs of working call.  +1 to commit.

Thanks again for your help,
PB
By: Paul Belanger (pabelanger) 2008-07-21 20:50:46

bbryant: My mistake looks like we still get an error from the CLI

[Jul 21 21:44:39] ERROR[28370] astobj2.c: bad magic number 0x29 for 0x8236668

However, everything appears to be working properly.
By: Brett Bryant (bbryant) 2008-07-22 10:48:10

pabelanger, i've uploaded a patch that will help with debugging. The newest patch will crash asterisk when that error occurs to get a core file demonstrating the problem.

If you wouldn't mind, run asterisk under valgrding while running this patch and look at doc/valgrind.txt if you're unsure of how to paste this output here. When it crashes, please refer to doc/backtrace.txt on how to get the backtrace information, and upload that as well.
By: Paul Belanger (pabelanger) 2008-07-22 11:14:20

bbryant: Applied patch, and crashed as expected.  Here are traces of the call.  Let me know if I missed anything.
By: Russell Bryant (russell) 2008-07-22 12:56:17

pestermann, can you test the final patch and verify that it works as expected?
By: Paul Belanger (pabelanger) 2008-07-22 13:00:36

russell: Any chance of a patch against 1.6.0-beta9?  I'd be more then happy to test it.
By: Brett Bryant (bbryant) 2008-07-22 13:09:28

pabelanger, you can use the 1.6 patch, just ignore the hunks that fail.
By: Paul Belanger (pabelanger) 2008-07-22 13:24:30

bbryant: Applied patch, failed with 2 chunks (see attached). Compiled and tested.  The patch works correctly, however we still see

[Jul 22 14:22:55] ERROR[27648] astobj2.c: bad magic number 0xdeadbeef for 0x826d708
By: Russell Bryant (russell) 2008-07-22 15:20:15

That message would be expected if you try to run this against beta9.  The latest 1.6.0 code uses reference counted objects that aren't in that version.
By: Paul Belanger (pabelanger) 2008-07-22 15:43:35

russell: We did a checkout of latest 1.6.0 branch (svn 132644), applied patch, compiled / installed... but calls are no longer work.  See attached (full.txt).

Below is our sip peer.

sip.conf
---
[sv0071ivr]
host=sv0071iv.voice
;port=5070
type=peer
transport=tcp
qualify=yes
promiscredir=yes
By: Brett Bryant (bbryant) 2008-07-23 02:44:07

pabelanger, that error is occuring because a call is attempting to be made with UDP instead of TCP (which is the only one you've enabled in your configuration). To fix this you can configure everything that contacts this peer to use TCP, or change the transport line in your configuration to the following:

transport=tcp,udp


By: Paul Belanger (pabelanger) 2008-07-23 12:50:49

bbryant: I think that is our issue.  Our SIP PEER is only capable of using SIP/TCP but asterisk is sending the invite via UDP. In the past the only setting we need to enable was transport=tcp under the SIP PEER.  Is there something else that needs to be set in the latest 1.6.0 branch?

Here is how we dial the peer.

extensions.conf
---
[from-zap]
exten => s,1,Dial(SIP/sv0071ivr,5)
By: Brett Bryant (bbryant) 2008-07-23 15:49:09

pabelanger, the newest patch should fix that error.
By: Paul Belanger (pabelanger) 2008-07-23 16:08:59

bbryant: :) I think you did it.  Applied the patch to latest 1.6 branch (133218) and no longer get any errors.  See attached (working.txt)

Thanks again for all your help on this,
PB
By: Digium Subversion (svnbot) 2008-08-01 11:31:41

Repository: asterisk
Revision: 135126

U   trunk/channels/chan_sip.c
U   trunk/configs/sip.conf.sample

------------------------------------------------------------------------
r135126 | tilghman | 2008-08-01 11:31:41 -0500 (Fri, 01 Aug 2008) | 9 lines

SIP should use the transport type set in the Moved Temporarily for the next
invite.
(closes issue ASTERISK-11304)
Reported by: pestermann
Patches:
      20080723__issue11843_302_ignores_transport_16branch.diff uploaded by bbryant (license 36)
      20080723__issue11843_302_ignores_transport_trunk.diff uploaded by bbryant (license 36)
Tested by: pabelanger

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=135126