Hi Ben, The problem we're facing now is that according to RFC3261 dialog is established after 183 Session Progress with a To tag, so Server A can't continue to receive out-of-dialog SIP messages. In this case we're unable to send a OpenSIPS-generated message with different To tag which occurs in my situation. Is there any way to resolve this situation? It looks to me that behaviour of Server A is correct as OpenSIPS acts as a proxy and passes messages from Server B and then suddenly injects a SIP message originated by itself. Looks like there has to be two 'legs' of the call, one between Server A and OpenSIPS and another one between OpenSIPS and multiple servers it tries to reach in order to establish the call, but in this case OpenSIPS can't act as a pure proxy. Please advise?
Thanks!. P.S. For some reason I'm not receiving your responses in my mailbox? пт, 27 мар. 2020 г. в 01:56, Yury Kirsanov <y.kirsa...@gmail.com>: > 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. > > 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. > > Regards, > Yury. > > пт, 27 мар. 2020 г. в 01:37, Yury Kirsanov <y.kirsa...@gmail.com>: > >> 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? >> >> пт, 27 мар. 2020 г. в 01:23, Yury Kirsanov <y.kirsa...@gmail.com>: >> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> Regards, >>> Yury. >>> >>> пт, 27 мар. 2020 г. в 01:02, Yury Kirsanov <y.kirsa...@gmail.com>: >>> >>>> Hi, >>>> As per my original email: >>>> 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. >>>> 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. >>>> >>>> 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. >>>> >>>> Regards, >>>> Yury. >>>> >>>> чт, 26 мар. 2020 г. в 19:13, Yury Kirsanov <y.kirsa...@gmail.com>: >>>> >>>>> Hi, >>>>> 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: >>>>> >>>>> append_to_reply("Reason: Q.850;cause=1"); >>>>> t_reply("404","Not Found"); >>>>> exit; >>>>> >>>>> 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. >>>>> >>>>> Here's an example of a call with my explanations >>>>> >>>>> Initial invite from server A, no 'to tag' as expected: >>>>> >>>>> INVITE sip:XXXXXXXXX@B.B.B.B SIP/2.0 >>>>> Max-Forwards: 67 >>>>> To: "XXXXXXXXX" <sip:XXXXXXXXX@B.B.B.B> >>>>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>>>> Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 >>>>> From: "YYYYYYYYY" <sip:YYYYYYYYY@A.A.A.A>;tag=117583367 >>>>> CSeq: 1741310 INVITE >>>>> User-Agent: User Agent >>>>> Contact: <sip:YYYYYYYYY@A.A.A.A:5060> >>>>> Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, >>>>> SUBSCRIBE, NOTIFY >>>>> Date: Thu, 26 Mar 2020 07:54:55 GMT >>>>> Content-Type: application/sdp >>>>> Content-Length: 250 >>>>> >>>>> v=0 >>>>> o=dcom 1585209295 1585209295 IN IP4 A.A.A.A >>>>> s=SIP Call >>>>> c=IN IP4 A.A.A.A >>>>> t=0 0 >>>>> m=audio 15340 RTP/AVP 8 0 18 101 >>>>> a=rtpmap:8 PCMA/8000 >>>>> a=rtpmap:0 PCMU/8000 >>>>> a=rtpmap:18 G729/8000 >>>>> a=fmtp:18 annexb=no >>>>> a=rtpmap:101 telephone-event/8000 >>>>> >>>>> Response from OpenSIPS: >>>>> >>>>> SIP/2.0 100 Giving a try >>>>> To: "XXXXXXXXX" <sip:XXXXXXXXX@B.B.B.B> >>>>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>>>> Via: SIP/2.0/UDP >>>>> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >>>>> From: "YYYYYYYYY" <sip:YYYYYYYYY@A.A.A.A>;tag=117583367 >>>>> CSeq: 1741310 INVITE >>>>> Server: Server Signature >>>>> Content-Length: 0 >>>>> >>>>> OpenSIPS has forwarded packet to Server B and Server B responded with >>>>> 183 and assigned a 'To' tag: >>>>> >>>>> SIP/2.0 183 Session Progress >>>>> Via: SIP/2.0/UDP >>>>> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >>>>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>>>> From: "YYYYYYYYY" <sip:YYYYYYYYY@A.A.A.A>;tag=117583367 >>>>> To: "XXXXXXXXX" <sip:XXXXXXXXX@B.B.B.B>; >>>>> *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* >>>>> CSeq: 1741310 INVITE >>>>> Server: PBX >>>>> Contact: <sip:B.B.B.B;did=d0a.99678f73> >>>>> Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, >>>>> BYE, CANCEL, UPDATE, PRACK, REFER >>>>> Content-Type: application/sdp >>>>> Content-Length: 354 >>>>> >>>>> v=0 >>>>> o=- 1585209295 1585209297 IN IP4 B.B.B.B >>>>> s=Asterisk >>>>> c=IN IP4 B.B.B.B >>>>> t=0 0 >>>>> a=rtpengine:673f999268ae >>>>> m=audio 32386 RTP/AVP 0 8 18 101 >>>>> a=maxptime:150 >>>>> a=rtpmap:0 PCMU/8000 >>>>> a=rtpmap:8 PCMA/8000 >>>>> a=rtpmap:18 G729/8000 >>>>> a=rtpmap:101 telephone-event/8000 >>>>> a=fmtp:18 annexb=no >>>>> a=fmtp:101 0-16 >>>>> a=sendrecv >>>>> a=rtcp:32387 >>>>> a=ptime:20 >>>>> >>>>> 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!!! >>>>> >>>>> SIP/2.0 404 Not Found >>>>> To: "XXXXXXXXX" <sip:XXXXXXXXX@B.B.B.B>; >>>>> *tag=a976.21514595b467be41a9b712a6b0b621d9* >>>>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>>>> Via: SIP/2.0/UDP >>>>> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >>>>> From: "YYYYYYYYY" <sip:YYYYYYYYY@A.A.A.A>;tag=117583367 >>>>> CSeq: 1741310 INVITE >>>>> Reason: Q.850;cause=1;text="Number is disconnected" >>>>> Server: Server Signature >>>>> Content-Length: 0 >>>>> >>>>> 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: >>>>> >>>>> SIP/2.0 404 Not Found >>>>> Via: SIP/2.0/UDP >>>>> A.A.A.A:5060;received=A.A.A.A;rport=5060;branch=z9hG4bK773616538 >>>>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>>>> From: "YYYYYYYYY" <sip:YYYYYYYYY@A.A.A.A>;tag=117583367 >>>>> To: "XXXXXXXXX" <sip:XXXXXXXXX@B.B.B.B>; >>>>> *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* >>>>> CSeq: 1741310 INVITE >>>>> Server: PBX >>>>> Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, >>>>> BYE, CANCEL, UPDATE, PRACK, REFER >>>>> Reason: Q.850;cause=1 >>>>> Content-Length: 0 >>>>> >>>>> And at this point Server A can match this reply and responds with an >>>>> ACK: >>>>> >>>>> ACK sip:XXXXXXXXX@B.B.B.B SIP/2.0 >>>>> Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538 >>>>> From: "YYYYYYYYY" <sip:YYYYYYYYY@A.A.A.A>;tag=117583367 >>>>> To: "XXXXXXXXX" <sip:XXXXXXXXX@B.B.B.B>; >>>>> *tag=0b49dc32-2c4b-413e-a349-c781a23d53b9* >>>>> Call-ID: 469A5568-E092-4038-B1B8-13AC9B9571CA >>>>> CSeq: 1741310 ACK >>>>> Max-Forwards: 67 >>>>> Contact: <sip:YYYYYYYYY@A.A.A.A:5060> >>>>> User-Agent: User Agent >>>>> Content-Length: 0 >>>>> >>>>> 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? >>>>> >>>>> Thanks! >>>>> >>>>> Best regards, >>>>> Yury. >>>>> >>>>
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users