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

Thu Mar 26 14:46:28 EST 2020

I see. If that is your need then you will get a new tag. As far as I know it would be a feature enhancement to change that behavior, though someone from OpenSIPS team may need to check me on that. It is operating within the RFC for this [1]:

When the proxy is aggregating information from several
responses, choosing a To tag from among them is arbitrary, and
generating a new To tag may make debugging easier.  This
happens, for instance, when combining 401 (Unauthorized) and
407 (Proxy Authentication Required) challenges, or combining
Contact values from unencrypted and unauthenticated 3xx
responses.

Receiving a final reply with a different To tag than a provisional reply is allowed and must be handled by Server A in order to accommodate SIP forking of messages. Server A is operating out of spec by refusing to accept the final reply because of the different To tag. The tags are only used to uniquely identify a Dialog, and the 183 response does not establish a dialog, nor does a 4xx response. [2]

The forking of SIP requests means that multiple dialogs can
be established from a single request.

[1] - https://tools.ietf.org/html/rfc3261#section-16.7
[2] - https://tools.ietf.org/html/rfc3261#section-19.3

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 10:25 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Issue with 'To' tag and t_reply

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.kirsanov at gmail.com<mailto:y.kirsanov at 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.kirsanov at gmail.com<mailto:y.kirsanov at 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 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/2de4db37/attachment-0001.html>