24 Aug
2009
24 Aug
'09
3:36 a.m.
Am 22.08.09 17:50, schrieb lorenzo:
hi!
i'm the developer of a sip app that happens to be connecting to a sip
server that's using SER.
i'm having troublewith the way SER handles incoming calls to my
stun-enabled ua (which is placed behind a router)
I have two clients running on the same machine. one is my app, the other
is Gizmo5.
when i make an outgoing call from my app to the user i'm logged in with
in Gizmo5, everything works.
but when i call my app from the Gizmo5 app, sniffing the network
traffic with wireshark, the only thing i see happening is the sip server
sending a 100 Giving a try to the calling ua.
The reason i'm posting this here, is that i know it's not a bug with my
app, since everything works fine when i don't use stun.
Just because your app works without stun does not mean it is bug, or?!
(note that i don't have direct access to ser's
configuration)
this is my app's REGISTER request (note that it has a *public ip*):
Sorry, but if it runs on a public IP, why do you use STUN at all?
Or are you just referring with "have" to the fact that your app "has"
successfully determined the public IP of its router?
The major difference in the messages below which I can spot is the IP
address in the Via header. Gizmo puts its private IP in the Via header,
where yours puts the public IP in the Via header.
SER's NAT support has functions to check the Via header for indications
of a NAT. It might be that your public IP mis-leads these check to
believe that your app does not need NAT traversal support (which it
obviously really does not need if it runs on a public IP anyway). But as
Martin wrote: we do not have access to sipphone's SER config, so we
can't tell you which NAT checks they perform.
My guess is, that your app is the classic example of the wrong usage of
STUN. Your REGISTER request does not contain a single indication any
more that your app is actually running behind a NAT. So how should SER
be able to identify you as being behind a NAT?
(That you are using the rport parameter is not enough, because as your
username already suggests: this is just an indication that you are doing
asymmetric SIP signaling (which is deprecated and totally broken if you
are behind a NAT anyway).)
Cheers
Nils
REGISTER sip:proxy01.sipphone.com SIP/2.0
Via: SIP/2.0/UDP 93.148.135.54:5060;rport;branch=z9hG4bK70207
Max-Forwards: 70
To:<sip:asymmetric@proxy01.sipphone.com>
From:<sip:asymmetric@proxy01.sipphone.com>;tag=z9hG4bK57274073
Call-ID: 557402852938(a)93.148.135.54
CSeq: 2 REGISTER
Contact:<sip:asymmetric@93.148.135.54:5060;transport=udp>
Expires: 3600
User-Agent: mjsip stack 1.6
Authorization: Digest username="asymmetric",
realm="proxy01.sipphone.com", nonce="xxx",
uri="sip:proxy01.sipphone.com", algorithm=md5, response="yyy"
Content-Length: 0
and the response:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 93.148.135.54:5060;rport=12810;branch=z9hG4bK70207
To:
<sip:asymmetric@proxy01.sipphone.com>;tag=92390300a369f0d75803e369c733575e.50aa
From:<sip:asymmetric@proxy01.sipphone.com>;tag=z9hG4bK57274073
Call-ID: 557402852938(a)93.148.135.54
CSeq: 2 REGISTER
Contact:<sip:asymmetric@93.148.135.54:5060;transport=udp>;expires=3600
Content-Length: 0
Gizmo5's app REGISTER request:
REGISTER sip:proxy01.sipphone.com SIP/2.0
Via: SIP/2.0/UDP
192.168.1.100:64064;branch=z9hG4bK-d87543-bbc1e2712d417352-1--d87543-;rport
Max-Forwards: 70
Contact:<sip:17474492586@93.148.135.54:10251>
To:<sip:17474492586@proxy01.sipphone.com>
From:<sip:17474492586@proxy01.sipphone.com>;tag=f43be43c
Call-ID: b1b4a060512d4b0c1250955005@YXN5bW1ldHJpYy5sb2NhbA..
CSeq: 2 REGISTER
Expires: 1800
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
User-Agent: MacGizmo/2.0.02 (Gizmo-s2n1)
Authorization: Digest
username="17474492586",realm="proxy01.sipphone.com",nonce="xxx",uri="sip:proxy01.sipphone.com",response="yyy",algorithm=MD5
Content-Length: 0
and response:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.1.100:64064;branch=z9hG4bK-d87543-bbc1e2712d417352-1--d87543-;rport=10251;received=93.148.135.54
To:
<sip:17474492586@proxy01.sipphone.com>;tag=92390300a369f0d75803e369c733575e.c70f
From:<sip:17474492586@proxy01.sipphone.com>;tag=f43be43c
Call-ID: b1b4a060512d4b0c1250955005@YXN5bW1ldHJpYy5sb2NhbA..
CSeq: 2 REGISTER
P-Behind-NAT: Yes
Contact:<sip:17474492586@93.148.135.54:10251>;expires=1800
Content-Length: 0
in the second case, the client gets the P-Behind-NAT flag set to Yes,
and for a good reason.
But then why is this all i get when trying to call the first ua? :
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP
192.168.1.100:64064;branch=z9hG4bK-d87543-7fb07a028db5c137-1--d87543-;rport=10251;received=93.148.135.54
To:<sip:asymmetric@proxy01.sipphone.com>
From:<sip:17474492586@proxy01.sipphone.com>;tag=bc135372
Call-ID: 88d41c746d51146e1250955219@YXN5bW1ldHJpYy5sb2NhbA..
CSeq: 1 INVITE
P-Behind-NAT: Yes
Content-Length: 0
whereas the inverse works:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 198.65.166.131;branch=z9hG4bKf3b1.bc014575.0
Via: SIP/2.0/UDP 93.148.135.54:5060;rport=13171;branch=z9hG4bK82654
Record-Route:<sip:198.65.166.131;lr;ftag=z9hG4bK90319798>
Contact:<sip:17474492586@proxy01.sipphone.com>
To:<sip:17474492586@proxy01.sipphone.com>;tag=6ae0e759
From:
"asymmetric"<sip:asymmetric@proxy01.sipphone.com>;tag=z9hG4bK90319798
Call-ID: 593542951976(a)93.148.135.54
CSeq: 1 INVITE
User-Agent: MacGizmo/2.0.02 (Gizmo-s2n1)
Content-Length: 0
CQBM: 244