[asterisk-bugs] [JIRA] (ASTERISK-26358) chan_sip: Contact is updated on re-200, but not on re-INVITE

[Joshua Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp updated ASTERISK-26358:
-----------------------------------

    Reviewboard Link: https://gerrit.asterisk.org/3877 https://gerrit.asterisk.org/3878 https://gerrit.asterisk.org/3879 https://gerrit.asterisk.org/3880

> chan_sip: Contact is updated on re-200, but not on re-INVITE
> ------------------------------------------------------------
>
>                 Key: ASTERISK-26358
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26358
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>            Reporter: Walter Doekes
>
> *Problem:* chan_sip does not update a changed Contact from a reINVITE.
> *Result:* when switching IP address mid-call, we can update the RTP
> endpoint and succesfully resume the call on a different host/port, but
> we cannot update the SIP endpoint. That, in turn, makes Asterisk unable
> to hang up the call properly. It tries to send the BYE to the original
> Contact, which is not listening anymore.
> RFC3261, 12.2:
> {quote}
>    Requests within a dialog MAY contain Record-Route and Contact header
>    fields.  However, these requests do not cause the dialog's route set
>    to be modified, although they may modify the remote target URI.
> ...
>    Target refresh requests only update the dialog's remote target URI,
>    and not the route set formed from the Record-Route.
> {quote}
> Ergo, we're free to update the Contact, and when the UAS or UAC changes
> source IP, we need to.
> chan_sip already allows the Contact to be updated if it receives a 200
> \[1\] (acts as UAC), but *not* if it receives an INVITE \[2\] (acts as
> UAS). The latter appears to be an oversight.
> \[1\]:
> {code}
> handle_response_invite
> ...
>         case 18X:
>                 parse_ok_contact(p, req);
> ...
>         case 200:
>                 if (ast_test_flag(&p->flags[0], SIP_OUTGOING)) { /* <-- should always be true */
>                         parse_ok_contact(p, req);
> {code}
> \[2\]:
> {code}
> handle_request_invite
> ...
>                 if (!p->owner) {        /* Not a re-invite */
>                         if (req->debug)
>                                 ast_verbose("Using INVITE request as basis request - %s\n", p->callid);
>                         if (newcall)
>                                 append_history(p, "Invite", "New call: %s", p->callid);
>                         parse_ok_contact(p, req);
>                 } else {        /* Re-invite on existing call */
>                         ast_clear_flag(&p->flags[0], SIP_OUTGOING);     /* This is now an inbound dialog */
> {code}
> *Suggested fix*: always parse_ok_contact() in handle_request_invite,
> not only if this is a *new* dialog ({{!p->owner}}).
> Then, the device which has updated its IP can send a reINVITE as a
> target refresh and any new in-dialog messages from Asterisk -- e.g. a
> BYE from Asterisk -- will get sent to the right destination.



--
This message was sent by Atlassian JIRA
(v6.2#6252)