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
