Re: Unable to make outbound calls via Metaswitch
Sean via ekiga-list <[email protected]> Fri, 12 Oct 2018 16:36:55 -0800
| Newsgroups | gmane.comp.gnome.apps.gnomemeeting |
|---|---|
| Message-ID | <CAOLitW7L8ZQB=pXnpF=_jQEtb9BO5-JWiB4PupPJHamjpojCgw@mail.gmail.com> |
--===============5747606820469149202== Content-Type: multipart/alternative; boundary="000000000000588c810578116796" --000000000000588c810578116796 Content-Type: text/plain; charset="UTF-8" Thanks Eugen, that gives me some place to look next. I'll go build the latest Opal and go from there. -Sean On Fri, Oct 12, 2018 at 12:34 PM Eugen Dedu <[email protected]> wrote: > Hi Sean, > > Thank you for your analysis. > > Unfortunately, the only way to change this behaviour is to modify the > source code of opal, which is used by ekiga and takes care of SIP. > > Perhaps this bug has been fixed in opal since Ekiga was released, but > currently there is no one working on Ekiga. > > Best regards, > Eugen > http://eugen.dedu.free.fr > > > On 12/10/2018 20:46, Sean via ekiga-list wrote: > > New to Ekiga and trying to find a Linux client that I can use with my > > company's SIP gateway (MetaSwitch). > > > > Inbound calls work ok. > > > > Outbound calls though do not work. After the initial INVITE our switch is > > setup to answer back a '401 Unauthorized' after an initial INVITE. The > > expected response would be that the client would send a new INVITE > without > > reusing the TO tag provided in the 'Status 100 Trying' message. When the > > second INVITE from Ekiga is sent, it provides authentication but it > reuses > > the TO Tag. > > > > Calling# 907550AAAA > > Called# 907632BBBB > > OS: Ubuntu Mate 17.x > > Ekiga v4.0.1 > > SIP Gateway: Metaswitch > > > > INVITE sip:907632BBBB@metaswitch SIP/2.0 > > CSeq: 1 INVITE > > v: SIP/2.0/UDP > > HOME_IP:5060;branch=z9hG4bKe892599d-a9cc-e811-95ba-b88a60eb21bb;rport > > User-Agent: Ekiga/4.0.1 > > f: "Sean" <sip:907550AAAA@metaswitch > >> ;tag=72d94c9d-a9cc-e811-95ba-b88a60eb21bb > > i: 7aea4c9d-a9cc-e811-95ba-b88a60eb21bb@laptop > > k: 100rel,replaces > > t: <sip:907632BBBB@metaswitch> > > m: "Sean" <sip:907550AAAA@HOME_IP:5060> > > Allow: > > > INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK > > l: 872 > > c: application/sdp > > Max-Forwards: 70 > > > > SIP/2.0 100 Trying > > CSeq: 1 INVITE > > Via: SIP/2.0/UDP > > > HOME_IP:5060;received=HOME_IP;rport=5060;branch=z9hG4bKe892599d-a9cc-e811-95ba-b88a60eb21bb > > Server: SIP/2.0 > > From: "Sean" <sip:907550AAAA@metaswitch > >> ;tag=72d94c9d-a9cc-e811-95ba-b88a60eb21bb > > Call-ID: 7aea4c9d-a9cc-e811-95ba-b88a60eb21bb@laptop > > To: <sip:907632BBBB@metaswitch>;tag=sip+1+37370041+7a4ac210 > > Content-Length: 0 > > > > SIP/2.0 401 Unauthorized > > CSeq: 1 INVITE > > Via: SIP/2.0/UDP > > > HOME_IP:5060;received=HOME_IP;rport=5060;branch=z9hG4bKe892599d-a9cc-e811-95ba-b88a60eb21bb > > Server: DC-SIP/2.0 > > From: "Sean" <sip:907550AAAA@metaswitch > >> ;tag=72d94c9d-a9cc-e811-95ba-b88a60eb21bb > > Call-ID: 7aea4c9d-a9cc-e811-95ba-b88a60eb21bb@laptop > > Supported: resource-priority, siprec, 100rel > > Organization: Metaswitch Networks > > To: <sip:907632BBBB@metaswitch>;tag=sip+1+37370041+7a4ac210 > > Contact: <sip:METASWITCH_IP:5060> > > Content-Length: 0 > > WWW-Authenticate: Digest > > > realm="metaswitch",nonce="47ef533f87db",stale=false,algorithm=MD5,qop="auth" > > > > ACK sip:907632BBBB@metaswitch SIP/2.0 > > CSeq: 1 ACK > > Via: SIP/2.0/UDP > > HOME_IP:5060;branch=z9hG4bKe892599d-a9cc-e811-95ba-b88a60eb21bb;rport > > From: "Sean" <sip:907550AAAA@metaswitch > >> ;tag=72d94c9d-a9cc-e811-95ba-b88a60eb21bb > > Call-ID: 7aea4c9d-a9cc-e811-95ba-b88a60eb21bb@laptop > > To: <sip:907632BBBB@metaswitch>;tag=sip+1+37370041+7a4ac210 > > Content-Length: 0 > > Max-Forwards: 70 > > > > INVITE sip:907632BBBB@metaswitch SIP/2.0 > > CSeq: 2 INVITE > > v: SIP/2.0/UDP > > HOME_IP:5060;branch=z9hG4bK82d69d9e-a9cc-e811-95ba-b88a60eb21bb;rport > > User-Agent: Ekiga/4.0.1 > > Authorization: Digest username="907550AAAA", realm="metaswitch", > > nonce="47ef533f87db", uri="sip:907632BBBB@metaswitch", algorithm=MD5, > > response="x", cnonce="c87c9d9e-a9cc-e811-95ba-b88a60eb21bb", nc=00000001, > > qop=auth > > f: "Sean" <sip:907550AAAA@metaswitch > >> ;tag=72d94c9d-a9cc-e811-95ba-b88a60eb21bb > > i: 7aea4c9d-a9cc-e811-95ba-b88a60eb21bb@laptop > > k: 100rel,replaces > > t: <sip:907632BBBB@metaswitch>;tag=sip+1+37370041+7a4ac210 > > m: "Sean" <sip:907550AAAA@HOME_IP:5060> > > Allow: > > > INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK > > l: 872 > > c: application/sdp > > Max-Forwards: 70 > > > > SIP/2.0 481 Call/Transaction Does Not Exist > > CSeq: 2 INVITE > > Via: SIP/2.0/UDP > > > HOME_IP:5060;received=HOME_IP;rport=5060;branch=z9hG4bK82d69d9e-a9cc-e811-95ba-b88a60eb21bb > > Server: SIP/2.0 > > From: "Sean" <sip:907550AAAA@metaswitch > >> ;tag=72d94c9d-a9cc-e811-95ba-b88a60eb21bb > > Call-ID: 7aea4c9d-a9cc-e811-95ba-b88a60eb21bb@laptop > > To: <sip:907632BBBB@metaswitch>;tag=sip+1+37370041+7a4ac210 > > Warning: 399 sip "The specified dialog does not exist" > > Content-Length: 0 > > > > ACK sip:907632BBBB@metaswitch SIP/2.0 > > CSeq: 2 ACK > > Via: SIP/2.0/UDP > > HOME_IP:5060;branch=z9hG4bK82d69d9e-a9cc-e811-95ba-b88a60eb21bb;rport > > Authorization: Digest username="907550AAAA", realm="metaswitch", > > nonce="47ef533f87db", uri="sip:907632BBBB@metaswitch", algorithm=MD5, > > response="42a186ed75e5f3629bd1183887447e44", > > cnonce="c87c9d9e-a9cc-e811-95ba-b88a60eb21bb", nc=00000002, qop=auth > > From: "Sean" <sip:907550AAAA@metaswitch > >> ;tag=72d94c9d-a9cc-e811-95ba-b88a60eb21bb > > Call-ID: 7aea4c9d-a9cc-e811-95ba-b88a60eb21bb@laptop > > To: <sip:907632BBBB@metaswitch>;tag=sip+1+37370041+7a4ac210 > > Content-Length: 0 > > Max-Forwards: 70 > > > > > > When trouble shooting this with our VOIP engineers, they pointed me to > RFC > > 3261 8.1.1.2 > > > > A request outside of a dialog MUST NOT contain a To tag; the tag in > > the To field of a request identifies the peer of the dialog. Since > > no dialog is established, no tag is present. > > > > After Metaswitch answers with the '401 Unauthorized', it deletes the > > reference to that TO tag and when Ekiga reuses it, Metaswitch can't match > > it to any current session. > > > > I've captured packets using Linphone and it behaves in the way our > > Metaswitch is expecting, to not include a TO tag when sending the second > > INVITE that includes authentication. > > > > Is there a way Ekiga's behavior can be changed locally via configuration > > file to either: > > > > 1. Not include the TO tag on the second INVITE > > 2. Include Authentication on the initial INVITE > > > > Is/could this be a feature request that I need to submit vs. a bug? > > > > Thanks. > > > > -Sean > > > > > > _______________________________________________ > > ekiga-list mailing list > > [email protected] > > https://mail.gnome.org/mailman/listinfo/ekiga-list > > > _______________________________________________ > ekiga-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/ekiga-list > --000000000000588c810578116796 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Thanks Eugen, that gives me some place to look next. I'= ;ll go build the latest Opal and go from there.<div><br></div><div>-Sean</d= iv></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Oct 12, 20= 18 at 12:34 PM Eugen Dedu <<a href=3D"mailto:[email protected]">= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex">Hi Sean,<br> <br> Thank you for your analysis.<br> <br> Unfortunately, the only way to change this behaviour is to modify the <br> source code of opal, which is used by ekiga and takes care of SIP.<br> <br> Perhaps this bug has been fixed in opal since Ekiga was released, but <br> currently there is no one working on Ekiga.<br> <br> Best regards,<br> Eugen<br> <a href=3D"http://eugen.dedu.free.fr" rel=3D"noreferrer" target=3D"_blank">= http://eugen.dedu.free.fr</a><br> <br> <br> On 12/10/2018 20:46, Sean via ekiga-list wrote:<br> > New to Ekiga and trying to find a Linux client that I can use with my<= br> > company's SIP gateway (MetaSwitch).<br> > <br> > Inbound calls work ok.<br> > <br> > Outbound calls though do not work. After the initial INVITE our switch= is<br> > setup to answer back a '401 Unauthorized' after an initial INV= ITE. The<br> > expected response would be that the client would send a new INVITE wit= hout<br> > reusing the TO tag provided in the 'Status 100 Trying' message= . When the<br> > second INVITE from Ekiga is sent, it provides authentication but it re= uses<br> > the TO Tag.<br> > <br> > Calling# 907550AAAA<br> > Called#=C2=A0 907632BBBB<br> > OS: Ubuntu Mate 17.x<br> > Ekiga v4.0.1<br> > SIP Gateway: Metaswitch<br> > <br> > INVITE sip:907632BBBB@metaswitch SIP/2.0<br> > CSeq: 1 INVITE<br> > v: SIP/2.0/UDP<br> > HOME_IP:5060;branch=3Dz9hG4bKe892599d-a9cc-e811-95ba-b88a60eb21bb;rpor= t<br> > User-Agent: Ekiga/4.0.1<br> > f: "Sean" <sip:907550AAAA@metaswitch<br> >> ;tag=3D72d94c9d-a9cc-e811-95ba-b88a60eb21bb<br> > i: 7aea4c9d-a9cc-e811-95ba-b88a60eb21bb@laptop<br> > k: 100rel,replaces<br> > t: <sip:907632BBBB@metaswitch><br> > m: "Sean" <sip:907550AAAA@HOME_IP:5060><br> > Allow:<br> > INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING= ,PRACK<br> > l: 872<br> > c: application/sdp<br> > Max-Forwards: 70<br> > <br> > SIP/2.0 100 Trying<br> > CSeq: 1 INVITE<br> > Via: SIP/2.0/UDP<br> > HOME_IP:5060;received=3DHOME_IP;rport=3D5060;branch=3Dz9hG4bKe892599d-= a9cc-e811-95ba-b88a60eb21bb<br> > Server: SIP/2.0<br> > From: "Sean" <sip:907550AAAA@metaswitch<br> >> ;tag=3D72d94c9d-a9cc-e811-95ba-b88a60eb21bb<br> > Call-ID: 7aea4c9d-a9cc-e811-95ba-b88a60eb21bb@laptop<br> > To: <sip:907632BBBB@metaswitch>;tag=3Dsip+1+37370041+7a4ac210<br= > > Content-Length: 0<br> > <br> > SIP/2.0 401 Unauthorized<br> > CSeq: 1 INVITE<br> > Via: SIP/2.0/UDP<br> > HOME_IP:5060;received=3DHOME_IP;rport=3D5060;branch=3Dz9hG4bKe892599d-= a9cc-e811-95ba-b88a60eb21bb<br> > Server: DC-SIP/2.0<br> > From: "Sean" <sip:907550AAAA@metaswitch<br> >> ;tag=3D72d94c9d-a9cc-e811-95ba-b88a60eb21bb<br> > Call-ID: 7aea4c9d-a9cc-e811-95ba-b88a60eb21bb@laptop<br> > Supported: resource-priority, siprec, 100rel<br> > Organization: Metaswitch Networks<br> > To: <sip:907632BBBB@metaswitch>;tag=3Dsip+1+37370041+7a4ac210<br= > > Contact: <sip:METASWITCH_IP:5060><br> > Content-Length: 0<br> > WWW-Authenticate: Digest<br> > realm=3D"metaswitch",nonce=3D"47ef533f87db",stale= =3Dfalse,algorithm=3DMD5,qop=3D"auth"<br> > <br> > ACK sip:907632BBBB@metaswitch SIP/2.0<br> > CSeq: 1 ACK<br> > Via: SIP/2.0/UDP<br> > HOME_IP:5060;branch=3Dz9hG4bKe892599d-a9cc-e811-95ba-b88a60eb21bb;rpor= t<br> > From: "Sean" <sip:907550AAAA@metaswitch<br> >> ;tag=3D72d94c9d-a9cc-e811-95ba-b88a60eb21bb<br> > Call-ID: 7aea4c9d-a9cc-e811-95ba-b88a60eb21bb@laptop<br> > To: <sip:907632BBBB@metaswitch>;tag=3Dsip+1+37370041+7a4ac210<br= > > Content-Length: 0<br> > Max-Forwards: 70<br> > <br> > INVITE sip:907632BBBB@metaswitch SIP/2.0<br> > CSeq: 2 INVITE<br> > v: SIP/2.0/UDP<br> > HOME_IP:5060;branch=3Dz9hG4bK82d69d9e-a9cc-e811-95ba-b88a60eb21bb;rpor= t<br> > User-Agent: Ekiga/4.0.1<br> > Authorization: Digest username=3D"907550AAAA", realm=3D"= ;metaswitch",<br> > nonce=3D"47ef533f87db", uri=3D"sip:907632BBBB@metaswitc= h", algorithm=3DMD5,<br> > response=3D"x", cnonce=3D"c87c9d9e-a9cc-e811-95ba-b88a6= 0eb21bb", nc=3D00000001,<br> > qop=3Dauth<br> > f: "Sean" <sip:907550AAAA@metaswitch<br> >> ;tag=3D72d94c9d-a9cc-e811-95ba-b88a60eb21bb<br> > i: 7aea4c9d-a9cc-e811-95ba-b88a60eb21bb@laptop<br> > k: 100rel,replaces<br> > t: <sip:907632BBBB@metaswitch>;tag=3Dsip+1+37370041+7a4ac210<br> > m: "Sean" <sip:907550AAAA@HOME_IP:5060><br> > Allow:<br> > INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING= ,PRACK<br> > l: 872<br> > c: application/sdp<br> > Max-Forwards: 70<br> > <br> > SIP/2.0 481 Call/Transaction Does Not Exist<br> > CSeq: 2 INVITE<br> > Via: SIP/2.0/UDP<br> > HOME_IP:5060;received=3DHOME_IP;rport=3D5060;branch=3Dz9hG4bK82d69d9e-= a9cc-e811-95ba-b88a60eb21bb<br> > Server: SIP/2.0<br> > From: "Sean" <sip:907550AAAA@metaswitch<br> >> ;tag=3D72d94c9d-a9cc-e811-95ba-b88a60eb21bb<br> > Call-ID: 7aea4c9d-a9cc-e811-95ba-b88a60eb21bb@laptop<br> > To: <sip:907632BBBB@metaswitch>;tag=3Dsip+1+37370041+7a4ac210<br= > > Warning: 399 sip "The specified dialog does not exist"<br> > Content-Length: 0<br> > <br> > ACK sip:907632BBBB@metaswitch SIP/2.0<br> > CSeq: 2 ACK<br> > Via: SIP/2.0/UDP<br> > HOME_IP:5060;branch=3Dz9hG4bK82d69d9e-a9cc-e811-95ba-b88a60eb21bb;rpor= t<br> > Authorization: Digest username=3D"907550AAAA", realm=3D"= ;metaswitch",<br> > nonce=3D"47ef533f87db", uri=3D"sip:907632BBBB@metaswitc= h", algorithm=3DMD5,<br> > response=3D"42a186ed75e5f3629bd1183887447e44",<br> > cnonce=3D"c87c9d9e-a9cc-e811-95ba-b88a60eb21bb", nc=3D000000= 02, qop=3Dauth<br> > From: "Sean" <sip:907550AAAA@metaswitch<br> >> ;tag=3D72d94c9d-a9cc-e811-95ba-b88a60eb21bb<br> > Call-ID: 7aea4c9d-a9cc-e811-95ba-b88a60eb21bb@laptop<br> > To: <sip:907632BBBB@metaswitch>;tag=3Dsip+1+37370041+7a4ac210<br= > > Content-Length: 0<br> > Max-Forwards: 70<br> > <br> > <br> > When trouble shooting this with our VOIP engineers, they pointed me to= RFC<br> > 3261 8.1.1.2<br> > <br> > A request outside of a dialog MUST NOT contain a To tag; the tag in<br= > >=C2=A0 =C2=A0 =C2=A0the To field of a request identifies the peer of th= e dialog.=C2=A0 Since<br> >=C2=A0 =C2=A0 =C2=A0no dialog is established, no tag is present.<br> > <br> > After Metaswitch answers with the '401 Unauthorized', it delet= es the<br> > reference to that TO tag and when Ekiga reuses it, Metaswitch can'= t match<br> > it to any current session.<br> > <br> > I've captured packets using Linphone and it behaves in the way our= <br> > Metaswitch is expecting, to not include a TO tag when sending the seco= nd<br> > INVITE that includes authentication.<br> > <br> > Is there a way Ekiga's behavior can be changed locally via configu= ration<br> > file to either:<br> > <br> >=C2=A0 =C2=A0 =C2=A0 1. Not include the TO tag on the second INVITE<br> >=C2=A0 =C2=A0 =C2=A0 2. Include Authentication on the initial INVITE<br= > > <br> > Is/could this be a feature request that I need to submit vs. a bug?<br= > > <br> > Thanks.<br> > <br> > -Sean<br> > <br> > <br> > _______________________________________________<br> > ekiga-list mailing list<br> > <a href=3D"mailto:[email protected]" target=3D"_blank">ekiga-list@g= nome.org</a><br> > <a href=3D"https://mail.gnome.org/mailman/listinfo/ekiga-list" rel=3D"= noreferrer" target=3D"_blank">https://mail.gnome.org/mailman/listinfo/ekiga= -list</a><br> > <br> _______________________________________________<br> ekiga-list mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">ekiga-list@gnome.= org</a><br> <a href=3D"https://mail.gnome.org/mailman/listinfo/ekiga-list" rel=3D"noref= errer" target=3D"_blank">https://mail.gnome.org/mailman/listinfo/ekiga-list= </a><br> </blockquote></div> --000000000000588c810578116796-- --===============5747606820469149202== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ekiga-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/ekiga-list --===============5747606820469149202==--