[OpenSIPS-Users] Issue with 'To' tag and t_reply
Yury Kirsanov
y.kirsanov at gmail.com
Mon Apr 6 04:04:08 EST 2020
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>:
> 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>:
>
>> 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/20200406/01554b7a/attachment-0001.html>
More information about the Users
mailing list