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

Mon Apr 6 13:24:10 EST 2020

Unfortunately I don’t think I can provide any further assistance. As far as I know Server A is still operating out of spec. The receipt of the 183 with To tag does establish an *early* dialog, but nowhere does that mandate that the server must stop receiving responses from any other dialog. Servers must be tolerant of downstream forking of SIP calls by proxies (like OpenSIPS) and until the final response is received they must be able to receive multiple provisional responses potentially with different To tags.

As I said before, on the OpenSIPS side there really is no way to solve this well. If OpenSIPS forks a call and receives multiple provisional responses from different downstream servers, how would it choose one to send back upstream? How could it know that is the one that will eventually answer? It can’t, so it sends them upstream as is and the UAC must handle it. When it needs to send a message it is operating per the RFC which recommends creating your own tag rather than randomly choosing a downstream tag which may or may not be the final responder.

I suppose some enhancements could be made to make it work in your specific case, where you do not have multiple downstream legs, but personally I don’t feel it would be worth the added complication. But that would be up to the OpenSIPS maintainers.

The only thing I can think that you could do to workaround the issue with Server A is to drop all provisional responses and only provide the final response, because you can’t guarantee until the final response what the final To tag will be.

Also, I will say that we do failover just like this in our OpenSIPS. We relay provisional responses as they come and we relay final responses, sometimes coming from different downstream servers due to failover. And sometimes we send the response ourselves. We’ve never had an issue with an upstream server complaining about the tag changing.

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: Monday, April 6, 2020 at 12:05 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Issue with 'To' tag and t_reply

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