Hi Alex, I did try removing the records routes, but I still received the '404 Not Here' response from the Server; I thought maybe it was an issue with the transport type, but I tried both UDP and TCP...with no luck. The BYE is definitely being sent to the correct Server and Port, this is why I thought it had some weird thing to do with the Record Route.
-----Original Message----- From: sr-users <[email protected]> On Behalf Of Alex Balashov Sent: Wednesday, September 19, 2018 10:29 AM To: Kamailio (SER) - Users Mailing List <[email protected]> Subject: Re: [SR-Users] re- double record route Record-Routes are present only in dialog-forming - that is to say, initial - INVITEs and their replies. A BYE is an in-dialog request and should have a Route set constructed from those RRs, but should not contain any RRs. On Wed, Sep 19, 2018 at 02:26:27PM +0000, Wilkins, Steve wrote: > Hi Mojtaba, > > I will try to explain the situation a little better. > > A softphone sends an 'INVITE' to a WebRTC Client, the call comes to Kamailio, > which then forwards it to Asterisk, and then Asterisk to the WebRTC Client. > The softphone is connected to a Providers Server (IP 10.20.5.5) and it sends > the Record Routes of (10.20.5.5;lr=on;r2=on), and > (10.20.5.5;transport=tcp;lr=on;r2=on) in the initial 'INVITE'. The problem > is, if the WebRTC client initiates the 'BYE', when Kamilio forwards the > 'BYE', the Records Route's form the initial 'INVITE' are missing and the > Provider ( softphone) returns "404 Not Here". > > Thank you, > -Steve > > -----Original Message----- > From: sr-users <[email protected]> On Behalf Of > Mojtaba > Sent: Monday, September 17, 2018 2:51 AM > To: Kamailio (SER) - Users Mailing List <[email protected]> > Subject: Re: [SR-Users] re- double record route > > Your response confused me, But let me describe some rules. > The BYE request is used the record route header in it's INVITE request in > Dialogs. Then when UE want to send BYE, It add a all record route in BYE > message. > On other hand, the SIP stack that UE is used, may be different, So you must > be sure about it. You have two choice: Diving to SIP stack in UE (doesn't > good choice), and use the power of Kamailio. > For example, Use Path header to save the second record route (or your > favourite record route) in INVITE message, then if the UE send BYE message > which the Path header in, use this Path header for relaying in kamailio. > As i said, It is needed to paste the log for better understanding. > With Regards.Mojtaba > On Mon, Sep 17, 2018 at 2:17 AM Wilkins, Steve <[email protected]> wrote: > > > > Hi Mojtaba, > > > > But when I send the 'BYE' doesn't the double Record-Route from the 'INVITE' > > (from IOS) need to be there, so that IOS can find it's Proxies and complete > > the transaction and send back a '200 OK'? > > > > Thank you, > > > > -----Original Message----- > > From: sr-users <[email protected]> On Behalf Of > > Mojtaba > > Sent: Sunday, September 16, 2018 12:47 PM > > To: Kamailio (SER) - Users Mailing List > > <[email protected]> > > Subject: Re: [SR-Users] re- double record route > > > > What do you mean exactly? Do you mean the INVITE is received from IOS has > > double record route? If this true, the Kamailio remove all record route > > when the INVITE request is received by default. In other words, Kamailio > > remove all record routes form downstream or upstream in INVITE request by > > default. > > You should paste a simple wireshark to solve it as soon. > > With Regards.Mojtaba > > On Sun, Sep 16, 2018 at 6:10 PM Wilkins, Steve <[email protected]> wrote: > > > > > > Hi Henning, > > > > > > > > > > > > Yes I do have that enabled. What is happening is that one of the > > > providers on IOS is sending a double record route on the INVITE, but it > > > is getting lost somewhere so when I send a 'BYE', I get a "404 not here". > > > When I look at the SIP message I see only one of the record routes from > > > the INVITE, therefore my assumption is, this is what is causing the 404, > > > because everything else looks good. > > > > > > > > > > > > _______________________________________________ > > > Kamailio (SER) - Users Mailing List [email protected] > > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > > > > > -- > > --Mojtaba Esfandiari.S > > > > _______________________________________________ > > Kamailio (SER) - Users Mailing List > > [email protected] > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > _______________________________________________ > > Kamailio (SER) - Users Mailing List > > [email protected] > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > -- > --Mojtaba Esfandiari.S > > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
