[SR-Users] bug ? remap_503_500 breaks dialogs
Daniel-Constantin Mierla
miconda at gmail.com
Thu Jul 23 16:14:40 CEST 2020
Hello,
I am not sure what variant you want to advocate with this
message/excerpt from RFC, but it is about "forwarded response to a
**request that contains a To tag**", and the request (the initial
INVITE) has no To tag.
For replies corresponding to requests within dialog, the to-tag has to
be preserved and I think kamailio does it even if it has to generate a
reply (e.g., timeout on re-INVITE routing).
Cheers,
Daniel
On 23.07.20 14:53, Henning Westerholt wrote:
>
> Hello,
>
>
>
> just to add to the RFC quoted below: this is referring to 1xx or 2xx
> responses. But later on, in the section, the RFC seems to be quite clear:
>
>
>
> If the only
>
> response that was received is a 503, the proxy SHOULD generate
>
> a 500 response and forward that upstream.
>
>
>
> A proxy MUST NOT modify the To tag in any forwarded response to
>
> a request that contains a To tag.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> *From:*sr-users <sr-users-bounces at lists.kamailio.org> *On Behalf Of
> *Gerry | Rigatta
> *Sent:* Thursday, July 23, 2020 2:41 PM
> *To:* miconda at gmail.com
> *Cc:* Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
> *Subject:* Re: [SR-Users] bug ? remap_503_500 breaks dialogs
>
>
>
> 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:111100791456321475 at 13.23.9.94:5060> SIP/2.0..Max-Forwards: 19.
>
> .P-Asserted-Identity: tel:+4867777777..Via: <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: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
> <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: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 <mailto:sr-users at lists.kamailio.org>
>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
>
> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com/>
>
> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://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 <http://www.asipto.com/>
>
> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://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/65284286/attachment.htm>
More information about the sr-users
mailing list