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 <eugen.d...@univ-fcomte.fr> 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 > > ekiga-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/ekiga-list > > > _______________________________________________ > ekiga-list mailing list > ekiga-list@gnome.org > https://mail.gnome.org/mailman/listinfo/ekiga-list >
_______________________________________________ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
