<div dir="ltr">Thanks a lot for your explanation, Ben! I thought that there can be an issue with Server A not accepting  my new SIP response, it looks like they're doing matching only based on SIP To tag and completely ignoring any Call-ID or DID matching as well as From tag matching, in my case From tag is always the same.<div><br></div><div>One more question, how do you think, can there be anything related with topology hiding I'm using? I really doubt that but just in case...As far as I understand my issue is not because I'm using topology hiding, but because OpenSIPS first passes To tag from remote server and then generates one by itself when I'm using a 't_reply' and Server A is just not accepting such behaviour, trying to match any SIP responses to To tag passed in 183 Session Progress. I tried to change topology_hiding() to loose_route() and nothing changed in my chain except for Server A now being able to see all RRs and Vias inside my network.</div><div><br></div><div>Regards,</div><div>Yury.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 27 мар. 2020 г. в 01:37, Yury Kirsanov <<a href="mailto:y.kirsanov@gmail.com">y.kirsanov@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">But the question is still here - how can I send a different t_reply code from failure_route? And then stop processing any further SIP messages?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 27 мар. 2020 г. в 01:23, Yury Kirsanov <<a href="mailto:y.kirsanov@gmail.com" target="_blank">y.kirsanov@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The problem is that I need to go through a list of SIP servers, analyze response of each of them and if it's an error like 4XX, 5XX or 6XX I need to send appropriate response to originating server. Let's say I'm not only adding a Reason field but upon receipt of 404 Not Found I want to respond with 480 Temporarily Unavailable with Reason: Q.850;Cause=41 for example? But Server B first replied with 183 Session Progress playing back a message 'Sorry, you need to top up your account' and then replied with SIP 402 Payment Required. I had to proxy 183 Session Progress back to Server A so its SIP client could hear that message and then I'd like to signal 480 Temporarily Unavailable - but I can't as OpenSIPS is using completely different To tag.<div><br></div><div>I can't do this in onreply_route as I'm going through a list of SIP servers (upstreams or downstreams), so it definitely needs to be done from failure route, as far as I understand, and yes, I'm matching against 4XX, 5XX and 6XX codes and I need to reply with 480 Temporarily Unavailable in most cases so Server A would have a possibility to do failover to any other server in that case. I don't want to just proxy 4XX, 5XX or 6XX response to it.</div><div><br></div><div>I've figured out why I have two 404 responses in my original call log - I was using sl_send_reply instead of t_reply and it was using original To tag but only on second attempt.</div><div><br></div><div>Regards,</div><div>Yury.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 27 мар. 2020 г. в 01:02, Yury Kirsanov <<a href="mailto:y.kirsanov@gmail.com" target="_blank">y.kirsanov@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div>As per my original email:</div><div>1. I was doing exactly as you suggested, in failure_route I'm using t_reply("404","Not Found") and it comes out with a wrong To: tag.</div><div>2. I don't need to proxy response from server B, I need to analyze its response and send a response to server A according to my needs.</div><div><br></div><div>Currently it seems that t_reply is not using same To tag if 183 Session Progress has been proxied, which is strange as I have dialog running.</div><div><br></div><div>Regards,</div><div>Yury.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 26 мар. 2020 г. в 19:13, Yury Kirsanov <<a href="mailto:y.kirsanov@gmail.com" target="_blank">y.kirsanov@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div>I'm using an OpenSIPS as a proxy between two servers. First one is sending SIP INVITE to OpenSIPS, then OpenSIPS forwards request to second server. I'm creating a dialog on initial INVITE. Second server then replies with SIP 183 Session Progress, plays back a message and then responds with 4XX code, for example SIP 404 Not Found (indicating that number dialed is disconnected). In OpenSIPS I'm receiving that reply and in failure_route I'd like to change that code to a bit different SIP 404, so I'm using following code:</div><div><br></div><div>append_to_reply("Reason: Q.850;cause=1");</div><div>t_reply("404","Not Found");</div><div>exit;</div><div><br></div><div>But in this case I can see that OpenSIPS generates additional branch (??? not sure here) with different "To" tag and pushes it out and then forwards original reply SIP packet even though I have an exit statement in my failure_route. I tried to do sl_send_reply and behavior is pretty much the same. Can someone let me know what I may be doing wrong? I need correct "To" tag to be used (based on 183 Session Progress message from server B and passed to server A previously) and second 404 shouldn't be forwarded out.</div><div><br></div><div>Here's an example of a call with my explanations</div><div><br></div><div>Initial invite from server A, no 'to tag' as expected:</div><div><br></div><div>INVITE sip:XXXXXXXXX@B.B.B.B SIP/2.0<br>Max-Forwards: 67<br>To: "XXXXXXXXX" <sip:XXXXXXXXX@B.B.B.B><br>Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA<br>Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538<br>From: "YYYYYYYYY" <sip:YYYYYYYYY@A.A.A.A>;tag=117583367<br>CSeq: 1741310 INVITE<br>User-Agent: User Agent<br>Contact: <sip:YYYYYYYYY@A.A.A.A:5060><br>Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, SUBSCRIBE, NOTIFY<br>Date: Thu, 26 Mar 2020 07:54:55 GMT<br>Content-Type: application/sdp<br>Content-Length: 250<br><br>v=0<br>o=dcom 1585209295 1585209295 IN IP4 A.A.A.A<br>s=SIP Call<br>c=IN IP4 A.A.A.A<br>t=0 0<br>m=audio 15340 RTP/AVP 8 0 18 101<br>a=rtpmap:8 PCMA/8000<br>a=rtpmap:0 PCMU/8000<br>a=rtpmap:18 G729/8000<br>a=fmtp:18 annexb=no<br>a=rtpmap:101 telephone-event/8000<br><br>Response from OpenSIPS:</div><div><br>SIP/2.0 100 Giving a try<br>To: "XXXXXXXXX" <sip:XXXXXXXXX@B.B.B.B><br>Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA<br>Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538<br>From: "YYYYYYYYY" <sip:YYYYYYYYY@A.A.A.A>;tag=117583367<br>CSeq: 1741310 INVITE<br>Server: Server Signature<br>Content-Length: 0<br><br>OpenSIPS has forwarded packet to Server B and Server B responded with 183 and assigned a 'To' tag:</div><div><br>SIP/2.0 183 Session Progress<br>Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538<br>Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA<br>From: "YYYYYYYYY" <sip:YYYYYYYYY@A.A.A.A>;tag=117583367<br>To: "XXXXXXXXX" <sip:XXXXXXXXX@B.B.B.B>;<font size="4" color="#ff0000"><b>tag=0b49dc32-2c4b-413e-a349-c781a23d53b9</b></font><br>CSeq: 1741310 INVITE<br>Server: PBX<br>Contact: <sip:B.B.B.B;did=d0a.99678f73><br>Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER<br>Content-Type: application/sdp<br>Content-Length: 354<br><br>v=0<br>o=- 1585209295 1585209297 IN IP4 B.B.B.B<br>s=Asterisk<br>c=IN IP4 B.B.B.B<br>t=0 0<br>a=rtpengine:673f999268ae<br>m=audio 32386 RTP/AVP 0 8 18 101<br>a=maxptime:150<br>a=rtpmap:0 PCMU/8000<br>a=rtpmap:8 PCMA/8000<br>a=rtpmap:18 G729/8000<br>a=rtpmap:101 telephone-event/8000<br>a=fmtp:18 annexb=no<br>a=fmtp:101 0-16<br>a=sendrecv<br>a=rtcp:32387<br>a=ptime:20<br><br>Server B responds with SIP 404 after playing back message that number is disconnected and I'm trying to reply to server A with custom Reason message. To_tag is completely different from the To tag that has been passed to server A after initial 183!!!<br><br>SIP/2.0 404 Not Found<br>To: "XXXXXXXXX" <sip:XXXXXXXXX@B.B.B.B>;<font size="4" color="#0000ff"><b>tag=a976.21514595b467be41a9b712a6b0b621d9</b></font><br>Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA<br>Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538<br>From: "YYYYYYYYY" <sip:YYYYYYYYY@A.A.A.A>;tag=117583367<br>CSeq: 1741310 INVITE<br>Reason: Q.850;cause=1;text="Number is disconnected"<br>Server: Server Signature<br>Content-Length: 0<br><br>Of course, server A just ignores this message as it can't match 'To' tag to its transaction. Now, for some reason, OpenSIPS forwards original reply from Server B to Server A with the same 'To' tag as in 183 Session Progress:</div><div><br></div><div>SIP/2.0 404 Not Found<br>Via: SIP/2.0/UDP A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538<br>Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA<br>From: "YYYYYYYYY" <sip:YYYYYYYYY@A.A.A.A>;tag=117583367<br>To: "XXXXXXXXX" <sip:XXXXXXXXX@B.B.B.B>;<font size="4" color="#ff0000"><b>tag=0b49dc32-2c4b-413e-a349-c781a23d53b9</b></font><br>CSeq: 1741310 INVITE<br>Server: PBX<br>Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER<br>Reason: Q.850;cause=1<br>Content-Length:  0<br><br>And at this point Server A can match this reply and responds with an ACK:</div><div><br>ACK sip:XXXXXXXXX@B.B.B.B SIP/2.0<br>Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538<br>From: "YYYYYYYYY" <sip:YYYYYYYYY@A.A.A.A>;tag=117583367<br>To: "XXXXXXXXX" <sip:XXXXXXXXX@B.B.B.B>;<b><font size="4" color="#ff0000">tag=0b49dc32-2c4b-413e-a349-c781a23d53b9</font></b><br>Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA<br>CSeq: 1741310 ACK<br>Max-Forwards: 67<br>Contact: <sip:YYYYYYYYY@A.A.A.A:5060><br>User-Agent: User Agent<br>Content-Length: 0<br></div><div><br></div><div>I think that t_reply is creating a new transaction instead of using existing one, but I'm not sure why and how to fix this?</div><div><br></div><div>Thanks!</div><div><br></div><div>Best regards,</div><div>Yury.</div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>