[Serusers] problems with stun using uas

Nils Ohlmeier lists at ohlmeier.org
Mon Aug 24 09:36:49 CEST 2009


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 at proxy01.sipphone.com>
> From:<sip:asymmetric at proxy01.sipphone.com>;tag=z9hG4bK57274073
> Call-ID: 557402852938 at 93.148.135.54
> CSeq: 2 REGISTER
> Contact:<sip:asymmetric at 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 at proxy01.sipphone.com>;tag=92390300a369f0d75803e369c733575e.50aa
> From:<sip:asymmetric at proxy01.sipphone.com>;tag=z9hG4bK57274073
> Call-ID: 557402852938 at 93.148.135.54
> CSeq: 2 REGISTER
> Contact:<sip:asymmetric at 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 at 93.148.135.54:10251>
> To:<sip:17474492586 at proxy01.sipphone.com>
> From:<sip:17474492586 at proxy01.sipphone.com>;tag=f43be43c
> Call-ID: b1b4a060512d4b0c1250955005 at 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 at proxy01.sipphone.com>;tag=92390300a369f0d75803e369c733575e.c70f
> From:<sip:17474492586 at proxy01.sipphone.com>;tag=f43be43c
> Call-ID: b1b4a060512d4b0c1250955005 at YXN5bW1ldHJpYy5sb2NhbA..
> CSeq: 2 REGISTER
> P-Behind-NAT: Yes
> Contact:<sip:17474492586 at 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 at proxy01.sipphone.com>
> From:<sip:17474492586 at proxy01.sipphone.com>;tag=bc135372
> Call-ID: 88d41c746d51146e1250955219 at 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 at proxy01.sipphone.com>
> To:<sip:17474492586 at proxy01.sipphone.com>;tag=6ae0e759
> From: "asymmetric"<sip:asymmetric at proxy01.sipphone.com>;tag=z9hG4bK90319798
> Call-ID: 593542951976 at 93.148.135.54
> CSeq: 1 INVITE
> User-Agent: MacGizmo/2.0.02 (Gizmo-s2n1)
> Content-Length: 0
> CQBM: 244
>




More information about the sr-users mailing list