Re: Unable to make outbound calls via Metaswitch

Opal changes often its API and Ekiga does not work with latest opal.  A 
better idea is that you try the development branch of Ekiga, which uses 
a much more version of opal, see "master/trunk (unstable branch)" at 
http://wiki.ekiga.org/index.php/Download_Ekiga_sources.

On 13/10/2018 02:36, Sean via ekiga-list wrote:
> 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
>>
> 
> 
> _______________________________________________
> ekiga-list mailing list
> [email protected]
> https://mail.gnome.org/mailman/listinfo/ekiga-list
>