[OpenSIPS-Users] Issue with 'To' tag and t_reply

[Ben Newlin]

You don’t have to call t_reply from failure_route. The default action of failure_route is already to relay the response back upstream [1], unless you created a new branch. Simply call append_to_reply and then exit. It is the t_reply call that is confusing things.

[1] - https://www.opensips.org/Documentation/Script-Routes-2-4#toc3

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of Yury Kirsanov <y.kirsanov at gmail.com>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: Thursday, March 26, 2020 at 4:15 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: [OpenSIPS-Users] Issue with 'To' tag and t_reply

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 at B.B.B.B SIP/2.0
Max-Forwards: 67
To: "XXXXXXXXX" <sip:XXXXXXXXX at 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 at A.A.A.A>;tag=117583367
CSeq: 1741310 INVITE
User-Agent: User Agent
Contact: <sip:YYYYYYYYY at 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 at 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 at 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 at A.A.A.A>;tag=117583367
To: "XXXXXXXXX" <sip:XXXXXXXXX at 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 at 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 at 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 at A.A.A.A>;tag=117583367
To: "XXXXXXXXX" <sip:XXXXXXXXX at 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 at B.B.B.B SIP/2.0
Via: SIP/2.0/UDP A.A.A.A:5060;rport;branch=z9hG4bK773616538
From: "YYYYYYYYY" <sip:YYYYYYYYY at A.A.A.A>;tag=117583367
To: "XXXXXXXXX" <sip:XXXXXXXXX at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200326/5dba3471/attachment-0001.html>