Unable to make outbound calls via Metaswitch

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Unable to make outbound calls via Metaswitch

Ekiga General mailing list
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
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list
Reply | Threaded
Open this post in threaded view
|

Re: Unable to make outbound calls via Metaswitch

Eugen Dedu-2
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
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/ekiga-list
>
_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list
Reply | Threaded
Open this post in threaded view
|

Re: Unable to make outbound calls via Metaswitch

Ekiga General mailing list
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 <[hidden email]> 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
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/ekiga-list
>
_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list

_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list
Reply | Threaded
Open this post in threaded view
|

Re: Unable to make outbound calls via Metaswitch

Eugen Dedu-2
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 <[hidden email]>
> 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
>>> [hidden email]
>>> https://mail.gnome.org/mailman/listinfo/ekiga-list
>>>
>> _______________________________________________
>> ekiga-list mailing list
>> [hidden email]
>> https://mail.gnome.org/mailman/listinfo/ekiga-list
>>
>
>
> _______________________________________________
> ekiga-list mailing list
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/ekiga-list
>
_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list