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.
(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*):
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@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@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@93.148.135.54 CSeq: 1 INVITE User-Agent: MacGizmo/2.0.02 (Gizmo-s2n1) Content-Length: 0 CQBM: 244
lorenzo wrote:
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)
Unfortunately, there is no single way SER is handling these things. This depends to a great deal on the config, NAT handling in particular.
This here
SIP/2.0 100 Giving a try
doesn't look like stock SER either.
I am afraid you will have to take this up, presumably, sipphone.com.
Regards, Martin
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@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@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@93.148.135.54 CSeq: 1 INVITE User-Agent: MacGizmo/2.0.02 (Gizmo-s2n1) Content-Length: 0 CQBM: 244
Nils Ohlmeier wrote:
Am 22.08.09 17:50, schrieb lorenzo:
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?
yes, what i was trying to say here is that the app correctly *discovered* the router's public ip through a query to a stun server.
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?
my understanding of the whole nat/sip issue was that, once i forge my REGISTER request with a public ip, then the server need not know the uac is actually residing in a private network. thus, no special actions need to be taken by the server, as it can simply send packets to my router's public ip, and the router will route the packets back to the correct host. as far as ports go, i thought rport solved the issue. if that's the case, then SER shouldn't even need to know i'm behind a NAT. am i correct?
one difference i see is that the response to my app's REGISTER request (rightfully) has no "received" parameter in the VIA field - since the IP packet's source address matches the "sent-by" parameter - but has an rport parameter. could that be the cause of the problem?
(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).)
my username has nothing to do with sip :) excuse my ignorance, but what exactly is asymmetric SIP signaling?
Cheers Nils
thanks a lot for your interest, asymmetric
-
lorenzo -
Martin Hoffmann -
Nils Ohlmeier