[SR-Users] bug ? remap_503_500 breaks dialogs
Daniel-Constantin Mierla
miconda at gmail.com
Thu Jul 23 16:08:25 CEST 2020
Hello,
there is no call at that moment, it is a routing-in-progress for the
initial INVITE. The proxy can cancel the outgoing branch that returned
the 183, send to another target address (e.g., call hunting scenario)
which comes back with another 183 and different to-tag, or if the second
target does not send any reply, then proxy generates itself a 408 reply
-- just to give an example of a possible valid scenario.
So, the To-tag is used to identify requests within an established dialog
or to terminate a proxy-created branch in early phase. It is not used to
match the reply for initial INVITE transaction -- for that purpose the
branch parameter of first via should be used by calling UA.
A call is terminated by a BYE and there to-tag matters indeed. But a
transaction is not identified by using to-tag.
Cheers,
Daniel
On 23.07.20 14:41, Gerry | Rigatta wrote:
> Hi Daniel,
>
> thanks for looking into this.
>
> The initial INVITE does not have a to-tag but there is an intermediate
> session progress with a to-tag. See grep below.
>
> The RFC does not distinguish between established or provisional
> dialogs when it comes to the handling of the to-tags. If there is a
> to-tag it must not be changed by the Proxy. Clearly that must be so
> because the to-tag is used by the UAC to identify the call.
>
> Best Gerry
>
>
> IP addresses are changed in below dialog for security reasons
>
> U 7.7.23.109:5060 -> 11.22.17.24:5060 #5
> INVITE sip:111100791456321475 at 13.23.9.94:5060 SIP/2.0..Max-Forwards: 19.
> .P-Asserted-Identity: tel:+4867777777..Via: SIP/2.0/UDP 7.7.23.109:5060
> ;rport;branch=z9hG4bK1682611991..From: "004867777777"
> <sip:004867777777 at 7
> 8.47.203.109>;tag=540342132..To: <sip:111100791456321475 at 13.23.9.94:5060
> >..Call-ID: 1279305029 at 7.7.23.109
> <mailto:1279305029 at 7.7.23.109>..CSeq: 1 INVITE..User-Agent: nulltech.
> .Contact: <sip:004867777777 at 7.7.23.109:5060>..Allow: ACK, INVITE, BYE,
> CANCEL, REGISTER, REFER, OPTIONS, PRACK, INFO..Supported:
> 100rel..Content-T
> ype: application/sdp..Content-Length: 209....v=0..o=yate 1595505273
> 1595505
> 273 IN IP4 7.7.23.109..s=SIP Call..c=IN IP4 7.7.23.109..t=0 0..m=audi
> o 28610 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap:0
> PCMU/8000..a=rtpm
> ap:101 telephone-event/8000..
>
> #
> U 11.22.17.24:5060 -> 7.7.23.109:5060 #6
> SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP
> 78.47.
> 203.109:5060;rport=5061;branch=z9hG4bK1682611991;received=7.7.23.109..Fr
> om: "004867777777" <sip:004867777777 at 7.7.23.109>;tag=540342132..To: <s
> ip:111100791456321475 at 13.23.9.94
> <mailto:111100791456321475 at 13.23.9.94>:5060>..Call-ID:
> 1279305029 at 7.7.23.10 <mailto:1279305029 at 7.7.23.10>
> 9..CSeq: 1 INVITE..Server: kamailio (5.2.3
> (x86_64/linux))..Content-Length:
> 0....
>
> #
> U 11.22.17.24:5060 -> 13.23.9.94:5060 #7
> INVITE sip:111100791456321475 at 13.23.9.94:5060 SIP/2.0..Record-Route: <si
> p:11.22.17.24:5060;lr=on>..Max-Forwards: 18..P-Asserted-Identity: tel:+
> 4867777777..Via: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d4.f1e37
> b7feb047b6707c5fb8a298d36fc.0..Via: SIP/2.0/UDP 7.7.23.109:5060;received
> =7.7.23.109;rport=5061;branch=z9hG4bK1682611991..From: "004867777777" <
> sip:004867777777 at 7.7.23.109>;tag=540342132..To: <sip:111100791456321475
> @13.23.9.94:5060>..Call-ID: 1279305029 at 7.7.23.109
> <mailto:1279305029 at 7.7.23.109>..CSeq: 1 INVITE..Us
> er-Agent: nulltech..Contact: <sip:004867777777 at 7.7.23.109:5060>..Allow:
> ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, PRACK,
> INFO..Supported
> : 100rel..Content-Type: application/sdp..Content-Length:
> 209....v=0..o=yate
> 1595505273 1595505273 IN IP4 7.7.23.109..s=SIP Call..c=IN IP4 7.7.23
> .109..t=0 0..m=audio 28610 RTP/AVP 8 0 101..a=rtpmap:8
> PCMA/8000..a=rtpmap:
> 0 PCMU/8000..a=rtpmap:101 telephone-event/8000..
>
> #
> U 13.23.9.94:5060 -> 11.22.17.24:5060 #8
> SIP/2.0 100 Trying..Via: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d
> 4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24..Via: SIP/2.0
> /UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;branch=z9hG4bK168
> 2611991..Record-Route: <sip:11.22.17.24:5060;lr=on>..From: "00371673360
> 58" <sip:004867777777 at 7.7.23.109>;tag=540342132..To: <sip:1111007914563
> 21475 at 13.23.9.94 <mailto:21475 at 13.23.9.94>:5060>..Call-ID:
> 1279305029 at 7.7.23.109 <mailto:1279305029 at 7.7.23.109>..CSeq: 1 INVIT
> E..User-Agent: Ravetel SIP proxy..Allow: INVITE, ACK, CANCEL,
> OPTIONS, BYE,
> REFER, SUBSCRIBE, NOTIFY, INFO..Supported: replaces..Contact:
> <sip:1111007
> 91456321475 at 13.23.9.94
> <mailto:91456321475 at 13.23.9.94>:5060>..Content-Length: 0....
>
> #
> U 13.23.9.94:5060 -> 11.22.17.24:5060 #9
> SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 11.22.17.24:5060;branch=
> z9hG4bK58d4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24..Vi
> a: SIP/2.0/UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;branch=
> z9hG4bK1682611991..Record-Route: <sip:11.22.17.24:5060;lr=on>..From: "0
> 04867777777" <sip:004867777777 at 7.7.23.109>;tag=540342132..To: <sip:103
> 000791456321475 at 13.23.9.94
> <mailto:000791456321475 at 13.23.9.94>:5060>;tag=as6d86b4e8..Call-ID:
> 1279305029 at 78.
> 47.203.109..CSeq: 1 INVITE..User-Agent: Ravetel SIP proxy..Allow:
> INVITE, A
> CK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO..Supported:
> replac
> es..Contact: <sip:111100791456321475 at 13.23.9.94:5060>..Content-Type: app
> lication/sdp..Content-Length: 235....v=0..o=root 714 714 IN IP4
> 136.243.29.
> 94..s=session..c=IN IP4 13.23.9.94..t=0 0..m=audio 10454 RTP/AVP 8 0 101
> ..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:101
> telephone-event/
> 8000..a=fmtp:101 0-16..a=ptime:20..a=sendrecv..
>
> #
> U 11.22.17.24:5060 -> 7.7.23.109:5060 #10
> SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 7.7.23.109:5060;received=
> 7.7.23.109;rport=5061;branch=z9hG4bK1682611991..Record-Route: <sip:116.2
> 02.187.204:5060;lr=on>..From: "004867777777" <sip:004867777777 at 7.7.23.
> 109>;tag=540342132..To: <sip:111100791456321475 at 13.23.9.94:5060>;tag=as6
> d86b4e8..Call-ID: 1279305029 at 7.7.23.109
> <mailto:1279305029 at 7.7.23.109>..CSeq: 1 INVITE..User-Agent: Ravet
> el SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
> NOTIFY, INFO..Supported: replaces..Contact:
> <sip:111100791456321475 at 136.24
> 3.29.94:5060>..Content-Type: application/sdp..Content-Length:
> 235....v=0..o
> =root 714 714 IN IP4 13.23.9.94..s=session..c=IN IP4 13.23.9.94..t=0
> 0..m=audio 10454 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap:0
> PCMU/800
> 0..a=rtpmap:101 telephone-event/8000..a=fmtp:101
> 0-16..a=ptime:20..a=sendre
> cv..
>
> #
>
> U 13.23.9.94:5060 -> 11.22.17.24:5060 #39
> SIP/2.0 503 Service Unavailable..Via: SIP/2.0/UDP 11.22.17.24:5060;bran
> ch=z9hG4bK58d4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24.
> .Via: SIP/2.0/UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;bran
> ch=z9hG4bK1682611991..From: "004867777777" <sip:004867777777 at 7.7.23.10
> 9>;tag=540342132..To: <sip:111100791456321475 at 13.23.9.94:5060>;tag=as6d8
> 6b4e8..Call-ID: 1279305029 at 7.7.23.109
> <mailto:1279305029 at 7.7.23.109>..CSeq: 1 INVITE..User-Agent: Ravet
> el SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
> SUBSCRIBE, N
> OTIFY, INFO..Supported: replaces..X-Asterisk-HangupCause: Call
> Rejected..X-
> Asterisk-HangupCauseCode: 21..Content-Length: 0....
>
> #
> U 11.22.17.24:5060 -> 13.23.9.94:5060 #40
> ACK sip:111100791456321475 at 13.23.9.94:5060 SIP/2.0..Max-Forwards: 18..Vi
> a: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d4.f1e37b7feb047b6707c5
> fb8a298d36fc.0..From: "004867777777" <sip:004867777777 at 7.7.23.109>;tag
> =540342132..To: <sip:111100791456321475 at 13.23.9.94:5060>;tag=as6d86b4e8.
> .Call-ID: 1279305029 at 7.7.23.109
> <mailto:1279305029 at 7.7.23.109>..CSeq: 1 ACK..Content-Length: 0....
> #
> U 11.22.17.24:5060 -> 7.7.23.109:5060 #41
> SIP/2.0 500 Service Unavailable..Via: SIP/2.0/UDP 7.7.23.109:5060;rport=
> 5061;branch=z9hG4bK1682611991;received=7.7.23.109..From: "004867777777"
> <sip:004867777777 at 7.7.23.109>;tag=540342132..To: <sip:1111007914563214
> 75 at 13.23.9.94
> <mailto:75 at 13.23.9.94>:5060>;tag=95329101123423eab1637e9ad490b3a6-9d3c..Call-ID:
> 1279305029 at 7.7.23.109 <mailto:1279305029 at 7.7.23.109>..CSeq: 1
> INVITE..Server: kamailio (5.2.3 (x86_64/l
> inux))..Content-Length: 0....
>
> #
> U 11.22.17.24:5060 -> 7.7.23.109:5060 #42
> SIP/2.0 500 Service Unavailable..Via: SIP/2.0/UDP 7.7.23.109:5060;rport=
> 5061;branch=z9hG4bK1682611991;received=7.7.23.109..From: "004867777777"
> <sip:004867777777 at 7.7.23.109>;tag=540342132..To: <sip:1111007914563214
> 75 at 13.23.9.94
> <mailto:75 at 13.23.9.94>:5060>;tag=95329101123423eab1637e9ad490b3a6-9d3c..Call-ID:
> 1279305029 at 7.7.23.109 <mailto:1279305029 at 7.7.23.109>..CSeq: 1
> INVITE..Server: kamailio (5.2.3 (x86_64/l
> inux))..Content-Length: 0....
>
> #
>
>
>> On 23 Jul 2020, at 10:51, Daniel-Constantin Mierla <miconda at gmail.com
>> <mailto:miconda at gmail.com>> wrote:
>>
>> Did the initial INVITE received the 200ok, the call is connected and
>> this is the case of a re-INVITE? In such case the dialog has to be
>> terminated by a BYE.
>>
>> If the call is not established, so it is between initial INVITE and
>> no 200ok was received, then the INVITE request did not contain the
>> To-tag. And what is done by Kamailio is valid as per email responses
>> so far.
>>
>> Maybe you can just send the ngrep output with all sip
>> requests/replies for this case and we can see exactly which scenario
>> you talk about.
>>
>> Cheers,
>> Daniel
>>
>> On 23.07.20 09:41, Gerry | Rigatta wrote:
>>>>
>>>> Indeed, at this stage there is no dialog established and there can
>>>> be many To-tags in 1xx provisional responses (eg, a parallel
>>>> forking scenario) -- the to-tag of the dialog has to be taken from
>>>> 200ok.
>>>>
>>> As far as I read this is not correct. Also a provisional dialog is a
>>> dialog according to RFC3261. Only in the case that the request did
>>> not contain a to-tag the provisional messages may insert their own
>>> to-tags:
>>>
>>> "1xx and 2xx responses may be involved in the establishment of
>>> dialogs. When a request does not contain a To tag, the To tag
>>> in the response is used by the UAC to distinguish multiple
>>> responses to a dialog creating request. A proxy MUST NOT
>>> insert a tag into the To header field of a 1xx or 2xx response
>>> if the request did not contain one. A proxy MUST NOT modify
>>> the tag in the To header field of a 1xx or 2xx response.”
>>> https://tools.ietf.org/html/rfc3261#page-111
>>>
>>> In any case, this bug is not a about provisional messages. The 500
>>> message terminates the dialog for the UAC (yate) and the UAC needs
>>> to be able to identify it. An UAC identifies the dialog by the
>>> call-id, local tag and remote tag.
>>>
>>>>>
>>>>> 12<https://tools.ietf.org/html/rfc3261#section-12> Dialogs
>>>>>
>>>>>
>>>>> A dialog is identified at each UA with a dialog ID, which
>>>>> consists of a Call-ID value, a local tag and a remote tag…"
>>>>>
>>>
>>>
>>>> On 23 Jul 2020, at 10:07, Daniel-Constantin Mierla
>>>> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>>>
>>>> Indeed, at this stage there is no dialog established and there can
>>>> be many To-tags in 1xx provisional responses (eg, a parallel
>>>> forking scenario) -- the to-tag of the dialog has to be taken from
>>>> 200ok.
>>>>
>>>> This parameter is probably to have a shortcut of doing:
>>>>
>>>> failure_route[REMAP503] {
>>>>
>>>> if(t_check_status("503")) {
>>>>
>>>> t_reply("500", "Server error");
>>>> exit;
>>>>
>>>> }
>>>>
>>>> Being like the server application is generating the 500 (so using
>>>> own tag), instead of forwarding the 503. Not a bug, but if anyone
>>>> is willing to add an option to allow re-using the to-tag from
>>>> received reply, I am fine with it.
>>>>
>>>> Anyhow, even if this would be fixed, I am wondering how yate is
>>>> going to work in parallel/serial forking scenarios where different
>>>> to-tags flow for a while and the final failure response can have
>>>> any to-tag, including a new one (e.g., from a device not sending
>>>> any 1xx or again from kamailio (e.g., when last target doesn't
>>>> reply at all)).
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>> On 23.07.20 06:08, M S wrote:
>>>>> The SIP code 503 is tricky in the sense that i can indicate either
>>>>> server maintenance or server overload. In both cases it can send
>>>>> Retry-After header and any subsequent requests from same source
>>>>> are ignored for the duration of Retry-After interval. [1].
>>>>>
>>>>> Additionally RFC3261 and RFC3263 define that transport failures
>>>>> (generally due to fatal ICMP errors in UDP and connection failures
>>>>> in TCP) should be treated as 503 response. [2].
>>>>>
>>>>> So in all above cases, it is most likely that dialog does not
>>>>> establishes at all and 503 response is treated similar to
>>>>> stateless response. Therefore, a to-tag can be added/replaced
>>>>> before sending it to UAC.
>>>>>
>>>>> Theoretically, kamailio should check and use to-tag from 503
>>>>> response when converting it to 500 response and only create new
>>>>> to-tag if it is absent.
>>>>>
>>>>> References:
>>>>>
>>>>> [1] https://tools.ietf.org/html/rfc3261#section-21.5.4
>>>>>
>>>>> [2]
>>>>> https://tools.ietf.org/html/draft-hilt-sip-correction-503-01#section-4
>>>>>
>>>>>
>>>>> Hope this helps.
>>>>>
>>>>>
>>>>>
>>>>> On Wed, 22 Jul 2020 at 21:08, Henning Westerholt <hw at skalatan.de
>>>>> <mailto:hw at skalatan.de>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>>
>>>>>
>>>>> Apparently, this is the way the code works:
>>>>>
>>>>>
>>>>>
>>>>> t_reply.c:
>>>>>
>>>>> if (relayed_code==503 &&
>>>>> tm_remap_503_500){
>>>>>
>>>>> /* replace a final 503 with a 500:
>>>>>
>>>>> * generate a "FAKE" reply and
>>>>> a new to_tag (for easier
>>>>>
>>>>> * debugging)*/
>>>>>
>>>>>
>>>>>
>>>>> Lets see if maybe others can comment as well. Otherwise you
>>>>> could just open an issue on our tracker, it is probably not
>>>>> that hard to change this.
>>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>> Henning
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Henning Westerholt – https://skalatan.de/blog/
>>>>>
>>>>> Kamailio services – https://gilawa.com <https://gilawa.com/>
>>>>>
>>>>>
>>>>>
>>>>> *From:* sr-users <sr-users-bounces at lists.kamailio.org
>>>>> <mailto:sr-users-bounces at lists.kamailio.org>> *On Behalf Of
>>>>> *Gerry | Rigatta
>>>>> *Sent:* Wednesday, July 22, 2020 8:58 PM
>>>>> *To:* Kamailio (SER) - Users Mailing List
>>>>> <sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>>
>>>>> *Subject:* [SR-Users] bug ? remap_503_500 breaks dialogs
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> I am using Kamailio 5.2.
>>>>>
>>>>>
>>>>>
>>>>> Apparently the remapping of 503 to 500 codes in the tm module
>>>>> does also change the to-tag. This behaviour breaks dialogs
>>>>> with yate and therefore calls hang and the 503 remains
>>>>> unacknowledged. After disabling the 503 to 500 remapping with
>>>>> modparam("tm", "remap_503_500", 0) all works fine again.
>>>>>
>>>>>
>>>>>
>>>>> Changing the to-tag in a dialog seems to contradict RFC3261,
>>>>> or do I see this wrongly?
>>>>>
>>>>>
>>>>> 12<https://tools.ietf.org/html/rfc3261#section-12>Dialogs
>>>>>
>>>>>
>>>>> A dialog is identified at each UA with a dialog ID, which
>>>>> consists of a Call-ID value, a local tag and a remote tag…"
>>>>>
>>>>>
>>>>>
>>>>> Thanks for looking into this.
>>>>>
>>>>>
>>>>>
>>>>> Gerry
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Kamailio (SER) - Users Mailing List
>>>>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Kamailio (SER) - Users Mailing List
>>>>> sr-users at lists.kamailio.org
>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>> --
>>>> Daniel-Constantin Mierla -- www.asipto.com
>>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>>> Funding: https://www.paypal.me/dcmierla
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> --
>> Daniel-Constantin Mierla -- www.asipto.com
>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>> Funding: https://www.paypal.me/dcmierla
>
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200723/0b21d980/attachment.htm>
More information about the sr-users
mailing list