Hi Bogdan, Here is a full trace, breakdown is like this
.2 INVITES to .164 .164 INVITES TO .168 .168 sends a 302 to .164 .164 sends .2 a 503 followed by a 302 .2 should never know about the 302 at all, but it's still getting back to the originating proxy. We are not using get_redirects() to do anything with the 302 - from some Googling and such it appears that might be needed, just not sure how it would be used. Thanks for looking at this. 69.xxx.xxx.2:5060 -> 72.xxx.xxx.164:5060 INVITE sip:[email protected] SIP/2.0. Via: SIP/2.0/UDP 69.xxx.xxx.2:5060;branch=z9hG4bK03578afa;rport. From: "Test" <sip:[email protected]>;tag=as4f36ab60. To: <sip:[email protected]>. Contact: <sip:[email protected]>. Call-ID: [email protected]. CSeq: 102 INVITE. User-Agent: None. Max-Forwards: 70. Remote-Party-ID: "Test" <sip:[email protected]>;privacy=off;screen=no. Date: Tue, 24 Aug 2010 12:01:35 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Type: application/sdp. Content-Length: 281. . v=0. o=root 2921 2921 IN IP4 69.xxx.xxx.2. s=session. c=IN IP4 69.xxx.xxx.2. t=0 0. m=audio 12570 RTP/AVP 18 0 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. U 72.xxx.xxx.164:5060 -> 69.xxx.xxx.2:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 69.xxx.xxx.2:5060;branch=z9hG4bK03578afa;rport=5060. From: "Test" <sip:[email protected]>;tag=as4f36ab60. To: <sip:[email protected]>. Call-ID: [email protected]. CSeq: 102 INVITE. Server: OpenSIPS (1.6.2-notls (x86_64/freebsd)). Content-Length: 0. . U 72.xxx.xxx.164:5060 -> 72.xxx.xxx.168:5060 INVITE sip:[email protected] SIP/2.0. Record-Route: <sip:72.xxx.xxx.164;lr=on;ftag=as4f36ab60;did=36f.3f41d571>. Via: SIP/2.0/UDP 72.xxx.xxx.164;branch=z9hG4bK23ef.2faf83c4.0. Via: SIP/2.0/UDP 69.xxx.xxx.2:5060;received=69.xxx.xxx.2;branch=z9hG4bK03578afa;rport=5060. From: "Test" <sip:[email protected]>;tag=as4f36ab60. To: <sip:[email protected]>. Contact: <sip:[email protected]>. Call-ID: [email protected]. CSeq: 102 INVITE. User-Agent: None. Max-Forwards: 69. Remote-Party-ID: "Test" <sip:[email protected]>;privacy=off;screen=no. Date: Tue, 24 Aug 2010 12:01:35 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Type: application/sdp. Content-Length: 281. . v=0. o=root 2921 2921 IN IP4 69.xxx.xxx.2. s=session. c=IN IP4 69.xxx.xxx.2. t=0 0. m=audio 12570 RTP/AVP 18 0 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. U 72.xxx.xxx.168:5060 -> 72.xxx.xxx.164:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 72.xxx.xxx.164;branch=z9hG4bK23ef.2faf83c4.0. Via: SIP/2.0/UDP 69.xxx.xxx.2:5060;received=69.xxx.xxx.2;branch=z9hG4bK03578afa;rport=5060. From: "Test" <sip:[email protected]>;tag=as4f36ab60. To: <sip:[email protected]>. Call-ID: [email protected]. CSeq: 102 INVITE. Server: OpenSIPS (1.6.2-notls (i386/freebsd)). Content-Length: 0. . U 72.xxx.xxx.168:5060 -> 72.xxx.xxx.164:5060 SIP/2.0 302 Moved Temporarily. Via: SIP/2.0/UDP 72.xxx.xxx.164;branch=z9hG4bK23ef.2faf83c4.0. Via: SIP/2.0/UDP 69.xxx.xxx.2:5060;received=69.xxx.xxx.2;branch=z9hG4bK03578afa;rport=5060. From: "Test" <sip:[email protected]>;tag=as4f36ab60. To: <sip:[email protected]>;tag=1235203116. Call-ID: [email protected]. CSeq: 102 INVITE. Content-Type: application/csv. Contact: sip:rn=6024810000;npdi;[email protected]. User-Agent: eXosip/3.1.0. Content-Length: 0. . U 72.xxx.xxx.164:5060 -> 72.xxx.xxx.168:5060 ACK sip:[email protected] SIP/2.0. Via: SIP/2.0/UDP 72.xxx.xxx.164;branch=z9hG4bK23ef.2faf83c4.0. From: "Test" <sip:[email protected]>;tag=as4f36ab60. Call-ID: [email protected]. To: <sip:[email protected]>;tag=1235203116. CSeq: 102 ACK. Max-Forwards: 70. User-Agent: OpenSIPS (1.6.2-notls (x86_64/freebsd)). Content-Length: 0. . U 72.xxx.xxx.164:5060 -> 69.xxx.xxx.2:5060 SIP/2.0 503 No more routes Via: SIP/2.0/UDP 69.xxx.xxx.2:5060;branch=z9hG4bK03578afa;rport=5060. From: "Test" <sip:[email protected]>;tag=as4f36ab60. To: <sip:[email protected]>;tag=f254695ad980185f5ba46cc313375d56.4b85. Call-ID: [email protected]. CSeq: 102 INVITE. Server: OpenSIPS (1.6.2-notls (x86_64/freebsd)). Content-Length: 0. . U 72.xxx.xxx.164:5060 -> 69.xxx.xxx.2:5060 SIP/2.0 302 Moved Temporarily. Via: SIP/2.0/UDP 69.xxx.xxx.2:5060;received=69.xxx.xxx.2;branch=z9hG4bK03578afa;rport=5060. From: "Test" <sip:[email protected]>;tag=as4f36ab60. To: <sip:[email protected]>;tag=1235203116. Call-ID: [email protected]. CSeq: 102 INVITE. Content-Type: application/csv. Contact: sip:rn=6024810000;npdi;[email protected]. User-Agent: eXosip/3.1.0. Content-Length: 0. . U 69.xxx.xxx.2:5060 -> 72.xxx.xxx.164:5060 ACK sip:[email protected] SIP/2.0. Via: SIP/2.0/UDP 69.xxx.xxx.2:5060;branch=z9hG4bK03578afa;rport. From: "Test" <sip:[email protected]>;tag=as4f36ab60. To: <sip:[email protected]>;tag=f254695ad980185f5ba46cc313375d56.4b85. Contact: <sip:[email protected]>. Call-ID: [email protected]. CSeq: 102 ACK. User-Agent: None. Max-Forwards: 70. Remote-Party-ID: "Test" <sip:[email protected]>;privacy=off;screen=no. Content-Length: 0. . U 69.xxx.xxx.2:5060 -> 72.xxx.xxx.164:5060 ACK sip:[email protected] SIP/2.0. Via: SIP/2.0/UDP 69.xxx.xxx.2:5060;branch=z9hG4bK03578afa;rport. From: "Test" <sip:[email protected]>;tag=as4f36ab60. To: <sip:[email protected]>;tag=1235203116. Contact: <sip:[email protected]>. Call-ID: [email protected]. CSeq: 102 ACK. User-Agent: None. Max-Forwards: 70. Remote-Party-ID: "Test" <sip:[email protected]>;privacy=off;screen=no. Content-Length: 0. On Tue, 2010-08-24 at 10:57 +0300, Bogdan-Andrei Iancu wrote: > Hi Brad, > > Maybe I do not fully understand your case, but opensips is not sending a > 302 after 200 OK...Maybe you can post the call flow (a SIP trace) from > the SIP server showing the entire scenario. > > Regards, > Bogdan > > Brad Bendy wrote: > > Hi, > > > > Im having a heck of a time figuring this out: > > > > INVITE comes to our switch, we send a INVITE to another proxy that > > responds with a 302, we parse that 302 in failure route then use a > > route() command to go to another route block which does some other > > processing (will send out more INVITE's, do certain things on failure, > > etc), if the original call does get canceled or completes successfully > > with a 200 OK the originating proxy receives the original 302 request > > plus what ever our final failure response code we want to send. > > > > The behavior does seem correct as openSIPs is just forwarding the > > 302, but in this case I want it to send only the final response code > > back to the originating client. > > > > The initital route block which sends the INVITE to get the 302 is very > > simple, we just write the rU and rd and send via t_relay, > > onreply_route does a little parsing then failure_route sends to a new > > block. > > > > Any help on this would be great, I think it's my logic in the switch > > that is wrong somewhere. > > > > Thanks! > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Users mailing list > > [email protected] > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > -- Brad Bendy Chief Technical Officer [email protected] Benga Networks, LLC. 10115 E. Bell Rd, Ste. 107-451 Scottsdale, AZ 85260-2189 Toll Free: 877-44-BENGA Local: 480-970-5200 Cell: 602-550-4004 Fax: 866-852-4468
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
