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

Thu Mar 26 14:37:25 EST 2020

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>:

> 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>:
>
>> 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>:
>>
>>> 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/20200327/585e6f66/attachment-0001.html>